OpenCode go unusable: TTFT extremely long #57403

Activity

1. opencode-agent commented on Oct 20, 2026

   

   opencode-agentBot

   on Oct 20, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for the report, @Ploppy3! To find out what's going on, could you add a few details?

   • Model: which OpenCode Go model you're using (e.g. opencode-go/deepseek-v4.1-flash).
   • How slow it is: roughly how long you wait for the first token, compared with the 3.2s shown on the status page.
   • How often: every request, or only some? Does it also happen with a tiny prompt in a fresh session, or only in long sessions with a lot of context?
   • Errors: does the request ever fail (e.g. unexpected EOF, timeouts, 5xx)? If so, the error text or relevant lines from the logs would help.
   • Whether other models or providers are fast for you in the same setup.

   You can reply here with the details, or edit the issue. If you edit it, please also leave a comment saying you've updated it, so we know when you're done.

   These existing issues might already cover your problem. The list is ordered by likelihood:

   • [opencode-go] deepseek-v4.1-flash: ~30% of API requests stall ~110s then fail with "unexpected EOF" before first token (tiny prompts included) #57270: deepseek-v4.1-flash requests on Go stall about 110s before the first token, even with tiny prompts
   • opencode-go: deepseek-v4.1-flash first-token latency scales with context (p90 ~25s at 657k, minutes at the tail), plus empty completions and missing finish_reason #57055: Go first-token latency for deepseek-v4.1-flash grows with context size
   • OpenCode Go service (zen/go/v1) frequent intermittent outages — HTTP 000 / 503 / Cloudflare 524 #36889: frequent intermittent outages of the OpenCode Go service (503 / 524)
   • Zen Go: deepseek-v4.1-flash decodes ~30% slower than the same model on Command Code and DeepSeek's own API #51010: slow decoding speed on Go for deepseek-v4.1-flash
   • [Bug]: session time.streamed is never persisted and step.streamed fires after the stream ends, not at first token #57178: the app records the "streamed" time when the stream ends instead of at the first token, so the time shown can be misleading
2. opencode-agent

   added

   triaging

   on Oct 20, 2026
3. Ploppy3

   changed the title [-]OpenCode go unusable TTFT extremely long[/-] [+]OpenCode go unusable: TTFT extremely long[/+] on Oct 20, 2026
4. Ploppy3 commented on Oct 20, 2026

   

   Ploppy3

   on Oct 20, 2026

   Author

   More actions

   • Model: opencode-go/deepseek-v4.1-flash which points to the 1017 variant
   • How long I waited, sometimes up to 5 minutes for the model to start thinking
   • How often: p50: 6.7s, p95: 51.8s
   • Most pass 200 ok, just extremely long stand by, waiting for first token, look like queuing by the inference provider
   • Affects only opencode-go/deepseek-v4.1-flash, the official DeepSeek provider works fine, with TTFT of 1 to 2s average
5. Ploppy3 commented on Oct 20, 2026

   

   Ploppy3

   on Oct 20, 2026

   Author

   More actions

   Cross-posting the controlled results from #57055, because they rule out the client-side explanations:

   • At 401k context with warm cache, max_tokens 256,000 vs 32,768: TTFT 4.175s vs 4.177s. No effect.
   • Removing x-session-affinity and X-Session-Id: no effect (4.43s, full 401,280-token cache hit).
   • Removing x-opencode-session: HTTP 400 MissingSessionID ("cannot be routed efficiently"). It is the routing key and cannot be removed.
   • Same ~400k session: TTFT ranges from 4.1s to 236.1s, all ~99.7% cached. The 236s request had 504 new tokens.
   • The 1203s entry was two 600s Cloudflare 524s followed by an 8s success; the default 300s client timeout normally hides this. In 7 days I saw 11 first-attempt 524s in ~12k requests.
   • Direct DeepSeek at 250–450k: p50 4.8s, p95 17.6s, max 42s.

   So this is not decode speed, max_tokens, or a missing/extra affinity header. It looks like gateway endpoint/queue scheduling at long context. The 4s–236s spread at the same context is the part that needs server-side logs.
6. neriousy commented on Oct 21, 2026

   

   neriousy

   on Oct 21, 2026

   Member

   More actions

   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.
7. neriousy

   closed this as completedon Oct 21, 2026
8. opencode-agent

   closed this as not plannedon Oct 23, 2026
9. opencode-agent commented on Oct 23, 2026

   

   opencode-agentBot

   on Oct 23, 2026 – with OpenCode Agent

   Contributor

   More actions

   Closing this for now, since we haven't heard back with the details we asked for (which OpenCode Go model, how long the first token actually takes, and how often it happens). Without them we can't tell which problem this is or try to reproduce it.

   If you still see this, reply with those details and we can reopen it. In the meantime, these existing issues may cover it:

   • [opencode-go] deepseek-v4.1-flash: ~30% of API requests stall ~110s then fail with "unexpected EOF" before first token (tiny prompts included) #57270: deepseek-v4.1-flash requests on Go stall about 110s before the first token
   • opencode-go: deepseek-v4.1-flash first-token latency scales with context (p90 ~25s at 657k, minutes at the tail), plus empty completions and missing finish_reason #57055: Go first-token latency grows with context size
   • OpenCode Go service (zen/go/v1) frequent intermittent outages — HTTP 000 / 503 / Cloudflare 524 #36889: intermittent OpenCode Go outages

   Thanks for reporting!
10. opencodejr

    reopened this on Nov 3, 2026
11. neriousy

    closed this as not plannedon Nov 12, 2026