CLI 0.154.0: "at capacity" since 11 Sep despite 5h 100% / weekly 80% #45892

Activity

1. laoyang75

   added

   bugSomething isn't workingSomething isn't working

   on Sep 16, 2026
2. github-actions

   added

   CLIIssues related to the Codex CLIIssues related to the Codex CLI

   connectivityIssues involving networking or endpoint connectivity problems (disconnections)Issues involving networking or endpoint connectivity problems (disconnections)

   on Sep 16, 2026
3. github-actions commented on Sep 16, 2026

   

   github-actionsbot

   on Sep 16, 2026 – with GitHub Actions

   Contributor

   More actions

   Potential duplicates detected. Please review them and close your issue if it is a duplicate.

   • [Bug] New Codex conversations fail with "Selected model is at capacity" while existing conversations remain usable on the same Pro account #45648
   • I have 100% quota available but cannot use the AI. This issue has persisted for a whole week. Every time I attempt to use it, I get the message: Selected model is at capacity. Please try a different model. #45368
   • Selected model is at capacity. Please try a different model. No matter how I swtich model, reset, reinstall, logout/login #45653
   • Codex has reported this error for four consecutive days: Selected model is at capacity. Please try a different model. #45611
   • selected model is at capacity error is occurring only on specific accounts. #45600

   Powered by Codex Action
4. d2020d commented on Sep 17, 2026

   

   d2020d

   on Sep 17, 2026

   More actions

   I can independently reproduce what appears to be the same issue on a ChatGPT Pro account.

   Environment

   • ChatGPT Pro
   • macOS / Apple Silicon
   • Codex CLI 0.154.0
   • Authentication: ChatGPT
   • Issue started around September 14, 2026

   Usage status

   This does not appear to be normal quota exhaustion.

   At the time of testing, /status showed approximately:

   • 5-hour limit: 100% remaining
   • Weekly limit: 71% remaining
   • Plan: Pro

   I have NOT used the available usage-limit reset.

   Minimal reproduction

   I tested using isolated ephemeral sessions:

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

   Each model was tested 10 times under the same conditions.

   Results

   Model	Success	Capacity	Processing / Other
   gpt-5.6-sol	1/10	9/10	0/10
   gpt-5.6-luna	4/10	6/10	0/10
   gpt-5.6-terra	0/10	0/10	10/10
   gpt-6-astra	3/10	7/10	0/10

   For Sol, Luna, and Astra, the primary failure is:

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

   Terra behaves differently: all 10 requests failed during processing rather than returning the normal capacity message.

   Example Terra failure:

   stream disconnected before completion: An error occurred while processing your request. You can retry your request, or contact us through our help center if the error persists.

   Terra request ID:

   5884fa60-3c13-42a7-a4a1-07d79ce400ad

   Additional diagnostics

   I also ran Codex with RUST_LOG=debug.

   The /models request succeeds normally:

   • HTTP status: 200
   • success=true
   • auth.mode=Chatgpt
   • authorization header attached

   A failed Sol request later records:

   event.kind=response.completed
   error.message="Selected model is at capacity. Please try a different model."
   model=gpt-5.6-sol
   slug=gpt-5.6-sol

   Example failed Sol thread ID:

   01a0aedf-07a4-78b0-b9a8-7111b18c7852

   Failure timestamp:

   2026-09-17T10:17:59.921Z
   (2026-09-17 18:17:59 UTC+8)

   Configuration isolation

   The problem persists with:

   • Codex CLI 0.154.0
   • --ignore-user-config
   • --ephemeral
   • /tmp working directory
   • read-only sandbox
   • reasoning effort set to low
   • minimal prompt
   • fresh sessions

   I also removed a third-party local Codex proxy that I installed only after this problem originally started. The issue continues without it.

   Identical requests under essentially identical client conditions can sometimes succeed and sometimes return capacity. For example, Sol succeeded 1/10 times, while the other 9/10 identical requests returned capacity.

   Changing models therefore changes the failure rate, but does not restore reliable operation.

   WebSocket observation

   I have separately observed WebSocket connection failures to:

   wss://chatgpt.com/backend-api/codex/responses

   Codex then falls back to HTTPS.

   However, I have observed BOTH outcomes after the HTTPS fallback:

   1. Successful completion ("OK")
   2. "Selected model is at capacity"

   Therefore, the WebSocket issue may be a separate network problem, but it does not by itself explain all of the capacity failures.

   I am currently performing an additional mobile-hotspot test with the local proxy/VPN bypassed to compare WebSocket-over-443 behavior and capacity stability on a completely different network path.

   Given the available quota, successful authentication, successful /models requests, intermittent success under identical conditions, and high failure rates across multiple models, this may be related to server-side serving/admission/routing rather than normal usage-limit exhaustion.

   I can provide additional request/thread IDs or sanitized debug logs if useful.