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

[proluct]

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.

#	Endpoint	Model	Payload	Result
A	/v1/messages	kimi-k3	minimal + top-level system	FAIL
B	/v1/messages	kimi-k3	minimal, no system	FAIL
C	/v1/messages	minimax-m3	minimal	200 OK
D	/v1/chat/completions	kimi-k3	minimal	200 OK

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

[github-actions]

This issue might be a duplicate of or closely related to existing issues. Please check:

• bug: opencode-go gateway returns reasoning_content instead of content in streaming responses #37635: Reports that the opencode-go gateway returns reasoning_content instead of content in streaming responses for all opencode-go models — the root cause you hypothesize (the translation layer failing to map reasoning_content to Anthropic thinking blocks) aligns directly with this issue.
• OpenCode Go: kimi-k3, kimi-k2.6, kimi-k2.7-code, glm-5.2, grok-4.5, qwen3.7-max, hy3-preview all fail with 'Upstream request failed' — non-standard 'mcp'/'system' fields rejected by strict provider validators #37771: Covers the same set of affected models (kimi-k3 and other reasoning models) failing with Upstream request failed, though from a different identified cause (mcp/system extra fields). Your issue narrows the failure to the /v1/messages endpoint specifically, which is a meaningful distinction you've already noted.

If #37635 covers the same underlying translation-layer bug, this issue may be a more targeted repro of that problem scoped to the Anthropic-compatible endpoint.

[silvioprog]

I'm seeing the same issue today with OpenCode Go and Kimi K3. I still have credits available, but every request fails with:

Error from provider (Console Go): Upstream request failed

opencode version: 1.18.4

[joepetrakovich]

You can try disabling any MCPs you have. It fixed it for me

[silvioprog]

@joepetrakovich, thanks a lot, worked for me too!