Repository navigation
fix(models): route Gemini to the Google API on every vendor - #260
ltmoerdani merged 1 commit into
Conversation
Gemini models served by OpenCode Go (gemini-4-argon-contributor) failed every request with 400 "Model does not support this protocol." — the gemini registry row was restricted to opencodezen, so Go fell through to the chat-completions catch-all while the gateway serves the model Google-native. The row now applies to every vendor; since Go's /zen/go/v1 base does not serve the :streamGenerateContent route at all, providers carry an optional googleModelsUrl (Go default https://opencode.ai/inference/go/v1/models per OpenCode's own endpoint table; Zen and custom apiBaseUrl gateways keep deriving from modelsUrl, issue ltmoerdani#247 contract intact). Also in this change: - feat(thinking): GeminiThinking strategy — Thinking Effort picker mapped to generationConfig.thinkingConfig (thinkingLevel + includeThoughts), opencodego.thinking.gemini workspace default. Verified live: the level is accepted and thinking is billed (thoughtsTokenCount). Thought summaries are not relayed upstream (opaque thoughtSignature only) — documented in thinking/gemini.ts. - fix(usage): updateRequestUsageSummary understands Google usageMetadata and candidates[].finishReason (Gemini usage logged n/a and metered 0). - fix(usage): [diag-empty-response] no longer requires completion tokens to fire — that precondition made the raw-SSE dump unreachable exactly when Google parsing produced nothing. - fix(models): stop sending temperature to Google models that declare temperature: false. Verified live on gemini-4-argon-contributor (200 OK, thinkingLevel accepted, real usage); deepseek-v4.1-flash / mimo-v2.6-flash regression checked. npm run lint 7/7; npm test 540/540. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
@NeoMetric nice one on splitting the Go Google base out of Ran it against current main (2986b1f): lint gate 7/7, 540/540 tests, tsc clean, merge state CLEAN. Base is already the tip of main, no rebase needed. I spent most of my time on the endpoint, since that's the part that could bite us. I probed both candidate bases and the error envelope tells you which adapter you hit: Also good: reusing One blocker though, this one needs a fix before it goes in.
Confirmed against your branch: So the user picks Minimal, the request goes out with no What I would do: build the allowed list from Two smaller notes, neither blocking on its own:
Small aside: On the registry drift you flagged for On the merge itself, I want to keep the commit history intact, so this goes in as a regular merge commit, not a squash. I will re-run the gate once the minimal fix lands. |
Gemini models served by OpenCode Go (gemini-4-argon-contributor) failed every request with 400 "Model does not support this protocol." — the gemini registry row was restricted to opencodezen, so Go fell through to the chat-completions catch-all while the gateway serves the model Google-native. The row now applies to every vendor; since Go's /zen/go/v1 base does not serve the :streamGenerateContent route at all, providers carry an optional googleModelsUrl (Go default https://opencode.ai/inference/go/v1/models per OpenCode's own endpoint table; Zen and custom apiBaseUrl gateways keep deriving from modelsUrl, issue #247 contract intact).
Also in this change:
Verified live on gemini-4-argon-contributor (200 OK, thinkingLevel accepted, real usage); deepseek-v4.1-flash / mimo-v2.6-flash regression checked. npm run lint 7/7; npm test 540/540.
📝 What does this change?
🧪 How did you test it?
✅ Checklist
npm run compilepassesnpm run lintpassesnpm testpassesnpm run packageproduces a VSIXCloses #259