Codex says "Selected model is at capacity. Please try a different model."
"Selected model is at capacity. Please try a different model." is Codex's own text for the server_is_overloaded error code. Per the openai/codex source (rust-v0.163.0, checked 2026-10-17), Codex shows it when the server answers HTTP 503 with that code, or when a streamed response fails with that code. It is not a usage limit: Codex's usage-limit messages read differently, starting with "You’ve hit your usage limit" or otherwise naming a usage limit, your workspace's credits or a spend cap. By the time the message appears, Codex has already made the retries it makes for this error, so send the prompt again later or pick another model with /model.
What the message means
For this error Codex prints fixed text of its own. Per the openai/codex source (rust-v0.163.0, checked 2026-10-17), Codex reads the server_is_overloaded code in two places: the JSON body of an HTTP 503 response, as "error": {"code": "server_is_overloaded"}, and a response.failed event inside a streamed response. Whatever message the server sends along with the code, Codex shows "Selected model is at capacity. Please try a different model." instead, so the advice to try a different model is Codex's, not the server's. A 429 rate limit, a usage limit and an HTTP 500 each have a message of their own (see the FAQ below).
What Codex already retried
Per the same source, Codex can retry this error in two layers before it shows the message:
- HTTP layer: an HTTP 503 is retried like any other 5xx response, up to request_max_retries times (documented default 4). This layer never retries a 429.
- Sampling loop: after that, Codex retries the overload only when the server said when to retry (a Retry-After value), up to stream_max_retries times (documented default 5; on the built-in OpenAI provider, which streams over WebSockets, the count starts again after Codex falls back to HTTPS), and can print Reconnecting... lines while it waits. Without that advice the turn ends right away.
- Inside a stream: an overload reported by a response.failed event gets no HTTP-layer retry. Codex retries it only when the failure event itself carries retry advice; a Retry-After header on the HTTP response that carried the stream does not count.
- OpenAI's Codex changelog entry for Codex CLI 0.161.0 (2026-10-07, checked 2026-10-17) reads: "Responses retries and WebSocket-to-HTTP fallback honor server retry guidance, reducing premature failures during overload."
What to do next
Send the prompt again after a short wait: the failed turn has already ended, and anything Codex finished earlier in it, such as file edits, stays as it is. If the message keeps coming back on the same model, do what it says and pick another model. Per OpenAI's Codex models page (checked 2026-10-17), /model in an interactive CLI session switches models or adjusts reasoning effort, and --model or its -m alias picks the model when you start Codex, for codex exec runs too. To start new sessions on another model, change the top-level model line in ~/.codex/config.toml. In scripts, retry a capped number of times with growing waits instead of looping on the error. Through Router One, switch only to a catalog model whose /models page lists POST /v1/responses, the endpoint Codex calls.
codex --model <model-id> # start Codex on another model codex exec -m <model-id> "<prompt>" # the same option for a non-interactive run
Where Router One fits
Router One does not promise capacity. When a route returns an eligible error, Router One can try another healthy route serving the same exact model, when one is available; the model ID you asked for stays the same, and this is not a zero-downtime guarantee. If no route is available, the request fails with an error that Codex reports, and you retry with bounded backoff or switch models. Look the request up in Dashboard → Logs by time and model: a row there shows its status and error message. If one model keeps failing, email support@router.one with the time, the model and, when the request has a row, its request ID.
FAQ
Is "Selected model is at capacity" a usage limit?
No. Per the openai/codex source (rust-v0.163.0, checked 2026-10-17), Codex reports usage limits with messages of their own, which start with "You’ve hit your usage limit" or otherwise name a usage limit, your workspace's credits or a spend cap, and an exhausted quota or spend limit with "Quota exceeded. Check your plan and billing details." "Selected model is at capacity" only means the server answered with the server_is_overloaded code.
Is it the same as "exceeded retry limit, last status: 429 Too Many Requests"?
No. That message is how Codex reports a 429 it stopped retrying: per the openai/codex source (rust-v0.163.0, checked 2026-10-17), the HTTP layer never retries a 429, and the sampling loop retries one only when the response says when to retry. What to check for that message, Dashboard → Logs included, is on the Codex exceeded-retry-limit page (https://router.one/codex-exceeded-retry-limit).
Codex printed "We’re currently experiencing high demand, which may cause temporary errors." Is that the same error?
No. Per the openai/codex source (rust-v0.163.0, checked 2026-10-17), that sentence is Codex's text for an HTTP 500 response. Codex retries a 500 in both layers with backoff even when the server gives no retry advice, so by the time it appears those retries have run out as well. Treat it the same way: send the prompt again later, and switch models if it keeps happening on one.
Can I make Codex keep retrying for longer?
Yes, within limits. Per Codex's configuration reference (checked 2026-10-17), request_max_retries (default 4) and stream_max_retries (default 5) are settings on your [model_providers.<id>] block in ~/.codex/config.toml. Per the openai/codex source (rust-v0.163.0), the stream budget applies to this error only when the server gives retry advice. Higher values can make Codex keep trying longer before it shows the message (for an HTTP 503, and for a streamed failure only when the failure event carries retry advice); they do not add capacity.
Does Router One switch to another model when one is overloaded?
No. Router One keeps the model ID you asked for. When a route returns an eligible error, it can try another healthy route serving the same exact model, when one is available; that is neither a capacity promise nor a zero-downtime guarantee. To move to another model, change it in Codex with /model or in the model line of ~/.codex/config.toml. The LLM fallback page (https://router.one/llm-fallback) explains how these retries work.
I use Codex from Mainland China. Is this a network problem?
No. The message stands for an error code in a server response, so the request did get an answer; network trouble shows up as different Codex errors, such as the stream-disconnected messages covered on the Codex Responses API page. Router One's endpoint is reachable from Mainland China without a VPN, with the same config.toml as anywhere else.