Codex long-running tasks repeatedly hit `server_overloaded` / At Capacity despite ~70% usage remaining
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 8/100
- Issue type
- Bug
- Clarity
- Needs clarification
- Activity status
- Active
- Domain
- ai-infra-agents
Research direction
The payload names no source files, tests or entry points, only server-side server_overloaded errors and a related report, #46632. A newcomer cannot start from code here; the first step is to read the comment thread and #46632 to see whether a maintainer has already triaged this as an incident. Done would mean a maintainer confirms the root cause or closes it as a duplicate, not a code change.
Written by the indexing model from the issue text.
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).
- Dominant language
- Rust
- Stars
- 129k
- Forks
- 20.3k
- Avg merge
- 1m
- Merged PRs (30d)
- 998
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from openai/codex
-
Python SDK: CodexClient.close() leaves the app-server's stdout/stderr pipes open (and never waits after kill)Possibly taken @akhil9tiet claimed this 1 day ago. Openapp-server bug
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
openai/codex#54908 · 2 comments ·
Maintainers usually reply within 1 day
-
bug CLI tool-calls windows-os
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Maintainers usually reply within 1 day
-
bug tool-calls
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
Clarification about NODE_REPL_TRUSTED_BROWSER_CLIENT_SHA256S in the VS Code extension environmentOpendocumentation extension windows-os
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
openai/codex#54780 · 1 comment ·
Maintainers usually reply within 1 day
-
bug context
Difficulty 2/5 Under an hour Newbie friendliness 74/100
Maintainers usually reply within 1 day
Similar issues
-
area:gc-repack-output bug factory:dogfood factory:triaged priority:p3 type:bug type:ux
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
gitbutlerapp/grit#1161 · 1 comment ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
feature
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
-
priority: low
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
storytold/photocraft#7520 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Maintainers usually reply within 1 day