“Selected model is at capacity”: Our Codex Capacity Incident Review
Posted August 12, 2026 by YAI Technical Team ‐ 9 min read
Recovery update — August 12, 2026: OpenAI Status has marked the increase in errors across API, Codex, and Work Mode as resolved. Reports from peers and our users this morning also indicate that service is returning to its previous level of stability. We are continuing to watch individual account cohorts and regions.
This is not an attempt to blame every failure on one layer. It is an incident review for users, enterprise customers, and industry peers.
Over the past two weeks, some people using Codex through YAI Router repeatedly received this message:
Selected model is at capacity. Please try a different model.
It sounds like a routine prompt to switch models. In this incident, however, the error persisted, affected accounts unevenly, and could appear between successful turns in the same session. For users who depend on Codex for long-running tasks, code review, and enterprise automation, that was no longer a negligible transient failure.
The short version
Our conclusions are:
- This was not an isolated YAI Router failure. Public reports show the same behavior across official Codex surfaces and other compatible entry points. Codex issues and OpenAI incident records provide independent evidence.
- Model capacity is not the same as account rate limiting, depleted usage, or an invalid subscription. An OpenAI Codex collaborator explained in issue #19583 that this message can mean there is insufficient regional capacity to serve the model, even when the user still has usage available.
- The pattern varied by account, region, or upstream capacity pool. Long-established accounts remained stable while a recently activated cohort failed much more often. Other reports showed a failed turn followed by a successful turn in the same session.
- We removed the temporary special-case handling after upstream recovery. Keeping an invasive workaround in the gateway could create duplicate requests, damage streaming or session state, and make future incidents harder to diagnose.
“Upstream capacity pool” is our operational conclusion, not an official disclosure of OpenAI's internal scheduler. From outside OpenAI, we cannot prove that one account maps to a particular physical machine. We also will not publish complete authentication artifacts, destination IP addresses, or account identifiers.
Where YAI Router sits in the path
YAI primarily provides stable AI API services for enterprise customers, including Codex- and Grok-related model access. On top of our production API Gateway foundation, we built yairouter.com as a unified service for individual users.
The service now supports dozens of universities and more than one hundred enterprise customers. A substantial group of enterprise customers also runs independently deployed YAI Router instances inside private networks or private clouds. Those deployments, and the shared cloud service, have operated reliably over the long term.
That made the key diagnostic question very specific:
Why would identical gateway code and request handling fail disproportionately for recently activated accounts while older accounts and many other users remained healthy?
Why this incident was unusually difficult to isolate
It was not global
Many users never saw the error. Some could switch accounts at the same time and continue working. We therefore rechecked:
- model names, reasoning effort, and protocol shape;
- differences between WebSocket and HTTP paths;
- local caches and configuration on new machines;
- credentials, funding status, plan access, and permissions;
- routing, retries, and session affinity inside the gateway.
The comparison was consistent: older accounts continued to operate normally, while a group of newly activated accounts could reproduce the capacity error even from a fresh machine with a minimal request. That made a local configuration or application-code difference much less likely.
The HTTP status was 200, but the response semantics were an error
On the affected path, we observed an upstream HTTP 200 response whose body represented model capacity unavailability. For a gateway, that has important consequences:
- status-only monitoring records a success;
- generic 4xx/5xx retry logic does not run;
- the body must be decoded before the business failure can be identified;
- streaming, usage accounting, and client state can disagree about the outcome.
To reduce user impact, we temporarily inspected every relevant 200 response and classified the capacity message in real time. This helped at the surface, but a gateway cannot manufacture upstream compute capacity. It also made a critical hot path much more complicated. Once the upstream origin was sufficiently established, we reverted that temporary logic.
A healthy account does not guarantee immediate capacity for every route
Valid authentication, successful funding, and an account in good standing establish eligibility. They do not guarantee that every model has available admission capacity in every region, at every time, and in every upstream pool. Confusing eligibility with immediate inference capacity is the main reason this error is so misleading.
How the evidence narrowed the scope
| Observation | Diagnostic implication |
|---|---|
| Older accounts were stable while new accounts failed under the same YAI Router code | Inconsistent with a gateway-wide software failure |
| A fresh machine and a minimal request could reproduce it | Unlikely to be a local cache or one broken client |
| Many accounts remained healthy | Inconsistent with a simple global limit affecting everyone |
| Funded, authorized accounts still received the message | Capacity and account entitlement are separate states |
| The same session could fail and then succeed | Consistent with transient admission, routing, or pool pressure |
| Upstream returned HTTP 200 with error semantics | Requires semantic error detection, not only transport monitoring |
These signals moved our focus from request generation to routing and capacity allocation after account authentication. Some authentication sessions expose edge-gateway host metadata, and we observed routing-related differences between the old and new cohorts. That supports our working hypothesis that some accounts entered an unhealthy upstream route or capacity pool. It does not prove OpenAI's physical topology.
The following is a sanitized structural example only. It is not a credential from a real account:
{
"host": "chat.gateway.<redacted>.api.openai.com",
"iss": "edge-gateway",
"aud": ["chatgpt.com"],
"iat": "<redacted>",
"exp": "<redacted>"
}What OpenAI's public records show
Our conclusion is not based only on internal logs. We reviewed OpenAI Status and public reports in the official openai/codex repository.
OpenAI Status
- August 11, 2026 — Increase in errors on API, Codex and Work Mode: OpenAI recorded identification, mitigation, monitoring, and full recovery at 22:42 UTC, or 06:42 Beijing time on August 12.
- July 9, 2026 — Elevated errors when selecting models: the incident explicitly referenced “Selected model is at capacity” across multiple models.
- July 17, 2026 — Increased server-overload errors for Codex 5.6-sol: OpenAI recorded elevated server-overload errors and the subsequent recovery.
- June 16, 2026 — Codex “Selected Model is at Capacity” error: an earlier official record of the same error class.
The status site also notes that availability is reported in aggregate across tiers, models, and error types, while an individual customer's experience can vary by tier, model, and API feature. This is why “many users are fine” and “a subset of accounts is repeatedly failing” are not contradictory observations.
The official Codex repository
- Issue #19583: a user reported capacity errors with substantial usage remaining. An OpenAI collaborator clarified that the message does not necessarily mean rate limiting or exhausted usage; it can indicate low capacity for that model in the user's region.
- Issue #17014: a model failed despite available quota, then a later minimal request succeeded, consistent with transient model admission rather than persistent account exhaustion.
- Issue #30073: the error appeared intermittently inside an active session, with successful requests before and after it.
- Issue #33853: a user requested bounded retry and queue pausing after this error, showing its real impact on long-running task orchestration.
A GitHub issue is a user report, not an internal root-cause statement. Taken together with the collaborator clarification, official status incidents, and independent reports from multiple clients, however, the evidence shows that this was not unique to YAI and should not be reduced to one user's balance or configuration.
What we did
While the origin was still uncertain, we took the least disruptive steps available:
- Classified error semantics inside 200 responses so failures were not recorded as successful completions.
- Preserved the original context and evidence across accounts, models, entry points, timestamps, and response shapes.
- Escalated through public and peer channels. We contacted relevant OpenAI personnel on X.com and compared timelines with peers using the same upstream service.
- Reverted the temporary workaround after upstream recovery. We did not continue hiding a capacity failure or silently changing the requested model.
- Monitored segmented recovery across older accounts, newer accounts, models, and transport paths instead of relying on one aggregate success rate.
We deliberately avoided unlimited retries. Retrying a large-context Codex task can repeat consumption, amplify upstream load, cause duplicate charges, or corrupt session and streaming state. Reliability means keeping failures explainable, recoverable, and auditable—not merely sending the same request again.
What users should do if the message returns
- Check OpenAI Status for an API or Codex incident.
- Do not immediately resubmit the same large agent task many times. Preserve the session and retry after a reasonable interval.
- Record the timestamp and timezone, model, entry point, affected account cohort, and request ID. Never send an API key, access token, or unredacted sensitive response fields.
- If the workload has a strict deadline, use a pre-validated fallback model and account for differences in capability, context, latency, and cost.
- Enterprise and private-deployment customers can send us a sanitized timeline. We will help distinguish a local gateway problem from an upstream account or model-capacity incident.
Our reliability commitment
Since launch, YAI Router has put stability, observability, and enterprise control ahead of simply listing more models. This incident reinforces several engineering principles:
- gateways must observe both HTTP status and response semantics;
- upstream capacity, regional routing, and account cohorts need segmented health signals;
- temporary compatibility logic needs an explicit exit condition;
- enterprise fallback must be controlled and auditable, never an invisible rewrite of the user's request.
Thank you to our users, enterprise customers, and peers for the patience, reproductions, and direct feedback. We will continue improving the API Gateway, YAI Router, and the surrounding Codex and Grok services to provide stable, transparent, and sustainable AI infrastructure.