On this page
If Codex shows “Selected model is at capacity. Please try a different model.”, the selected model cannot serve the current request. Start by preserving your work, checking service status and remaining usage, then trying another available model or retrying after a delay. A capacity message alone does not establish that you have exhausted your plan or that your account is restricted.
This guide covers an interrupted coding task in the desktop app, the interactive CLI, an IDE integration, or a scripted run. It also explains what to do when a smaller model fails, the status page is green, or Codex had already submitted an external job.
If the exact message is “This model is temporarily unavailable” in Grok or another product, use the product-specific unavailable-model guide to identify that product first. Similar wording does not establish the same cause or recovery path.
Reviewed October 3, 2026. Client behavior and account access can change. Commands below follow current OpenAI Docs; use your installed client's available commands and model picker.
First steps when the error appears
- Save the error and your place. Record the exact message, model, client version, time with timezone, and last completed action. Keep the existing chat.
- Check OpenAI service status. Read the affected components and incident updates. An old resolved incident does not describe today's failure.
- Check usage in your account. A reset time or an explicit usage-limit notice calls for allowance troubleshooting. Use the official pricing and usage guide, which also documents CLI /status for remaining limits. A paid subscription and a capacity error can coexist.
- If a retry countdown is visible, follow it. Otherwise allow a delay before one retry, or choose another model offered to your account. Do not start overlapping copies of the task.
- Continue only unfinished work. Before resuming, inspect files, running commands, and external job IDs. A failed response does not prove that earlier actions failed.
There is no reliable universal “wait exactly ten minutes” rule. Stop repeated attempts when they return the same result; use the client timer, service updates, or a planned later retry. If the task is urgent, prepare a handoff with the current files and remaining steps.
Capacity, usage limits, API errors, and network failures
The message on your screen is the starting evidence. More than one problem can occur during a session, so read the next error as well as the first one.
| What you see | What it establishes | Useful next action |
|---|---|---|
| Selected model is at capacity | The selected model could not serve this request; it does not identify a personal allowance reset | Check status and usage, try an available alternative, preserve the chat |
| Explicit usage-limit notice or a displayed reset time | An account allowance needs attention | Follow the account's current limit and reset information |
| API HTTP 429 | Several causes are possible, including rate, spend, usage, or credit limits | Read the error body and code before retrying or changing billing |
| API HTTP 503 with server_is_overloaded | The requested API model is temporarily overloaded | Honor Retry-After when present; use bounded retries |
| Invalid credentials, permission denied, missing model | Authentication or access requires investigation | Check sign-in method, workspace, API organization/project, and client support |
| Connection failure, certificate error, or timeout | A connection or request failed; it may have a different cause | Check network and proxy settings and inspect the operation's outcome |
| Reviewer-model or remote-compaction capacity message | A supporting operation failed | Record which operation failed; changing the main model may not address it |
OpenAI documents the API error distinctions in Error codes. API HTTP statuses are examples for API clients, not a claim that the Codex banner always exposes the same HTTP code.
Do not read a context percentage as an account balance. Context usage measures how much conversation fits in the current model's window. Remaining account allowance answers a different question. Record both if they are shown, with their labels.
Also separate subscription access from API access. OpenAI's authentication guide explains ChatGPT sign-in and API-key sign-in as different access paths. A ChatGPT payment does not automatically change the API organization associated with a key.
Recover an interrupted coding task without losing progress
Before submitting the original instruction again, inspect the actual work. For a Git project, run these read-only commands in the affected checkout:
git status --short
git diff --stat
git diff
Check staged changes separately with git diff --cached if needed. Inspect newly created files too; ordinary git diff does not include untracked file contents. Save unsaved editor buffers and make a private checkpoint or backup appropriate to your project. Never reset or clean the repository just to remove the capacity error.
Example. Codex was changing validation in two files and running a focused test. The capacity error appeared before its final response. One file may already be complete, the second partial, and the test may still be running. Replaying “implement validation” gives the next turn an unnecessarily ambiguous starting point.
Use a continuation message like this after reviewing the state:
Continue the interrupted validation task in this chat.
First inspect the current diff and the last test output.
Preserve my changes and other agents' changes.
Finish only the missing validation and its relevant verification.
If a command or external task already started, check its status before repeating it.
This prompt guides recovery; the word “continue” does not create model capacity. If the request fails again, keep the saved state and use the next appropriate step.
The reason for checking actions first is documented in OpenAI's agent recovery guidance: a failed turn may already have changed files or called tools. That API guidance supports the recovery principle; it does not make every Codex client expose the API session states.
When several people or agents share a checkout, identify who owns each changed file. Resume in the original worktree when possible. A newly opened project directory may have a different branch, ignored configuration, or dependency state, even if its name looks familiar.
Desktop app recovery
Keep the affected chat open and inspect its latest tool results and review panel. If the model control is available, select an alternative offered for that chat and send a focused continuation. If you need the original model's capability, save the recovery note and try later.
Do not force a restart while unrelated chats are still working merely because one turn failed. For an unresponsive interface, first save buffers and identify running work. OpenAI's desktop troubleshooting guide recommends checking approval waits, testing a basic terminal command, and using a smaller focused chat for stuck states; it advises waiting for active chats before restarting a stuck app.
The review panel can show changes made outside Codex. Treat a displayed diff as repository state, not proof that the failed turn authored every line. Review which files actually belong to this task before asking an agent to edit them.
If only one chat fails: prepare a compact recovery note before testing a new chat. Include the task goal, checkout path, branch, completed changes, tests already run, and remaining work. A new chat is a diagnostic option, not a guaranteed capacity fix or an automatic transfer of all previous context.
Interactive Codex CLI recovery
Inside the interactive CLI, /status shows session information and /model opens the available model selection. Choose an offered alternative and confirm the selected model before resuming. These are CLI composer commands; typing them into an ordinary shell or a ChatGPT web conversation is a different action.
If the terminal session closed, reopen a saved interactive session:
codex resume
Use the picker to identify the affected chat. Where you know its session ID, the explicit form is:
codex resume SESSION_ID
SESSION_ID is a placeholder. With several parallel chats in one repository, an explicit session is safer than assuming the most recent session is yours. The official reference also supports codex resume --last, scoped to the current working directory, and model overrides on resumed sessions. See Codex CLI and the resume command reference.
If you change a model on a resumed run, use an identifier available to your sign-in method and client. Keep the existing approval and sandbox settings unless the work independently requires a reviewed change. Broader filesystem permission does not supply inference capacity.
IDE integration and scripted runs
In an IDE, save buffers, review the diff, and continue from the existing chat where possible. Use the model control or command menu your integration exposes. VS Code-compatible extensions and native JetBrains or Xcode integrations have different interfaces; a CLI command is not automatically an IDE command. The official IDE guide explains the supported integration paths.
If the extension alone becomes unresponsive, record its version and save your recovery note before restarting that interface. Moving to the CLI can help isolate a client issue, but it does not establish that the same model will become available. Check the directory, branch, credentials, and saved-chat availability before a handoff.
For an interrupted non-interactive run, the current command reference supports:
codex exec resume SESSION_ID
Use the saved ID associated with that run. Check logs and side effects first; do not wrap the entire business workflow in an endless “run again until success” loop. A model may stop after creating files, starting an export, or submitting a job.
For a custom OpenAI API client, distinguish retryable overload or temporary rate limits from credentials and billing errors. Follow a valid Retry-After, add jitter when using your own backoff, and cap attempts and total elapsed time. Existing SDK retry behavior depends on version and configuration. See the official rate-limit guide.
When every model fails or service status looks normal
Collect a small comparison instead of changing several settings at once:
| Controlled check | What the result helps distinguish |
|---|---|
| Same client, same account, one offered alternative | Whether the failure is limited to the selected model |
| Same client, a new small chat after saving a handoff | Whether the issue follows the original chat |
| Another supported client with the same intended identity | Whether one client or version behaves differently |
| Account usage and workspace access inspection | Whether a separate allowance or access condition is visible |
A successful short request only proves that request worked. It does not establish that a long task or a different model has recovered. A failed comparison likewise cannot reveal OpenAI's internal routing or the reason an account behaves differently.
For missing or inaccessible models, OpenAI's workspace model availability guide recommends checking the surface, sign-in method, identity boundary, access controls, and client support. Selecting a model in configuration cannot grant access that the identity lacks.
If your banner names a reviewer or compaction operation, include that exact detail in the report. Do not infer that reducing the main model's reasoning effort controls a separate supporting model.
Avoid these misleading “fixes”
- Buying credits before checking usage. Credits can extend eligible exhausted allowances; that does not establish a remedy for a capacity-only failure. Follow the account's displayed condition.
- A guaranteed VPN country or off-peak schedule. A successful request after changing networks does not prove the location caused recovery. Investigate network settings when connection evidence points there.
- Deleting authentication, caches, sessions, or project files. These actions can remove useful evidence or interrupt other chats. Diagnose a local or sign-in problem before considering its targeted repair.
- Changing passwords or disabling security features to clear capacity. Account-security actions need their own evidence; the banner alone does not provide it.
- An automatic “continue” bot with no stop condition. It can repeat completed actions and hide persistent failures. Bound retries and inspect progress.
If Codex was running an OwnerClue lead workflow
Model recovery and lead-job recovery are separate. OwnerClue searches use asynchronous tasks. A successful create response returns HTTP 202 and data.id; it does not return the completed lead list.
If the ID was saved, read GET /api/v1/leads/searches/{id} with an authorized leads:read key. For queued or running, poll within the API's limits. For completed, read results or export. For failed, inspect the job error. Do not submit a second search simply because Codex stopped explaining the first one.
If the create response was lost, inspect your task list and submission record. An unchanged request should reuse its original Idempotency-Key rather than inventing a new key. Keep the body and key together in your recovery note. This reduces duplicate submissions; it is not a promise that every failed request needs a refund or cancellation.
See the OwnerClue API guide for scopes, pagination, idempotency, and limits, or check saved jobs in the workspace. An API task can outlast the agent conversation controlling it.
Report a persistent problem with useful evidence
Use the client's feedback flow while the failed chat is still available. OpenAI Docs describes optional session sharing and diagnostics; review logs before sharing them. Never include API keys, access tokens, or the contents of auth.json.
Exact error:
First and latest occurrence, including timezone:
Client and version; OS; IDE if applicable:
Selected model and reasoning setting:
Sign-in method; intended workspace or API project:
Remaining usage and labels, as displayed:
Session/request/feedback ID, if available:
Operation that failed: message, review, compaction, tool, or export:
Results of one controlled alternative-model/client test:
Last completed action and saved work:
Business impact and smallest reproduction:
A concise report is more actionable than repeated prompts or an assumed diagnosis. Use official troubleshooting and feedback instructions to find the appropriate reporting route.
Frequently asked questions
Does this mean my Codex quota is used up?
The banner alone does not establish quota exhaustion. Check the account's actual usage and any explicit limit notice. Context remaining, tokens consumed, and allowance remaining have different meanings.
How long should I wait?
Use a displayed retry timer or service update when available. No fixed recovery time is established for every account and model. After repeated identical failures, defer the task or report it with evidence.
Will switching models always work?
No. It is a practical option when another suitable model is offered. Multiple models or supporting operations can fail, and access differs by client and identity. Keep the original model requirement in your handoff if an alternative cannot meet it.
Does Codex retry automatically?
Observe your client. A visible retry countdown can be followed; a finished turn with an error requires an appropriate new action. This guide does not assume every app, release, and error class has the same retry behavior.
Will starting a new chat restore my code?
The files are in your checkout or task environment. A new chat does not reconstruct missing files or automatically receive the old conversation. Inspect saved work and provide a handoff before continuing.
Does the error prove my account is flagged?
No. Persistent differences between accounts merit a support investigation, but the error string alone cannot identify an internal account restriction. Record the observable facts rather than an assumed cause.
Sources and review method
Recovery commands, account/access distinctions, and API retry guidance were checked against the linked OpenAI Docs pages on October 3, 2026. Coding and job-recovery examples are illustrative procedures, not claims that a particular outage was reproduced. We compared competing guides and search-result discussions, then retained useful diagnostic structure while excluding unverified fixed waits, routing explanations, and universal retry claims. This article is a recovery guide, not a live service-status report.