Business planning depends on continuity. We allocate people, agree deadlines and arrange work in a sequence. A disclosed usage limit can be included in that plan. Scheduled maintenance can be accommodated. An unexpected stop with no clear explanation or dependable recovery time is much harder to manage.
That is the problem I am encountering with OpenAI’s Codex. The message is simple:
Selected model is at capacity. Please try a different model.
The business implications are considerably less simple. What can I promise a client if the tool may stop after work has begun? How much time should I reserve for recovery? What does a Pro subscription allow me to depend on?
Model capacity and account usage limits are separate failure categories. That distinction explains why available allowance can coexist with a capacity error. It also exposes a gap in how a paid AI service can be used for business planning.
Planning a business workflow around AI? Our engineers in Bali can help you assess the software, infrastructure and fallback options behind it. Talk to our engineers.
An allowance does not tell us whether work can continue
Codex’s public error definitions assign this exact message to server overload, separately from an exhausted usage allowance or exceeded quota. OpenAI’s API documentation also distinguishes a temporarily overloaded model from usage and spending limits. These sources explain the categories; they do not diagnose the particular requests in my screenshots. Codex error definitions, OpenAI error documentation
A usage allowance describes a budget for activity. Capacity concerns whether the service can accept a request at that moment. Having budget left therefore does not resolve an availability problem.
For a business, this creates what I would call a soft limiting factor: an additional constraint on usable work whose boundary is unclear to the customer. This is a description of the practical effect, not an official OpenAI limit. The uncertainty is “soft”; the interruption can be a complete stop.
A visible allowance helps me budget consumption. To schedule delivery, I also need a reasonable basis for expecting the work to continue.
The interruption arrives after work has begun
My screenshots from 30 October 2026 show the capacity message at different stages of work. An earlier desktop view captures a planning conversation. A later view of the same named task shows the assistant reporting completed preparation and some website changes, with further imports and connections underway. The capacity banner then appears with a Retry button.
In a separate task viewed on mobile, the warning appears alongside a substantial displayed set of file changes. Opening the agent panel shows three agents still labelled “Working.” That label does not establish whether they were actually continuing, waiting or displaying an outdated status. It leaves the person responsible for the project needing to establish the real state of the work.
The screenshots do not prove that work was lost. They show why interruption and uncertainty are a costly combination: before continuing, someone has to determine what was completed, what remains active and what the next attempt will do.
A Retry button is an action the customer can take. It is not an estimate of when the project can resume reliably.
Other paying users describe the same problem
There are public reports from other subscribers, including Pro users who say they still had allowance available.
| Report date | Subscriber’s reported experience |
|---|---|
| 7 September 2026 | A Pro 20x user reported capacity errors across multiple models with approximately 80% allowance remaining. New sessions and model switching reportedly did not help. GitHub report |
| 23 October 2026 | A Pro user reported failures since the previous day, including in Codex, with more than half their quota remaining. Fresh chats and troubleshooting reportedly failed to restore access. Community report |
| 27 October 2026 | A Pro user reported several days without usable access and a dashboard showing no consumption. They described failures across devices and networks. Community report |
| 28 October 2026 | A subscriber identifying their plan as Pro at $200 per month described roughly two weeks of frequent interruptions. They objected that switching models undermined their reason for buying that subscription. Community report |
| 28 October 2026 | A Plus user reported repeated capacity errors within a single cloud task that prevented it from finishing. GitHub report |
These are individual accounts, not a representative survey or independently audited service measurements. They establish that other users are reporting the same practical difficulty. They cannot establish how often it affects the subscriber population or whether every incident has the same cause.
Recovery also varies. One desktop report was updated on 23 October to say that conditions had improved substantially and retries usually worked, although intermittent failures remained. That matters: some interruptions clear, while the available reports offer no dependable recovery time a business can apply to its next task. Recovery update
Subscription terms can change while businesses are planning around them
There is another uncertainty alongside model availability: the allowance included in the subscription itself.
A video examining the planned 30 October Pro 200 reduction describes a drop from 20 times the Plus allowance to 10 times, at the same $200 monthly price. A subscriber’s published copy of OpenAI’s earlier notice also sets out a planned reduction from 200 to 100 weekly GPT-6 Pro messages in Chat, alongside 62,500 temporary usage credits valued at $2,500 and due to expire on 31 December. Those were announced changes, distinct from an unexplained capacity interruption. Video supplied for this article, Subscriber’s copy of the notice
That planned reduction was cancelled. OpenAI’s release notes dated 29 October say Pro 200 customers already on the higher Work and Codex allowance keep it, while customers on the lower allowance are brought up to the same level. The same update doubles Work and Codex allowances for Pro 100 and Pro 500. It does not give every existing Pro 200 subscriber another doubling. OpenAI release notes
The current Pro help page separately confirms that the higher weekly GPT-6 Pro message limit is retained and lower-limit Pro 200 accounts are brought up to it. Chat message limits and Work/Codex usage remain separate allowances. It would therefore be inaccurate to describe either planned Pro 200 cut as taking effect today. Current Pro terms
The reversal is good news for affected subscribers and deserves acknowledgment. It also changes the story from a cut taking effect to a business being asked to interpret an announcement, prepare for it and then absorb a reversal. Anyone who acted on the earlier notice may already have spent time comparing alternatives or reconsidering a workflow.
The video’s calculations illustrate another difficulty: the percentage depends on what is being compared. Under its assumed token mix and a hypothetical halving of the budget, moving from GPT-6 Sol to GPT-6.1 Sol would retain approximately 76% of the token volume. In the same simplified comparison, half a budget on GPT-6.1 Terra buys as many tokens as a full budget on GPT-6.1 Sol. Neither result means the same tasks will be completed to the same standard. They compare different models, and the planned budget reduction has now been withdrawn.
There is a verifiable pricing relationship behind part of the discussion. For Astra, Sol 6.1 and Terra 6.1, the published Standard-speed Codex input, cached-input and output credit rates are numerically 25 times the corresponding Standard API dollar rates. That comparison alone does not establish a guaranteed API-dollar budget inside a subscription. OpenAI explicitly separates API pricing from included subscription usage. Codex pricing, API pricing
Temporary resets complicate the baseline further. The community tracker cited by the video lists 12 reset-related dates between 5 and 27 October, including a banked reset. A reset announcement is not evidence that every subscriber received and fully consumed another complete allowance. A busy month supported by repeated resets is a weak basis for estimating sustainable capacity in an ordinary week. Community reset tracker
For business continuity, these distinctions matter. An allowance, a temporary credit grant, a promotional reset and model availability each answer a different question. Clear, dated terms should let a customer separate them without reconstructing a subscription from emails, videos and social posts.
Cancelling the reduction preserves the higher allowance as a baseline for planning. It does not establish that the capacity interruptions described here have been resolved.
Has OpenAI sold more access than it can reliably deliver?
That is a reasonable question to ask. These reports do not answer it.
OpenAI announced on 31 March 2026 that it had raised $122 billion in committed capital at an $852 billion post-money valuation. Those dated figures demonstrate enormous financial scale. They do not measure the spare computing capacity available for a particular model at a particular moment. OpenAI funding announcement
Large companies can encounter real shortages. Funding does not instantly become installed hardware, electricity or available inference capacity. Genuine constraints can also coexist with decisions about how access is allocated.
OpenAI openly describes traffic management in its API documentation: rate limits help distribute access and manage infrastructure load. That establishes that allocation controls exist in the API. It does not establish which controls, if any, explain these Codex subscription failures. OpenAI rate-limit documentation
To conclude that OpenAI is overselling would require evidence about the access being sold, the capacity deployed, the expected demand and the reliability customers were led to expect. The screenshots and forum reports do not provide that complete picture.
They do justify asking OpenAI to explain the gap between paid access and usable access. Customers should not have to reverse-engineer that gap from error messages.
The message steers behaviour even when its cause is unclear
The instruction to try another model explicitly directs the customer toward a different choice. Whether the cause is temporary overload, an allocation decision or a fault, the customer is being asked to adapt.
That matters when the selected model is part of a working process. A business may have chosen it after testing its accuracy or ability to handle a difficult task. A substitute can require fresh checking. Changing models halfway through an assignment can therefore add work even when it restores access.
Some users also suspect account-specific restrictions. The 27 October poster says an AI-assisted support response described an account-level limitation. That is the poster’s account of a support exchange, not independently verified evidence of a general restriction policy. It deserves investigation rather than being treated as proof of deliberate manipulation. Reported support experience
The uncertainty itself is damaging. When users cannot tell whether they are encountering congestion, a product fault or a restriction, suspicion fills the gap left by the explanation.
Business continuity needs clearer stopping and recovery conditions
Consider a team scheduling a website release. Content preparation, implementation, verification and approval depend on one another. If an AI task stops during implementation, the team may have to reconstruct its state before verification can begin. Even if all completed changes remain intact, the delivery schedule can slip.
This is an illustrative planning problem, not a claim that my screenshots establish a missed release or financial loss. It shows why usable capacity matters beyond the number on an allowance meter.
A larger subscription allowance addresses how much activity a customer may consume. It does not, by itself, answer when a chosen model will become available after a capacity failure. OpenAI’s own pricing guidance distinguishes usage allowances and explains that consumption depends on the model and task. Those details help budget usage; they do not provide a recovery timetable for the interruptions described here. OpenAI pricing guidance
For business planning, I want OpenAI to make four things clear:
- The reason for the stop: distinguish exhausted allowance, service congestion, account restrictions and product failures as far as the system can determine them.
- The recovery expectation: show whether work is queued, retrying automatically or awaiting a user action, with an estimate when one is available.
- The state of unfinished work: explain what completed, what remains active and where continuation will begin.
- The value and stability of a tier: state which availability or continuity improvements it provides, alongside its normal allowance, temporary promotions and dated changes.
When no recovery estimate is possible, saying so clearly is more useful than leaving the customer to interpret a changing spinner.
Credibility depends on what customers can rely on
An occasional service failure is understandable. Repeated interruptions without enough information to plan around them make a provider harder to trust with a business dependency.
OpenAI does not have to offer unlimited computing to address this problem. It does need to make the operational limits understandable enough for customers to decide how much responsibility to place on the service.
For my future planning, I will judge a Pro subscription by completed, verified work and the effort needed to recover from interruptions, as well as its nominal allowance. Work with firm deadlines needs a usable fallback and enough time for human review. That additional preparation belongs in the cost of relying on the tool.
The unresolved question is whether the access being sold matches the continuity businesses reasonably expect. Until OpenAI explains these stopping points and recovery conditions more clearly, that uncertainty will continue to weaken its credibility as a dependable part of business operations.
Dependable operations need engineering expertise as well as capable AI tools. Bring your next software, infrastructure or automation project to our team in Bali, and let’s discuss how to plan for interruptions and recovery. Discuss your next project.
Sources and user reports checked on 30 October 2026.
