stream disconnected before completion is account-scoped — switching ChatGPT accounts changes the failure rate ~7× #45925

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   connectivityIssues involving networking or endpoint connectivity problems (disconnections)Issues involving networking or endpoint connectivity problems (disconnections)

   on Sep 16, 2026
2. github-actions commented on Sep 16, 2026

   

   github-actionsbot

   on Sep 16, 2026 – with GitHub Actions

   Contributor

   More actions

   Potential duplicates detected. Please review them and close your issue if it is a duplicate.

   • Selected model is at capacity. Please try a different model. #45924

   Powered by Codex Action
3. eteai commented on Sep 16, 2026

   

   eteai

   on Sep 16, 2026

   Last edited by eteai

   Author

   More actions

   New evidence: the capacity error is exclusive to the affected account

   The duplicate bot pointed at #45924 (another Pro user on the same app version 26.908.70816, reporting the same stream disconnected before completion, and likewise asking for it to be fixed "for my account"). That issue also reports a second, related error:

   Selected model is at capacity. Please try a different model.

   I see that same error — and it splits perfectly along the account boundary:

   Account	Selected model is at capacity	Successful output items	Rate
   Account A (first period)	42	2,258	1.86%
   Account B	0	5,523	0.00%
   Account A (after switching back)	5	533	0.94%

   On account B this error never occurred once across 5,523 successful output items. On account A it occurred 47 times.

   The occurrences also cluster tightly around the account switches — a dense run immediately before switching away from account A, and another dense run immediately after switching back to account A. Between those two boundaries, across the entire account B period, there is not a single occurrence.

   Why this matters

   These two symptoms look like one root cause, and because account B produced exactly zero occurrences across 5,523 successful items, the constraint does not look like shared contention.

   Additional questions for maintainers

   In addition to the three questions in the original report:

   1. Is the account with x-codex-primary-reset-at = 1789805617 served from a different capacity pool or tier than the account with x-codex-primary-reset-at = 1789950507?
   2. Is there a capacity/quota dimension that is account-scoped rather than plan-scoped? Both accounts report identical headers (x-codex-plan-type: pro, x-codex-active-limit: premium, x-codex-credits-* identical), so the difference is not visible to the client.

   Related: #45924 — same app version, same primary symptom, also reported as account-specific.

   👍React with 👍1Reacted by AloneInfinity
4. eteai commented on Sep 16, 2026

   

   eteai

   on Sep 16, 2026

   Last edited by eteai

   Author

   More actions

   Correction: the capacity-pool explanation does not hold up — the difference is account-level and load-independent

   In my previous comment I proposed that account A might simply be served by a saturated capacity pool. I have now tested that against the data and it does not hold up. Posting the correction so the investigation is not pointed the wrong way.

   Two controls were run against the Selected model is at capacity occurrences. All times below are expressed in US Pacific, the load baseline for the provider's infrastructure.

   Control 1 — time of day (load) does not explain it

   Provider-local (US Pacific) window	Activity volume	at capacity occurrences
   09:00–18:00 (peak load)	64,161	0
   22:00–01:00 (lowest load)	60,877	38

   The two windows carry a comparable volume of activity, yet the error appears only in the low-load window and never during peak hours. The client's own activity is spread across the full day (US business hours account for roughly a quarter of all activity), so this is not an artifact of the client only working at night.

   If this were capacity saturation, the errors would concentrate at peak — instead they are entirely absent from it.

   Breakdown of every at capacity occurrence by US Pacific hour: 20:00(2), 21:00(2), 22:00(7), 23:00(6), 00:00(10), 01:00(15), 02:00(2), 03:00(5), 04:00(5), 05:00(3), 07:00(1), 12:00(1).

   Hours 09:00, 10:00, 11:00, 13:00, 14:00, 15:00, 16:00, 17:00 and 18:00 — all of which carry substantial activity — produced zero.

   Control 2 — the client's own concurrency does not explain it

   Active session threads per hour, abbreviated to the relevant rows:

   Account	Active threads	Successful items	at capacity
   B (its heaviest hour)	31	973	0
   B	36	339	0
   B	22	130	0
   B	14	356	0
   B	9	637	0
   A	33	503	5

   Account B ran with 31 and 36 concurrent threads and recorded zero capacity errors, including its single heaviest hour (973 successful items). Account A hit 5 errors at 33 threads.

   Concurrency is therefore not the trigger either — B sustained more of it with no errors at all.

   What this leaves

   The failure is independent of:

   • time / provider load
   • the client's own concurrency
   • model (5 models affected)
   • reasoning_effort (high / medium / low all affected)
   • plan, tier, credits (headers byte-identical between the two accounts)

   It tracks only the account. That is consistent with an account-level state rather than any load-dependent explanation.

   Revised request for maintainers: rather than capacity-pool routing alone, could you check whether the account with x-codex-primary-reset-at = 1789805617 carries:

   1. an account-level trust, risk, or abuse flag (or a degradation applied by such a system);
   2. an account-scoped capacity quota distinct from the plan quota (both accounts are pro / premium with identical exposed headers);
   3. an account-scoped experiment or routing assignment affecting /backend-api/codex/responses.

   Limitation, stated plainly: client-side data can establish that the difference is account-scoped and load-independent, but it cannot identify which server-side mechanism produces it. Only the provider side can distinguish a risk flag from a capacity quota.

   Related: #45924 — same app version, same symptom, also reported as account-specific.

   👍React with 👍1Reacted by AloneInfinity
5. eteai commented on Sep 16, 2026

   

   eteai

   on Sep 16, 2026

   Author

   More actions

   Timing evidence: most failures are immediate, which rules out the long-connection explanation

   A common explanation for this class of error is that a long-running stream is closed mid-flight by a proxy, firewall, TLS inspection, or an idle timeout. I measured time-to-failure to test whether that fits.

   Method: for each error entry in the client log, locate the nearest preceding request POST recorded in the same session thread and compute the elapsed time. All figures are elapsed durations, not wall-clock times.

   Selected model is at capacity (n = 47)

   Elapsed	Count
   0–5 s	30
   5–15 s	11
   15–30 s	5
   30–60 s	1

   median 2 s, p90 20 s, maximum 36 s.

   Every occurrence failed within 36 seconds. This is an immediate refusal to start, not a stream that was cut partway through.

   stream disconnected before completion (n = 84)

   Elapsed	Count
   0–5 s	62 (74%)
   5–15 s	1
   15–30 s	3
   30–60 s	1
   60–120 s	3
   120–300 s	2
   300–1925 s	12 (14%)

   median 1 s, p90 1855 s, maximum 1925 s.

   The distribution is bimodal.

   What this implies

   • The at capacity errors are unambiguously immediate refusals — all under 36 s.
   • For stream disconnected, the dominant mode is also immediate: 74% fail within 5 seconds. A stream that terminates in under 5 seconds was never long-running, so an idle timeout, a proxy connection ceiling, or a TLS-inspection interruption cannot account for the majority of these failures.
   • The late failures (14%, 5–32 minutes) are where a genuine mid-stream cut would plausibly appear. They are a minority — and per the account comparison above, they also track the account rather than the transport.

   Taken together with the earlier controls (no occurrences during provider peak load; account B sustaining 31–36 concurrent threads with zero occurrences), the picture points to a server-side decision made at request time, scoped to the account, rather than a transport-level interruption.

   For completeness, the transport side was checked directly and is clean: the local proxy logged 102,504 lines mentioning the relevant domains with 0 error lines, 25,566 routing decisions 100% through the proxy, 0 outbound-node failures, and 15/15 consecutive connectivity probes succeeded at a stable ~0.70 s.

   Methodology caveat: time-to-failure is estimated from the most recent request POST in the same thread rather than from a per-request start marker, so a small number of entries may be attributed to the wrong request. The concentration of 62 of 84 samples in the 0–5 s bucket is robust to that limitation; the individual bucket boundaries are not.

   👍React with 👍1Reacted by AloneInfinity
6. eteai commented on Sep 16, 2026

   

   eteai

   on Sep 16, 2026

   Author

   More actions

   Controlled A/B experiment: same machine, same client, same prompt — only the account differs

   Following the earlier comments, I ran a proper controlled experiment rather than relying on observational log analysis. This is the strongest evidence I can produce from the client side.

   Method

   • Client: codex-cli 0.154.0-alpha.6.2 (the binary shipped inside the Codex desktop app)
   • Identical request every time: codex exec -s read-only --skip-git-repo-check -C <same dir> "Reply with exactly one word: OK"
   • Two batches of 20 requests each. Between batches only the signed-in ChatGPT account was changed — same machine, same network, same proxy, same client build, same models.
   • Each batch's account was verified afterwards from the response header x-codex-primary-reset-at (billing-window fingerprint), so we know which account actually served each batch. Raw per-request output was retained for every run.

   Result

   Batch	Account fingerprint	Success	Failure	Duration
   A	1789805589	0	20	34–174 s
   B	1789950506–1789950511	20	0	21–126 s

   Account A: 100% failure. Account B: 0% failure. Same machine, same minute, same everything else.

   The failure is a two-stage chain — and the WebSocket part is not the account difference

   Every request in both batches went through the identical transport failure:

   ERROR codex_api::endpoint::responses_websocket:
     failed to connect to websocket: IO error: Connection reset by peer (os error 54),
     url: wss://chatgpt.com/backend-api/codex/responses
   ERROR: Reconnecting... 2/5 → 5/5
   warning: Falling back from WebSockets to HTTPS transport. request timed out
   

   Account B hit exactly the same WebSocket resets on every single request and still succeeded — it fell back to HTTPS and completed normally.

   The difference appears only after the fallback:

   Account	After the HTTPS fallback
   A	Selected model is at capacity. Please try a different model. → fails
   B	completes normally

   So these are two independent problems and should not be conflated:

   1. WebSocket transport is being reset — affects both accounts equally, therefore environmental (proxy/network on the client side), not account-related. A client-side workaround exists (supports_websockets = false), and with it the same 20 requests complete in 13–16 s instead of 120–126 s.
   2. After falling back to HTTPS, account A is refused with at capacity while account B succeeds — this is the actual account-scoped defect, and it is downstream of the transport.

   This also means the "long-running WebSocket stream was closed" explanation does not account for the account difference: the WebSocket behaviour was identical on both accounts in the same session.

   Corroboration

   • Selected model is at capacity. Please try a different model. #45924 — another Pro user, same app version, same primary symptom.
   • Codex CLI (ChatGPT login, Pro 20x): frequent ‘stream disconnected before completion’ + repeated ‘Selected model is at capacity’ (Request ID 68f16728-07bb-4a24-b7ca-500757169524) #45949 — Codex CLI on Linux, Pro 20x, reports both the stream disconnected error and Selected model is at capacity, and reproduced it across two different networks. The same symptom pair, from an unrelated environment.

   Request

   The account with x-codex-primary-reset-at = 1789805617 (same account as 1789805589, which is its current window value) is served materially worse than 1789950507 on identical inputs, on the same machine, in the same session. Could the server-side state of that account be checked for an account-level flag, quota, or routing assignment that would explain a 0/20 vs 20/20 split?

   Client-side data can prove the difference is account-scoped; it cannot identify which server-side mechanism produces it.

   👍React with 👍1Reacted by AloneInfinity
7. eteai commented on Sep 16, 2026

   

   eteai

   on Sep 16, 2026

   Author

   More actions

   Decisive discriminator: the failure is specific to the Codex service path, not to the account

   A new control isolates the problem much more tightly than anything above.

   Same account, same browser, same machine, same network, same session:

   Surface	Result
   Codex (chatgpt.com/codex) on account A	"Selected model is at capacity. Please try other models." — fails
   Regular ChatGPT chat on account A	works normally — normal reply produced
   Codex on account B	works normally

   This rules out several explanations at once:

   • Not a general account degradation or account-level flag — regular ChatGPT chat on the same account works fine.
   • Not a region-level restriction — again, regular chat is unaffected.
   • Not the network, proxy, or browser — both surfaces were exercised from the same browser on the same connection.
   • Not a client implementation issue — the failure now reproduces on three independent clients: the desktop app, the Codex CLI, and Codex on the web.

   What remains is narrower and more actionable: account A is limited or throttled specifically on the Codex service path, while the rest of the account is unaffected.

   Account A
     ├─ regular ChatGPT  (different backend path)          → works
     └─ Codex            (/backend-api/codex/responses)    → refused
   

   A note on request IDs, since it affects what can be reported

   While assembling data for a separate report I found that the client is not always given a request ID:

   • stream disconnected before completion errors do carry a request ID in the message body.
   • Selected model is at capacity errors — the ones that actually characterise this account difference — do not carry any request ID.
   • Successful requests expose no server-side request ID at all. The response headers for a completed request contain only transfer-encoding, connection, server, and the x-codex-* quota headers — there is no x-request-id or equivalent.

   So for anything other than a stream disconnected error, a client-side report cannot supply a correlating request ID. Asking users for one on a successful request or on a capacity refusal cannot be satisfied. If there is another client-visible handle that could be logged instead, that would make reports like this far easier to act on.

   Why this matters for triage

   The failure being Codex-path-specific makes it checkable directly: is account A hitting a Codex-specific quota or rate limit, or does it carry a Codex-service-scoped flag, distinct from the account's general standing?