Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A 429 does not always mean “wait and try again.” First inspect the error body and response headers: the cause may be temporary throttling, an exhausted quota or balance, or a billing limit. Retry only transient limits; respect a valid Retry-After value, and otherwise use capped exponential backoff with jitter and a firm retry budget.
Why a 429 can happen even when your average request rate looks safe
A displayed per-minute limit does not necessarily mean requests are evaluated only in neat one-minute blocks. A burst can exceed a shorter enforcement interval even when the average over a full minute seems acceptable. Limits can also apply to token volume, not just request count. For OpenAI, long prompts and unnecessarily high output-token allowances can contribute to token-rate errors. See OpenAI’s troubleshooting guidance.
Repeated immediate retries can make the problem worse: unsuccessful requests still count toward OpenAI’s per-minute limit. A 429 may also reflect exhausted prepaid balance or a spending or usage cap, which waiting will not fix. Read the structured error details before deciding what to do. OpenAI’s rate-limit guide explains retry behavior; its Help Center article distinguishes rate pressure from account and billing issues.
What to do when a request returns 429
- Inspect the response. Check the HTTP status, structured error body, and headers. Determine whether it describes temporary rate pressure, a quota or billing problem, or another request error.
- Do not retry account or request failures blindly. Correct a depleted balance, spend cap, invalid request, or other non-transient cause first. Repeating the same request will not resolve it.
- Honor a valid
Retry-After. Treat the specified delay as a minimum wait. If clients are likely to resume together, add a small random delay after that minimum to avoid a synchronized burst. - Use backoff if no valid server delay is available. Increase the wait exponentially between attempts and add random jitter. Cap each wait, set a finite attempt count, and enforce a total time budget.
- Defer rather than retry early. If the server’s valid delay exceeds your client’s maximum wait or the operation’s deadline, save the work for later instead of ignoring the delay.
- Check for SDK retries. OpenAI says its official SDKs retry eligible 429 and 503 responses subject to settings. Defaults and behavior for long retry delays depend on SDK version and configuration. Account for those retries before adding an application-level loop.
- Reduce pressure and make work recoverable. Smooth bursts, lower concurrency where appropriate, review prompt and output sizes, and persist completed units so a terminal failure does not force the whole job to start over.
How to implement a safe retry policy
Use the server’s signal first
When a provider supplies a valid Retry-After, wait at least that long. Retrying sooner can simply fail again; Anthropic’s documentation puts it plainly: “Earlier retries will fail.” A random offset can help multiple workers avoid waking at precisely the same time, but it should not shorten the server’s requested delay.
#1 Best Overall
Bound retries when the signal is missing
Without a usable server delay, apply capped exponential backoff with jitter. The cap prevents one individual wait from growing without limit; an attempt limit prevents endless retries; and an overall deadline keeps a job from occupying a worker indefinitely. If that budget runs out, surface a clear failure or queue the unfinished work for a later run.
Avoid nested retry storms
Before wrapping an SDK call in your own retry loop, establish whether the SDK already retries and how its installed version handles long delays. Otherwise, one logical operation can produce more attempts than your application’s retry count suggests. Configure one layer as the owner of retry policy where possible, and log both the logical operation and actual request attempts.
Reduce the chance of hitting a limit again
- Smooth traffic: spread requests over time rather than releasing a large batch at once. OpenAI explicitly recommends spreading requests over time in its troubleshooting guide.
- Review token demand: remove unnecessary prompt content and avoid allowing more output than the task needs. For OpenAI, token rate limits can matter alongside request rate.
- Control concurrency: reduce simultaneous work when errors cluster during bursts, then increase it cautiously while monitoring responses.
- Separate transient pressure from a hard cap: inspect error details and account status before changing traffic behavior. A balance or spending limit requires an account-side remedy, not a longer retry loop.
- Make batch work resumable: record completed items and report a terminal error for the unfinished portion instead of restarting all work or retrying forever.
Rate-limit signals differ by provider
Do not assume that a status code, header, quota unit, or remedy from one API applies to another. The relevant limit might count requests, input tokens, output tokens, or distinct primary and secondary budgets.
| Provider and API | What the documentation says is limited | Signals and response |
|---|---|---|
| OpenAI API | Per-minute request and token limits; short enforcement intervals can make bursts matter. | Temporary rate limiting returns 429 and may include Retry-After. Follow a valid delay; otherwise use exponential backoff with jitter. A 429 can also relate to exhausted balance or spending or usage limits, so inspect the error details. OpenAI rate-limit guide and Help Center guidance. |
| Anthropic Messages API | Requests per minute, input tokens per minute, and output tokens per minute, by model class. | Documentation describes 429 responses that identify the exceeded limit, a retry-after header, and headers for limit, remaining capacity, and reset time. Its spend-cap 429 does not carry Retry-After, so do not assume every 429 is temporary throttling. Anthropic rate-limit documentation. |
| GitHub REST API | Primary and secondary rate limits. | Headers such as x-ratelimit-remaining and x-ratelimit-reset describe primary-limit state; GitHub says response headers take precedence over the periodic rate-limit endpoint if they disagree. For primary exhaustion, wait for reset. For secondary limits, honor retry-after when present; otherwise follow the documented wait guidance, including an initial wait of at least one minute in specified cases and longer waits if failures continue. Repeated requests while limited may risk an integration ban. GitHub REST API rate-limit documentation. |
How to tell whether the fix worked
Judge the change by whether the job completes without a retry storm, not by whether the first retry succeeds. Check logs for the response status, error category, retry delay, attempt count, and final outcome. If 429s persist, distinguish repeated bursts or high token demand from an account cap, and verify the provider’s current documentation: quotas, headers, and SDK behavior can change.
Quick Recap
Rank #3
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
