feat(providers): add OpenCode Zen gateway as a declarative provider - #10939
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3018cf5a7c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0eba471176
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| "dynamic_models": false, | ||
| "model_doc_link": "https://opencode.ai/docs/zen", | ||
| "preserves_thinking": true, | ||
| "models": [ |
There was a problem hiding this comment.
Include all Zen chat-completions models
Because dynamic_models is false, fetch_supported_models returns only this static array, so documented OpenCode Zen /chat/completions models that are not listed here are undiscoverable in goose. I checked the current Zen docs and /zen/v1/models payload: compatible models such as big-pickle, laguna-s-2.1-free, ling-3.0-flash-free, longcat-2.0-free, north-mini-code-free, nemotron-3-ultra-free, and glm-5 are served on the same OpenAI-compatible endpoint but will not appear in model selection or inventory refresh unless users manually type them.
Useful? React with 👍 / 👎.
0eba471 to
5dcef55
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5dcef5541a
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| {"name": "glm-5.1", "context_limit": 204800}, | ||
| {"name": "deepseek-v4-pro", "context_limit": 1000000}, | ||
| {"name": "deepseek-v4-flash", "context_limit": 1000000}, | ||
| {"name": "deepseek-v4-flash-free", "context_limit": 1000000}, |
There was a problem hiding this comment.
Correct the free Flash context limit
For deepseek-v4-flash-free, this declares a 1,000,000-token window even though the bundled canonical record specifies 200,000 (canonical_models.json:112540-112542); other new entries such as Kimi K3 and MiniMax M3 also disagree with that catalog. Canonical materialization corrects normal requests, but the CLI model-switch path reads metadata().known_models directly (crates/goose-cli/src/session/mod.rs:955-969), so switching from a model with a 200k–1m context to this model suppresses the smaller-window/compaction warning. Align the declared limits with the canonical records.
Useful? React with 👍 / 👎.
|
Rebased onto Verification after rebase
|
OpenCode Go (/zen/go/v1) already ships as opencode_go.json, but the main Zen gateway (https://opencode.ai/zen/v1) was missing a bundled definition (see issue aaif-goose#8381). Add opencode_zen.json following the same pattern, with catalog_provider_id opencode matching the canonical registry. Lists the models Zen serves over /chat/completions (DeepSeek, GLM, Kimi, MiniMax, Qwen, MiMo); GPT/Grok (/responses), Claude (/messages) and Gemini (Google wire format) use other endpoints and are excluded so the OpenAI-compatible engine only surfaces models it can serve.
map_provider_name aliased opencode_go to opencode-go but had no arm for opencode_zen, so canonicalization looked up opencode_zen/<model> instead of opencode/<model> and missed the 85 real opencode/* records (context limits, costs, reasoning). Add opencode_zen -> opencode, mirroring opencode_go, plus a parallel test.
5dcef55 to
fe06145
Compare
|
🤖 Rebased |
michaelneale
left a comment
There was a problem hiding this comment.
thanks @vincenzopalazzo
|
@michaelneale Thanks for merging. I am wondering if we should take a different approach here on adding models and have some sort of skill built into Goose to set up a model? I need to be honest, it is overwhelming now for non-tech people choose the right provider :) |
Summary
https://opencode.ai/zen/v1) as a bundled declarative provider —opencode_zen— alongside the existingopencode_go.opencode_go.jsonpattern;catalog_provider_id: "opencode"matches the canonical registry entry./chat/completionsendpoint.Context
Issue #8381 ("Add OpenCode Go/OpenCode Zen to provider configuration") was closed stating both shipped in #6934, but only OpenCode Go (
/zen/go/v1) ever received a bundled declarative definition (opencode_go.json). The main Zen gateway never got one, so it was only reachable via manual custom-provider setup. This fills that gap.Design choice: static curated model list (
dynamic_models: false)The Zen gateway serves models over multiple wire formats:
/chat/completions— DeepSeek, MiniMax, GLM, Kimi, MiMo (OpenAI-compatible) ✓ included/responses— GPT, Grok/messages— Claude, QwenThe declarative
openaiengine only speaks/chat/completions. Withdynamic_models: true,fetch_supported_modelswould hit/v1/modelsand surface all 85 models — including GPT/Claude/Gemini — which would then fail with a wire-format mismatch. So this lists only the documented/chat/completionsmodels. (If maintainers confirm Zen's/chat/completionsnormalizes all models, this can be flipped todynamic_models: true.)Verification
cargo test -p goose-providers --lib declarative→ 10 passed, incl.expose_declarative_providers_enumerates_all_bundled_json_filesandall_bundled_providers_are_validcargo clippy -p goose-providers --all-targets -- -D warnings→ cleanMaintainer-directed; no separate Ready issue (context issue #8381 is closed).