[Bug] OpenCode Go: kimi-k3 fails on /v1/messages with "Upstream request failed" while /v1/chat/completions succeeds #38378

Description

kimi-k3 is reachable and healthy through the Go gateway on the OpenAI-compatible endpoint,
but the same model on the Anthropic-compatible endpoint fails every time. Raw curl, no
OpenCode client involved, same API key, same base URL, all within a few minutes.

B (fails):

curl -sS https://opencode.ai/zen/go/v1/messages \
  -H "x-api-key: $OPENCODE_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"kimi-k3","max_tokens":64,"messages":[{"role":"user","content":"hi"}]}'

{"error":{"message":"Error from provider (Console Go): Upstream request failed",
"type":"invalid_request_error","param":null,"code":"invalid_request_error"}}

A returns the identical body, so the top-level system field is not the trigger.

C (works) — same endpoint, same shape, only the model id differs:

{"id":"2aa1258130e5d23e1650cc18eec08790","type":"message","role":"assistant",
"stop_reason":"end_turn","model":"minimax-m3",
"content":[{"type":"text","text":"Hi! How can I help you today?"}], ...}

D (works) — same model as B, OpenAI-compatible endpoint:

{"id":"chatcmpl-6a611f430c5a9d44de3c2368","model":"kimi-k3","choices":[{"index":0,
"finish_reason":"length","message":{"role":"assistant","content":"",
"reasoning_content":"The user just said \"hi\" - a simple greeting. ..."}}],
"usage":{...,"completion_tokens_details":{"reasoning_tokens":61}}}

What this rules out. D shows upstream credentials, routing, and quota are fine for
kimi-k3. C shows /v1/messages itself is fine. B contains no mcp, system, thinking,
reasoning_effort, or temperature, so it is not the payload-field class of bug in #37771,
not models.dev#3331 (temperature), and not #38329 (thinking + reasoning_effort). The failure
is specific to the intersection of kimi-k3 and /v1/messages.

Likely mechanism. In D, kimi-k3 puts its output in reasoning_content with content
empty. The Anthropic Messages format has no reasoning_content; it needs to be mapped to a
thinking content block. If the Anthropic translation layer doesn't handle
reasoning_content, it produces an empty or invalid response and reports it as a generic
upstream failure. That would predict this hitting reasoning models specifically, which
matches the affected set reported in #37771 (kimi-k3, kimi-k2.6, kimi-k2.7-code, glm-5.2,
grok-4.5, qwen3.7-max) while non-reasoning models on the same plan work.

Note this is distinct from #37771 and #37815: in both of those the OpenCode client path
fails, whereas here /v1/chat/completions succeeds and only /v1/messages fails.

Environment: OpenCode Go plan, Windows 11.

Happy to run any payload against either endpoint.

Plugins

No response

OpenCode version

1.18.4

Steps to reproduce

Prerequisites: an active OpenCode Go subscription and an API key.

export OPENCODE_API_KEY=<your Go key>

Each step below changes exactly one variable from the previous one.

1. Baseline: confirm the Anthropic endpoint works at all.
Uses minimax-m3, a non-reasoning model.

curl -sS https://opencode.ai/zen/go/v1/messages \
  -H "x-api-key: $OPENCODE_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"minimax-m3","max_tokens":64,"messages":[{"role":"user","content":"hi"}]}'

Result: 200 OK, valid Anthropic response.

2. Change only the model id to kimi-k3. Same endpoint, same payload shape.

curl -sS https://opencode.ai/zen/go/v1/messages \
  -H "x-api-key: $OPENCODE_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"kimi-k3","max_tokens":64,"messages":[{"role":"user","content":"hi"}]}'

Result: fails.

{"error":{"message":"Error from provider (Console Go): Upstream request failed",
"type":"invalid_request_error","param":null,"code":"invalid_request_error"}}

3. Add a top-level system field, to check whether it is the trigger.

curl -sS https://opencode.ai/zen/go/v1/messages \
  -H "x-api-key: $OPENCODE_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"kimi-k3","max_tokens":64,"system":"You are helpful.","messages":[{"role":"user","content":"hi"}]}'

Result: identical error to step 2. system is not the trigger.

4. Change only the endpoint to /v1/chat/completions. Same model as steps 2 and 3.

curl -sS https://opencode.ai/zen/go/v1/chat/completions \
  -H "Authorization: Bearer $OPENCODE_API_KEY" \
  -H "content-type: application/json" \
  -d '{"model":"kimi-k3","max_tokens":64,"messages":[{"role":"user","content":"hi"}]}'

Result: 200 OK. kimi-k3 responds normally, with its output in reasoning_content.

Expected behavior

Step 2 returns a valid Anthropic-format response, the same way step 1 does for minimax-m3
and step 4 does for kimi-k3 on the OpenAI-compatible endpoint.

Actual behavior

Step 2 and step 3 fail with a generic invalid_request_error. The failure occurs only at
the intersection of kimi-k3 and /v1/messages: the same model succeeds on
/v1/chat/completions (step 4), and the same endpoint succeeds with a different model (step 1).

Two notes on using it:

• Steps 1 and 4 are the load-bearing ones. They're the controls that convert "Kimi is broken" into "the translation layer is broken," so don't trim them for brevity.
• If you add a --ssl-no-revoke you needed locally, leave it out of the report. It's your machine's TLS interception, not reproducible for them, and including it invites a wrong-track reply about certificates.

If step 4 gives finish_reason: "length" again, bump to "max_tokens": 512 so the 200 is unambiguous rather than truncated mid-reasoning.

Screenshot and/or share link

No response

Operating System

Windows 11

Terminal

No response