OpenCode Go Gemini 4 Argon Contributor is routed to Chat Completions instead of Gemini #7097

Client or integration

Codex App

Provider or upstream service

OpenCode Go (opencode-go/gemini-4-argon-contributor)

OpenCodex version

2.84.0

Endpoint or capability

POST /v1/responses inbound; model-specific upstream protocol selection for OpenCode Go's Gemini endpoint.

Current behaviour

OpenCodex advertises opencode-go/gemini-4-argon-contributor in the Codex model picker. Selecting it and sending a prompt fails immediately with HTTP 400, Model does not support this protocol.

The request trace shows that OpenCodex accepts the Responses request, selects the opencode-go provider, then translates responses -> ir -> chat and sends it through adapter: "openai-chat". The local opencode-go configuration has a provider-wide openai-chat adapter and https://opencode.ai/zen/go/v1 base URL. A second attempt with reasoning effort high failed identically to the first attempt at xhigh, so the reasoning level is not the cause.

Expected behaviour

This model should use OpenCode Go's documented Gemini endpoint and Gemini request/response wire while other Go models retain their own protocols. If that route is not implemented, OpenCodex should not advertise the model as callable through the current provider configuration.

Minimal redacted request or reproduction

1. Configure the built-in opencode-go provider with a Go subscription key. No custom model adapter override is set.
2. In Codex App, select opencode-go/gemini-4-argon-contributor and send a simple prompt.
3. Inspect the OpenCodex request log. The model is selected, but the upstream attempt uses openai-chat and fails with 400.

Redacted relevant configuration:

{
  "providers": {
    "opencode-go": {
      "adapter": "openai-chat",
      "baseUrl": "https://opencode.ai/zen/go/v1",
      "authMode": "key"
    }
  }
}

Actual response or error

status: 400
upstreamError: Provider error 400: Model does not support this protocol.
attempt.adapter: openai-chat
protocolTrace.inbound: responses
protocolTrace.upstream: chat
protocolTrace.requestPath: responses -> ir -> chat
failureStage: headers-only
failureCause: payload-rejected

Upstream documentation

OpenCode Go lists Gemini 4 Argon Contributor (gemini-4-argon-contributor) on the Gemini model endpoint with @ai-sdk/google, unlike its Chat Completions models: https://opencode.ai/docs/go/#endpoints

Suggested mapping or implementation notes

Code inspection on dev at 08bb2e4 narrows the fix to two coupled changes:

1. Select a trusted, exact-model Gemini route. The Go registry entry defaults to openai-chat and has exact-model Responses exceptions, but none for Gemini. Adding "gemini-4-argon-contributor": "google" to modelWireDefaults alone does not work: wire resolution and the static policy resolver allow only openai-chat and openai-responses for these defaults. Keep the user-configurable modelAdapters allowlist narrow; add a trusted registry/hard-pin path for this exact model. Scope it to the canonical Go destination and key-auth configuration, so a custom same-named provider cannot send its credential to the Go endpoint.
2. Provide a Go-specific Gemini transport. The Google adapter currently constructs an AI Studio /v1beta/models/<id>:generateContent path. OpenCode Go documents /inference/go/v1/models/gemini-4-argon-contributor; the selected adapter needs to build that Go path for generateContent and streamGenerateContent, using the Go credential contract without changing AI Studio or Antigravity traffic. The existing Go session-header helper should continue to carry x-opencode-session after wire selection.

Regression coverage should assert the outgoing Gemini URL, request wire, authentication/session headers, streaming completion and one tool-result continuation; it should also show that sibling Go Chat/Responses/Messages models are unchanged and that a custom destination cannot trigger the Go-specific route.

The wrong URL/protocol is confirmed by the trace and code. The generic Google adapter uses x-goog-api-key, but this report has not established that OpenCode Go rejects that header; the auth behavior should be verified against the Go endpoint rather than assumed. OpenCodex already has model-specific Go wire precedents in #1482 and #4847.

Additional context

Related: #1482 (Go Luna routed to the wrong protocol; fixed), #4847 (per-model Go Messages exception; fixed). This report is specifically about the Go Gemini endpoint.

Checks

• I searched existing provider and compatibility issues.
• The request and response above omit credentials, account details, request IDs, conversation IDs, and personal data.
• The expected protocol is based on OpenCode Go's published endpoint table.