Repository navigation
Account-specific capacity errors across Codex models despite a fully available weekly allowance #43337
Description
Environment
- Subscription: ChatGPT Pro 20x
- Verified CLI version:
codex-cli 0.153.4, bundled with the desktop app - Minimal reproduction platform: macOS, Apple Silicon
- Models:
gpt-6-astra,gpt-5.6-luna, both atlowreasoning - Latest verified reproduction: September 7, 2026, approximately 10:58–10:59 UTC+8
Problem
One of my Pro 20x accounts repeatedly receives:
Selected model is at capacity. Please try a different model.
A second account with the same subscription works normally under comparable conditions.
I have also observed this problem across Linux, macOS ARM64, and Windows 11, using Codex CLI, app-server, and the desktop app. Switching models or clients does not resolve it.
Minimal reproduction
With the affected account signed in, run the following using Codex CLI 0.153.4:
codex exec \
--ignore-user-config \
--ephemeral \
--skip-git-repo-check \
-C /tmp \
-s read-only \
-m gpt-6-astra \
-c 'model_reasoning_effort="low"' \
--json \
'Reply with exactly OK. Do not use tools.'Repeat with -m gpt-5.6-luna.
Both tests failed with:
{"type":"error","message":"Selected model is at capacity. Please try a different model."}
{"type":"turn.failed","error":{"message":"Selected model is at capacity. Please try a different model."}}These were fresh temporary tasks with user configuration disabled, rather than continuations of long conversations.
Quota and authentication checks
Immediately before these tests, the affected account’s usage endpoint returned the following fields:
{
"plan_type": "pro",
"rate_limit": {
"allowed": true,
"limit_reached": false,
"primary_window": {
"used_percent": 0,
"limit_window_seconds": 604800
}
}
}The weekly allowance had just reset: 0% used, 100% remaining. The usage endpoint reported allowed: true and limit_reached: false, but both minimal requests still failed with the capacity error.
Local checks confirmed that the authentication file and token identity claims referred to the affected account, the access token had not expired, and no API key was configured.
Expected behavior
Ordinary requests should succeed when access and quota are available, or return an actionable explanation if an account-specific restriction applies.
Investigation request
Could the team correlate these failures with backend telemetry and check the affected account’s provisioning, routing, throttling, and quota accounting? The client-side evidence does not establish which of these is responsible.
Related: #41790. This report adds a same-subscription account comparison and a minimal reproduction with user configuration disabled and 100% of the weekly allowance remaining.
I can provide account details and diagnostic identifiers through a private support channel.
Activity
github-actions commentedon Sep 7, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
edge1999 commentedon Sep 7, 2026
Package: Pro 20x
Platform: ChatGPT desktop client for macOS, Codex mode
MacOS version: 26.6.2
Application release: 26.901.51231 (from application logs)
Symptom:
Terra, Luna, Sol, and Astra all continue to prompt:
Selected model is at capacity. Please try a different model.
Confirmed:
codex_error_info = server_overloaded
plan_type = pro
primary.used_percent = 20.0
rate_limit_reached_type = null
This is not only a failure to automatically generate session titles, but also a continuous failure of the main task itself.
meowameowameow commentedon Sep 7, 2026
Same question.
kaixiaochai777-ship-it commentedon Sep 7, 2026
hi 我也碰到这个问题了 你现在解决了吗～
medetasi commentedon Sep 7, 2026
I’m experiencing the same account-specific capacity issue.
Same PC, same network, same Codex client, same model, and same time window:
I submitted Codex diagnostics via /feedback.
Thread ID:
01a07ba0-2252-7651-abcb-44fef1b585f7
M0rtzz commentedon Sep 7, 2026
Same question.
Poseidon-fan commentedon Sep 7, 2026
Same question.
Turtle-Li commentedon Sep 7, 2026
Same question
1saifj commentedon Sep 7, 2026
Same issue @tibo-openai
ip2w commentedon Sep 7, 2026
Same to me, since the night before last, even sol and luna can't be guaranteed to work properly.
I'm on the pro20x subscription plan.
LSQ0317 commentedon Sep 8, 2026
same here
43 remaining items
wq378664056-create commentedon Sep 19, 2026
I’m seeing the same issue on a ChatGPT Pro account using Codex Desktop on Windows.
For several days, Codex has repeatedly returned:
What I have confirmed:
Because the issue spans multiple models and conversations while quota remains available, could the team please check whether this account is hitting an abnormal backend routing / capacity allocation / admission-control / provisioning state rather than ordinary single-model congestion?
If useful, I can provide screenshots, exact UTC-3 timestamps, Codex version, and request/feedback IDs from fresh reproductions.
jumpingFinger commentedon Sep 20, 2026
I am seeing the same exact error in the Codex desktop app on both Windows and macOS:
Selected model is at capacity. Please try a different model.The issue first appeared while I was using the Codex desktop app on Windows. I then switched to a Mac and reproduced the same error with the same account, so the problem is not specific to one operating system or one local installation.
In one local turn, the error was returned repeatedly at several separate stages: while loading the OpenAI Docs skill, during web search, and during browser-assisted search. This was not tied to one prompt or one tool invocation; the selected model failed repeatedly throughout the turn.
The desktop app otherwise remained responsive. I have a screenshot showing the repeated capacity errors in the turn history. The cross-platform reproduction is consistent with an account/session routing or capacity assignment issue rather than a local project error. I can provide additional timestamps or diagnostics through a private channel if needed. Adding instrumented data from an affected account, since most of this thread is "same" reports.
Environment
Failures logged locally (UTC)
What this shows
Control experiment
Same account, same machine:
codex execcompleted N/N requests while Desktop failed M/N in the same period. Same models, minutes apart.yangjinmin666 commentedon Sep 20, 2026
Same issue, ChatGPT Pro (20x), still ongoing after 21+ hours. Adding a complete elimination matrix
so the team can skip the usual back-and-forth.
Account: ChatGPT Pro (plan=pro, x-codex-active-limit=premium) — account ID available to staff on request
In-app feedback ID: 01a0bb5f-3d4f-7a30-a542-4f939aeb107a
Window: 2026-09-19 14:28 -> 2026-09-20 16:30 local (UTC+8), ongoing
MEASURED
model.", delivered IN-STREAM after HTTP 200. No 429/503 was ever returned.
x-codex-primary-used-percent=19, no restriction field in any response header.
ELIMINATED BY DIRECT MEASUREMENT (not by reasoning)
model-cache errors. Capacity failures continued unchanged afterwards.
AND a Japanese residential FTTH IP (125.103.213.39, AS17506, ftth.ucom.ne.jp, Tokyo). Identical
failure rate; cf-ray confirms the switch (-SJC -> -NRT).
bucket with 19 requests had 0%.
(33.9%).
MINIMAL REPRODUCTION (matches @gv1983us-commits's method, no user config required)
codex exec --skip-git-repo-check -m gpt-5.6-terra -c model_reasoning_effort=high "reply OK"
-> succeeds most of the time
codex exec --skip-git-repo-check -m gpt-5.6-terra -c model_reasoning_effort=high "describe" -i img.png
-> during 02:26-03:16 local this failed on 5 of 5 models, then recovered on its own
FAILING REQUEST IDS (HTTP 200, then died in-stream)
04:29:15 gpt-6-astra req_be708ea607d845df897148f33a4fdaf2 cf-ray a3db576d3fdcf4a6-NRT
04:30:12 gpt-6-astra c09497a9-93c4-4ea2-ad0e-9abc607addfe cf-ray a3db58c06b4b49a8-NRT
04:30:29 gpt-6-astra req_0d7c2655f00340f49019d76c15b24fa2 cf-ray a3db593b2c905087-NRT
04:32:21 gpt-6-astra req_05e3417afdb741489779a9f51f456ae9 cf-ray a3db5bf90eaaac08-NRT
04:33:28 gpt-5.6-luna req_d86caa1d9dcf4046a243c99836b84955 cf-ray a3db5d9bfe43d77d-NRT
04:35:23 gpt-6-astra ee8dede7-883c-4d5e-9c51-9bb7c4ec274b cf-ray a3db605e7805d74c-NRT
(60 more available on request.)
ASK
Official community guidance (OpenAI Support, 2026-09-14) states that "access to certain models or
features may be temporarily limited based on account activity, even when a paid subscription is
active", and that access is automatically reassessed once the activity affecting availability stops.
If that is the mechanism here, please:
on the remaining server-side possibilities (e.g. the safety-buffering path — every response carries
x-codex-safety-buffering-enabled: true and x-codex-safety-buffering-faster-model: gpt-5.6-luna).
Impact: a task issuing 10 sequential requests (the median Codex turn issues 3, the mean 12, observed
max 201) completes uninterrupted only ~15% of the time. This has blocked work for 21+ hours on a paid
Pro subscription.
HUL-27 commentedon Sep 20, 2026
I have an additional observation that may help narrow this down.
Environment:
Observed behavior:
This looks like a useful correlation between the usage/entitlement state and Codex admission/routing. I cannot tell whether Usage is causing the inference issue or whether both are consequences of a shared backend/account-state problem, but the inverse correlation is strong enough that it may be worth checking the account's entitlement/usage state together with Codex admission/capacity routing.
I can provide screenshots and timestamps privately if useful.
HUL-27 commentedon Sep 20, 2026
Additional observation from the same account/session, which may help distinguish a pure capacity problem from a state-refresh problem:
Sequence observed after waking the desktop app:
"Selected model is at capacity. Please try a different model."
So the change is not limited to whether a new request is admitted. An already-active turn also appears to be rehydrated/re-attached/restarted in the UI at approximately the same moment that Usage state becomes available.
I cannot tell from the UI alone whether:
However, the timing suggests that Usage/account-state refresh may be correlated with both:
This may be worth correlating against backend telemetry for entitlement/usage refresh, app-server reconnect/session rehydration, and admission/routing decisions for the same account.
HUL-27 commentedon Sep 20, 2026
Follow-up that refines my previous observation:
After waking the desktop app again, I retried a previously unfinished window/task.
Observed sequence:
This means my earlier observation should NOT be interpreted as "opening Usage directly causes capacity." Capacity can also occur while Usage is still unavailable/unloaded.
The pattern now looks more like a transient account-state refresh/race after app resume:
A more accurate hypothesis is therefore:
app resume -> account/entitlement/usage state refresh -> transient inconsistency in Codex admission/routing and possibly session/stream rehydration
I still cannot determine causality from the client UI alone, but this sequence weakens the simpler "Usage panel itself triggers the bug" explanation and points more toward a shared backend/account-state synchronization issue.
If useful, I can continue collecting timestamped sequences of app resume, Usage availability, capacity failures, retries, and successful turns.
HUL-27 commentedon Sep 20, 2026
Important clarification to my earlier Usage-related observations:
There are two distinct "Usage not loaded" states, and they should not be conflated.
State A — persistent Usage failure
State B — normal transient loading
So the stronger correlation is not:
"Usage not loaded -> Codex works"
It is instead:
"Persistent Usage backend/panel failure -> Codex was consistently healthy"
while:
"Normal/transient Usage loading -> no protection from capacity errors"
This weakens the idea that merely opening the Usage panel or waiting for it to load is causal. A better hypothesis is that a real/persistent failure of the Usage/entitlement path may push the account onto a different fallback/cached path, while the normal healthy Usage/entitlement path may still coexist with the account-scoped Codex admission/routing failure.
I cannot prove the internal mechanism from the client, but the distinction between persistent Usage failure and ordinary transient loading is repeatable enough that it seems important for backend correlation.
linyuhanggg commentedon Sep 20, 2026
Same account-level symptom here, now with in-product feedback logs uploaded and a matching report filed: #46798
Two data points that may help this thread:
service_tier = "priority"(Fast) does not avoid it. Correlating all 41 failures with the tier active at that turn:default36,priority3, unlabelled 4 — the priority-tier failures were 2026-09-20 09:00:04Z, 09:00:18Z and 09:07:19Z. Worth ruling out, since "turn on Fast mode" is the usual advice.codex exec: gpt-6-astra failed 1 of 6 runs and gpt-5.6-sol 1 of 4.Also not effort-related (medium 27 / high 13 / low 1) and not a usage limit (weekly window 4.0% used,
rate_limit_reached_type: null).liushilong471-dotcom commentedon Sep 20, 2026
me too，the same problem。
HUL-27 commentedon Sep 20, 2026
Additional observations from the same affected Plus account, combining this afternoon's controlled tests with a recurring time-of-day pattern.
Persistent Usage failure window — Codex became unusually stable
During a period when the Usage panel was genuinely broken for an extended time (I explicitly opened it and stayed on it; it did not load for a long time), Codex was markedly more reliable.
Observed during that same persistent Usage-failure window:
019fa292-ee7e-7521-866a-79bc54e1345dreply OKOK.OK.So this was not a single recovered thread or a single-model coincidence. During one persistent Usage-service failure window, both Luna and Sol worked across multiple independent conversations, including fresh minimal tests.
Important clarification:
Current healthy window
Later, Usage recovered and was visible normally while Codex also worked normally, including Luna at high reasoning. So Usage availability itself is clearly not a simple on/off trigger for the capacity error.
The pattern currently looks more like an intermittent backend/account-state condition that can produce several combinations:
This points more toward a shared account-state / entitlement / admission / routing subsystem than the Usage UI itself being causal.
Preliminary time-of-day pattern
I have also noticed a recurring time-of-day pattern (all times in China Standard Time / Beijing time, UTC+8):
This is still an observation rather than a proven schedule, but it has repeated enough to be worth correlating against backend serving-pool / scheduler / account-routing telemetry.
At the moment, the best working description is:
intermittent account-scoped admission/routing instability, potentially amplified by time-of-day load, with persistent Usage-service failure sometimes coinciding with a surprisingly healthy Codex path.
I can continue collecting timestamped A/B sequences (Usage state, model, reasoning level, thread, success/capacity outcome) if that would help correlate server telemetry.
xini444915666-ctrl commentedon Sep 29, 2026
Same issue here on ChatGPT Pro 20x.
The problem has persisted since Sep 22, 2026 across multiple Codex models. My local logs contain 60 distinct affected turns, all with
codex_error_info: server_overloaded.I submitted an affected session through Codex
/feedbackwith diagnostics included.Feedback ID:
01a0eb8b-243f-7bd1-83d4-1a8de7299c2bI posted the full timeline and evidence here:
#45376 (comment)
Please correlate this Feedback ID with backend diagnostics if possible.
Poonwai commentedon Sep 29, 2026
fuck openai！
ewinhao-ops commentedon Oct 1, 2026
Same issue on my account (ChatGPT Pro 20x, Codex desktop app 26.928.21956, macOS 27.0).
If this is an account-level limitation, it would really help to know what triggers it and how to get it reviewed.
CCHorizon-cmyk commentedon Oct 9, 2026
Additional occurrence — 2026-10-09 (UTC+08:00), full weekly allowance after reset
I'm reporting another occurrence of this same user-visible failure in Codex Desktop:
Selected model is at capacity. Please try a different model.This is an additional observation consistent with capacity failures occurring despite an available weekly allowance. It does not establish whether the cause is service-side capacity, account routing, or entitlement/provisioning. Please investigate the affected model-serving path and distinguish these errors from an exhausted quota where possible.
The error and quota UI screenshots are available, but I have not published them or any account identifiers, credentials, session content, or local logs in this public thread.
Related same-day report involving the same two models: #52394.
CCHorizon-cmyk commentedon Oct 9, 2026
Additional reproduction reported on 2026-10-09 (UTC+08:00) from a Codex Desktop user:
Selected model is at capacity. Please try a different model.This appears consistent with the account/quota-versus-model-capacity symptoms described in this issue, with additional affected model coverage as of October 9. It may also be related to #52394, but a shared root cause has not been established.
Could maintainers investigate request routing, entitlement propagation after quota resets, and capacity/overload responses when the usage meter reports 100% available? Screenshots of the exact UI error and usage meter were provided to the assistant, but are not attached here; no account identifiers or local project data are included.