[Feat] Add Cloudflare AI Gateway and Workers AI model providers - #3242
pridemusvaire wants to merge 2 commits into
Conversation
…on the catalog architecture. Operators connect one Cloudflare token, account, and gateway id (AI Gateway) or token and account (Workers AI); OpenCode registers both providers in full, the inference gateway injects the cf-aig-gateway-id header and rewrites Workers AI catalog slugs onto Cloudflare's /ai/v1 surface, and non-task helpers reuse the same registration so configured reasoning applies.
…s. R_MODEL_ENV_KEYS adds custom provider credentials; it does not replace the catalog-derived set, so a Cloudflare model still forwards its required account and gateway values to helper inference when custom key names are configured.
|
Fixed in 71d2ce7. R_MODEL_ENV_KEYS was replacing the catalog-derived provider env keys at the runtime resolver (packages/db resolveProviderKeyNames), unlike every forwarder which unions them; selected catalog models now keep their own env keys alongside custom names, so the required Cloudflare account and gateway values reach helper inference. Covered by a new packages/db test. |
|
@roomote-community please review this pull request again and flag anything outstanding |
Re-reviewing the current head, including the Re-reviewing the current head. Findings, if any, will be posted directly on the pull request. |
|
No outstanding code issues found at Reply anytime · Open in Roomote |
What
Adds Cloudflare AI Gateway and Cloudflare Workers AI as built-in task-model providers on develop's catalog-driven provider architecture.
Env vars:
CLOUDFLARE_AI_GATEWAY_API_TOKEN,CLOUDFLARE_AI_GATEWAY_ACCOUNT_ID,CLOUDFLARE_AI_GATEWAY_ID(AI Gateway),CLOUDFLARE_WORKERS_AI_API_TOKEN,CLOUDFLARE_WORKERS_AI_ACCOUNT_ID(Workers AI).The port
packages/types/src/model-provider-config.ts): twoSETUP_MODEL_PROVIDER_CATALOGentries following the Azure AI Foundry pattern (additionalEnvFieldsfor account id and gateway id,authKind: 'api-key'), plus both ids inENABLED_DIRECT_TASK_MODEL_PROVIDER_IDS. Credential env-var forwarding derives from the catalog.packages/types/src/cloudflare-opencode-provider.ts, following thebedrock-opencode-provider.ts/kimi-for-coding-opencode-provider.tspattern): neither provider depends on OpenCode's models.dev catalog; OpenCode gets@ai-sdk/openai-compatible, the/accounts/<id>/ai/v1base URL, the key, and (AI Gateway) thecf-aig-gateway-idheader. Wired into the task worker (agent-home.ts) and the non-task helper runtime (opencode-runtime.ts), including the operator-suppliedOPENCODE_CONFIG_CONTENTpath where reasoning merges before registrations onto the rewritten model id.apps/api):requiredHeaderson the gateway provider schema injectscf-aig-gateway-idfrom the deployment env (identity-pattern validated); the request body'smodelfield is rewritten so models.dev'sworkers-ai/@cf/...slug reaches Cloudflare as@cf/....@roomote/types(rewriteCloudflareOpenCodeModelIdand friends) so task, helper, and gateway paths all address Cloudflare with the same id.Supersedes
#3015 and #2809, which were built on the pre-catalog provider registration architecture and now conflict with develop. Their review findings (missing Cloudflare registration under operator config content, reasoning merged under the un-rewritten id) are covered here, with tests.
Verified
packages/types: 157 tests (incl. the newcloudflare-opencode-providersuite) - passpackages/cloud-agents: 143 tests (opencode-runtime, non-task-provider-usage) - passapps/worker: 93 agent-home tests - passapps/api: 80 inference-gateway tests - passapps/web: 59 + 31 + 31 tests (task-models lookup, models-dev, setup docs) - passpnpm exec turbo check-types: 27/27 packages cleanpnpm lint:fast+pnpm exec oxlint --deny-warnings: cleangitleaks detect: no leaks