GPT-6 Astra: repeated "Selected model is at capacity" on Pro 20x — rollout logs show server_overloaded with 0% usage used #43700

What version of the Codex App are you using (From “About Codex” dialog)?

Codex Desktop (bundled codex-cli 0.153.4)

What subscription do you have?

ChatGPT Pro (20x)

What platform is your computer?

Darwin 25.5.0 arm64 (Apple Silicon Mac, macOS)

What issue are you seeing?

Codex Desktop repeatedly terminates turns with:

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

Model: gpt-6-astra. This has been recurring since Aug 28 and escalated sharply on Sep 7–8.

Local rollout JSONL logs classify all of these terminations as:

"codex_error_info": "server_overloaded"

while the rate-limit snapshots in the same logs show the account is nowhere near any limit:

plan_type: pro
used_percent: 0.0
rate_limit_reached_type: null

Measured from my local rollout logs:

Important detail: turns are not rejected upfront — they are admitted, run for a while, then killed mid-flight. In the Sep 7 session the killed turns ran on average 85 s before termination (max 275 s), losing in-progress work on long-running tasks.

Retrying succeeds intermittently, then fails again in bursts. Switching models and starting new sessions does not reliably recover.

What steps can reproduce the bug?

1. Sign in with a ChatGPT Pro account (auth via ChatGPT, not API key) in Codex Desktop 0.153.4 on macOS arm64.
2. Select gpt-6-astra.
3. Start normal coding tasks.
4. Turns intermittently terminate with the capacity banner; the rollout log records codex_error_info: "server_overloaded" while used_percent stays at 0.0.

Session IDs for server-side correlation:

• 01a07ab7-4da3-7cf0-b711-638991ba5df0 (Sep 7, 27 terminal errors, 07:14–12:27 UTC)
• 01a07ef7-1841-70e0-9344-a8d33ad34714 (Sep 8, 6 terminal errors, 03:02–04:38 UTC)

What is the expected behavior?

1. The UI message should distinguish server-side capacity / admission-control failures from per-account quota exhaustion — "Selected model is at capacity. Please try a different model." reads like quota guidance, but my quota was at 0% used and switching models does not help.
2. Long-running turns should be retried with bounded backoff within the same turn (or resume from a preserved state) instead of being killed mid-flight after minutes of work.
3. status.openai.com showed "fully operational" with 100% Codex uptime during these windows; Codex-side regional serving degradation is not reflected there.

Additional information

• The escalation timing coincides with the global paid-usage reset on the evening of Sep 7 (PST); community reports consistently spike right after each reset, which is consistent with a demand surge against fixed serving capacity rather than per-account throttling.
• Community reports suggest Asia/Singapore-serving-region users are hit especially hard, and some users report a VPN region switch mitigates it — which points at regional serving pools.
• This matches the patterns already reported in Repeated "Selected model is at capacity" errors interrupting Codex tasks on ChatGPT Pro #41790, Selected model is at capacity — GPT-5.5, GPT-5.6-Sol, and GPT-6 Astra all failing (only 5.4-mini works), Sep 7 2026 #43398, Repeated "Selected model is at capacity" errors on ChatGPT Pro despite 100% usage remaining; rollout logs show server_overloaded #43663, Multiple GPT-5 / GPT-6 models return "Selected model is at capacity" #43375, gpt-6-astra: websocket closed by server before response.completed on every turn, HTTP fallback 5xx, 'Selected model is at capacity' (0.153.4, ChatGPT Pro) #43517 — filing with my own telemetry/session IDs for correlation; happy for maintainers to merge into an existing tracking issue.