Repository navigation
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
Description
I’m using Codex CLI on Linux, authenticated via “Sign in with ChatGPT” (not an API key). My account is on a ChatGPT Pro 20x tier. Starting today, reliability has degraded significantly and is seriously impacting usage.
Problem A — Streaming disconnects (incomplete responses):
- During normal prompts, the CLI often fails mid-response with: “stream disconnected before completion … An error occurred while processing your request.”
- This interrupts generation and forces retries; work cannot be completed reliably.
- Example request ID:
68f16728-07bb-4a24-b7ca-500757169524(please correlate with my timestamps/time zone).
Problem B — Capacity message blocks the selected model:
- Frequently see: “Selected model is at capacity. Please try a different model.”
- This happens repeatedly today (previously rare) and prevents consistent use of the selected model.
Network / environment notes:
- Initially observed on CERN internal network; I also reproduced after switching to a different network, so it’s not isolated to that network.
- OS: Linux (CLI). Codex CLI version: (fill in from
codex --version) - Model selected: (fill in)
- Approx timestamps + timezone: (fill in)
Expected: Stable streaming responses and model access consistent with my plan.
Actual: Frequent disconnects and repeated capacity blocks; overall experience is not acceptable for a paid Pro-tier workflow.
Activity
eteai commentedon Sep 16, 2026
Cross-referencing #45925.
Your report matches a symptom pair I have been investigating and reproducing:
stream disconnected before completiontogether withSelected model is at capacity. Please try a different model.The two appear to be linked — the capacity refusal shows up right after the client falls back from the WebSocket transport to HTTPS.Two things from my side that may be useful to you:
The WebSocket transport failure (
Connection reset by peeronwss://chatgpt.com/backend-api/codex/responses) is environmental and not account-specific — I observe it on two different accounts from the same machine. A client-side workaround that skips WebSocket entirely exists: declare a provider withsupports_websockets = false(the built-inopenaiprovider cannot be overridden, so mirror it under a custom name). With it, requests drop from ~120 s to ~13–16 s and the WebSocket errors disappear entirely. It does not fix theat capacityrefusal.For the
at capacity/ disconnect part, a controlled A/B on one machine — 20 identical requests per account, nothing changed but the signed-in account — gave 0/20 successes on one account and 20/20 on the other. So it can be strongly account-scoped. If you have a second account available, that comparison is worth running; it produces much stronger evidence than log observation.Details, method and raw data: #45925.
github-actions commentedon Sep 16, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
stream disconnected before completionis account-scoped — switching ChatGPT accounts changes the failure rate ~7× #45925Powered by Codex Action
eteai commentedon Sep 16, 2026
A control that may be worth running, from an investigation in #45925.
If you have access to a second ChatGPT account, the single most informative comparison is:
On the account I was investigating, Codex failed with
Selected model is at capacitywhile regular ChatGPT chat on the same account, same browser, same network, worked normally. That combination rules out a general account problem, a region restriction, and anything client- or network-side — and points specifically at a Codex-service-scoped limit on the account.If several of us can reproduce that split, it is a much sharper signal than the raw error alone.
Two related findings that may save you time:
Selected model is at capacityerror does not carry a request ID, and successful requests expose no server-side request ID at all — onlystream disconnectederrors do. So a request ID cannot be supplied for every failure.Connection reset by peeronwss://chatgpt.com/backend-api/codex/responses) is separate and affects working accounts too. It can be bypassed client-side with a provider that setssupports_websockets = false, which cut request time from ~120s to ~13-16s in my testing. It does not change the capacity refusal.Full method and raw data: #45925.