Repository navigation
Codex long-running tasks repeatedly hit server_overloaded / At Capacity despite ~70% usage remaining #52394
Description
Summary
On Windows Codex Desktop, long-running tasks have become unreliable due to repeated "Selected model is at capacity. Please try a different model." errors. Model switching can briefly resume work but the error returns soon afterward, interrupting the same task. The usage dashboard still shows approximately 70% remaining.
The issue became substantially worse on 2026-10-09 (UTC+08:00); 2026-10-08 was relatively normal.
Environment
- Product: Codex Desktop on Windows
- Affected selected models: GPT-6.1 Sol, GPT-6 Astra (and GPT-6 Sol observed during switching)
- Account usage: approximately 70% remaining when the issue occurred
- Workload: one long-running, multi-step task involving repeated model/tool turns
Observed behavior
- Start a long-running task and allow multiple turns/tool operations.
- Partway through, Codex reports "Selected model is at capacity" and shows reconnect attempts (up to 5/5 in the UI).
- Switch to a different high-tier model.
- The existing task can make further progress briefly, but At Capacity recurs shortly afterward.
- The repeated interruptions make it difficult to finish the long-running task even though the account has substantial remaining usage.
Locally observed evidence
A read-only PowerShell search of recent Codex session .jsonl logs found:
- 41 matches containing
server_overloaded - 41 matches containing the text
Selected model is at capacity - 0 matches for
server_is_overloaded - 0 matches for
stream disconnected
Important: These are keyword-match counts, not 41 confirmed independent failures. The two sets of 41 matches may refer to the same underlying log events. The failures were primarily observed while working on one long-running task.
No raw logs, project content, local filesystem paths, account identifiers, or authentication material are included in this public report.
Expected behavior
When model capacity is temporarily unavailable, Codex should recover from transient server overload where possible, preserve progress across retries/model switches, and continue the long-running task without repeated manual intervention. Remaining usage quota should be differentiated clearly from transient service-capacity errors.
Request
Could the team investigate:
- Service-side capacity / routing for the affected high-tier models when usage quota remains available.
- Whether switching models during a long-running conversation continues hitting the same overloaded infrastructure or request path.
- How
server_overloadedis retried and how interrupted long-running tool/task state is recovered after retry exhaustion. - Whether a currently active incident or known regression explains the worsening on 2026-10-09.
Screenshots of the UI error and the aggregated local error counts can be provided on request.
Related report for context: #46632 (capacity errors reported despite unused quota; not asserting an identical root cause).
Activity
github-actions commentedon Oct 9, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
huaqiyingxue commentedon Oct 9, 2026
I am experiencing a very similar issue on ChatGPT Work for Windows, and I have collected precise failure records from the local Codex session transcripts.
Environment
Reproduction and Observed Behavior
Session IDs
Diagnostic feedback was successfully submitted through the desktop app for both sessions:
01a11b2b-a3ea-7fd3-ad85-ae2845206bdd01a11ee2-f767-7940-b78e-f96ee911c3ddConfirmed JSONL Failures
Both failures below are from the second session.
Failure 1 — Line 648
2026-10-09T06:26:34.512Z01a11f55-a6fa-79c3-a16a-075cce3c7658task_completeserver_overloaded125023 msnullFailure 2 — Line 776
2026-10-09T06:41:02.767Z01a11f5a-0e61-7743-9b85-5c0416011db7task_completeserver_overloaded704669 msnullBoth events contain the exact error message:
Selected model is at capacity. Please try a different model.The second failure occurred after approximately 11 minutes and 45 seconds of task execution.
Request
Could the maintainers investigate the persistent
server_overloadedfailures affecting Windows desktop Work sessions, including model routing, capacity allocation, and task recovery behavior?The issue has significantly disrupted long-running tasks across multiple conversations.
I have already submitted in-app diagnostic feedback and can provide additional redacted log excerpts if required.
Thank you.
majinqing commentedon Oct 10, 2026
I also have the same problem
majinqing commentedon Oct 10, 2026
Is there a solution
isYaoNoistu commentedon Oct 10, 2026
I also have the same problem
yiyuyanshen commentedon Oct 10, 2026
Additional reproducible diagnostics from Windows 11:
Selected model is at capacity/codex_error_info: server_overloadedin brand-new conversations as well as long-running tasks, on GPT-6 Astra and GPT-6.1 Sol.codex -m gpt-6-astrasuccessfully responds to a simple prompt.task_completeerrors all containcodex_error_info: server_overloaded(2026-10-10).service_tier = "priority", and removing theCODEX_CLI_PATHoverride did not resolve it. Process inspection confirmed Desktop runs its own backend underAppData\\Local\\OpenAI\\Codex\\bin\\...\\codex.exe, not the npm CLI.This points to a Desktop-specific failure path rather than a general inability of the account/model to serve CLI requests. Please investigate Desktop routing/retry/streaming behavior. No credentials or private logs included.
yiyuyanshen commentedon Oct 10, 2026
Additional observation / possible trigger (not yet confirmed by controlled A/B testing): On Windows Codex Desktop, the repeated
server_overloaded/Selected model is at capacityfailures seem to occur when I use the UI's Goal / 目标 mode. When I do not use that mode, tasks appear to run normally. This could explain why reinstalling, repairing, changing models, and clearing caches did not provide a lasting fix. I have not yet verified the exact mode implementation or performed repeated same-task A/B tests, so please treat this as a promising correlation rather than a confirmed root cause. It may be useful to compare the request and task-execution paths with Goal mode enabled versus disabled.bigerbigernerd commentedon Oct 12, 2026
same issue
lumpyjoe108 commentedon Oct 13, 2026
Additional independent report (Australia, 12–13 October 2026):
Request: Please investigate server-side capacity/routing and how
server_overloadedis retried during remote compaction and long-running agent work. Temporary capacity failures should back off and resume without terminalising an ongoing optimisation task.This is a symptom report based on observed UI messages. No private repo contents, account IDs, raw logs or session identifiers are included here.
JYAFF commentedon Oct 13, 2026
Environment
Product: Codex desktop app for Windows
Subscription: ChatGPT Pro ($200/month)
Primary model/configuration: GPT6-astra and GPT6.1-soul, both at the ultra setting
Affected models: Multiple models available in the desktop app, not only my primary selection
Observed behavior
Start a long-running task in the Windows desktop app and let it run.
During execution, the app displays:
“Selected model is at capacity. Please try a different model.”
I have also observed the UI entering a reconnecting state, such as “1/5”, with task execution interrupted.
Retry or switch to another available model.
Capacity errors continue to occur, so switching models is not a reliable workaround.
This is not a single, brief incident. It has repeatedly disrupted my normal use over several days, and its frequency keeps increasing, making it difficult to rely on Codex to complete longer tasks. My usage quota is still plentiful when these errors occur, so this does not appear to be caused by hitting my plan’s limits.
mc935330004 commentedon Oct 13, 2026
I'm encountering the same recurring capacity error in Codex on 2026-10-13 (UTC+08:00).
Exact error:
What I observed:
I haven't independently confirmed the root cause or whether other models work in my environment. The screenshot shows the repeated capacity message, but no backend error codes are available to me.
Could the team please investigate whether capacity/routing issues or conversation compaction retries can cause these repeated failures, and share a workaround or service update? I can provide a screenshot if needed (without exposing project or account details).
Thank you.