Repository navigation
Account-scoped "Selected model is at capacity" on a Pro account since Sept 14 - cross-over test shows it follows the account, not the machine or network #46231
Description
Another Pro account with the same account-scoped "Selected model is at capacity" pattern, with a full cross-over test.
Environment
- ChatGPT Pro (headers:
x-codex-plan-type: pro,x-codex-active-limit: premium), weekly allowance untouched at failure time (x-codex-secondary-used-percent: 0), 5-hour window at 63-66%. - Codex Desktop 26.908.70816 (Windows 11) and Codex CLI 0.154.0. Also reproduced with
codex execin fresh threads withmcp_servers={}, at low / high / ultra reasoning effort. - Models: gpt-6-astra, gpt-5.6-sol, gpt-5.6-luna, gpt-5.6-terra, gpt-5.5 all fail the same way.
Failure rate from the desktop app's own logs (local time UTC+8)
| Date | Turns | Failed |
|---|---|---|
| Sept 13 | 66 | 0 (0%) |
| Sept 14 | 105 | 48 (45%) |
| Sept 15 | 38 | 6 (15%) |
| Sept 16 | 58 | 31 (53%) |
| Sept 17 | 55 (last 24h) | 39 (71%) |
Almost all failures are Selected model is at capacity; a few are stream disconnected before completion. They return 12-60 s after the turn is submitted. Single-round turns sometimes get through; anything that needs a second sampling round dies.
Cross-over test (this is the account, not the machine or the network)
- My account on several different computers: fails on every one of them.
- A colleague's ChatGPT account on my computer, same office network, same Codex client: works with zero errors.
- Other AI services on my machine work normally at the same time.
Sample failed turns (UTC)
- 2026-09-17 08:01:07Z gpt-5.6-luna thread
01a0100b-e4ec-77e2-8d52-c6d4c281833fturn01a0ae60-5f0b-72d3-b445-91196fd9279a - 2026-09-17 07:46:00Z gpt-6-astra same thread, turn
01a0ae54-4bcc-7601-9c81-ecd3cefb5723 - 2026-09-16 13:59:10Z gpt-6-astra thread
01a09bdb-1511-7b43-ae56-2cf8043762fdturn01a0aa83-2499-7cb0-9a1f-a1a5fd7d368e
Server request IDs from stream disconnected before completion bodies: e6e2469e-ba60-4cd0-afc2-eb666956979a, 0ce20e89-3222-4c04-90a3-2bd0439feb52.
A support ticket was filed and escalated to a specialist on Sept 17 via help.openai.com; no reply yet. status.openai.com shows no Codex incident for any of these days.
Would appreciate an acknowledgment from the Codex team on whether this is an account-level restriction and what clears it.
Activity
github-actions commentedon Sep 17, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
server_is_overloadedon GPT-5.6 Sol: one Plus account fails while two other Plus accounts work on same machine/network #46133Powered by Codex Action
agotfred commentedon Sep 17, 2026
Same problem, it has been almost unusable today.
I get disconnects, stuck at "working" forever, stopping in the middle of outputs while still appearing to be working etc. I don't get any "Selected model is at capacity" messages however.
carlosGuimaraes1 commentedon Sep 17, 2026
I am seeing the same issue on a ChatGPT Pro account with Codex CLI 0.154.0 on Windows.
I reproduced it with VS Code closed, no CI, no parallel Codex sessions, and only one Codex CLI process running.
At the time of reproduction,
/statusshowed:The failure occurred at:
2026-09-17T17:18:39.578Z
(14:18:39 BRT / UTC-3)
The rollout transcript explicitly records:
"Selected model is at capacity. Please try a different model."
with:
"codex_error_info":"server_overloaded"
codex doctor --jsonreports:I also reproduced the issue with gpt-5.6-luna.
The behavior is intermittent: a minimal request can succeed, and a few minutes later the same model can fail. Longer coding tasks are especially affected because the task may start normally, use tools/read files, and then fail on a later model call with the same capacity error.
I submitted diagnostics through Codex
/feedback.Uploaded feedback thread:
01a0b06b-7b32-7980-89ed-0ef47e2c63bc
Affected session with the confirmed
server_overloadedevent:01a0b05f-af79-7f41-b4b3-5275eff9d11b
This appears very similar to the account-scoped behavior described in this issue.
SeolJiChen commentedon Sep 20, 2026
I'm experiencing the same issue. It started a few days ago and appears to be account-specific.
I repeatedly get "Selected model is at capacity. Please try a different model." during normal Codex tasks, often followed by long retry/backoff periods (sometimes ~300 seconds).
At the same time, my Codex usage is being depleted approximately 3–4x faster than before for comparable tasks.
The issue has persisted for several days while other Codex users I know are not experiencing it.
Feedback ID: 019ff9bf-31d1-7130-8612-aa2773f172a0
maurovideosmr-wq commentedon Sep 21, 2026
Consistent with the account-scoped finding, with one refinement from our trace: the routing decision appears to be per-model, not a per-account blanket.
Same account, same machine, same minutes on 2026-09-21:
gpt-6-solrequested →gpt-6-solserved (12/12 correct), whilegpt-6-astrarequested →gpt-5.6-lunaserved (196 of 235 completed responses; 2 pairs hard-correlated to local request logs by response ID / turn ID).The Astra→Luna substitution state also flipped twice within a single capture session with zero client-side changes: Astra served once at 19:42 UTC, Luna again, Astra served 20:17–20:19 (9 responses), then Luna again through end of capture. That points to server-side dynamic routing following account/model state — nothing on the client, matching your cross-over conclusion. Full tables and response IDs in my comment on #46632.