Codex “Selected Model Is at Capacity”, “Reconnecting” and Usage-Limit Errors: What OpenAI’s Docs and Status Incidents Show

Short answer: Three different problems get called “Codex not working.” A usage limit means your plan’s allowance is spent, and OpenAI documents it. The capacity message appears in no OpenAI documentation page we read (it does appear in one OpenAI status incident title), and OpenAI documents no cause. Comments from a GitHub account labelled Contributor say it reflects capacity for the model, not a rate limit on your account, though some user reports describe it as account-specific. “Reconnecting” is a message users report while a connection is retried, and OpenAI’s pages do not define it. The three can also appear in the same session. From July 12 to October 9, 2026, we counted 25 incidents on OpenAI’s status page that tag or name Codex, with a median open time of 111 minutes. We read the documents on October 12, 2026; nothing here is a tested fix.

Key takeaways

Key takeaways

1. A usage-limit notice is about your allowance. Check the usage dashboard, or /status in the CLI, first.
2. OpenAI documents no cause for the capacity message or “Reconnecting”, so any explanation of them comes from user reports and comments, not OpenAI’s documentation.
3. Of 161 GitHub issue titles about the capacity message filed July 12 to October 9, 146 came on days with no Codex incident, so a clean status page does not rule it out.

What do the three messages mean, and what does OpenAI document?

A usage limit caps how much Codex your plan allows in a time window. Capacity message and Reconnecting are our labels for two messages users report and OpenAI does not define. We claim no cause for either.

Usage limits: the one message OpenAI documents

OpenAI’s pricing page (the old developers.openai.com/codex address redirects) says local messages and cloud tasks share one allowance. Its message ranges per five-hour period for Plus and standard Business “are not fixed message limits.” Pro plans “currently have no five-hour limit,” and weekly limits may apply.

If you hit a limit mid-turn, the page says the agent can keep working on that turn. The Help Center article on Codex with a ChatGPT plan then points you to the usage page or limit banner: add credits (Plus and Pro), apply a reset, upgrade, or wait. Support does not reset limits, but wants to hear from you if access has not returned after the stated reset time.

To see where you stand, use the usage dashboard or /status in a CLI session. Developers get a label, UsageLimitExceeded, in the App Server reference.

Does OpenAI document “selected model is at capacity”?

No. We searched the combined Codex and ChatGPT documentation export (about 50,000 lines), the pricing page, the troubleshooting page, and the Help Center’s Codex and ChatGPT error-message articles. The message appears in none.

What exists instead:

• GitHub comments, not documentation. On April 7, 2026, in issue #17014, an account labelled Contributor on the repository, wrote that the message is “not specific to your account.” On May 12, in #19583, it wrote that the message does not mean you are rate limited, and that capacity to serve the model is running low in your region. On June 16 it commented on #19583 that the problem “has been mitigated” (the issue is now closed).
• A forum reply. On July 17, an account named OpenAI_Support replied in a community thread the problem “sounds like an issue on our end.”
• Two status incidents (read on their pages). The first, titled Codex “Selected Model is at Capacity” Error, ran 10:32 to 13:48 UTC on June 16 (196 minutes), degraded on all five Codex components. The second, “Codex 5.6-sol Experiencing Increased Server-Overload Errors”, ran 17:19 to 20:42 UTC on July 17 (204 minutes), with no component marked. Both first updates say users were experiencing “elevated errors for the impacted services.” The June incident predates our dataset, so it is not in the counts below.

User reports (unverified). On October 12, a title search for “at capacity” in the openai/codex repository returned 199 results (183 contain the full “selected model is at capacity” wording): 198 issues and one pull request, the first filed February 12, 2026. 128 were filed in September, and 178 of the issues remain open. We did not check that every title describes the same failure.

Of the 161 titles filed between July 12 and October 9, 15 were filed on a day when a Codex-touching status incident was open (20 of the 90 days), and 146 on other days. Reports cluster on particular days, mostly in September when no incident was open, so this comparison cannot show what caused them. It shows only that a quiet status page does not rule the message out.

“Reconnecting” and “stream disconnected”: what the documents say

Users report both Reconnecting and stream disconnected before completion during connection trouble, sometimes together. Neither string appears in OpenAI’s documentation. Four related pieces do:

• Network guidance. The Help Center’s network article says Codex uses a WebSocket connection to wss://chatgpt.com/ for “Codex model sampling and streaming.” If a network blocks it, features “may stall, disconnect, or fail to stream updates correctly.” IT teams are asked to allow WebSocket traffic.
• Retry defaults. The configuration reference lists, for custom model providers, 4 retries for HTTP requests, 5 for streaming interruptions and a 300,000 millisecond idle timeout. Of the 97 “reconnecting” issue titles, 21 include a counter such as “3/5.” The 5 may be a coincidence: no page links the two, and the error after the counter differs between reports (401 Unauthorized in #8807, 413 Payload Too Large in #10922).
• Error names. The App Server reference lists ResponseStreamDisconnected, ResponseStreamConnectionFailed and ResponseTooManyFailedAttempts.
• A diagnostic. The Help Center Codex article says codex doctor gives “diagnostics covering startup, connectivity, and performance issues.”

As user reports, 187 issue titles contain “stream disconnected” (the first on July 15, 2025) and 97 “reconnecting” (October 23, 2025). Some titles mention proxies, VPNs, WSL, sign-in problems or server errors. We name no cause because no OpenAI source gives one.

Which OpenAI status incidents touched Codex from July to October 2026?

Method. Our copy of OpenAI’s status incidents holds 112 that started between July 12 and October 9, 2026 (retrieved October 10). A script kept every incident listing at least one of five Codex components (Codex Web, Codex API, CLI, VS Code extension, Codex in ChatGPT Desktop) and added those whose title names Codex but tag none (†). Minutes run from the first update to the first “resolved” update. The count uses our October 10 working copy of 112 incidents. The published 111-row file behind our reliability dataset has one row fewer, so totals can differ by one.

Result. we counted 25 of the 112 (22%) that tag or name Codex: 19 by component and 6 by title. The median stayed open 111 minutes, the mean 276, and 12 stayed open over two hours. At least one was open for about 100 hours in total, counting overlaps once. Of the 19 tagged, 9 list five or more other components, so many are wide incidents. The table shows the 16 whose title names Codex. The other nine are titled for ChatGPT or Work Mode, or name no product: July 14, July 23 (two, including the longest at 1,677 minutes), July 25 (two), September 3 at 00:04, September 23, October 5 at 07:03 and October 7 at 02:00.

Asterisk (*): OpenAI linked a write-up. Dagger (†): OpenAI tagged no Codex component.

Only one title uses overload or capacity wording. Eight of the 25 carry a write-up, and one is about Codex alone: the September 25 write-up says users signing in with ChatGPT got authentication (401) and gateway (502) errors after a credential-leak detector wrongly flagged internal credentials. Access through customer API keys “was unaffected.” Neither message is quoted in any OpenAI write-up we hold; see what the write-ups say caused incidents.

Open time is not downtime. OpenAI’s page shows the Codex group at 99.95% for what we read as the 90 days to October 10, which we rebuilt by counting partial outages at 30% and degraded time at zero. Across the 15 incidents with OpenAI write-ups that we compared, first status posts ran a median 20 minutes after the start the write-ups give (details).

What to do when a Codex session fails, using only documented guidance

1. Read the notice. A limit, reset time or credit option means your allowance. Open the usage dashboard or run /status, then choose credits, a reset, an upgrade or waiting.
2. For capacity or Reconnecting, check status.openai.com for your client’s component: CLI, VS Code extension, Codex Web, Codex API or Codex in ChatGPT Desktop. Scan incident titles for Codex too, because 6 of the 25 incidents tagged no Codex component. An open incident is a possible explanation; no incident does not rule it out.
3. On a work network or VPN, ask IT to apply the WebSocket guidance. Run codex doctor if your install has it; OpenAI’s pages describe it in the Windows section.
4. If it persists, contact Support with a screenshot and the time it happened, or search the openai/codex issues.

For the general check across ChatGPT and Claude, see our five-step path.

What we could not verify

• What the capacity and Reconnecting messages mean in OpenAI’s own words. The explanations above come from GitHub comments and incident titles.
• Who runs the GitHub account that made those comments, beyond its Contributor label.
• Whether some user reports are right that the capacity message is account-specific (for example issue #46231); we could not check this.
• Whether the “3/5” counter is the documented streaming retry count.
• Whether the 199 GitHub titles describe one failure, or whether incidents explain any given report. The day-by-day comparison is descriptive.
• How OpenAI chooses which Codex problems get an incident. Our counts cover posted incidents only.
• The cause of any one user’s failure; we did not run Codex to reproduce these messages.

Last reviewed October 12, 2026. OpenAI documents were read that day; incident counts use our saved copy retrieved October 10, and the GitHub title search ran October 12.

Frequently asked questions