Repository navigation
Frequent "Selected model is at capacity" on GPT-6.1-Sol despite 97% 5h and 99% weekly quota remaining #50252
Description
What version of Codex CLI is running?
0.159.3
What subscription do you have?
ChatGPT Plus
Which model were you using?
GPT-6.1-Sol (reasoning: medium, summaries: auto)
What happened?
Codex CLI repeatedly stops very early during normal repository analysis with:
Selected model is at capacity. Please try a different model.
This happens even though the account has almost all usage allowance remaining and plenty of context window available.
At the time of the failure, /status showed:
Server: Local background server
Model: GPT-6.1-Sol (reasoning medium, summaries auto)
Model provider: openai
Permissions: Workspace (Ask for approval)
Account: Plus
Context window: 76% left (70.7K used / 258K)
5h limit: 97% left
Weekly limit: 99% left
The task was ordinary local repository inspection (searching/reading Web UI and Java server files). The failure occurred shortly after the task started, not near the context or usage limits.
Expected behavior
Codex should continue the task when the account has available quota, or distinguish transient backend/model-capacity failures from account rate-limit/quota failures and retry appropriately.
Actual behavior
The task terminates immediately with:
Selected model is at capacity. Please try a different model.
This can happen after only a small amount of work, requiring manual continuation/retry.
Additional context
There are other reports of the same capacity message (for example #46142), and #50074 reports related behavior on Codex CLI 0.159.3. This report adds a reproducible case on GPT-6.1-Sol with a Plus account where both the 5-hour and weekly quotas are almost completely unused.
No request IDs are available yet. I can provide diagnostic logs/request IDs if maintainers specify which Codex CLI diagnostics would be most useful.
Activity
github-actions commentedon Oct 2, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
aetherxeg-source commentedon Oct 2, 2026
A useful diagnostic boundary here is:
account quota availability != model-serving capacityBoth can prevent execution, but they are different authorities and should remain different evidence classes. A capacity rejection should carry a reason class tied to the serving model/backend generation, while quota/rate-limit decisions should cite the account-limit authority.
Conceptually:
The UI should not let a healthy quota display imply that capacity cannot be the blocker, and conversely should not present a transient capacity failure as an account-limit condition.
A useful conformance test is to inject the same request under three independent failures: exhausted quota, transient model capacity, and provider rate-limit. Each must produce a distinct typed verdict and retry policy. For the capacity case, a bounded retry should preserve the same logical turn identity so a retry cannot accidentally duplicate already-started work.
That makes
/statusand the terminal failure mutually interpretable rather than two unrelated observations.zhbllc-CPU commentedon Oct 3, 2026
URGENT: Repeated gpt-6.1-sol capacity failures on October 3, 2026
Our Codex tasks using gpt-6.1-sol repeatedly fail with:
During the same period, gpt-6-astra tasks work without this error.
These are our observed results; the root cause and whether there is a wider outage have not been confirmed.
Please urgently investigate model-specific capacity, admission, and routing, and restore normal service as soon as possible. Please provide a status update and a supported workaround.
jmurph8111 commentedon Oct 12, 2026
@rrez2002 @aetherxeg-source @fcoury @zhbllc-CPU Find the solution?? Im dying, i got 2k in credits and 200 dollar subscription litterally unsuable I cant DO ANYTHING. ITS UNBEARABLE
chenzhiwu commentedon Oct 13, 2026
Same issue here on ChatGPT Pro, Codex CLI 0.162.1, macOS arm64, mostly gpt-6.1-sol (high), with 99% weekly quota left.
Since Oct 8, about 50% of my turns fail with
server_overloaded/ "Selected model is at capacity" (97 failures in total). It also happens on gpt-6-sol, gpt-5.6-sol and gpt-5.6-luna. Many of the failures come mid-turn, after tool calls have already succeeded. Changing the egress IP and running with--no-daemondon't help.Full details with UTC timestamps and turn IDs: #53531