Repository navigation
Codex App repeatedly shows "Selected model is at capacity" despite healthy connectivity #45835
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.908.70816
What subscription do you have?
Pro Lite
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
Codex frequently fails with:
"Selected model is at capacity. Please try a different model."
OpenAI Status shows no active incident, and codex doctor reports healthy auth, HTTP connectivity, and a successful WebSocket HTTP 101 handshake.
What steps can reproduce the bug?
Feedback ID: 01a0a78c-2547-7231-a3bb-5d200048d632
What is the expected behavior?
Codex should process the request normally when the model is available, or show the actual underlying error instead of a misleading capacity error.
Additional information
Please inspect the backend request associated with the Feedback ID to determine why this environment repeatedly receives capacity errors despite healthy connectivity.
Activity
github-actions commentedon Sep 16, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
BackGwa commentedon Sep 16, 2026
This issue has persisted for the past three days. While the OpenAI Status page continues to report that everything is operating normally, a considerable number of users appear to be experiencing the same problem.
Given that, I’m genuinely curious as to how this situation is still being classified as “normal.”
icannotwait commentedon Sep 16, 2026
@BackGwa https://community.openai.com/t/issue-selected-model-is-at-capacity-please-try-a-different-model/1396264/87
The more you use subscription, the more they lose, so they throttle you harder.
BackGwa commentedon Sep 16, 2026
The most concerning aspect of this issue is that it does not appear to be limited to particularly heavy users. It seems to be affecting users with relatively ordinary usage patterns as well.
I would not consider myself a heavy user by any reasonable standard. I do not use multiple agents in parallel, nor do I routinely assign sustained, high-load workloads to the model. I am nowhere near 100 million tokens per day, and recently I often have not even reached 50 million tokens. Despite that, I am still being subjected to these restrictions, which is genuinely difficult to understand.
More importantly, being unable to access the model precisely when I actually need it is difficult to reconcile with the expectations of a paid service.
If there is, in practice, a five-hour usage limit or some other form of dynamic usage restriction, I believe it would be far better to disclose those limits and the user’s current usage transparently. That would allow users to understand when they are approaching a limit and would avoid a great deal of unnecessary confusion.
As it currently stands, users can suddenly lose access without being given any meaningful information about the applicable limit, how close they are to it, or when access will be restored. From a user’s perspective, this is extremely opaque and creates a significant gap between the level of access the service appears to offer and the level of access that is actually available.
BackGwa commentedon Sep 16, 2026
I realize that a GitHub issue may not be the ideal place for this kind of commentary, but I would still like to state my view clearly.
What is clear is that, regardless of whether the underlying cause is in fact a server capacity issue on OpenAI’s side, the frequency of the “Selected model is at capacity” error has increased noticeably.
If the actual cause is related to server availability or increased overall demand, I would think it would be more appropriate to reflect that in the service status and clearly inform users that capacity-related restrictions are currently occurring.
As things stand, however, the Status page continues to indicate that all systems are operating normally, while users are being denied access with a “Selected model is at capacity” message. If the threshold for that restriction is not even fixed and can vary depending on circumstances, it becomes very difficult for users to understand what level of service they can actually rely on.
If server-side capacity constraints are effectively being handled through variable, per-user limits, then the service may appear fully operational from the outside while the amount of access actually available to users changes dynamically. It is difficult to regard that as a particularly transparent way of operating the service.
If there is a capacity problem, simply acknowledging that there is a capacity problem would be far easier to understand. From a user’s perspective, being told that everything is operating normally while access is nevertheless being refused is, at the very least, somewhat contradictory.
ivLis-Studio commentedon Sep 16, 2026
I am experiencing the same problem.
I use a total of three Plus accounts and one Pro 20x account, but this problem does not occur with the three Plus accounts. This issue occurs only with the Pro 20x account, and it does not appear to be an issue related to the use of proxies or third-party programs.
BackGwa commentedon Sep 16, 2026
I’m also fairly confident that this issue is occurring more frequently among Pro users. Looking at the reports currently posted on GitHub, several of the affected users appear to be subscribed to either the 20x Pro or 5x Pro plan.
BackGwa commentedon Sep 16, 2026
More testing is still needed, but one thing I noticed during my experiments is that the issue does not seem to occur when using the Daybreak Blue model.
Normally, the “Selected model is at capacity” error occurs repeatedly regardless of which model is selected, to the point where it can make it nearly impossible to continue working. However, so far, I have not observed the same interruptions while using Daybreak Blue.
GaryLBQ commentedon Sep 16, 2026
What a letdown. The Pro account actually feels worse than the Plus account.
BackGwa commentedon Sep 16, 2026
To be candid, I find one of the Codex team’s previous responses to this issue somewhat concerning.
I understand that OpenAI cannot disclose the exact details of internal account checks or abuse-prevention systems. That part is reasonable. However, I do not think that response fully addresses what users are actually experiencing.
If access is being restricted because of “account activity,” then why is the client reporting “Selected model is at capacity” instead? And if this is effectively some form of account restriction or enforcement action, shouldn’t that at least be communicated clearly to the affected user, either in the product itself or by email? Being restricted without any explicit notice, while being shown what appears to be an unrelated capacity error, leaves users with no realistic way to understand what has happened.
On the other hand, if this genuinely is a capacity issue, it is difficult to reconcile that with the Status page continuing to show normal operation while multiple users have been reporting the same behavior for several days.
The most frustrating part is that users effectively have no action they can take. There is no clear limit to check, no restriction notice to review, no meaningful troubleshooting step, and no indication of when normal access will return. At that point, all we can really do is open a GitHub issue and wait indefinitely for something to change.
I do not think users are asking OpenAI to reveal internal detection logic or anything that could be used to bypass safeguards. We are simply asking for enough information to determine whether this is a usage limit, an account-level restriction, a genuine capacity problem, or an actual bug.
At the moment, the previous explanation provides very little practical clarity, while leaving affected users with essentially nothing they can do on their side.
BackGwa commentedon Sep 16, 2026
I have collected some of the publicly reported issues describing the same or very similar symptoms.
#43337 #39643 #44113 #45600
#45648 #45901 #44558 #43663
#44516 #43398 #41790 #43738
Similar symptoms are being reported across different subscription tiers, operating systems, clients, and models. Some reports also indicate that, even under the same environment, the issue affects one account while another account works normally.
And these are only some of the cases that users have taken the time to report publicly. The actual number of affected users is likely higher.
Given how consistently similar reports continue to appear, I am genuinely curious whether these should still be considered separate, isolated issues.
BackGwa commentedon Sep 17, 2026
I’ve just posted a topic about this issue on the OpenAI Developer Community:
https://community.openai.com/t/selected-model-is-at-capacity-has-been-disrupting-codex-for-days-yet-there-is-still-no-clear-explanation/1398340/
[Moved] -> https://community.openai.com/t/severe-model-degradation-and-persistent-selected-model-is-at-capacity-errors/1397724/42
WachsenHaus commentedon Sep 17, 2026
same problem
benjamindell commentedon Sep 18, 2026
I am also experiencing this issue. Im on a 20x plan and for the last week its been unusable. Every few minutes i get the dreaded "Selected model is at capacity. Please try a different model." message. Its infuriating.
Is this actively being looked into?
mradwankhalil commentedon Sep 19, 2026
Related data point: identical account-side serving degradation on a Pro Lite account — manifesting as severe slowness (not only capacity errors), reproduced with no third-party client involved:
codex exec/resume), trivial follow-up turns: 26.0s / 29.3s / 33.2s; per-turn usage 196k input / 151k cached → ~45k tokens re-processed per turn./backend-api/codex/responses(no client), single short sentence: 10.9–20.8s wall, TTFB 1.5–3.5s;service_tier:"priority"→ still"service_tier":"auto"(fast lane not granted);flex→ HTTP 400.x-codex-plan-type: prolite,x-codex-active-limit: premium, weekly usage 8–9%, credits 0. No restriction flag visible, yet requests serve slowly.x-oai-request-id: cd9ec4e2-5624-47cb-94a0-295ffa502d16.x-codex-secondary-window-minutes: 0). It disappeared Sep 6 ~18:30 GMT+3 after a usage-limit reset — the same window serving degraded.Related pattern reports: #46231 (account-scoped capacity on Pro, cross-over tested), #45733 (Luna xhigh quota drain + stalls since Sep 14), #46284 (Pro detected as Pro Lite).
Question for the Codex team: can you check the backend request IDs above and confirm whether Pro-tier accounts are currently served at reduced priority / under account checks, and how affected users get that reviewed? Full evidence pack available (2-hour latency series, header captures, request IDs, support-case reference).
zhaotiemao commentedon Sep 20, 2026
I'm having the same problem. When will it be fixed? I can't get any work done.
BackGwa commentedon Sep 21, 2026
It still hasn’t been resolved at all.
mountainsRivers98 commentedon Sep 21, 2026
+1 一直报错！！
benjamindell commentedon Sep 21, 2026
This is getting ridiculous for me. Almost every thread now that I'm working on today is getting blocked with that same "selected model is at capacity" message. Codex is completely unusable.
BackGwa commentedon Sep 22, 2026
I received an official response from OpenAI Support regarding this issue via email.
In practical terms, Mikee D’s response can be summarized as follows:
... I have to say, this response is extremely difficult to accept.
OpenAI says it is aware of the issue. Yet if it affects only some users, it does not need to be reflected on the Status page. OpenAI also says it cannot confirm or disclose the exact cause, and even if users are unable to use a paid service properly or suffer actual disruption to their work as a result, no compensation will be provided.
At that point, it is difficult to interpret this as anything other than the user being expected to absorb the entire cost and impact of a problem on OpenAI’s side.
OpenAI acknowledges that the problem exists, but does not need to publicly reflect it, cannot explain its cause, and will not compensate users affected by it.
I genuinely struggle to understand how this is considered an acceptable response to paying customers.
If users are unable to properly use a paid service because of an issue on the service provider’s side, I believe the provider should bear at least some responsibility for that failure.
BackGwa commentedon Sep 30, 2026
This issue is still ongoing.
mradwankhalil commentedon Oct 10, 2026
Clarifying my September 19 data point: the latency series and plan/window headers show a problem on my account's observed serving path, but they do not by themselves identify backend queueing, reduced priority, an account restriction, or the same root cause as the App capacity error. “Pure queue/congestion behavior” was too strong.
The request ID remains useful for OpenAI's backend investigation, which client-side testing cannot replace. I have not performed a new inference run or independently verified a backend fix; I can supply a minimal redacted timing/header sample privately if the team requests it.
BackGwa commentedon Oct 19, 2026
I will no longer discuss this matter.