Repository navigation
Widespread “Selected model is at capacity” errors are making Codex unreliable, including for Pro users #43786
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.901.51231
What subscription do you have?
ChatGPT Pro
What platform is your computer?
Darwin 24.6.0 x86_64 i386
What issue are you seeing?
Codex has recently become extremely unreliable due to frequent:
"Selected model is at capacity. Please try a different model."
errors.
This is clearly not an isolated incident. There have been numerous recent reports from other Codex users experiencing the same problem, including ChatGPT Pro subscribers. For a paid Pro service, the current frequency of these capacity failures is becoming unacceptable and is seriously disrupting normal development workflows.
The problem is not limited to occasional peak-time failures. It can happen repeatedly during normal Codex usage and frequently interrupts long-running agent tasks after substantial work has already been completed.
In my experience:
- The error occurs repeatedly, not just once or twice.
- ChatGPT Pro accounts are also affected.
- Usage quota can still be available when the error occurs.
- Retrying often immediately produces the same capacity error.
- Switching to another model does not always resolve it.
- Continuous or concurrent Codex usage appears to make the issue significantly worse.
- Long-running coding tasks can be interrupted halfway through execution.
This makes Codex very difficult to rely on for serious development work. A coding agent must be able to execute a multi-step task without randomly losing model availability in the middle of the workflow.
More importantly, the current error message is too vague.
"Selected model is at capacity" does not tell users whether the actual cause is:
- global model capacity exhaustion,
- account-level capacity allocation,
- account-level routing,
- concurrency throttling,
- rate limiting,
- regional capacity,
- backend overload protection,
- or some other internal scheduling mechanism.
This distinction matters, especially for Pro users who are paying for higher usage limits and still have significant quota remaining.
Please investigate this as a broader Codex service reliability issue rather than treating it as an isolated transient model-capacity error.
At minimum, Codex should:
- Automatically retry temporary capacity errors using exponential backoff instead of immediately failing the agent task.
- Preserve the current execution state and resume automatically when capacity becomes available.
- Clearly distinguish model capacity errors from rate limits, quota limits, concurrency limits, and account-level throttling.
- Avoid terminating long-running agent workflows because of short-lived backend capacity shortages.
- Provide better transparency about whether Pro users have dedicated/different capacity allocation or are subject to the same overloaded capacity pool.
Given the number of recent reports from other users, including Pro subscribers, I believe this deserves investigation as a service-level reliability problem.
Please clarify whether the Codex team is already aware of the current increase in capacity errors and whether any mitigation is being implemented.
What steps can reproduce the bug?
anything
What is the expected behavior?
No response
Additional information
No response
Activity
github-actions commentedon Sep 8, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Saphulot commentedon Sep 8, 2026
I reviewed the related issues detected by the bot.
This appears to be part of a broader ongoing capacity problem rather than an isolated report. Multiple recent reports, including #43700, #43663, #43738, and #43688, describe the same "Selected model is at capacity" behavior, including on ChatGPT Pro / Pro 20x accounts with substantial or even 100% usage remaining.
Some of those reports also show server_overloaded in the rollout logs.
I am keeping this issue open for now because the problem is still actively occurring and appears to be affecting multiple Pro users across Codex App/CLI.
It would be helpful if the Codex team could confirm whether this is a known backend capacity incident and whether mitigation is currently underway.