Repository navigation
[opencode-go] deepseek-v4.1-flash: first request of a new x-opencode-session stalls before headers (9.4% >10s, p99 105s) — follow-up to #57270 #62591
Description
Description
Follow-up to #57270 (closed): we still see the same stall-before-headers behavior on OpenCode Go, measured over the 7 days up to 2026-11-07. The stall hits the first request of a new x-opencode-session about 10× more often than the following requests in the same session.
Setup: server-side integration calling https://opencode.ai/zen/go/v1/chat/completions directly over HTTPS (no OpenCode client/CLI), streaming, model deepseek-v4.1-flash, Go plan. A stable x-opencode-session is sent per conversation. Our client waits up to 120 s for response headers, then aborts and resends the identical request.
Time to response headers, 7 days (includes the retry time when a request was resent):
| value | |
|---|---|
| p50 / p90 / p95 / p99 | 1.8 s / 4.1 s / 5.8 s / 19.7 s |
| over 10 s | 1.9% of requests |
| no headers after 120 s (aborted by us) | 0.6% of requests |
| retry after the 120 s abort: time to headers | median 2.4 s, p90 33.5 s |
First request of a session vs the rest:
| request | share of requests | p95 | p99 | over 10 s |
|---|---|---|---|---|
1st request of a new x-opencode-session |
11% | 30.8 s | 105 s | 9.4% |
| 1st request of a later turn, same session | 8% | 6.0 s | 25.5 s | 2.2% |
| following requests in the same turn | 81% | 4.9 s | 9.4 s | 0.9% |
Example, 2026-11-07 (UTC): a new session's first request was sent at 12:07:04. No headers had arrived by 12:09:04 (120 s), so it was aborted and resent; the retry got headers at 12:09:07 (~3 s) and then streamed normally (thinking deltas immediately). In the same minutes, a request from another session took 45 s and 63 s to get headers, without hitting the ceiling.
The pattern matches #57270 and #57849: no bytes at all until the headers arrive (no keep-alive), and an immediate resend of the same request is usually fast. That makes it look like queueing/admission in the gateway rather than prefill. The prompt prefix is ~40k tokens, and the slow cases also happen when it is already cached.
Questions:
- Is there a known queue/admission step for a new
x-opencode-session(routing/affinity) that can hold a request without sending headers? - Can the gateway send response headers (or SSE keep-alive comments) early while a request is queued, the way the DeepSeek API does, so clients can tell "queued" apart from "dead"?
- What client timeout before resending do you recommend? Is
ttft_admission_refused(providers: opencode-go stream aborts on transient capacity errors instead of retrying #62306) the intended signal instead of a silent wait?
Related: #57270, #57849, #57055, #59902, #62306.
Plugins
None. Not using the OpenCode client; direct HTTP calls to the OpenCode Go API.
OpenCode version
N/A — no OpenCode client/CLI involved.
Steps to reproduce
- Start a new conversation with a fresh
x-opencode-sessionand send a streaming chat completion to/zen/go/v1/chat/completionswithdeepseek-v4.1-flash. - Measure the time to response headers. About 1 in 10 first requests takes over 10 s; about 1 in 100 takes over 100 s or never answers.
- Abort and resend the identical request: it usually gets headers in 2–4 s.
Intermittent. In our traffic the worst hours were 16:00–18:00 UTC and around 00:00 UTC.
Operating System
Linux server (Ubuntu)
Activity
opencodejr commentedon Nov 7, 2026
Thanks for the careful follow-up, @willy3087. Splitting the numbers by first request of a new
x-opencode-sessionversus later requests, and giving an example with UTC timestamps, makes the pattern much clearer.This stall happens inside the hosted OpenCode Go service, before it sends response headers. No OpenCode app code is involved, so it can't be investigated or fixed from this repository. Your questions are also for the team that runs the service: whether there's a queueing or admission step for new sessions, whether it could send early headers or SSE keep-alive comments, what client timeout to use, and whether
ttft_admission_refusedis the intended signal.Problems with the OpenCode Go service, like billing and account support, aren't handled in GitHub issues. Please email [email protected] with:
x-opencode-sessionvalues involvedIf you've already emailed, the team will get to it, especially now that we've seen it here. Please keep API keys, email addresses and account details out of this public issue and put them only in the email.
Related public issues, if you want to follow them:
opencode-go/deepseek-v4.1-flash, logged through the OpenCode client (open)[opencode-go] deepseek-v4.1-flash: ~30% of API requests stall ~110s then fail with "unexpected EOF" before first token (tiny prompts included)#57270: your earlier report of this problem, which was sent to emailttft_admission_refused/prefill_cap_refusedcapacity errorsThe bot will close this issue in 1 day.
opencodejr commentedon Nov 8, 2026
Hi @willy3087, I'm closing this now. Problems with the hosted OpenCode Go service are handled by email, not in GitHub issues. If new sessions are still stalling before headers, or you still want answers on admission, keep-alives and client timeouts, please email [email protected] with your time windows, UTC timestamps and session IDs. Please keep keys and account details out of this public thread. The closest public issue, if you want to follow it, is #57849. Thanks again for the thorough measurements.