Repository navigation
Go: deepseek-v4.1-flash returns 429 Endpoint is unavailable while other Go models succeed #57613
Description
Description
Requests to deepseek-v4.1-flash on the OpenCode Go endpoint fail with
HTTP 429
{"error":{"type":"server_error","message":"Upstream request failed: Endpoint is unavailable."}}
while other Go models return 200 on the same API key, same endpoint, in the same minute.
This lines up with the open incident on status.opencode.ai ("Upstream provider issues — Go: deepseek-v4-pro and deepseek-v4.1-flash are seeing increased error rates", started Oct 20 23:44 UTC), but for this workspace the failures started earlier and are still happening now. deepseek-v4-pro returns 503 with the same body.
Control matrix
2026-10-21T02:47Z, one Go key, endpoint https://opencode.ai/zen/go/v1/chat/completions, requests issued back-to-back, all carrying x-opencode-session:
| model | attempt | HTTP | x-opencode-log-id |
|---|---|---|---|
deepseek-v4.1-flash |
1 | 429 | 01a15c5b-2540-7917-84d2-80df4fc4fab0 |
deepseek-v4.1-flash |
2 | 429 | 01a15c5b-27d8-71f9-ab7e-008307fdc82e |
glm-5.3 |
1 | 200 | 01a15c5b-2a4a-7c41-a486-f149cedf4d96 |
glm-5.3 |
2 | 200 | 01a15c5b-2dec-7e56-a6cd-a4b19d1ff8eb |
kimi-k2.7-code |
1 | 200 | 01a15c5b-311f-76d2-bc97-a976470f03bd |
kimi-k2.7-code |
2 | 200 | 01a15c5b-3665-7ab7-8bb3-50b002cfdb88 |
minimax-m3.1-flash-free |
1 | 200 | 01a15c5b-418e-7d6e-9544-ee4a6f870717 |
minimax-m3.1-flash-free |
2 | 200 | 01a15c5b-4655-76f1-ae6f-58a14449dd7e |
Minimal body used:
{"model":"<model id>","messages":[{"role":"user","content":"hi"}],"max_tokens":8}Earlier in the same window deepseek-v4.1-flash alternated inconsistently (429, then 200, then 200) for identical requests, which is what makes it hard to work around at the client level.
Steps to reproduce
- Use a Go key whose workspace has an active subscription and region set to Global.
POST /zen/go/v1/chat/completionswith"model": "deepseek-v4.1-flash"and a minimal body.- Observe
429/503Upstream request failed: Endpoint is unavailable. - Repeat with
glm-5.3,kimi-k2.7-codeorminimax-m3.1-flash-freeseconds later — all return200.
Environment
- Client: Hermes Agent
v0.21.7+132.gf594424(sends a stablex-opencode-sessionper conversation; includes PR #101864) - Endpoint:
https://opencode.ai/zen/go/v1/chat/completions - Wire format:
chat_completions - Workspace region: Global
- OS: server Ubuntu 22.04, client Windows 11
- Terminal: OrcaTerm
- OpenCode version: N/A (not an OpenCode client)
Impact
Every agent turn fails on the primary model. Since 2026-10-20T17:24Z, six scheduled runs in this workspace failed at this step. Workaround is pinning a non-DeepSeek model, which loses the DeepSeek quota the plan is priced around.
Questions
- Is a healthy upstream endpoint currently configured for the
deepseek-v4.1-flashchat/completionsroute? The error carries anx-opencode-log-idbut nox-opencode-endpoint-id, which in Zen Go: /v1/responses 503 'Endpoint is unavailable' sticks to a single conversation and never recovers (deepseek-flash, Codex client) #53120 was the signature of the gateway giving up before an endpoint served the request. - Zen Go: /v1/responses 503 'Endpoint is unavailable' sticks to a single conversation and never recovers (deepseek-flash, Codex client) #53120 describes per-conversation sticky provider binding (
stickyId = sessionId ?? workspaceID ?? ip) that is only written on success. If this workspace got bound to a dead endpoint, can that binding be reset server-side, or does it expire on its own? - Given the status page reports monitoring data as missing on and off, is there a better signal we can watch than the public status page?
Happy to provide the full request/response dumps or more log ids if useful.
Activity
opencode-agent commentedon Oct 21, 2026
Thanks for the detailed report and the log IDs. It looks like
deepseek-v4.1-flash(anddeepseek-v4-pro) on OpenCode Go keep failing for your workspace while other Go models work, and that this matches the current upstream incident on the status page.This is a problem with the hosted OpenCode Go service, not the OpenCode app, and support for Go, Zen and account issues isn't handled in GitHub issues. Please email [email protected] with the details: the failing model, the time window, the
x-opencode-log-idvalues you listed, and your questions about endpoint health and resetting the sticky binding. If you've already emailed, the team will get to it, especially now that we've seen it here. Please keep your API key, account email and other account details out of this public issue and put them only in the email.Related reports, in case they're useful:
deepseek-v4.1-flashThe bot will close this issue in 1 day.
going358 commentedon Oct 21, 2026
Additional Codex
/v1/responsesevidence from Windows 11:0.163.0-alpha.10.2through a local passthrough proxy2026-10-21 07:06:16 UTC429 Too Many Requestscf-ray:a4de6b1b5fe6562b-EWRx-opencode-log-id:01a15d48-3406-791b-961a-98cba3262791x-opencode-endpoint-id: absent{"error":{"type":"server_error","message":"Upstream request failed: Endpoint is unavailable."}}The client made three bounded attempts over roughly 39 seconds and consistently received the same body. This falls inside the Go elevated-error window reported on the status page from
06:46–09:57 UTC.Could you confirm whether this signature indicates a stale per-conversation sticky binding or endpoint-pool failure, and whether transient 429 responses of this form should carry
Retry-Afterfor Codex clients? I am not posting account identifiers or request content.neriousy commentedon Oct 21, 2026
Thanks for the report, and sorry for the disruption. This was a temporary problem with the hosted service or an upstream model provider, and it has since recovered. You can see live status and past incidents at https://status.opencode.ai. If you still see this now, please open a new issue with the time (with timezone), model, and request ID from the console logs.
opencode-agent commentedon Oct 22, 2026
Hi @hanukkah1, I'm closing this issue now because problems with the OpenCode Go service and accounts are handled by email, not on GitHub. If
deepseek-v4.1-flashordeepseek-v4-prostill fails for your workspace, please email [email protected] with the model, the time window and thex-opencode-log-idvalues. Please keep your API key and account details out of public issues and send them only by email. Thanks again for the detailed report.