Codex Rescue

Codex reset guide

Codex rate limit reset for API keys

Using Codex with an API key and seeing 429? Read Retry-After and x-ratelimit-reset headers, distinguish temporary limits from billing caps, then retry safely.

The short answer

For requests made with your own OpenAI API key, a 429 is an API response that must be interpreted from the project’s rate-limit and billing context. A temporary request or token limit can have Retry-After and x-ratelimit-reset-* response headers; a hard spend cap needs account action instead of a short retry. Those headers describe API resources, not the five-hour or weekly ChatGPT-plan Codex allowance. Start with the actual failing response.

Is this your situation?

  • You deliberately configured an API key for Codex or an integration and the response or log includes HTTP 429.
  • You can inspect the HTTP response headers and need to tell a temporary request limit from a project or organization cap.
  • A retry loop keeps failing even after a short wait, raising the possibility of a hard spend limit or a different constraint.
  • A ChatGPT subscription page shows remaining usage, but the failing API request belongs to another billing arrangement.

Step by step

  1. Confirm this is the API-key path

    Check the authentication method for the failing client and the project or organization tied to its key. Do not publish the key in a screenshot or support post. If the client instead uses ChatGPT sign-in, use the plan-limit guide; its banked resets and usage dashboard are not substitutes for API response headers.

  2. Capture the exact 429 context

    Record the response status, time, endpoint or model, and any safe request ID. Note whether the error describes a temporary rate limit, insufficient quota, or a hard spend cap. The OpenAI API rate-limit guide says 429 can have different causes, so the numeric status alone is not enough to choose a remedy.

  3. Read the headers without inventing a clock

    When present, Retry-After states a minimum number of seconds to wait for a temporary limit. The x-ratelimit-reset-requests and x-ratelimit-reset-tokens headers express time until the request or token limit resets; project-token resets may have their own header. Use the header that matches the exhausted resource. These values are not a weekly Codex reset timestamp.

  4. Retry temporary limits conservatively

    For a temporary limit, wait at least the indicated duration when Retry-After is present and use exponential backoff for additional attempts. Reduce concurrency or request size if the same resource is repeatedly exhausted. Unsuccessful retries can also count toward a rate limit, so a tight immediate loop can prolong the problem.

  5. Handle account-action errors separately

    If the error is a hard spend limit or exhausted billing quota, waiting for a short request window will not resolve it. Check the project and organization limits in the OpenAI developer console and follow the account’s billing path. Do not assume a ChatGPT plan upgrade or public Codex reset will raise an API project cap.

  6. Verify the result and preserve evidence

    After a bounded wait or account correction, make a small test request and compare its status and remaining-limit headers. If it still fails, retain the sanitized response and project context for support. Avoid sharing API keys, authorization headers, or full request bodies that may contain private data.

Still stuck?

  • If no reset header is present, do not fabricate a reset time; inspect the developer-console limit and the response body.
  • If the 429 appears only in a signed-in ChatGPT-plan session, switch to the usage-limit guide rather than changing API billing.
  • If the response indicates an outage instead of an account limit, check the official status report before further retries.

Frequently asked questions

Is x-ratelimit-reset-requests my Codex weekly reset date?

No. It is an API response header for the request-rate-limit resource. The ChatGPT-plan Codex weekly allowance is a separate account mechanism.

Should I retry every 100 milliseconds after a Codex API 429?

No. Use Retry-After when present and otherwise bounded exponential backoff. Rapid unsuccessful attempts can consume rate-limit capacity and do not fix a hard spend cap.

Why does a 429 persist after the reset header interval passed?

The exhausted resource may be a different token or project limit, a hard spend cap, or an ongoing issue. Read the response body, remaining headers, and developer-console project limits before changing anything.

Sources and scope

The sources below support the product behavior described here. Any live transcript classification is our interpretation, not a reading of your OpenAI account.

Last updated: