Codex "Selected model is at capacity" September 2026 update and how to continue

TL;DR

Symptom Codex prints Selected model is at capacity. Please try a different model. and stalls (capacity means the model’s serving slots, not your context window)

Workaround Interactively, don’t switch models; tell it to continue in the same thread and it usually resumes

Limitation In unattended or loop runs (overnight autonomous jobs) the manual continue doesn’t apply. Auto-retry exists as of August 2026, but since September 7 the error hits every model on some accounts and nothing client-side is confirmed to clear it (see the September 8, 2026 update at the end)

Update (2026-09-08): From September 7 the error is no longer limited to GPT-5.6 Sol. One report has GPT-6 Astra, all three GPT-5.6 models and GPT-5.5 failing for the same user. In separate reports the rollout logs tag the failed turns server_overloaded at 0% quota used, and one reporter found that a second Pro account works on the same machine. Details in the September 8, 2026 update. The September 3, 2026 update covers the GPT-5.6 Sol wave.

While Codex was working, it printed Selected model is at capacity. Please try a different model.
This was almost my first time hitting it. Context compaction had not run, and the thread itself did not look broken.

I sent this in the same thread.

Keep going without stopping.

Codex then continued as if nothing had happened.
As of this write-up, I have not hit the same error again during that resumed run.

That behavior makes it too early to throw away the thread just from this message.
In my case, one model call was rejected, but the task state and conversation context remained intact.

Capacity is not context capacity

The capacity in this message reads as model-side serving capacity, not context length or context compaction.
In this case, context compaction had not run.

In a nearby GitHub issue, an OpenAI maintainer explains that this is not an account-specific rate limit, but capacity pressure on the selected model.
The relevant comment is in openai/codex #17014.

So I read capacity here as:

No available serving slot for the selected model

The word “capacity” can make it sound like context limit or remaining tokens.
For this error, it is better treated as a separate model-serving condition. If Codex still has the thread state, the next successful request can resume the work.

Closed issues and open issues are mixed together

The issue state around this error has to be read in separate buckets.
The same message appears across short incident reports, stale banner reports, and retry-mechanism requests.

These are the states I saw on June 11, 2026 JST.

Issue	State	Notes
#17014	closed	Maintainer explained it as model capacity, not an account rate limit
#22277	closed	Treated as a May 12, 2026 incident and later commented as mitigated
#11635	open	Stale capacity banner while the model keeps responding
#22390	open	Request for backoff retry and task-state retention on transient capacity errors
#27149	open	June 9, 2026 report around gpt-5.5 capacity errors and recovered-session context left

“The May 12 incident was mitigated” and “retry/state retention for capacity errors is still open as a product request” can both be true.
My local “continue prompt resumed the task” case sits closer to the stale-banner thread in #11635 and the state-retention request in #22390.

Continue in the same thread first

The first move is to keep the thread open.
If Codex shows this error mid-task and the task state is still present, the next user input can resume it.

In my case, a short forceful continue prompt was enough.

Keep going without stopping.

A more explicit version would be:

Continue the previous task. Check the current state first, then resume from the unfinished step.

If that does not go through, then model switching is the next thing to try.
In Codex CLI, use /model inside a thread, or start a new session with codex -m <model>. Codex model selection is also documented in Codex Models.

Changing models mid-task can slightly change the judgment style of the output.
For work where quality matters, I would first retry on the same model once, then switch only if it still does not pass.

Unattended runs are still a separate question

Both Codex and Claude Code can now handle larger contexts.
They can also take on more complex automated work than before.

But errors like this capacity failure, or the tool-call breakage I wrote about in Claude Code ‘court’ bug: tool calls leak as text instead of running, make unattended completion a separate question.

Large context and long unattended reliability are not the same property.
If one user message saying “continue” is enough to recover, that is useful, but the run is no longer fully unattended.

For long tasks, the current practical pattern is still to split work into smaller chunks, leave progress in files or git diff, and give the agent an easy way to resume after a stop.

Current observation

This article only covers one local observation and what is visible in public issues.

In my case, context compaction had not run.
After Selected model is at capacity. Please try a different model., sending a continue prompt in the same thread resumed the task.
I have not yet seen the same error repeat during the resumed run.

My current operating note is:

Do not discard the thread immediately.
Send a continue prompt in the same thread.
Switch models only if that does not pass.
If it repeats, record the issue number, timestamp, model, and whether context compaction had run.

The error message sounds severe.
At least in this run, it did not mean the task was over.

Update (2026-07-01)

The workaround here, telling it to continue in the same thread, assumes someone is watching the screen. In long autonomous loops or overnight unattended runs you can’t do that manual step, so a capacity error just leaves the task stalled.
Codex still has no automatic retry for capacity errors. #22390 requests exactly that: keep a long-running task alive overnight and handle transient capacity with automatic retry plus retained state. It’s open as of July 1. Today you only get the “try a different model” message, and the user ends up being the retry loop.
#22277 notes there’s no pre-flight server-health check, so tasks can crash mid-pipeline. If you run Codex unattended, wrap it with your own capacity-error detection and retry/resume logic.

Update (September 3, 2026)

GitHub reports since August 31

Since August 31, 2026, reports of this error have concentrated on GitHub. #41790 (ChatGPT Pro, three stops in one 15-minute task) leads, and #41810, #41805, #41798, #41808, and #42169 were all filed between August 31 and September 2. All of them are still open as of September 3.
Nearly every report names GPT-5.6 Sol, across Codex CLI 0.144.1 through the 0.151.0 series and Codex Desktop 26.825 and 26.826. One user hit it with 92% of the 5-hour window and 81% of the weekly window left, which fits the June reading of model-side serving capacity rather than quota.
OpenAI’s status history lists ChatGPT Work errors and latency on August 31, but no incident that names GPT-5.6 Sol or this capacity error.

Issue	Opened	Environment	Report
#41790	Aug 31	Codex App, Pro	Three stops in a 15-minute task, retry countdown of 117 seconds
#41798	Aug 31	Desktop 26.825, Windows	Auto-retry succeeds but the Goal stays paused
#41805	Aug 31	CLI 0.144.1, macOS, Plus	More than 10 times a day; restart and `codex resume` don’t help
#41808	Aug 31	Desktop, macOS, Pro	Goal flips to blocked with no `update_goal` call
#41810	Aug 31	CLI 0.151.0-alpha.7.2, Pro	Running task dies mid-turn with no way to resume that turn
#42169	Sep 2	Desktop 26.826, Windows, Plus	Repeats even on a plain prompt

Automatic retry behavior

The July 1 update said there was no automatic retry. There is now. After the error, Codex shows a countdown to the retry (117 seconds in one report), and per the comments on #41790 the wait grows with each occurrence.
But several reports say the retry goes through, the same error returns a few minutes later, and the user ends up sending continue anyway. One count was eight stops in 25 minutes.
The retry-and-retain-state request, #22390, picked up a comment on August 31 and remains open.

Desktop Goal state after the retry

When the automatic retry succeeds, the turn resumes but the Goal stays paused (#41798, Windows). On macOS, #41808 shows the Goal flipping to blocked with no update_goal call from the agent, while the same logs report full_context_window_limit_reached=false and token_limit_reached=false.
An overnight goal run that is dead by morning can also have stopped on the terminal side, with suspended (tty input), rather than on this server-side capacity error. The terminal-side case is in Codex ‘suspended (tty input)’ on macOS: stdio MCP servers keep the tty.

Update (September 8, 2026)

Models and issues reported from September 7

From September 7, for the same user, GPT-6 Astra, the GPT-5.6 models Sol, Terra and Luna, and GPT-5.5 all return Selected model is at capacity, and switching models or starting a new session does not reliably clear it (#43398, #43368, #43688). One commenter on #43337 still had it after signing in again. The models reported as still answering are gpt-5.4-mini at standard reasoning effort (#43398) and the codex-5.3 series (#43682).
Ten issues with this message were opened between September 7 and the morning of September 8 UTC, on top of the September 3 batch, which is still open in full. Eight of the ten name a ChatGPT Pro account. Seven run Codex CLI 0.153.4 or Desktop 26.901, one the VS Code extension 26.901, and two give no client version. None of the ten has a comment from OpenAI staff as of September 8 JST, and the tracker’s duplicate bot links most of them to each other in its comments.

Issue	Opened	Environment	Report
#43337	Sep 7	CLI 0.153.4, macOS, Linux and Windows, Pro 20x	One Pro account fails on Astra and Luna while a second Pro account works on the same machine
#43368	Sep 7	Desktop 26.901, macOS, Pro 20x	Terra, Luna, Sol and Astra all fail with about 80% of usage left
#43375	Sep 7	Codex, version not given	Astra and the GPT-5.6 models fail in turn; asks for a request ID in the UI
#43398	Sep 7	CLI 0.153.4, Ubuntu 22.04, Pro 20x	Astra, Sol, Terra, Luna and GPT-5.5 fail; only standard (non-high-effort) gpt-5.4-mini works reliably
#43517	Sep 7	CLI 0.153.4, macOS, Pro	Astra websocket closed by the server every turn, HTTP fallback returns 5xx; Sol works on the same machine
#43638	Sep 8	Desktop 26.901, Windows, Pro 20x	Sol, Terra and Luna return capacity; Astra returns `invalid_prompt` instead
#43663	Sep 8	VS Code extension 26.901, Linux, Pro 20x	8 of 9 tasks in one session ended with `server_overloaded`
#43682	Sep 8	Codex, version not given	gpt-5.5, 5.6, 6 and 5.4-mini all fail; only codex-5.3 answers
#43688	Sep 8	App 26.901 and CLI 0.153.4, macOS and Windows, Pro	Every model and reasoning level fails; Retry does not clear it
#43700	Sep 8	Desktop with CLI 0.153.4, macOS, Pro 20x	65 `server_overloaded` on Sep 7; killed turns ran 85 seconds on average

What the rollout logs say

Three reports opened the rollout or session logs that Codex keeps per session. Every failed turn is tagged codex_error_info: "server_overloaded", while the rate-limit snapshot in the same file reads plan_type: pro, used_percent: 0.0, rate_limit_reached_type: null (#43700, #43663; #43368 shows used_percent = 20.0).
The turns are not rejected up front. A September 6 comment on #41790 reports a GPT-6 run at Ultra reasoning that ran 3 hours 48 minutes and edited 24 files before the capacity message ended it. On September 7, the killed turns in #43700 ran 85 seconds on average and up to 275 seconds before the banner, and #43663 counts 339 to 482 output tokens generated before server_overloaded.
#43517 has the transport view on gpt-6-astra. The websocket to chatgpt.com/backend-api/codex/responses connects, the server closes it 15 to 20 seconds later before response.completed, Codex retries the sampling request five times, falls back to HTTP, and the HTTP attempt failed as well.

Two Pro accounts on one machine

#43337 runs the following one-line codex exec on two Pro 20x accounts from one machine.

codex exec --ignore-user-config --ephemeral --skip-git-repo-check \
  -C /tmp -s read-only -m gpt-6-astra \
  -c 'model_reasoning_effort="low"' --json \
  'Reply with exactly OK. Do not use tools.'

It is a fresh ephemeral task that does not load $CODEX_HOME/config.toml, so a failure is not specific to an existing thread or that configuration file. What is wrong on the backend side it cannot tell.
One account got the capacity error on gpt-6-astra and gpt-5.6-luna, the other answered. Two commenters on the same issue reproduced the comparison on one PC, one network and one client, with one account failing and a second working. One of them also found that switching back to the affected account brought the failures back.
One account failing while the other works does not fit the June explanation of a model whose serving slots are full. There is no explanation from OpenAI yet.

A failure ends with {"type":"turn.failed","error":{"message":"Selected model is at capacity. Please try a different model."}}.

Status page

OpenAI’s status page lists Elevated errors across ChatGPT and Codex on September 3 (14:58 to 16:55 UTC) and an APAC region error increase on September 4 that names Codex Cloud, both resolved. There is no incident for September 7 or 8, and the page reads All Systems Operational as of 14:00 JST on September 8.
This error has been posted as an incident before: Codex “Selected Model is at Capacity” Error on June 16 and Codex 5.6-sol Experiencing Increased Server-Overload Errors on July 17.

How the June steps hold up

When the automatic retry lands and the thread is intact, the June steps still apply: send continue in the same thread and don’t discard it. The reports that got work done did it on gpt-5.4-mini, on the account that still worked on the same machine, on Sol in the #43517 environment, on codex-5.3 in #43682, or in the minutes between bursts of failures. Keep progress in files or git diff, so a turn killed after 85 seconds does not take the work with it.