ChatGPT or Codex says "Selected model is at capacity": why the model is unavailable and what to do

Last verified: November 9, 2026
When ChatGPT or Codex stops in the middle of a reply with the message "Selected model is at capacity. Please try a different model.", the model you picked could not take your request at that moment. In most cases the fix is to wait a few minutes, refresh or start a new chat, and retry, because OpenAI's own support staff describe the condition as temporary and say a model can be briefly unavailable even when the OpenAI status page shows no incident. The message has nothing to do with the usage allowance of your plan: many people who see it still have most of their weekly or five-hour quota left, and a real usage limit produces a different message with a reset time.
The error has been reported since April 2026, mostly by people on paid plans (Plus and Pro) and mostly in Codex, the coding agent that runs in the ChatGPT desktop app, in the Codex command-line tool and in code editors such as VS Code. Since September it also appears in ordinary chats and in the Work mode of the ChatGPT desktop app. OpenAI has logged several capacity incidents for Codex on its status page, and in September its support staff confirmed a second, less obvious cause: access to some models can be temporarily limited for a single account based on account activity, even while a paid subscription is active.
··········
WHERE THE CHATGPT AND CODEX "SELECTED MODEL IS AT CAPACITY" MESSAGE APPEARS.
The wording is the same everywhere: "Selected model is at capacity. Please try a different model." What changes is the surface and the moment it shows up. In chats it usually replaces the answer and, in some versions of the app, comes with a short retry countdown. In Codex it tends to interrupt a task that was already running, sometimes after several minutes of work, and in one variant it names the step that failed, for example "Error running remote compact task: Selected model is at capacity", which appears when Codex tries to compress a long conversation to keep working.
The table below collects where users on the official OpenAI Developer Community forum have reported the message, and the models they named. A "model" here is the specific AI version selected in the picker, such as GPT-6.1 Sol or GPT-6 Luna.
........
Surface | Models named in reports | First reports seen |
Codex in VS Code (ChatGPT extension) | GPT-5.4, GPT-5.6 Sol, GPT-6 Sol | April 2026 |
Codex desktop app (macOS, Windows) | GPT-5.6 Sol, GPT-6 Sol, GPT-6 Luna, GPT-6.1 | July 2026 |
Codex command-line tool (CLI) | gpt-5.6-sol, gpt-6-astra, GPT-6 Luna | September 2026 |
ChatGPT desktop app, Chat and Work modes | All models in the picker | September to November 2026 |
ChatGPT chats (plan Plus or Pro) | GPT-6.1 Sol, Terra and Astra | November 2026 |
........
When every model in the picker returns the same message, the request is failing above the level of a single model, and switching models will not help. When only one model fails while the others answer normally, the "try a different model" advice in the message itself is the quickest way to keep working.
··········
WHY CHATGPT AND CODEX SAY A MODEL IS AT CAPACITY: CAUSES, CHECKS AND FIXES.
OpenAI has not published a help article for this message. The causes below come from the OpenAI status page, replies signed by OpenAI Support on the official forum, the Codex changelog and the OpenAI API error reference; the last row is based on repeated user reports and is labelled as such.
........
Cause | How to check | Fix |
A capacity incident on OpenAI's side | status.openai.com lists an open incident for ChatGPT or Codex | Wait for the incident to be resolved, then retry |
A short overload of one model with no incident listed | Other models answer, the status page is green | Wait a few minutes and retry, or pick another model |
A temporary limit on your account based on account activity | Every model fails on every surface for hours or days while quota remains | Stop the activity, wait for the automatic reassessment, contact support |
A long Codex task interrupted mid-run (user reports) | The error appears after several minutes of work, often during compaction | Send a follow-up message to resume, or start a new task |
API overload (API-key sessions and apps built on the API) | The response is HTTP 503 with code server_is_overloaded | Follow the Retry-After header and retry |
........
The status page has recorded the problem by name. On June 16, 2026 OpenAI opened an incident titled "Codex 'Selected Model is at Capacity' Error" affecting one ChatGPT component and four Codex components; a mitigation was applied and the incident was marked resolved after about three hours. On July 17 a second incident, "Codex 5.6-sol Experiencing Increased Server-Overload Errors", was resolved the same day. In October, OpenAI Support wrote on the forum that the company had "added capacity and shipped changes today to reduce these interruptions".
··········
HOW TO FIX "SELECTED MODEL IS AT CAPACITY" IN THE CHATGPT APP.
These steps follow the troubleshooting order OpenAI Support gave in its forum replies of October and November 2026, from the quickest check to the support request.
1. Open status.openai.com and look for an open incident on ChatGPT or Codex. If one is listed, nothing on your side will fix it; wait for the "Resolved" update.
2. Wait a few minutes before retrying. OpenAI Support wrote on November 4 that "a model can be temporarily unavailable even when no incident is listed on OpenAI Status", and its advice was to give it a few minutes.
3. Refresh the page or restart the app, then start a new chat with the same model. Support suggested a fresh session in October, when users reported that the old conversation kept failing.
4. Pick a different model in the model picker for the current task. If the other models answer, the problem is limited to the model you chose; if they all return the same message, go to the next step.
5. Update the app. ChatGPT for iOS version 1.2026.300 (November 2) shows reconnect errors with a single Retry control, and earlier builds added Retry actions for failed loads.
6. If the message persists across all models for several hours, write to support@openai.com with the app or browser version, the date, time and time zone of the failures, a redacted screenshot and any request ID shown. These are the details OpenAI Support asked for in its November 4 reply.
If the conversation itself will not open after the error, the problem is a different one; our guide to the ChatGPT "Could not load this conversation" error covers that case.
··········
HOW TO FIX THE CODEX "SELECTED MODEL IS AT CAPACITY" ERROR IN THE CLI, IDE AND DESKTOP APP.
In Codex the error can stop a job halfway through a change. Start with the same checks as in the app (status page, a short wait), then use the Codex tools.
1. Resume the task. Several users on the official forum report that waiting a few minutes and sending a follow-up such as "continue" lets Codex pick up where it stopped without losing work. This is a user-reported workaround, not documented by OpenAI, and each follow-up counts against your usage.
2. Switch the model. In the desktop app and on the web, use the model and reasoning control under the composer (open Advanced to choose a specific model). In the CLI, type /model and choose another model. You can also start Codex with a model flag or set a default in the configuration file, as shown in the official documentation below.
3. Check which models your account can see. The CLI command codex debug models prints the model catalog Codex receives; the documentation notes that the available options depend on "plan, client, workspace settings, and rollout".
4. Update the Codex CLI. Version 0.166.0 (October 29, 2026) added a change described in the changelog as "Distinguish policy-restricted capacity failures from server overloads", so recent versions are better at telling an account-level restriction apart from a real overload. The latest release on the day of this check was 0.167.0 (November 6).
5. Report the failure with the details OpenAI asks for: the model, the time and time zone, and the task reference. The /feedback command and the openai/codex issue tracker on GitHub are the two channels users point to; one user reported that /feedback itself failed with "Couldn't verify feedback permissions" during an outage.
The model flag and configuration syntax come from the official Codex documentation. Replace the model ID with another model your plan offers: the current Codex lineup lists gpt-6-astra, gpt-6.1-sol, gpt-6.1-terra and gpt-6-luna.
codex --model gpt-6.1-sol
codex exec -m gpt-6.1-sol "..."model = "gpt-6.1-sol"Before a long Codex run, committing your work in Git gives you a clean point to return to if the task stops halfway. For the models themselves and what each one is for, see our overview of Codex models in 2026.
··········
WHEN CHATGPT OR CODEX SHOWS THE CAPACITY MESSAGE BECAUSE OF AN ACCOUNT-LEVEL LIMIT.
The least intuitive cause is one OpenAI Support described on September 14, 2026, in a forum thread where Codex desktop users on macOS and Windows saw the message for days. The reply said that "access to certain models or features may be temporarily limited based on account activity, even when a paid subscription is active", that "access is automatically reassessed and can return to normal once the activity affecting availability stops", and that OpenAI is "unable to provide additional details about these checks".
The pattern users describe in these cases differs from an overload. Every model fails, on every surface, for hours or days; retrying, switching models and changing networks make no difference; the usage dashboard still shows most of the allowance unused, with users quoting figures such as 45% or 92% remaining. In one case a support reply quoted on the forum said the user was "unable to use your selected model in Codex/Work", without giving a reason. One user also reported that a different account, a work account, kept working.
There is no setting that lifts this kind of limit. OpenAI documents only the process: the limit is reviewed automatically, access can return once the activity behind it stops, and support is the channel for questions about a specific account.
··········
DOCUMENTED BY OPENAI VS REPORTED BY USERS: "SELECTED MODEL IS AT CAPACITY".
........
Statement | Status | Where it comes from |
Capacity incidents have affected Codex and ChatGPT | Documented | OpenAI status page, June 16 and July 17, 2026 |
A model can be unavailable with no incident listed | Documented | OpenAI Support forum reply, November 4, 2026 |
Access can be limited per account based on activity | Documented | OpenAI Support forum reply, September 14, 2026 |
OpenAI added capacity to reduce interruptions | Documented | OpenAI Support forum reply, October 15, 2026 |
Recent CLI versions separate policy limits from overloads | Documented | Codex changelog, version 0.166.0 |
Sending "continue" resumes an interrupted Codex task | Reported by several users | OpenAI Developer Community threads |
The error appears with quota still available | Reported by many users | OpenAI Developer Community threads |
Changing network or VPN does not clear it | Reported by several users | OpenAI Developer Community threads |
........
OpenAI has not published a cause for individual cases.
··········
API USERS: THE OPENAI 503 SERVER_IS_OVERLOADED ERROR BEHIND THE CAPACITY MESSAGE.
People who run Codex with an API key, or who build their own apps on the OpenAI API, meet the same condition as an HTTP error. The OpenAI API error reference lists it as "503 - Model temporarily overloaded", with the type service_unavailable_error and the code server_is_overloaded. A related 429 error with the code slow_down means the request rate rose too quickly. In the open-source Codex client both codes are handled as a "server overloaded" error, a category kept separate from usage-limit errors.
........
HTTP status | Code | Official cause | Official solution |
503 | server_is_overloaded | The requested model is temporarily overloaded | Follow the Retry-After header when present, then retry |
429 | slow_down | Your request rate increased too quickly | Follow Retry-After, reduce the rate, increase it gradually |
500 | (none) | Issue on OpenAI's servers | Retry after a brief wait, contact support if it persists |
........
The documentation adds one detail for error handling in code: in the Python library, a 429 response raises RateLimitError and a 503 response raises InternalServerError, so a retry handler should catch both and read error.code before deciding how long to wait. Rate limits measured in requests and tokens per minute are a separate topic, covered in our guide to ChatGPT and OpenAI API 429 Too Many Requests errors.
··········
TELLING THE CHATGPT CAPACITY MESSAGE APART FROM A USAGE LIMIT.
Both stop you from using a model. A usage limit is tied to your plan: it tells you that you have used your allowance and shows when it resets, and the usage page in ChatGPT or Codex confirms it. The capacity message gives no reset time, appears even with quota left, and can clear on its own within minutes. If you are unsure which one you hit, open the usage dashboard first; if the allowance is far from used up, treat the message as a capacity or access problem and follow the steps above. Plan allowances, the five-hour Codex windows and the shared ChatGPT and Codex limit coming in December are explained in our guide to ChatGPT usage limits.
··········
"SELECTED MODEL IS AT CAPACITY" IN CHATGPT AND CODEX: THE PRACTICAL CONCLUSIONS.
The message means that the request did not get a slot on the model you chose, and OpenAI's own replies point to three different reasons: a service incident visible on the status page, a short overload that never reaches the status page, and a temporary limit applied to one account based on its activity. The first two clear with time, a refresh or a different model. The third lasts longer, affects every model at once and has no user-side fix beyond stopping the activity and contacting support.
Codex users gain the most from keeping the CLI and apps updated, switching models with /model or the model flag, and resuming interrupted tasks once the model answers again. API developers see the same condition as a 503 server_is_overloaded error, and the documented response is to honor Retry-After and retry.
··········
FOLLOW US FOR MORE.
·····
DATA STUDIOS
·····
datastudios.org




