Repository navigation
[Zen Go] /v1/responses returns 500 for all non-DeepSeek models (mimo/glm/ox-alpha) while /v1/chat/completions works #44910
Description
Zen Go gateway: /v1/responses returns 500 for every non-DeepSeek model while /v1/chat/completions works
Summary
Since ~2026-08-25 13:00 UTC+8, the Go gateway (https://opencode.ai/zen/go/v1/responses) returns 500 Internal server error for all non-DeepSeek models, while the same models keep working via https://opencode.ai/zen/go/v1/chat/completions. This breaks Codex (desktop & CLI) users on the Go subscription, because Codex speaks the Responses wire protocol exclusively.
This looks like a regression in the gateway's chat→responses adapter layer. Notably glm-5.2 was already served natively over Responses (verified 2026-08-23) and is now also 500ing, so the breakage seems to affect the whole non-deepseek responses path.
Evidence matrix (probed directly against opencode.ai, bypassing any local proxy; 2026-08-25 14:10–14:20 UTC+8)
| upstream model id | POST /v1/responses |
POST /v1/chat/completions |
|---|---|---|
| deepseek-v4-flash | 200 completed | 200 |
| deepseek-v4-flash-vision-exp | 200 completed | 200 |
| deepseek-v4-pro | 200 completed | 200 |
| mimo-v2.5 | 500 {"type":"error","error":{"type":"error","message":"Internal server error"}} |
200 (slow, 13–29s) / intermittent timeouts |
| mimo-v2.5-pro | 500 Internal server error | 200 |
| glm-5.3 | 500 Internal server error | 200 |
| glm-5.2 | 500 Internal server error (was native-responses OK on 2026-08-23) | 200 |
| glm-5.1 | 500 Internal server error | 200 |
| glm-5 | 500 Internal server error | 200 |
| ox-alpha-free | 500 Internal server error | intermittent 200 / 503 "Endpoint is unavailable" |
Minimal reproduction
# 500 — responses endpoint
curl -sS -X POST https://opencode.ai/zen/go/v1/responses \
-H "Authorization: Bearer $ZEN_API_KEY" -H 'Content-Type: application/json' \
-d '{"model":"mimo-v2.5","input":[{"role":"user","content":[{"type":"input_text","text":"hi"}]}],"max_output_tokens":64,"stream":false,"store":false}'
# → HTTP 500 {"type":"error","error":{"type":"error","message":"Internal server error"}}
# 200 — same model, chat endpoint, same moment
curl -sS -X POST https://opencode.ai/zen/go/v1/chat/completions \
-H "Authorization: Bearer $ZEN_API_KEY" -H 'Content-Type: application/json' \
-d '{"model":"mimo-v2.5","messages":[{"role":"user","content":"hi"}],"max_tokens":32}'Also reproducible with "stream":true, with string-style "input", and for every model listed above.
Impact
All Responses-wire clients (Codex family) on Go subscriptions cannot use mimo/glm/ox-alpha at all; only DeepSeek-family models remain usable. OpenCode desktop keeps working for these models because it uses the chat-completions path.
Request
Either restore the responses path for these models, or expose a per-model wire-format hint so clients can pin chat-completions. Happy to provide more traces if needed.
Activity
github-actions commentedon Aug 25, 2026
This issue might be a duplicate of existing issues. Please check:
muse-sparkmodel needed/responseswhile/chat/completionsreturned 500 (inverse symptom, same gateway adapter layer)/v1/responsesSSE stream is incomplete for Go service, breaking Codex-style clientsIf your issue is distinct from those, feel free to clarify the differences so maintainers can triage appropriately.
MarkLee9625 commentedon Aug 26, 2026
Fresh 2026-08-26 probe data confirming this is still down after yesterday's adapter-fix merges: #45104. Matrix matches yours cell-for-cell (chat 4/4 OK, responses 4/4 instant 500, control DeepSeek all-green). Also documented the misleading client-side 'high demand' message from Codex.
metrofun commentedon Aug 31, 2026
A per-model wire hint doesn't solve this for protocol-locked clients like Codex.
The gateway boundary should be:
client protocol -> canonical semantics -> working backend protocolHere that means Codex keeps speaking Responses while mimo/glm/ox-alpha are lowered to Chat Completions. #44659 demonstrates the inverse case, so protocol clearly isn't a model property either.
This is exactly the class of problem we built swobuforge/swobu around: Responses and Chat are independent on each side of the gateway, with tools/reasoning translated between them.
Model availability really needs to be
(model, protocol, capabilities), not justmodel.Tarquinen commentedon Oct 20, 2026
Thanks for the report! Those models aren't served on the
/responsesendpoint. Each Go model is available on the endpoint listed for it in the Go docs, which is/chat/completionsfor models like GLM and MiMo: https://opencode.ai/v2/docs/console/go#endpointsOx Alpha is also no longer offered. Closing this issue.
— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊