Codex 429: Diagnose “Exceeded Retry Limit” Before Retrying

exceeded retry limit, last status: 429 Too Many Requests tells you what Codex observed when its retry sequence stopped. It does not identify why the system handling the request kept returning 429.

The cause might be a ChatGPT plan usage window, an OpenAI Platform API rate or billing control, a limit imposed by another model provider, or a temporary service failure. Those cases can produce the same terminal line but require different fixes. Before changing retry settings or waiting an arbitrary number of hours, identify which request path failed and preserve the detailed response that came with it.

Identify the request path first

Start with how this Codex session obtains model access. The account or provider that receives the request owns the most useful evidence.

• ChatGPT-authenticated Codex. You signed in with a ChatGPT account and use the allowance attached to that account. Inspect Codex /usage, /status, the displayed reset information, and other activity sharing the account.
• OpenAI Platform API. Codex sends requests using an OpenAI API key associated with a Platform organization and project. Inspect the complete API error object, error.code, request ID, project limits, usage, and billing controls.
• Custom provider or gateway. Codex sends model traffic to another endpoint, such as a company gateway or third-party provider. Inspect the effective endpoint and provider, response headers and error body, and that provider's quota, billing, logs, and status information.

Do not identify the path based only on the word “Codex.” Codex is the client in all three cases; the system rejecting the request can differ.

If you are unsure, inspect the current session before sending more traffic. The official Codex command reference describes /status and /usage: /status shows session configuration and token usage, while /usage shows account token activity. The exact fields and command availability can vary by Codex surface and version, so treat them as evidence—not as automatic root-cause detectors.

Preserve the clues that retries can erase

Before restarting the session, capture enough context to distinguish a temporary throttle from a limit that requires human action:

1. Record the timestamp with time zone, Codex surface and version, operating system, model, and whether the failure occurred locally or in a cloud task.
2. Save the complete error body locally, not just the final terminal line. Keep error.code, HTTP headers such as Retry-After, and the request ID when present; sanitize them before sharing.
3. Note the authentication path: ChatGPT sign-in, OpenAI API key, or the name of the configured custom provider. Do not copy the key itself.
4. Capture the relevant usage, reset, rate-limit, spend-limit, or billing view at the same time as the failure.
5. Check whether another terminal, automation, teammate, cloud task, or application is using the same account, project, organization, or gateway.
6. Record whether every request fails or only a particular model, task, or high-concurrency workload fails.

This evidence is more useful than increasing the retry count. More retries can create more rejected traffic while leaving a billing, quota, or provider problem untouched.

Diagnose ChatGPT-authenticated Codex usage

For a session signed in with ChatGPT, start with /usage and any reset information the current interface provides. Codex consumption is not a fixed number of prompts: OpenAI's current Codex plan documentation says usage varies with factors such as the model, task size and complexity, context, reasoning, tools, retrieval, caching, and local versus cloud execution. Applicable local and cloud usage can share a five-hour window, and additional weekly limits may apply.

That does not justify a universal “wait five hours” rule. Plans, models, features, rollouts, and the point at which an individual window began can differ. Use the allowance and reset evidence shown for the affected account.

• If the account clearly shows an exhausted allowance and a reset time, stop retrying and wait for the displayed reset or use an account-supported option shown in the product.
• If usage remains available, the display conflicts with the failure. Capture both observations and investigate concurrent activity, the affected surface and model, and independently visible service information.
• If /usage is unavailable or inconclusive, classify the result as “not yet determined.” Do not relabel it as an API billing problem unless an API key actually handled the request.

An allowance display is a snapshot, and /status describes the session. Neither alone proves that a specific request was rejected because its quota was exhausted.

Diagnose OpenAI Platform API traffic

For API-key traffic, preserve the structured response. OpenAI's API error guide documents several 429 categories, including request-rate throttling, exhausted credits, organization or project spend limits, and an organization usage limit. The response's error.code and message are therefore more diagnostic than the HTTP status by itself.

Check that you are looking at the same organization, project, and model used by the failed request. OpenAI's rate-limit guide explains that API limits are defined at organization or project scope and vary by model; current limits are available in the Developer Console.

Use the evidence to choose the action:

• A Retry-After header accompanies a temporary rate rejection: classify it as transient API throttling. Wait at least as long as directed, then make one controlled retry.
• Rate counters show a request or token burst: classify it as rate pressure. Reduce concurrency or request volume; use bounded backoff if you control the HTTP client.
• The structured error identifies credits, billing, spend, or usage limits: classify it as an account control. Correct the identified condition in the affected organization or project; retries alone cannot restore access.
• The error lacks enough detail or conflicts with the console: leave it unclassified. Preserve the request ID and timestamps, verify the project context, then escalate with a minimal reproduction.

When you own the HTTP client and the failure is genuinely transient, follow Retry-After when supplied. Otherwise, the official retry guidance recommends exponential backoff with random jitter. Bound both the attempt count and total elapsed time. This is API-client advice; it does not prove that a ChatGPT-authenticated Codex failure is a transient API rate limit.

Diagnose a custom provider or gateway

A custom endpoint moves the diagnostic boundary. The visible 429 may come from the model vendor, an internal proxy, an API gateway, or a policy layer in front of them. OpenAI Platform billing pages cannot explain a rejection from a different upstream.

Confirm the effective provider and base endpoint without exposing credentials. Then inspect that system's response body, headers, quota and billing view, request logs, and service status. If a gateway fronts another provider, correlate the same request across both layers using a request or trace ID. A gateway may also rewrite an upstream error, so record both the status Codex received and any deeper cause recorded in gateway logs.

If you cannot establish which endpoint handled the request, the diagnosis should remain unclassified. Changing accounts, purchasing credits, or tuning retries before locating the rejecting system is guesswork.

Decide whether another retry is useful

Retry only when the evidence supports a condition that can clear without an account or configuration change.

• Retry later: a valid Retry-After, a clearly displayed usage reset, or independently confirmed transient service recovery gives you a concrete condition to wait for.
• Change load, then retry once: API evidence shows request- or token-rate pressure and you can reduce concurrency, request frequency, or token load accordingly.
• Do not retry yet: the response identifies depleted credits, a spend or usage limit, or a provider quota that must be changed.
• Stop and collect evidence: usage appears available but repeated controlled requests fail, or the error body and account surfaces disagree.

Use one small, controlled request after the relevant condition changes. If it fails with the same evidence, stop the loop. Repeated success-free attempts add noise and may consume capacity if some requests reach the upstream system.

Handle “usage remaining” without assuming an outage

Remaining usage and a retry-limit error can coexist. The usage display may cover a different account boundary, another provider may be rejecting the request, a specific model may have a separate constraint, or a service fault may be involved. The mismatch is a reason to investigate, not proof of any one explanation.

There is historical evidence for this caution. In January 2026, an openai/codex issue recorded the same surface symptom while users reported remaining allowance; an OpenAI maintainer later said that incident's underlying cause had been addressed. When a similar symptom later recurred, the maintainer treated it as a different issue and requested fresh logs and a new report.

That issue proves only that identical terminal text has had more than one cause. It does not establish that a current failure is an outage, that the historical fix regressed, or that another user's workaround applies to you.

Prepare a report that someone can act on

If the cause remains unexplained, provide a compact reproduction instead of a theory:

text
Observed at: <timestamp and time zone>
Codex surface/version: <CLI, IDE, or cloud surface and version>
OS/environment: <relevant non-secret details>
Authentication path: <ChatGPT | OpenAI API | custom provider>
Model/provider: <exact identifier, if safe>
Expected: <what should have happened>
Actual: <sanitized full error and error.code>
Request ID: <retained or safely shared according to support guidance>
Usage/limits evidence: <same-time observation>
Concurrency: <other clients or jobs sharing the boundary>
Minimal reproduction: <smallest steps that still fail>
Already tried: <one bounded retry or relevant account correction>

Review every attachment and pasted log. Remove API keys, authorization headers, cookies, organization or project identifiers that are not required, prompt content, private file paths, proprietary code, and personal data. Keep an unredacted local copy only if your security policy permits it.

The historical issue above mentioned /feedback logs and a new bug report, but reporting workflows can change by Codex version and surface. Use the support or feedback path currently offered in your installation or account, and include the sanitized evidence rather than assuming an old issue thread is still the correct destination.

The reliable stopping rule

You have a defensible diagnosis when the rejecting request path, the detailed 429 evidence, and the relevant account or provider state agree. You have a defensible unclassified result when one of those pieces is still missing or they conflict.

In either case, the final retry-limit line is not the root cause. Wait only for an observed reset or transient condition, change billing or limits only on the system that handled the request, and escalate only after preserving a minimal, redacted reproduction. That approach avoids both endless retries and confident fixes aimed at the wrong account.