Repository navigation
Repeated "Selected model is at capacity" errors interrupting Codex tasks on ChatGPT Pro #41790
Description
What issue are you seeing?
I am a ChatGPT Pro user using the latest Codex app.
Starting today, August 31, 2026, Codex has repeatedly shown the following error:
"Selected model is at capacity. Please try a different model."
This is happening very frequently during normal agent tasks even though I still have plenty of usage remaining.
In one single task lasting about 15 minutes, I encountered this capacity error 3 times. Codex entered retry backoff (for example, a 117-second retry), resumed briefly, and then hit the same capacity error again.
This severely disrupts long-running Codex workflows. The task was actively editing files and running commands when the model capacity errors occurred.
I have been using ChatGPT Pro during my current subscription period and had essentially never encountered this problem before today. Today it suddenly started happening repeatedly.
This does not appear to be a usage-limit issue. My Pro usage quota is still available.
Please investigate model serving capacity / routing for ChatGPT Pro Codex users.
Screenshot attached showing three "Selected model is at capacity" errors during the same ~15-minute task.
What steps can reproduce the bug?
- Open the latest Codex app while signed in with a ChatGPT Pro subscription.
- Select the affected model.
- Start a normal long-running coding task that edits files and runs commands.
- Allow Codex to continue working for several minutes.
- During the task, Codex displays:
"Selected model is at capacity. Please try a different model." - Wait for the automatic retry/backoff.
- Codex resumes, but the same capacity error occurs again shortly afterward.
In my latest reproduction, the error occurred 3 times within approximately 15 minutes.
What is the expected behavior?
No response
Additional information
No response
Activity
github-actions commentedon Aug 31, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
gucheng2020-svg commentedon Aug 31, 2026
而且,出现 Selected model is at capacity. Please try a different model. 后会有一个自动重试的倒计时,这个倒计时会随着出现次数变多,越来越长
gucheng2020-svg commentedon Aug 31, 2026
gucheng2020-svg commentedon Aug 31, 2026
25分钟报错8次,绝了
yokinoshitayoki commentedon Aug 31, 2026
gucheng2020-svg commentedon Aug 31, 2026
我是今天才碰到,而且太频繁了,动不动就停了,这谁受得了
StarkBotha commentedon Aug 31, 2026
Also experiencing this intermittently, on codex cli Ubuntu. OpenAI status shows no incidents.
Ciscodefran commentedon Aug 31, 2026
Additional reproduction from another user on 2026-08-31:
0.151.06.6.87.2-microsoft-standard-WSL2(x86_64)gpt-5.6-solSelected model is at capacity. Please try a different model.Expected: transient capacity pressure should be retried without dropping/interruption of the active turn; if retry cannot recover, preserve the turn and provide a resumable failure state.
pokeQAAQ commentedon Aug 31, 2026
I've also encountered this, and it's becoming more frequent, especially after the update today
lingkong-q commentedon Aug 31, 2026
I'm the same. What's happening? I just came across it today. I've never seen it before. This really gets in the way of using it.
Water-Run commentedon Aug 31, 2026
Can confirm—I’m seeing the same issue very frequently, especially on longer-running tasks. I’m on Pro 20x, and Codex still repeatedly hits the capacity error, stops, and needs another “Continue” before it will resume.
It has gotten frequent enough that I now keep a separate Grok Build conversation open as an AI provost; whenever “Selected model is at capacity. Please try a different model.” appears, Grok sends “Continue.”
It looks like, after Tibo’s resets yesterday and today, he may have to hit the reset button yet again tomorrow.
myklovenyzforever commentedon Aug 31, 2026
Additional deduplicated telemetry from a post-reset Pro workload
I collected additional local Codex telemetry for this issue from the same account on August 31, 2026.
Audit scope
To avoid double-counting, I did not count every serialized appearance of the text:
Selected model is at capacity. Please try a different model.A single subagent failure can appear more than once in local telemetry—for example, in the child rollout, the parent notification, and later
waitorcloseoutput.Instead, I counted only terminal events matching:
type = event_msgpayload.type = task_completepayload.error.codex_error_info = server_overloadedand deduplicated them by
turn_id.Results
server_overloadedturnsgpt-5.6-solmaxserver_overloadedeventsThe nearest preceding in-thread weekly-usage snapshots associated with the post-reset failures ranged from:
In other words, approximately 45%–85% of the weekly allowance was still remaining around the observed failures. The events were therefore not caused by weekly-quota exhaustion.
These were terminal task failures rather than harmless internal retry messages. In several cases, the parent task received an errored subagent status and had to replace or restart the failed work.
This client-side telemetry cannot determine the backend root cause, but it does establish repeated terminal serving-overload failures for
gpt-5.6-solatmaxreasoning while substantial Pro weekly usage remained available.Could the team investigate model-serving capacity and routing for
gpt-5.6-sol, particularly during concurrent long-running Codex task-tree workloads?I can provide a sanitized event-level table containing anonymous tree/thread labels, UTC timestamps, model, reasoning effort, error code, and the nearest preceding weekly-usage percentage if useful.
shinstar5 commentedon Sep 2, 2026
I’m seeing the same pattern on ChatGPT Plus. The issue first appeared after a long-running Codex task, and afterward GPT-5.6 Sol repeatedly returned “Selected model is at capacity” in both the Codex app and CLI.
At the time, I still had 92% of my 5-hour usage and 81% of my weekly usage remaining.
CLI feedback thread: 01a05fcc-d6af-7e70-937c-bbad3def908f
Possibly related CLI report: #41805
Lio-Green commentedon Sep 2, 2026
I can confirm the same issue in the Codex desktop app on Windows. Multiple interruptions during a long-running task were caused by the exact error:
Selected model is at capacity. Please try a different model.I also submitted in-app feedback so the occurrence can be correlated with server-side telemetry.
Feedback ID:
01a05f3e-3c8f-77f0-9528-23bc9b939b5fZZZackZhang commentedon Sep 6, 2026
Additional GPT-6 Ultra reproduction on macOS / ChatGPT Pro:
26.901.41123(bundledcodex-cli 0.153.3)Darwin 25.6.0 arm64 arm(macOS 26.6.2, build 25G83)The task had already completed substantial work and the UI showed 24 edited files (+1,249 / -14) when the run terminated with:
Selected model is at capacity. Please try a different model.Expected: retry with backoff or preserve a resumable failure state so a long-running task can continue on the same model without losing continuity. The task/session identifiers and screenshot are intentionally omitted from this public comment; they can be shared privately through in-app feedback if needed.
Cc0703-D commentedon Sep 7, 2026
解决了吗
Cc0703-D commentedon Sep 7, 2026
1
shaoke-cpu commentedon Sep 10, 2026
Same error since 2026-09-08 on every model, quota mostly unused.
Key difference from other reports here: a second ChatGPT account on the
same machine, network, Codex version (0.153.4) and model works fine at
codex-failed-turns.txt
the same time, so on my side this is account-scoped, not capacity.
thread_id: 01a08495-908f-7440-9b82-eac82fdb3619
yangyefd commentedon Sep 21, 2026
I am seeing the same intermittent issue on Codex CLI.
Environment:
A previous failing rollout recorded:
codex_error_info: "server_overloaded"
I have uploaded diagnostics through Codex feedback.
Uploaded thread ID:
01a0c2d5-c569-7e91-a4bd-e7a70359361b
The issue is intermittent and still occurs with substantial weekly usage remaining.
Water-Run commentedon Sep 22, 2026
It started triggering frequently again over the past hour. It may be related to Tibo saying that the limit would be reset, so everyone started working intensively.
This move by OpenAI is pretty sneaky too—it specifically targets people who make a /goal to the model and then go to sleep... only to wake up and see “Selected model is at capacity”; the task never even started :-o
edwardswhiskeyblues-alt commentedon Oct 6, 2026
Additional Windows Codex Desktop reproduction on 2026-10-06.
Environment / scope:
gpt-6-solxhighObserved failures:
Every failed turn returned exactly:
Selected model is at capacity. Please try a different model.The chat entered a backend
systemErrorstate. This is not explained by account quota: ordinary usage remained allowed, weekly usage was 46%,rateLimitReachedTypewas null,spendControlReachedwas false, and credits were available. The public OpenAI status page showed no active incident at the time.Operationally important detail: some of these turns performed command/tool work before ultimately failing. Therefore, retrying is not safely equivalent to re-running the turn; the client must first reconcile partial side effects to avoid duplicate writes or duplicate external actions. The final delayed attempt likewise began work and completed a command before receiving the same capacity failure.
This looks consistent with a model-routing/admission-capacity problem that can persist for at least an hour without appearing as a public service incident. It would be helpful if Codex could:
whiz-ai-code commentedon Oct 13, 2026
Additional Windows Codex Desktop report on 2026-10-13: I am a ChatGPT Pro user and again encountered the exact message
Selected model is at capacity. Please try a different model.The conversation/task then stopped responding or making progress. This is still recurring. I do not have the exact model, app version, occurrence timestamp, or diagnostic logs available for this report. Please ensure capacity errors leave the active task recoverable and do not strand the desktop conversation in a stuck state.whiz-ai-code commentedon Oct 14, 2026
Additional recurrence observed on 2026-10-14: I encountered the same
Selected model is at capacity. Please try a different model.message again in Codex Desktop. The attached screenshot shows the exact error text. This continues to interrupt normal use; please keep the active task recoverable after capacity failures.