Severe latency + aborted streams on opencode-go (Console Go) — streams hang for minutes and fail with "other side closed" / "Endpoint is unavailable" #52215

Activity

1. github-actions commented on Sep 30, 2026

   

   github-actionsBot

   on Sep 30, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of existing issues. Please check:

   • #36889: intermittent OpenCode Go service outages with HTTP 000/503/524 errors.
   • #49041: DeepSeek V4.1 Flash stopped responding through OpenCode.
   • #45076: intermittent "Endpoint is unavailable" errors on free models, including Ox Alpha Free and Muse Spark.
2. Dante-dan commented on Oct 1, 2026

   

   Dante-dan

   on Oct 1, 2026

   Contributor

   More actions

   I traced the Go chat route into the gateway handler. It forwards caller cancellation upstream and supports bounded provider failover, but that failover depends on the deployed model's fallback/sticky settings. The actual routing comes from deployment model configuration, rather than a checked-in mapping for deepseek-v4.1-flash.

   The reported Endpoint is unavailable message is an upstream response, while DNS failures, socket resets, and the 300-second header timeout represent different failure points. This source inspection does not reproduce the incident or establish a gateway-code cause.

   Could a maintainer correlate the supplied September 29–30 UTC timestamps/Brazil requests with the selected upstream endpoint and its health/status, and share the non-secret routing details for this model (whether fallback is configured and whether stickiness is strict or preferred)? Whether those requests never received headers or instead lost an established response stream would help distinguish routing/failover behavior from an upstream stream failure. The working OpenRouter comparison is useful, but may select a different upstream endpoint.
3. bstorm-solucoes commented on Oct 1, 2026

   

   bstorm-solucoes

   on Oct 1, 2026 via email

   Author

   More actions

   First of all, thank you very much for your response! I have some important information to add: I’m still having this problem; there are times when it gets worse and others when it’s not as bad, but it’s hard to work this way. What I’ve noticed is that some calls either don’t get answered or get canceled. The duration varies—some calls stay on hold for quite a while before being ended (“other side closed”), while others are ended more quickly. However, once the call connects, it no longer freezes and stays smooth throughout the call, even if it’s a long one. Since this was really affecting my work and I didn’t find anyone else reporting the same problem—at least not with the same severity—I thought about using a different network, so I connected my PC via my cell phone’s data connection instead of my fiber ISP. Immediately after that, everything worked perfectly. Clearly, there’s something related to the routing through the fiber ISP, but it happens exclusively with calls from the Go and Zen models; OpenRouter works without any issues. All my other services work fine, too. I turned off the router for a while to refresh the IP address from the ISP, but it didn’t help—even with a new IP, as long as I connect through my fiber ISP, the problem persists. This started happening on September 29, 2026. Before that, nothing like this had ever happened; everything had always run smoothly and without any problems. Is there anything I can do to fix this? If you need more information, I’m here to help. Thanks Em qua., 30 de set. de 2026 às 21:35, Dante ***@***.***> escreveu:

   …

   *Dante-dan* left a comment (anomalyco/opencode#52215) <#52215 (comment)> I traced the Go chat route <https://github.com/anomalyco/opencode/blob/02c3891d9b40c0cd98dbafa2f102555ac2f277d9/packages/console/app/src/routes/zen/go/v1/chat/completions.ts> into the gateway handler <https://github.com/anomalyco/opencode/blob/02c3891d9b40c0cd98dbafa2f102555ac2f277d9/packages/console/app/src/routes/zen/util/handler.ts#L164>. It forwards caller cancellation upstream and supports bounded provider failover, but that failover depends on the deployed model's fallback/sticky settings. The actual routing comes from deployment model configuration <https://github.com/anomalyco/opencode/blob/02c3891d9b40c0cd98dbafa2f102555ac2f277d9/packages/console/core/src/model.ts#L85>, rather than a checked-in mapping for deepseek-v4.1-flash. The reported Endpoint is unavailable message is an upstream response, while DNS failures, socket resets, and the 300-second header timeout represent different failure points. This source inspection does not reproduce the incident or establish a gateway-code cause. Could a maintainer correlate the supplied September 29–30 UTC timestamps/Brazil requests with the selected upstream endpoint and its health/status, and share the non-secret routing details for this model (whether fallback is configured and whether stickiness is strict or preferred)? Whether those requests never received headers or instead lost an established response stream would help distinguish routing/failover behavior from an upstream stream failure. The working OpenRouter comparison is useful, but may select a different upstream endpoint. — Reply to this email directly, view it on GitHub <#52215?email_source=notifications&email_token=AOX2NTQCN5EQDEHSXYUQRGL5RWRDPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKOJSGIZTAMRQHEZ2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-5922302093>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOX2NTUQVKMRF7UAGJYU5Y35RWRDPAVCNFSNUABFKJSXA33TNF2G64TZHM4TONJXGM2DGMJZHNEXG43VMU5TKNRUGA2TSNZZGM3KC5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AOX2NTQMO7FM2VHGKC7EHB35RWRDPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKOJSGIZTAMRQHEZ2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/AOX2NTV2JHJRCCXHEMVLSSL5RWRDPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKOJSGIZTAMRQHEZ2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>
4. thdxr commented on Oct 11, 2026

   

   thdxr

   on Oct 11, 2026

   Member

   More actions

   Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.

   — from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊
5. thdxr

   closed this as not plannedon Oct 11, 2026