Repository navigation
go: /v1/messages returns 503 "Endpoint is unavailable" for mimo/glm and other models while /v1/chat/completions works #50502
Description
Description
Summary
The Anthropic-compatible endpoint of OpenCode Go (https://opencode.ai/zen/go/v1/messages) returns 503 Upstream request failed: Endpoint is unavailable for a batch of catalog models (all MiMo and GLM models, kimi-k2.x, hy3/hy4, longcat, grok, gpt-5.6-luna), while the same API key and the same model respond normally via /v1/chat/completions at the same minute. This breaks Claude Code (listed as a validated client) for those models.
Environment
- opencode version: v2.0.12 (client-side; issue is server-side at opencode.ai/zen/go)
- OS: Windows_NT 10.0.26200 (win32 x64)
- Terminal: Unavailable: terminal environment variables are not set
- Shell: C:\Windows\system32\cmd.exe
- Install/channel: latest
- Active plugins: None found in config
Reproduction
With a valid OpenCode Go API key (session header included):
- Anthropic path (used by Claude Code) — fails:
curl -i https://opencode.ai/zen/go/v1/messages \
-H "content-type: application/json" \
-H "anthropic-version: 2023-06-01" \
-H "x-api-key: $GO_API_KEY" \
-H "x-opencode-session: $(uuidgen)" \
-d '{"model":"mimo-v2.6-pro","max_tokens":32,"messages":[{"role":"user","content":"Say hi"}]}'- OpenAI-compatible path (used by OpenCode) — works:
curl -i https://opencode.ai/zen/go/v1/chat/completions \
-H "content-type: application/json" \
-H "authorization: Bearer $GO_API_KEY" \
-H "x-opencode-session: $(uuidgen)" \
-d '{"model":"mimo-v2.6-pro","max_tokens":32,"messages":[{"role":"user","content":"Say hi"}]}'Expected Behavior
/v1/messages serves every model in the Go catalog, since Claude Code and other Anthropic-protocol clients are listed as validated clients in the Go docs.
Actual Behavior
Step 1 returns 503 {"type":"error","error":{"type":"api_error","message":"Upstream request failed: Endpoint is unavailable."}} within ~1s. Step 2 returns 200 with a normal completion at the same time (A/B tested within the same minute, 2026-09-22).
Full model sweep against /v1/messages, same key, same session header:
| Result | Models |
|---|---|
| 200 OK | deepseek-v4.1-flash, deepseek-v4-flash, deepseek-v4-pro, kimi-k3, qwen3.8-max, qwen3.8-flash, qwen3.7-plus, minimax-m3, minimax-m2.7 |
| 503 Endpoint is unavailable | mimo-v2.6-pro, mimo-v2.6-flash, glm-5.3-flash, glm-5.3, glm-5.2, kimi-k2.6, kimi-k2.7-code, hy3, hy4-preview, longcat-2.0, grok-4.6, gpt-5.6-luna |
All /v1/chat/completions variants of the failing models return 200 (spot-checked mimo-v2.6-pro, glm-5.3-flash, deepseek-v4.1-flash).
Additional Context
- Reproduces consistently for
mimo-v2.6-proandglm-5.3-flashover multiple days;deepseek-v4.1-flashon the same endpoint works the whole time. - Tested with
x-opencode-sessionpresent and aclaude-cli/*user agent, so this is not the MissingSessionID check. - Claude Code (validated client per Go docs) hits
/v1/messagesexclusively, so every affected model is unusable from Claude Code while working fine in OpenCode. - Workaround: use one of the 200-OK models in Anthropic-protocol clients until the routing for the failing models is fixed.
Plugins
No response
OpenCode version
No response
Steps to reproduce
No response
Screenshot and/or share link
No response
Operating System
No response
Terminal
No response
Activity
github-actions commentedon Sep 22, 2026
This issue might be a duplicate of existing issues. Please check:
If one of these already tracks the problem, consider adding a comment there with your reproduction details (especially the full model sweep table) rather than tracking it separately.
lero007 commentedon Sep 22, 2026
Thanks for the pointers — I checked all four. They're the same failure family but none tracks this exact breakage, so keeping this open, with data that fills a gap:
/v1/messagesvs/v1/chat/completionsasymmetry, but forkimi-k3back in July. Re-tested today:kimi-k3now returns 200 on/v1/messages, while a different batch (all mimo, all glm, kimi-k2.x, hy3/hy4, longcat, grok-4.6, gpt-5.6-luna) fails with503 Endpoint is unavailable. Different model set, different error body./v1/chat/completionsin August with a model set that has since flipped: qwen/grok failed then and work now; glm-5.2 worked then and fails now (on/v1/messages)./v1/responsesfor Codex) with the same structure: DeepSeek OK, non-DeepSeek broken. Cross-referencing, since together they show the breakage spans at least two adapter paths./v1chat endpoint from Sep 5. Several models it reported as dead (e.g.minimax-m2.7,glm-5.x) now return 200 on chat, again showing the failing set shifts over time.Cross-issue pattern (combining this issue with #38378, #43163, #44910, #47463): DeepSeek-family models work on every protocol endpoint at every point in time, while non-DeepSeek models fail per adapter, in rotating batches — Jul:
/v1/messages(kimi-k3) → Aug:/v1/chat/completions(qwen/grok) → Aug 25:/v1/responses(all non-DeepSeek) → Sep 22:/v1/messages(mimo/glm/kimi-k2.x/hy/longcat/grok/gpt-luna). This looks like one root cause in the gateway's per-protocol adapters for non-DeepSeek upstreams rather than isolated incidents.This issue specifically documents the current
/v1/messagesbatch (Claude Code impact + full 22-model sweep table, 2026-09-22), which none of the above cover. Happy to fold into a canonical tracking issue if one is preferred.Tarquinen commentedon Oct 20, 2026
Thanks for the report! The
/messagesendpoint only serves the models listed for it in the Go docs, like MiniMax M3 and Qwen. MiMo, GLM and the other models are served on/chat/completionsor/responses: https://opencode.ai/v2/docs/console/go#endpoints. Closing this issue.— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊