The quick answer
Selected model is at capacity. Please try a different model. tells you that the selected Codex model cannot accept this request because of capacity and suggests using another model. Choose another model available to your account, or wait and retry later if you need the original model. This message alone does not establish that your personal allowance is exhausted or give a recovery time.
1. Switch to an available model
Use the official model controls for your client:
- Desktop app: open the model control beneath the composer and choose an available alternative.
- Interactive CLI: enter
/modeland select a model offered in that session. - IDE extension: use the model switcher beneath the composer when available.
Check the selected model before sending one small continuation. Use an alternative suitable for the task; no particular replacement is guaranteed to have capacity. Changing reasoning effort alone is not the same as switching models.
Availability depends on your plan, workspace, sign-in method and client. If the expected model is missing, use the model-access checks. These controls do not apply identically to every cloud workflow; Codex cloud does not let you change its default model through the local picker.
2. If you must use the original model, wait
Pause repeated submissions and try one small continuation later. If a fuller error supplies a retry delay, respect it. The capacity message itself does not promise recovery in five minutes, after five hours or at your next weekly reset.
While waiting, review local changes, run existing tests or prepare the next task without another model call. A personal reset countdown cannot measure model capacity or tell you when the service will accept the request.
3. Remaining allowance does not guarantee model capacity
Personal usage limits and the selected model's available capacity answer different questions. Check your Codex usage to confirm the account's actual limits; do not assume that buying credits, a reset offer or a new chat restores a model's capacity.
The OpenAI API error reference distinguishes temporary overload from rate-limit and quota errors. This Codex message alone does not identify an HTTP status. If the full error instead reports 429, follow the 429 troubleshooting guide; if it explicitly identifies exhausted allowance, use limit recovery steps.
4. Continue from verified progress
Keep the existing conversation when your client supports switching there. Before resubmitting work, inspect changed files, command results and completed external actions. A failed response does not prove that earlier work was undone, and switching models does not guarantee automatic continuation at the failed step.
A useful continuation is:
Check the current files and completed steps. Continue only the unfinished work, and verify the result before repeating any external action.
If you need a new conversation, carry over the goal, constraints, relevant files, verified progress and next step. Do not rely on it automatically inheriting the old conversation's context.
5. If several models fail, widen the check
Confirm the account, workspace, client version and authentication method. For API keys or a custom gateway, identify which service returned the error and check that provider's access and service information. A subscription reset time does not diagnose an API project or gateway.
Check the OpenAI status page for broader incidents. An operational status page does not rule out an account-specific or model-specific failure. Avoid continuous retries or resetting your local configuration based only on this message.
What to record if it persists
Keep the exact error, selected model, client/version, timestamp and timezone, sign-in method, request ID if supplied, and whether one small request or an available alternative also fails. Remove credentials and private task content before sharing through the appropriate support channel. Record observations, not a guessed HTTP status or promised recovery time.