"Selected model is at capacity" in Codex: not a usage limit

The string is not a generic UI message — it's written directly into Codex's open-source code as the display text of a specific error variant, ServerOverloaded. Codex raises it when the backend responds with HTTP 503 and an error code of server_is_overloaded; a different 503 code, slow_down, is mapped to a separate rate-limit error instead, so the two aren't the same code path even though both start as a 503 (source).

An OpenAI status-page incident used this exact title and listed the affected surfaces as Codex Web, the Codex API, the CLI, the VS Code extension, and Codex in ChatGPT Desktop (status.openai.com). Third-party relay gateways that proxy Codex traffic can pass the identical string straight through to their own users, unmodified (example).

It is not the same message everywhere. Claude Code's own overload error is worded differently ("API Error: Repeated 529 Overloaded errors"), and Anthropic's own docs say explicitly that a 529 "is not your usage limit" either (Claude Code docs). Cursor doesn't use this wording at all: a search of Cursor's own forum for the exact phrase returns no results, and Cursor shows a differently worded message of its own, "We're experiencing high demand for the selected model right now" (Cursor forum). We could not find an official OpenAI statement that this exact string appears in the ChatGPT web app, so this page does not claim that it does.

Capacity is also regional, not global: an OpenAI maintainer described the shortage as being specific to "your region," and in one case where one account on a machine failed constantly while a second account on the same machine succeeded, the maintainer said they suspected — without confirming — that the two sessions were simply routed to different regions or data centers (openai/codex #46103).

• Switch models. The error message itself suggests this, and it matches Claude Code's own advice for its equivalent overload error, since capacity is tracked per model, not per account (Claude Code docs).
• Wait and retry. The error is often transient — one reporter found the same model and account succeeded on a later, otherwise-identical request (openai/codex #17014).
• Check status.openai.com. A prior wave of this exact error, in June 2026, had a matching incident on OpenAI's own status page (status.openai.com).

On automatic retries: Codex's own test suite shows a 503 response carrying a Retry-After header being retried and recovering, which suggests some request-level retry already exists for at least that case (test source, inferred from test code, not documented as behavior you can rely on). A pull request specifically adding retry handling for this capacity error was still open and unmerged as of September 23, 2026 (openai/codex #31058), and in practice a long-running Codex task can still end on this error with no automatic retry and no retained state (openai/codex #22390).

OpenAI has not published a typical duration for this error. What's on the record, from specific incidents:

• June 16, 2026 status-page incident: about 3 hours 16 minutes from "identified" to "fully recovered" (status.openai.com).
• May 12, 2026: a GitHub issue tracking a wave of this error was opened and marked mitigated by OpenAI staff about 8 hours later (openai/codex #22277).
• A July 17, 2026 incident about server-overload errors on a specific Codex model lasted roughly 3 hours 23 minutes. It's linked here because of the matching "server-overload" wording, not because OpenAI has confirmed it's the same underlying issue (status.openai.com).
• Report volume rose sharply in September 2026: a GitHub search for the exact phrase in the openai/codex repository returns on the order of 150 issues opened between September 1–23, 2026, versus roughly 24 in August and 24 in June — an approximate search count, not an official figure (issue search).

A single occurrence can also simply clear up on retry within minutes (see "What to try" above) — there's no one fixed pattern.

OpenAI's own Codex maintainers, across several 2026 issue threads, have explained this message the same way each time: a shortage of server-side capacity for a specific model, not anything about your account (see the quotes below). That has been the consistent line since at least April 2026.

In September 2026, an OpenAI community-team staff member posted in a thread specifically about this error:

"Access to certain models or features may be temporarily limited based on account activity, even when a paid subscription is active." — Prashant_Pardesi, OpenAI Community team, community.openai.com

That post does not say this specific error message is caused by such a restriction — it's a general statement about account-activity-based access limits, posted in a thread about this error, not a direct claim that the two are the same thing. The same post adds:

"Access is automatically reassessed and can return to normal once the activity affecting availability stops." — Prashant_Pardesi, OpenAI Community team, community.openai.com

So, as of this writing, there are two separate, only loosely connected threads of official commentary: a server-capacity explanation given directly about this error message, and a general note about account-activity-based access limits posted in the same discussion. We have not found an OpenAI statement that directly equates the two, and this page does not present them as the same thing.

If what you're actually looking at says something like "Try again at <time>", that's Codex's separate usage-limit error, not this one — in the code, only the usage-limit error carries a reset timestamp (source). That's the case to check this site's own Codex reset history or the reset-odds tool for — not this page.

One wrinkle worth knowing: the Codex Desktop app's own capacity banner has, in at least one reported case, included its own "Try again after <date>" wording as part of the capacity message itself (openai/codex #11635) — worded with "after" rather than "at," but easy to confuse. In that same thread, one user noted the time shown happened to match their own weekly usage-limit reset time; the maintainer described the thread as being about server capacity, not usage accounting:

"this thread is unrelated to usage accounting or reporting ... which is about insufficient capacity on the server for a given model." — openai/codex maintainer, openai/codex #11635

So a "try again" phrase alone isn't a fully reliable signal by itself — check whether the message is naming a usage or plan limit specifically, or just says the model is at capacity.