# Codex “Selected Model Is at Capacity”: Not Your Limit, What to Do

> “Selected model is at capacity” means OpenAI had no room to serve that model, not that you ran out of usage. Wait, try one other model, or start a new chat.

- URL: https://blog.laozhang.ai/en/posts/codex-selected-model-at-capacity
- Published: 2026-10-15
- Updated: 2026-10-15
- Author: LaoZhang AI Team (https://blog.laozhang.ai/en/about)
- Topic: Troubleshooting
- Tags: Codex, Selected Model Is at Capacity, server_overloaded, GPT-6.1 Sol, Troubleshooting

---
Codex ends a failed turn with this line when OpenAI tells it the model you picked has no room for your request:

```text
Selected model is at capacity. Please try a different model.
```

It is not a usage limit, not a rate limit on your account, and not a retired model. In the current Codex client (rust-v0.162.1, released October 9, 2026), the line appears only when the server returns the error code `server_is_overloaded`. An OpenAI Codex maintainer described it this way on GitHub: it "does not mean that you are being rate limited or are out of usage. It means that we are running low on capacity to serve this model in your region." Your remaining usage does not change the outcome. If the overload arrived before the response started, Codex already retried it several times before showing you the line.

What to do, in order:

1. Wait a few minutes and send the turn again. The public incidents behind recent waves were resolved within the day.
2. If it fails again, pick one other model in `/model` (or the model picker in the app) and try once.
3. If you were deep in a long conversation, open a new chat and give it a short summary of where you were.
4. If every model and a fresh chat keep failing for more than an hour, check the OpenAI status page, then report it with `/feedback`.

The rest of this guide shows how to confirm you hit this error and not a lookalike, what Codex did before printing it, and which of those steps fits your situation.

## What “Selected model is at capacity” means in Codex

The message is fixed text in the Codex source. In `protocol/src/error.rs` at tag rust-v0.162.1, the error `ServerOverloaded` displays exactly "Selected model is at capacity. Please try a different model." Codex raises that error in two situations only:

- The server answers **HTTP 503** and the JSON body carries `error.code: "server_is_overloaded"`.
- The response stream has already started and then sends a `response.failed` event with the same code.

Everything else goes elsewhere. A 503 with a different body becomes `unexpected status 503 …`. A 429 goes to the usage-limit message, the quota message, or the bare "exceeded retry limit" line. So the capacity line tells you one specific thing: the server said the model was overloaded.

`server_is_overloaded` is a standard OpenAI API error, not a Codex invention. [OpenAI's API error-codes guide](https://developers.openai.com/api/docs/guides/error-codes) lists it as "503 - Model temporarily overloaded", with the cause "The requested model is temporarily overloaded" and the advice to follow the `Retry-After` header when present, then retry. The same guide lists the 429 errors for request-rate problems separately. What load or routing condition makes OpenAI send the code is not published.

When Codex shows the line, the turn stops. In the session log the failed turn has no final reply (`last_agent_message: null`) and an error tagged `codex_error_info: "server_overloaded"`. That tag is what you check in the next section.

## Is my account flagged, or out of usage?

No evidence points to an account flag. An OpenAI Codex maintainer has answered this question several times in the openai/codex GitHub repository:

- April 7, 2026 (issue #17014): "This isn't a rate limiting message — that is, it's not specific to your account. This message indicates that we are out of capacity on this model."
- May 12, 2026 (issue #19583): "it does not mean that you are being rate limited or are out of usage."
- September 17, 2026 (issue #46103): a Plus account failed 11 of 11 requests while a Free account on the same machine, network, client and model succeeded 11 of 11. The maintainer replied: "I suspect this is because your two sessions were routed to different regions (data centers)."

That last case explains why the error can feel personal. Two sessions can land in different OpenAI data centers, so one person can fail repeatedly while a coworker is fine. "Region" here means the data center serving the session, not your country. A VPN does not choose it: the reporter of issue #53524 switched between US, Japan and Singapore routes on October 13 and nothing changed.

Claims on forums that the message means your account went into a "risk control" pool, or that changing your password, re-enabling two-factor authentication and staying signed out for 48 hours fixes it, have no public evidence behind them. They contradict the maintainer statements above. Deleting `~/.codex`, reinstalling Codex or buying credits also does nothing for this error. None of them changes which server answers your request, and nothing in this error path looks at your usage.

To confirm your usage separately, run `/status` (session settings and token usage) or `/usage` (account usage) in the CLI. In GitHub reports from October 13 and 14, people hit the capacity error with most of their usage left. One Pro user had 99% of the weekly quota remaining, and OpenAI Support told them it was not a rate limit.

## Confirm it in your session logs: search for `server_overloaded`

Codex writes every session to `~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl` (or under `$CODEX_HOME` if you set it). On macOS or Linux, this lists the session files that hit the capacity error:

```bash
grep -rl "server_overloaded" ~/.codex/sessions
```

This counts the failures and prints the exact error that was recorded:

```bash
grep -rh "server_overloaded" ~/.codex/sessions | grep -o '"error":{[^}]*}' | sort | uniq -c
```

On the LaoZhang AI Team authoring Mac on October 15, 2026, the second command printed:

```text
17 "error":{"message":"Selected model is at capacity. Please try a different model.","codex_error_info":"server_overloaded"}
```

On Windows the sessions live in `%USERPROFILE%\.codex\sessions`. This PowerShell equivalent has not been run, so treat it as untested:

```powershell
Get-ChildItem "$env:USERPROFILE\.codex\sessions" -Recurse -Filter *.jsonl | Select-String -Pattern "server_overloaded" -List | Select-Object Path
```

If the search finds nothing for the turn that just failed, you hit a different error. Match the text on screen:

| What Codex shows | What it is | Where to go |
|---|---|---|
| `Selected model is at capacity. Please try a different model.` and `server_overloaded` in the log | The server reported the model overloaded | Keep reading |
| `You've hit your usage limit…` with a reset time | Your plan's Codex usage ran out | [Codex Weekly Limit Reset: Find Your Time or Reset Now](https://blog.laozhang.ai/en/posts/openai-codex-usage-limits) |
| `Quota exceeded. Check your plan and billing details.` | API credits or a spend cap ran out (API key sign-in) | Your OpenAI API billing settings |
| `exceeded retry limit, last status: 429 Too Many Requests` | A 429 Codex could not classify | [Fix Codex Exceeded Retry Limit 429, 401, and Stream Disconnected](https://blog.laozhang.ai/en/posts/codex-exceeded-retry-limit-429) |
| `unexpected status 503 …` | A 503 without the overload code, for example from a relay or gateway | [Fix Codex Exceeded Retry Limit 429, 401, and Stream Disconnected](https://blog.laozhang.ai/en/posts/codex-exceeded-retry-limit-429) |
| The model "does not exist or you do not have access" | The model is retired or not on your plan | [Codex GPT-5.5 Model Not Found: Retired Oct 14, What to Use Now](https://blog.laozhang.ai/en/posts/codex-gpt-5-5-model-not-found) |

## What Codex retried before it showed the capacity error

By the time you see the line, Codex has already retried an overload that arrived as an HTTP 503. It has not retried one that arrived mid-stream. Codex never switches to another model on its own.

LaoZhang AI Team ran this on October 15, 2026 with the Codex CLI bundled in the ChatGPT desktop app (`codex-cli 0.162.0-alpha.17.2`). Codex used an isolated `CODEX_HOME`, default retry settings, and a custom provider pointed at a local mock server that returned overload errors on purpose. Each scenario was one `codex exec "say hi"` run:

| Mock server response | Requests Codex sent | Time to error | What Codex printed |
|---|---|---|---|
| HTTP 503 with `server_is_overloaded`, no `Retry-After` | 5, spaced 0.21, 0.42, 0.76, 1.72 s apart | about 4 s | The capacity line, nothing before it |
| The same 503 plus `Retry-After: 2` | 30, each 2.0 s apart | 58 s | `Reconnecting... 1/5` through `5/5`, then the capacity line |
| HTTP 200 stream that sends `response.failed` with `server_is_overloaded` | 1 | under 1 s | The capacity line at once |

Every request in all three runs named the same model. The client did not fall back to anything else.

![Three mock-server cases: a 503 without Retry-After sent 5 requests in about 4 seconds, a 503 with Retry-After 2 sent 30 requests over 58 seconds with Reconnecting 1/5 to 5/5, and a mid-stream response.failed sent 1 request and stopped](https://blog.laozhang.ai/posts/en/codex-selected-model-at-capacity/img/codex-overload-retry-test.webp)

The results match the source. The tests in `core/tests/suite/retry_after.rs` check that an HTTP overload is retried up to the configured request limit, that a server `Retry-After` adds whole-turn retries, and that an overload inside the stream ends the turn. That gives you a clue from the screen alone: if you saw `Reconnecting... n/5` lines before the capacity message, Codex was retrying the whole turn, which in the test happened only when the server sent `Retry-After`.

The limits of this test: it shows how the client handles a given response. It does not show why OpenAI's servers send the code, and it did not go through ChatGPT sign-in. The desktop app and the IDE extension were not run separately, although they report the same error. Other Codex versions may retry differently.

## Two failure patterns: rejected in seconds or 14–34 minutes into a turn

The capacity error shows up in two shapes, and the shape tells you what you lost.

The authoring Mac's own logs show both. Between October 3 and October 8, 2026, 17 turns on `gpt-6.1-sol` ended with `server_overloaded`, 15 of them on October 8 (UTC). Most were automated runs started in parallel, on one ChatGPT-signed-in account:

| Pattern | Turns | What happened |
|---|---|---|
| Rejected before any output | 4 | Failed 6–17 seconds after the request, with no first token |
| Failed mid-turn | 13 | Had already streamed output and run tools. Twelve died 14–34 minutes in, one after about 67 seconds |

The October 8 failures clustered between 14:11 and 15:01 UTC. The OpenAI status page lists no Codex incident that day. Outside the bursts, the same account mostly worked: one long interactive session completed 202 of its 221 turns.

Other reports describe the same split. In issue #53531, a Pro user on CLI 0.162.1 counted 97 failed turns from October 8 to 13, and 56 of them happened mid-turn, after the model had streamed output and run tools. Issue #53648 describes three GPT-6.1 Sol turns in a row failing after 9–18 minutes of work; one ended with the capacity error and the other two with response-stream errors.

What each pattern means for you:

- **Rejected in seconds.** Nothing ran. Waiting and sending the same prompt again costs you nothing.
- **Failed mid-turn.** Commands and file edits that already ran stay on disk, but the turn produced no final answer. Run `git status` or `git diff` to see what changed before you send another prompt. The model is never told about the capacity failure (a maintainer confirmed this in issue #26290), so a bare "try again" can repeat the same long approach. Tell it what is already done and ask it to continue from the current state.

![Split of 17 failed gpt-6.1-sol turns: 4 rejected 6 to 17 seconds after the request with no output, 13 failed mid-turn after streaming output and running tools, with the October 8 burst between 14:11 and 15:01 UTC](https://blog.laozhang.ai/posts/en/codex-selected-model-at-capacity/img/codex-capacity-failure-patterns.webp)

## What to try: wait, switch models, new chat, or Fast mode off

Try these from the cheapest to the most disruptive. Stop at the first one that works.

**Wait and resend.** The incidents with a public record cleared within hours. On October 13 the status page listed "Degraded performance in GPT-6.1 Sol Codex and Work mode", and on October 14 "Degraded performance in Codex and ChatGPT Work". Both are marked resolved, and neither names the capacity message. A few minutes is enough to find out whether a wave is passing.

**Switch to one other model.** In the CLI, run `/model` and pick from the list. For a single run, `codex -m <model>` overrides your config, and `model = "…"` in `config.toml` changes the default. In the desktop app and IDE extension, use the model picker. Choose only from what your own picker shows, because Codex fetches that list from the server per account. As of October 15, 2026, the list for ChatGPT sign-in can include `gpt-6.1-sol` (rolling out to Plus and higher plans), `gpt-6-sol`, `gpt-6-astra`, `gpt-5.6-sol`, `gpt-5.6-terra` and `gpt-5.6-luna`, with `gpt-6-luna` for Free and Go in the desktop app. `gpt-5.5` and `gpt-5.4` are retired for ChatGPT sign-in and will fail with a different error. For who gets 6.1 Sol and what changes when you move to it, see [GPT-6.1 Sol: Pricing, Access, and What Breaks When You Switch](https://blog.laozhang.ai/en/posts/gpt-6-1-sol).

Switching helps only when the shortage is limited to one model. Reports go both ways. The October 13 incident named GPT-6.1 Sol. But in issue #53531 the same failures hit `gpt-6.1-sol`, `gpt-6-sol`, `gpt-5.6-sol` and `gpt-5.6-luna`, and in the September 8 wave after the GPT-6 Astra launch (issue #43738) people reported every model failing for hours. If one other model fails too, cycling through the rest rarely changes the result.

**Start a new chat for a long conversation.** In issue #53524, continuing a long desktop conversation failed on four models while "Creating a new chat works immediately." In issue #53952, a brand-new conversation failed four times in four minutes. A new chat is a cheap test, not a guaranteed fix. In the CLI, `/new` starts one. `/compact` summarizes the current conversation instead, if you want to keep going in the same thread. Before you leave a long thread, ask for or write a short summary of the work done so far so the new chat can pick it up.

**Turn Fast mode off, if it was on.** Codex models offer a Fast speed tier. One user in issue #37790 reported the error stopped after turning Fast off on GPT-5.6 Sol. That is a single report, so treat it as a quick test you can undo, not a known cause.

Things that do not help: restarting the app repeatedly, reinstalling, deleting `~/.codex`, changing your VPN route, changing your password, or raising client retry settings. The last one can stretch the wait on an HTTP overload, but an overload inside the stream ends the turn no matter what the retry settings say.

## Using a custom provider or relay: who sent the overload?

If Codex talks to a custom provider, gateway or third-party relay instead of OpenAI directly, the 503 or stream event that Codex parses came from that endpoint. The local test above used exactly this path: a custom provider produced the capacity line with no OpenAI server involved.

So with a relay in the middle, three things can be true. The relay passed through a real OpenAI overload. The relay sent its own `server_is_overloaded` because its upstream pool was full. Or the relay rewrote the error, in which case you may see `unexpected status 503 …` or a different message entirely. OpenAI's status page and the openai/codex issues say nothing about a relay's capacity. Check the relay's own status or logs, and test the same prompt with ChatGPT sign-in or an OpenAI API key if you have one. If only the relay route fails, the shortage is on the relay's side. For how the provider settings are wired, see [Codex Custom Provider Setup: API Key, Base URL, and Auth](https://blog.laozhang.ai/en/posts/codex-config-toml).

## When to stop retrying and what to put in a report

Stop resending when all three hold for more than about an hour: the same error on two different models, the same error in a fresh chat, and no relay between you and OpenAI. At that point more attempts mostly add noise.

There is no published duration for these waves. The October 13 and 14 incidents were resolved within the day. The burst on the authoring Mac lasted about an hour. Issue #53952 reported 77 of 77 failures over 7 hours 41 minutes, still continuing after the public incident was marked resolved.

Then:

1. Check [the OpenAI status page](https://status.openai.com) for an open Codex incident. If one is open, wait for it to resolve.
2. Run `/feedback` in Codex to send logs to the maintainers.
3. If you open or join a GitHub issue in openai/codex, include your Codex version (`codex --version` or the app's About dialog), your plan, the model and reasoning effort, the time in UTC, whether the failure came in seconds or mid-turn, whether a new chat and another model also failed, and the count from the `grep` command above. Leave out prompt contents and anything private.

Most of the October 13 and 14 issues had no maintainer reply as of October 15, 2026, so expect the report to help diagnosis rather than unblock you that day.

## FAQ

### Does switching models fix “Selected model is at capacity” in Codex?

Sometimes. It works when only the model you picked is short on capacity, which is what the message suggests. During wider waves, such as September 8 and October 8–14, 2026, users reported every model failing. Try one other model from your own `/model` list. If that also fails, wait instead of cycling through the rest.

### Will there be a reset, and how long does it last?

There is no reset to wait for, because the error is not tied to a usage window. It ends when OpenAI has capacity for the model again. Public incidents on October 13 and 14, 2026 were resolved within the day, while some individual reports describe failures lasting more than seven hours.

### Is Codex silently using a different model when it hits capacity?

The Codex client does not switch models on its own. In the local test, every retry named the same model, and the turn ended with the error instead of an answer from another model. Whether OpenAI's servers ever route a request to a different model is not documented. `/status` shows the model your session is configured to use.

### What does “Reviewer model is at capacity” mean?

People using Codex auto-review have reported this wording in the OpenAI Developer Community, saying it blocks edits. The automatic reviewer runs as a separate model, and in v0.162.1 it retries its own review when it gets a capacity error. The exact "Reviewer model" wording does not appear in that version's source. The cause is the same kind of shortage, so the same steps apply: wait, then try again.

### What about “Error running remote compact task: Selected model is at capacity”?

That came from the older remote compaction step that summarizes long conversations. In June 2026 a Codex maintainer said compaction had moved to the same endpoint as normal turns, which eliminated "remote compaction" errors. If you still see that exact wording, update Codex, and report it with `/feedback` if it continues on the latest version.

## Sources

External pages this guide links to, in the order they appear. Last updated 2026-10-15.

- [OpenAI's API error-codes guide](https://developers.openai.com/api/docs/guides/error-codes) (developers.openai.com)
- [the OpenAI status page](https://status.openai.com/) (status.openai.com)