Codex is working, retries, and suddenly stops with exceeded retry limit, last status: 429 Too Many Requests. When the dashboard still shows quota left, the natural reaction is to assume Codex broke. That is not quite it, and the message carries a clue many people skip.
The error shows up in recent reports in the official openai/codex repository. Issue #57084, opened on 2026-10-26, documents failures on Linux with VS Code and a ChatGPT Pro plan, including one with 99% of the weekly allowance still available. As of 2026-11-01, OpenAI had not published a cause or a fix in that issue.
What does "exceeded retry limit, last status: 429" mean?
It means the server answered HTTP 429 (too many requests) and Codex used up its automatic retries before giving up. In the Codex source, the message is built as exceeded retry limit, last status: <status>, with , request id: <id> appended when the server returns that identifier.
What separates this error from a plan limit is in codex-rs/codex-api/src/api_bridge.rs. On a 429, Codex reads the response body. If the error type is usage_limit_reached, it shows the quota message ("You've hit your usage limit..."). Any other 429 becomes exceeded retry limit. In other words, this message is not the notice that your quota ran out.
| What you see | What it means | What to do |
|---|---|---|
You've hit your usage limit | Plan quota exhausted | Wait for the reset or buy credits |
exceeded retry limit, last status: 429 Too Many Requests | Generic 429, not the plan quota | Steps below |
Selected model is at capacity. Please try a different model. | The chosen model has no capacity right now | Switch model with /model |
How do you diagnose and work around it?
Follow the order. The first three steps take seconds and rule out the causes you can fix yourself.
- Read the exact text. If the message is "You've hit your usage limit", it is plan quota and the first row of the table applies. If it is
exceeded retry limit, keep going. - Check quota with
/status. The command shows the session configuration and token usage. If plenty of quota is left and the error persists, your plan limit is not the problem. - Switch model with
/model. The command chooses the model and reasoning effort. The records in issue #57084 all come from the same model (gpt-6.1-sol, low effort), and the source has a per-model capacity error. Running the same task on another model shows whether the rejection is specific to that one. - Wait before retrying. In issue #57084, retry warnings from several turns converged on the same time, within 0.7 seconds, with waits of a few minutes. Firing the same request again in a row only renews the wait.
- Update Codex. The latest release at the time of this research is
0.166.0(2026-10-29), checked withgh release list -R openai/codex.
/status
/modelCan you raise the number of automatic retries?
Only for a provider you configure yourself. In the source, request_max_retries (default 4) and stream_max_retries (default 5) are fields of a model provider entry, each capped at 100. Example for your own provider in ~/.codex/config.toml:
[model_providers.my-gateway]
name = "My gateway"
base_url = "https://gateway.example.com/v1"
request_max_retries = 8
stream_max_retries = 10Two honest caveats. I did not test whether these fields apply to the default OpenAI provider, so I do not promise they fix your case. And more retries do not change the server's decision: if the rejection is about capacity or a short usage window, you just wait longer before seeing the same error.
What should you save if the error continues?
Copy the request id at the end of the message when it appears, along with the UTC time, the model, the reasoning effort, the Codex version and the /status output. The author of issue #57084 points out that the missing Retry-After and request identifier in the logs is what blocks the analysis, and asks for exactly this data. Attach it to the issue, without tokens, project paths or prompts.
If your provider's limit is what stalls your day, Verboo Code delivers unlimited tokens on the plan, so the next attempt does not depend on a quota window.
