Lower concurrency
Start by reducing parallel jobs. A small steady queue is safer than a burst of retries.
TackleKey
429 rate limit
Handle 429 rate limit errors without creating a retry storm
A 429 is a signal to slow down and inspect quota, concurrency, retries, and shared key usage. The fix is usually controlled backoff plus better request shaping.
Common causes
Backoff with jitter
Retry after a delay and add jitter so many jobs do not retry at the same second.
Separate keys
Use different project keys for production, tests, batch jobs, and tools so one job does not starve the others.
Check model route
Some models or providers have tighter limits. Test a small request and check status before scaling.
Debugging order
| Step | What to check | Entry |
|---|---|---|
| Request logs | Look for repeated 429s from the same key, model, or job. | Open |
| Pricing and availability | Confirm the model is still visible and suitable for your workload. | Open |
| Small queue test | Run a smaller batch and watch whether successful responses recover. | Open |
| Route candidates | Compare lower-cost candidates after rate behavior is stable. | Open |
Do not retry immediately in a tight loop. That can increase failures and make the effective cost worse.
FAQ
Is 429 always a provider outage?
No. It can be project quota, burst concurrency, shared key traffic, model-specific throttling, or retry behavior.
Should I increase timeout for 429?
Timeouts do not solve rate limits. Use backoff, lower concurrency, and inspect quota and logs.
Can another model help?
Sometimes, but compare success, latency, price, and logs before moving production traffic.
Try TackleKey with one OpenAI-compatible change
Create an account, generate a project API key, then replace your client base URL with the TackleKey endpoint. Keep keys server-side and verify live pricing before scaling traffic.