anomalyco / anomalyco/opencode

Zen gateway: createBodyConverter has no "google" branch — cross-family gemini-* requests forward a body with no contents

Open
#39,696 0 comments 0 reactions 1 assignee View on GitHub

@fwang is already working on this.

Since Jul 30, 2026.

Dominant language
TypeScript
Stars
209k
Forks
27.5k
PR merge metrics
PR metrics pending

Description

Summary

createBodyConverter in packages/console/app/src/routes/zen/util/provider/provider.ts has egress branches for anthropic, openai, and oa-compat, but none for google. Any cross-family request targeting a gemini-* model therefore falls off the end of the function and returns undefined, and the request body forwarded to Google contains no contents key at all.

The model never sees the messages. Google responds with Missing key at ["contents"].

Reproduction
curl https://opencode.ai/zen/v1/chat/completions \
  -H "Authorization: Bearer $OPENCODE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemini-3.1-pro",
    "messages": [{"role":"user","content":"hello"}]
  }'

→ error from Google: Missing key at ["contents"]

Affects every gemini-* model on /zen/v1/chat/completions, and by the same code path on /zen/v1/messages and /zen/v1/responses. The native /zen/v1/models/[model] endpoint is unaffected, because there from === to and the body is passed through untouched.

Root cause

googleHelper declares format: "google" (google.ts:31) and its modifyBody is the identity function (google.ts:38-40), so it does no conversion of its own:

modifyBody: (body: Record<string, any>) => {
  return body
},

createBodyConverter (provider.ts:182-195) never produces a Google body:

export function createBodyConverter(from: ZenData.Format, to: ZenData.Format) {
  return (body: any): any => {
    if (from === to) return body

    let raw: CommonRequest
    if (from === "anthropic") raw = fromAnthropicRequest(body)
    else if (from === "openai") raw = fromOpenaiRequest(body)
    else raw = fromOaCompatibleRequest(body)

    if (to === "anthropic") return toAnthropicRequest(raw)
    if (to === "openai") return toOpenaiRequest(raw)
    if (to === "oa-compat") return toOaCompatibleRequest(raw)
    // to === "google" falls through -> undefined
  }
}

handler.ts:189-191 then spreads that undefined into the outgoing body:

providerInfo.modifyBody({
  ...createBodyConverter(opts.format, providerInfo.format)(body),
  model: providerInfo.model,
  ...
})

Spreading undefined is legal JavaScript and contributes zero keys, so what reaches Google is essentially { "model": "gemini-..." }. The failure is silent on the gateway side and only surfaces as Google's schema error.

The missing branch isn't caught at compile time because createBodyConverter's returned function is annotated (body: any): any, so neither the missing to === "google" case nor the implicit undefined return is a type error.

Suggested fix

Ideally, implement the Google conversion — toGoogleRequest / fromGoogleResponse / fromGoogleChunk — so Gemini models work on the OpenAI- and Anthropic-shaped endpoints like every other family.

If that's out of scope for now, the minimum viable fix is to fail loudly rather than forward a malformed body: reject cross-family Gemini requests with a clear 4xx explaining that gemini-* models must be called via /zen/v1/models/[model]. Silently sending a body with no messages is the worst of the available behaviours, since it looks like a Google-side problem.

It would also be worth giving createBodyConverter an exhaustive switch (or a non-any return type) so a future added format is a compile error instead of an undefined at runtime.

Happy to open a PR if useful.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.