Skip to content

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

Open

Description

@Saphulot

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

Activity

  1. added
    appIssues related to the Codex desktop app
    on Sep 8, 2026
  2. added
    bugSomething isn't working
    connectivityIssues involving networking or endpoint connectivity problems (disconnections)
    on Sep 8, 2026
  3. Saphulot commented on Sep 8, 2026

    @Saphulot
    Author

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingconnectivityIssues involving networking or endpoint connectivity problems (disconnections)

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions