For the past several days, Codex has repeatedly been failing with the following message:
Selected model is at capacity. Please try a different model.
I have been experiencing this issue myself and have documented it in GitHub issue #45835. Similar reports are also appearing across multiple topics in the OpenAI Community, which makes it increasingly difficult to treat this as an isolated problem affecting a single user or environment.
At first, I assumed this was simply a temporary capacity issue. That would be understandable. However, after several days of repeated failures, the larger concern is that users still do not have a clear explanation of what this error actually represents.
In my environment, codex doctor reports authentication, HTTP connectivity, and WebSocket connectivity as healthy, and the WebSocket handshake completes successfully. I still have usage available, and the OpenAI Status page continues to show normal operation. Despite that, Codex repeatedly fails with “Selected model is at capacity,” sometimes frequently enough to make normal development work difficult.
From a user’s perspective, this is contradictory. The diagnostics say the environment is healthy, the Status page says the service is operational, and usage remains available, yet Codex itself refuses requests because of capacity. The error also explicitly suggests trying another model, but switching models, signing in again, starting a new conversation, or restarting the client does not necessarily resolve the problem.
This also raises concerns about whether the error message accurately describes the underlying issue. Users have no practical way to determine whether they are facing an actual model-capacity shortage, a usage limit, an account-level restriction, a routing or admission-control problem, or some other backend issue.
I do not expect OpenAI to disclose internal abuse-prevention systems or account evaluation logic. However, keeping internal criteria private is different from leaving users unable to identify even the basic category of failure that is preventing them from using the service. At minimum, the user-facing message should accurately describe the type of problem involved.
If materially different conditions can all surface as the same “Selected model is at capacity” message, users are inevitably pushed toward the wrong troubleshooting steps. Waiting or switching models may make sense for a genuine capacity shortage, but those actions may be completely irrelevant if the actual issue is account-specific or somewhere else in the backend.
The Status page creates a similar problem. If some users are unable to use Codex normally for several days while the service continues to be shown as fully operational, then the status information does not adequately reflect the experience of those affected users.
I am not arguing that paid services should never experience capacity shortages, backend failures, or temporary restrictions. Those things can happen. The problem is that when they do happen, users should be given enough information to understand what kind of problem they are dealing with and whether there is anything meaningful they can do about it.
This issue is now being discussed both in GitHub issue #45835 and across multiple OpenAI Community topics. Yet affected users still cannot clearly determine whether this is a known issue, what category of failure they are experiencing, or whether there is any supported action beyond simply waiting and retrying.
OpenAI does not need to disclose every internal detail. But it would be reasonable to clarify whether the recurring “Selected model is at capacity” behavior is a known problem, whether this message can represent conditions other than actual model capacity, what affected users are expected to do, and why significant service disruption is not reflected more clearly in the Status page.
The most frustrating part is not simply that requests fail. It is that Codex can refuse work for days while diagnostics and service status indicate that everything is normal, and the only explanation provided to the user may not clearly describe why access is being denied.
Service problems are understandable. Leaving users without enough information to identify or respond to those problems is a separate issue.
A very similar discussion previously ended with the response shown above, followed by the topic being closed.
That response effectively leaves affected users with only one piece of information: access may be limited for reasons they are not allowed to know, and they should simply wait until it changes.
That is an extremely weak conclusion for a paid service issue. Users are not asking for internal detection rules or anything that could be used to circumvent safeguards. They are asking for enough information to know what has happened to their access and whether there is anything they are expected to do.
More importantly, closing the topic after giving such a vague explanation creates the appearance of resolution without actually providing one. The conversation disappears, but the users affected by the problem are left in exactly the same position as before.
It is a little like turning off the warning light and calling the dashboard fixed. The visible complaint is gone; the reason it appeared is not.
And when users later return with the same problem, they are forced to start the same discussion again from the beginning.
That is the part I find particularly difficult to accept. A support response does not become sufficient simply because the topic containing it has been closed.
If access has been deliberately limited, affected users should at least be told clearly that their access is limited and what they can reasonably expect next. “We cannot provide additional details” should not also mean “there is nothing meaningful we will tell you at all.”
Closing a topic is an administrative action. It is not evidence that the user’s problem has been resolved.
I 100 percent agree with this
Надеюсь массовый отказ от использования PRO обанкротит эту помойку…
【Disclaimer: This is purely my subjective opinion, please judge carefully.】
I’ve spoken with numerous users, both those with unrestricted accounts and those hit by restrictions. None of them were abusing their accounts. Here are my personal observations:
- Improvement may not come until next week, when 6sol rolls out officially.
- IP address is not the primary cause of the restrictions.
- Some users maintain stable performance by running their accounts on US/Japan ISP datacenter nodes or residential IPs. Subscribing via iOS/Googleplay with US billing region also seems to lower the chance of triggering risk controls, and the cost is reasonable.
- High concurrency has no direct link to the limitations. I activated a Plus account yesterday and it suffered degraded output after just two hours. I was using it alone with a single session and zero concurrency, yet the issue still occurred.
To sum up: The ideal setup is a static residential IP, iOS subscription with US billing, and a Google account. If possible, prioritize the Business plan or the regular 5X plan.
All I want is to use my X20 account normally. I renewed my subscription just 12 hours before OpenAI shut down X20. I only got to use it for a little over 24 hours before severe model degradation kicked in. Now I can’t even get it to respond properly. Support is ignoring my messages. I paid for a service that I cannot use, and it’s really hard to accept. I will keep trying other solutions.
Colleagues, I propose organizing a class action lawsuit against OpenAI. It is obvious that the current situation is a scam designed to secure funding without providing a service of proper quality. Since my Pro x20 subscription prevents me from building a website due to model capacity limits, I suggest that those with active Plus or Pro x5 subscriptions build it instead. Let’s build the website based on the attached Prompt. I am ready to host this website on my own server. Promt:
