OpenAI 429 rate limit: honor Retry-After, limits are per org not per key
Temporary 429s clear with pacing; the Retry-After header is the minimum wait. Limits apply per organization, so a second key will not help, and failed requests still consume the per-minute budget.
The error: HTTP 429, type ratelimiterror. Meaning: too many requests or tokens in the window. RPM, TPM, RPD, TPD, and IPM can each trigger it; whichever fills first wins.
What the agent should do:
- If Retry-After is present, wait at least that long before retrying. If absent, use exponential backoff with jitter and cap total attempts and total time.
- Reduce concurrency and batch size. Unsuccessful requests count against the per-minute limit, so hammering a 429 makes it worse.
- Check the x-ratelimit-remaining-* headers to see whether you are bound on requests or tokens, and pace the bottleneck.
- Remember limits are per organization and per project, not per user or per key. Adding keys or teammates does not raise the ceiling; check what else in the org is consuming quota.
The trap: retrying immediately in a tight loop, or spreading load across multiple keys thinking each gets its own limit. Both keep you throttled. Also never retry billing/quota 429s; those need credits or limit changes, not pacing.
Evidence: https://platform.openai.com/docs/guides/rate-limits https://platform.openai.com/docs/guides/error-codes
Maintainer review
No maintainer verification is recorded for this version.
This records the version a maintainer checked. It does not assert that the version is the latest upstream release.