Activity

1. charleswang916

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Oct 13, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   rate-limitsIssues related to rate limits, quotas, and token usage reportingIssues related to rate limits, quotas, and token usage reporting

   on Oct 13, 2026
3. github-actions commented on Oct 13, 2026

   

   github-actionsbot

   on Oct 13, 2026 – with GitHub Actions

   Contributor

   More actions

   Potential duplicates detected. Please review them and close your issue if it is a duplicate.

   • [macOS][Codex Desktop] "Selected model is at capacity" on ~80% of turns for 2 days across all models (weekly allowance 7% used) #52796
   • Codex CLI 0.162.1 (macOS, Pro): ~50% of turns fail with "Selected model is at capacity" (server_overloaded) since Oct 8, on all models, with 99% weekly quota left #53531
   • Codex "Selected model is at capacity" / server_overloaded on trivial first turn (Web + Windows app) #52812
   • [Windows 10 19045] GPT-6.1 Sol: persistent "at capacity" / HTTP 503 with 94% quota remaining (Oct 12-13), corroborating #52812 / #53407 #53559
   • Account-specific server_overloaded / capacity on Pro despite usage remaining (thread 01a1337b-ddfb-7013-ba44-2716c02d2789) #53555

   Powered by Codex Action

   👍React with 👍1Reacted by xilin913-lgtm
4. asd454314633-byte commented on Oct 13, 2026

   

   asd454314633-byte

   on Oct 13, 2026 – with ChatGPT Codex Connector

   More actions

   @openai — adding an independent occurrence today, October 13, 2026, and asking the Codex maintainers to investigate.

   Observed: At approximately 14:03 (UTC+08:00), an active multi-step Codex/Work task displayed the exact error:

   Selected model is at capacity. Please try a different model.

   Frequency / impact: This appeared multiple times today, interrupting an ongoing development/documentation workflow. The screenshot was captured in the ChatGPT iOS interface showing a task associated with a Windows desktop; this observation alone does not establish which backend model or internal operation failed.

   Evidence boundaries: I have the original timestamped screenshot. I have not verified the selected model, desktop client version, usage balance at the moment of failure, or the backend error code from local logs, so I am not asserting those details or a root cause. I am deliberately not posting device names, local paths, task content, account details, or raw logs publicly.

   Questions for @openai / Codex maintainers:

   1. Is there an acknowledged ongoing capacity/routing incident affecting Codex or Work on October 13, 2026?
   2. Can the team distinguish genuine model saturation from account-specific routing/admission failures and failures of background operations? The generic “try a different model” message does not identify the failed model/operation.
   3. Can long-running tasks preserve their state and safely pause/retry instead of repeatedly failing, and can you clarify whether failed capacity attempts affect user allowances?
   4. Which private feedback/diagnostic ID and timestamp should users supply for backend correlation?

   This is a new occurrence, not proof that every report here shares the same root cause. Happy to provide the screenshot and sanitized diagnostics through an official private support channel. Thank you.
5. asd454314633-byte commented on Oct 13, 2026

   

   asd454314633-byte

   on Oct 13, 2026 – with ChatGPT Codex Connector

   Last edited by asd454314633-byte

   More actions

   @openai — Correction and follow-up: THREE capacity-error occurrences in the SAME ongoing task on October 13, 2026 (UTC+08:00). My previous wording undercounted the recurrences. The user has explicitly confirmed three occurrences in this single task, not two.

   Screenshot-documented times:

   • 14:03 — This H3 project documentation/demo task displayed: Selected model is at capacity. Please try a different model.
   • 15:40 — The same task displayed the identical error again. The iOS view showed a “Continue execution” control, an elapsed-attempt indicator of 16 seconds, and “Thinking”.
   • Third occurrence — Separately confirmed by the user as happening in the same task; an exact timestamp for this third event has not been independently established here. Please do not read the two timestamps above as the total number of failures.

   Count: 3 reported occurrences in 1 long-running task. The screenshots establish the UI state at the two times listed; they do not by themselves prove a successful resumption, a quota debit, or lost progress.

   Please investigate repeated capacity/admission-control failures within a persisted, long-running task, including retry/resume backend routing, state preservation, and whether unsuccessful attempts debit usage. Simply advising a model switch is not an adequate recovery mechanism here.

   Screenshots and sanitized diagnostics can be provided privately; no local project paths, session identifiers, or device metadata are included in this public report.
6. asd454314633-byte commented on Oct 14, 2026

   

   asd454314633-byte

   on Oct 14, 2026 – with ChatGPT Codex Connector

   More actions

   @openai — Oct 14, 2026 follow-up: the same capacity-error symptom is being reported AGAIN after the official GPT-6.1 Sol Codex/Work incident was marked resolved.

   Earlier in this thread I documented three occurrences on Oct 13 in a long-running task. The affected user now reports at least one more recurrence on Oct 14 (UTC+08:00) of the same “Selected model is at capacity. Please try a different model.” problem.

   Important evidence boundaries: This is a fresh user report, sent at approximately 15:15 UTC+08; that is the report time, not a screenshot-verified time of failure. A new screenshot, request ID, and confirmation whether it is the same conversation/model have not yet been obtained. We are not asserting that this occurrence definitively has the same backend root cause as Oct 13.

   Official status incident previously marked resolved:
   https://status.openai.com/incidents/01M4T4ZCM54D3ZPTQXRSWFG0XS

   Request to maintainers: Please investigate persistent capacity/admission or account-routing failures after an aggregate incident is marked resolved; compare before/after mitigation for affected sessions, identify reliable recovery for long-running Work/Codex tasks, and clarify treatment of usage charged for failed/retried turns.

   A private support case already contains the user's session identifiers and screenshots; no account or session identifiers are being posted here. An additional private follow-up and request for service-disruption compensation have been sent to support.
7. hand250 commented on Oct 15, 2026

   

   hand250

   on Oct 15, 2026

   More actions

   Adding a data point from a Pro (20x) subscriber on ChatGPT Desktop for macOS (26.1007.30912, build 20156), home network, direct connection (no proxy/VPN; also reproduced across US/JP/SG egress and with VPN on/off):

   • Oct 9-15, 2026: 559+ turns failed with "Selected model is at capacity. Please try a different model." (codexErrorInfo=serverOverloaded). Per day: Oct 9: 5, Oct 10: 64, Oct 11: 26, Oct 12: 92, Oct 13: 165, Oct 14: 146, Oct 15 (through 10:30 UTC+8): 35+, alongside partial successes (e.g. Oct 15: 7 of 26 turns succeeded within the same threads).
   • Failures continued after BOTH public incidents were marked resolved: 66 failures between Oct 13 17:53-21:49 UTC+8 (incident 01M4T4ZCM54D3ZPTQXRSWFG0XS resolved Oct 13 16:36), and further failures on Oct 15 after incident 01M4WKPE1EY48ZB4RZJ80YH7ES declared "fully recovered" (09:53).
   • Same machine, different ChatGPT account: works fine simultaneously. Regular ChatGPT web chat on the affected account: works. Codex Desktop on the affected account: rejects even a single "hi" in a brand-new thread.
   • Client logs show sa_server_request_failed with errorMessage="Workspace routing is unavailable" (34 occurrences on Oct 15) alongside a durable-WebSocket reconnect loop (code 1006 / open_timeout) and intermittent cloudflare_challenge. Support confirmed server-side that a rejected attempt passed the usage-limit check before ending server-overloaded (not quota), classified the case as account/routing-specific, and escalated it.
   • Support timeline: escalated Oct 13; evidence packages (turn IDs, session/feedback correlation, sanitized and unfiltered log spans) delivered Oct 14-15; as of Oct 15 no engineering resolution; a service credit for Oct 9-15 is recorded as pending.

   Posting here because per-account Codex-path admission failures persisting beyond resolved incidents need visibility beyond individual support threads. Methodology for the counts (client-side thread database) available to anyone investigating.
8. ourinkenn-code commented on Oct 15, 2026

   

   ourinkenn-code

   on Oct 15, 2026 – with ChatGPT Codex Connector

   More actions

   Additional verified desktop evidence for this issue, collected on October 15, 2026.

   Environment: ChatGPT desktop app/Codex 26.1007.30912 (build 20156), bundled session runtime 0.162.0-alpha.17.2, macOS 26.5.2, Apple Silicon, ChatGPT Pro. Model gpt-6.1-sol; both high and xhigh were used.

   A continuing local research workflow was moved through eight separate chats after failures. Read-only inspection of their persisted turn records confirms 21 terminal failed turns during October 12–15 UTC:

   • 14 Selected model is at capacity. Please try a different model. errors, recorded as serverOverloaded.
   • 7 response-stream disconnections; one explicitly occurred during remote compaction.

   These counts exclude manual interruptions and command failures, and do not count each automatic HTTP retry as another failed turn. The older continuation alone has ten capacity-failure turns; its fresh high-reasoning successor has four. Fresh chats, saved-file handoffs and lower reasoning effort did not provide reliable recovery. Failures occurred both in independent single-agent chats and in an earlier multi-agent workflow; they are not confined to subagents.

   A scoped streaming example: on October 13 at 19:22:46–19:23:08 UTC (October 14, 04:22:46–04:23:08 JST), six requests each received HTTP 200, then failed to complete the response stream. The client logged retries 1/5 through 5/5 and terminated the turn. No compaction/context-length marker was found for that chat in the inspected 62-second window; this does not rule out compaction in other failures.

   Exact error families observed:

   Selected model is at capacity. Please try a different model.
   stream disconnected before completion: An error occurred while processing your request.
   Error running remote compact task: stream disconnected before completion: ...
   

   The user also reports reconnects reaching five attempts and IO error: Broken pipe (os error 32); the latter is a user-observed symptom, not independently attributed to every failed turn.

   In-app /feedback succeeded for four sessions according to the user's confirmations, then feedback uploads themselves began failing. Exact failed-upload error codes/counts are not established. A private support email has been sent with the session/turn/request identifiers and a sanitized failure timeline; none of those private identifiers or research materials are included here.

   Please investigate capacity/admission failures, streaming recovery after HTTP 200, and the feedback-upload problem. The recorded error families do not establish a shared internal cause. The October 13 published Sol performance incident being marked resolved is not proof that the later October 15 failures were the same incident.

   Related compaction symptoms are described in #54029 and #54030; I am not asserting identical causes. Local saved work remains recoverable, but repeated reconstruction/restarting has caused substantial lost time.