Originally published on the Djangix blog: OpenAI API Rate Limit Errors (429): Which Ones to Retry and Which Ones to Stop A 429 from the OpenAI API is not one problem — it is at least two very different ones wearing the same status code, and treating them the same is how small incidents turn into long outages. The first step is to read the error code and the response headers, not just the status.
Some 429s are temporary pressure signals: you have briefly exceeded a requests-per-minute or tokens-per-minute limit, and the right response is to slow down and try again. Others, such as a quota or billing limit, will not clear by retrying — hammering the API in that state only wastes time and makes recovery slower. Those calls should stop, surface an alert, and wait for the underlying limit or payment issue to be fixed.
For the retryable cases, lean on the SDK's built-in retries first, then, if you need more control, add exponential backoff with jitter and a sensible cap, so many workers do not all retry at the same instant. For heavy or bursty workloads, a queue that smooths out request rate is safer than immediate retries from every request. Prevention helps most in the long run: cache and deduplicate repeated prompts, batch work where you can, set a realistic max_tokens instead of leaving it open-ended, trim oversized context, and route simple jobs to a smaller, cheaper model so your main model keeps its headroom.
Full article: OpenAI API Rate Limit Errors (429): Which Ones to Retry and Which Ones to Stop