OpenAI API rate limits can stop a request even when the account still has money available. A 429 response can also describe a quota or account constraint that waiting will not fix. Read the response body, relevant headers and account limits before choosing a retry policy.
The rate-limit guide separates request and token limits from account usage and spending controls. The error-code guide supplies the recovery context. Together they explain why a single “retry every 429” rule is incomplete.
Find the constraint that was reached
A workload can encounter request-per-minute or token-per-minute limits, as well as other model or endpoint metrics. Sending fewer requests does not necessarily solve a token constraint if each request is large.
The applicable values depend on the account, model and usage tier. Read the account’s Limits view and the current response headers rather than borrowing a number from another project’s example.
A useful application log associates the HTTP status with the error type and code. It should also record the request’s model and the relevant retry information, without exposing API keys or sensitive prompt content.
| Evidence | What it helps distinguish |
|---|---|
| Error body | Temporary traffic limit, overload or account action |
| Remaining/reset headers | Which request or token allowance is constrained |
| Organization/project limits | The values applying to this workload |
| Spend controls | Whether a financial cap has stopped traffic |
A burst can fail below an average-per-minute estimate
An application’s average rate can look acceptable while its workers release requests at the same instant. The guide discusses limits enforced over shorter intervals and rapid increases in traffic.
That is a scheduling problem as well as a retry problem. A queue that spreads work can avoid turning each deployment or batch start into a synchronized burst. Set concurrency with the relevant request and token constraints in mind.
The documented slow_down condition uses HTTP 429 for a rate that increases too quickly. Temporary model overload is documented separately as HTTP 503 with server_is_overloaded. Inspect the body because the status alone does not supply the whole diagnosis.
Respect the server’s wait instruction
A temporary error may include Retry-After. The documentation describes it as a minimum wait before another attempt. Add a small random delay so many clients do not all return at the same moment.
If the header is missing or invalid, the guide recommends exponential backoff with jitter: increase the delay across failed attempts while varying it slightly. Limit both the attempt count and the total retry time.
An application deadline matters here. A request intended to support an immediate user interaction may no longer be useful after a long delay. Deferring it or reporting the temporary failure can be more appropriate than keeping an unbounded background loop alive.
Account action is different from temporary pressure
OpenAI distinguishes retryable traffic conditions from quota, billing and other errors requiring action. Its current rate-limit guide also separates spend alerts from hard spend limits: an alert allows traffic to continue, while a hard cap can cause affected requests to return 429.
A retry loop cannot change the account’s configuration. Confirm the specific error and investigate the corresponding billing, quota or spending control.
This is why a monitoring label such as “429s rising” needs a second dimension. Temporary traffic pressure and a monthly account cap can produce the same status while requiring different responses.
Do not multiply retries across layers
Official SDKs retry eligible responses subject to their settings. An application can accidentally wrap that behavior in another retry loop, causing several underlying requests for every attempt it thinks it is making.
The guide says to disable SDK retries when managing them yourself or account for them in the overall limits. Match this review to the installed SDK version, because handling of long server delays varies.
Unsuccessful requests also contribute to per-minute limits. Rapidly repeating the request can maintain the very pressure the application is trying to escape.
Decide which work needs an immediate response
Interactive traffic and deferred processing have different deadlines. A bulk task can often enter a queue; a user-facing request needs a clear response when its time budget expires.
For deferred work, the Batch API guide describes a different processing route. It is not an automatic substitute for an interactive call. The prompt-caching guide addresses cost accounting; a cheaper request still has to fit the relevant traffic limits.
Review latency, token volume, retries and the actual error reason together. That produces a useful recovery policy instead of an attempt counter that grows whenever the service says no.
