Repository navigation
Repeated "Selected model is at capacity" errors on ChatGPT Pro despite 100% usage remaining; rollout logs show server_overloaded #43663
Description
What version of the IDE extension are you using?
26.901.22334
What subscription do you have?
pro 20x
Which IDE are you using?
vscode
What platform is your computer?
Linux 5.15.0-79-generic x86_64 x86_64
What issue are you seeing?
Codex repeatedly fails with the following error when using gpt-5.6-sol and gpt-6-astra:
Selected model is at capacity. Please try a different model.
I inspected the Codex rollout logs and found that all failed tasks are classified as:
"codex_error_info": "server_overloaded"For example, in one recent session (rollout-2026-09-07T15-17-51...jsonl), there were 9 task_complete events:
- 8 failed with
codex_error_info: "server_overloaded" - 1 completed successfully
Some failed requests had already generated approximately 339–482 output tokens before terminating with server_overloaded, so the requests were not always rejected immediately.
This does not appear to be a usage-limit issue. The same rollout logs contain:
plan_type: pro
used_percent: 0.0
rate_limit_reached_type: null
Authentication mode is:
auth_mode=chatgpt
The failures are intermittent and occur in bursts. On September 7, 2026 (UTC+8), I observed 19 failures clustered roughly as follows:
~11:02 7 failures
~14:09 4 failures
~15:17 8 failures
Occasional requests succeed between these failure periods.
Because the client-side error is consistently server_overloaded while the account has available usage, this appears to be a server-side capacity, admission-control, or routing issue rather than a local quota problem.
What steps can reproduce the bug?
-
Sign in to Codex using a ChatGPT Pro account (
auth_mode=chatgpt). -
Select either:
gpt-5.6-sol
or:
gpt-6-astra
-
Start a new Codex session.
-
Submit a normal coding request.
-
If the first request succeeds, repeat several normal requests.
During affected periods, requests repeatedly fail with:
Selected model is at capacity. Please try a different model.
The corresponding rollout log entries show:
"codex_error_info": "server_overloaded"At the same time, token_count events report:
plan_type: pro
used_percent: 0.0
rate_limit_reached_type: null
The issue is intermittent: requests may occasionally succeed, followed by multiple consecutive server_overloaded failures.
Retrying or switching between gpt-5.6-sol and gpt-6-astra does not reliably resolve the problem.
What is the expected behavior?
Codex requests should execute normally when the account has available usage and access to the selected model.
If the backend is temporarily overloaded, Codex should ideally retry the request with appropriate backoff instead of terminating the task, especially when the request has already started generating output.
If the failure is caused by account-specific routing, admission control, provisioning, or a particular ChatGPT-auth serving pool rather than model-wide capacity, the error should distinguish that condition from a generic:
Selected model is at capacity.
It would also be helpful if the Codex team could correlate these server_overloaded failures with backend telemetry to determine whether they originate from model serving capacity, ChatGPT-auth admission control, regional/serving-pool routing, or account-specific provisioning.
Additional information
No response
Activity
github-actions commentedon Sep 8, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
chmcgrat commentedon Sep 8, 2026
I’m seeing the same issue on Codex Desktop. So far I have reproduced it on GPT-5.6 Terra and GPT-5.6 Luna, including Luna Light, but I have not tested every available model, so others may also be affected.
I also reproduced it in a brand-new chat where the first prompt was only: “Run git status only. Do not edit anything.” It immediately returned “Selected model is at capacity. Please try a different model.”
My account shows ~99% remaining 5-hour usage and 100% remaining weekly usage.
Feedback ID: 01a07f3e-dc4e-7860-9fe9-2df6188f3ca5
l1rx commentedon Sep 11, 2026
Is there any result?
nano8259 commentedon Sep 11, 2026
not yet