Widespread “Selected model is at capacity” errors are making Codex unreliable, including for Pro users

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:

1. Automatically retry temporary capacity errors using exponential backoff instead of immediately failing the agent task.
2. Preserve the current execution state and resume automatically when capacity becomes available.
3. Clearly distinguish model capacity errors from rate limits, quota limits, concurrency limits, and account-level throttling.
4. Avoid terminating long-running agent workflows because of short-lived backend capacity shortages.
5. 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

No files, tests, or entry points are named. Start by reproducing the error with any Codex task and compare repeated retries, model switches, and available quota. Done would require reliable handling of temporary capacity failures, preserved long-running task state, and clearer distinction between capacity, quota, rate, and concurrency errors.