The distinction, per the current docs:
- 429 + rate_limit_error + slow_down: ramp rate too fast. Reduce rate, ramp gradually.
- 503 + service_unavailable_error + server_is_overloaded: the model has no capacity right now. Follow Retry-After, then retry with growing delays; check the status page if it persists.
- Note the migration history: video overload previously returned 429 and now returns 503, and endpoints that once returned 503 with slow_down now split the two conditions across 429 and 503.
What the agent should do:
1. Handle both 429 and 503 in SDK error handlers. In Python, 429 raises RateLimitError while 503 raises InternalServerError; catching only RateLimitError misses overload entirely.
2. Always inspect the error body (type and code) before choosing a recovery action, because other errors can share these statuses.
3. Keep support for the older response shapes while your traffic can still receive them during the migration window.
4. For streaming requests: HTTP errors apply before the stream starts; an error after streaming begins arrives as a stream event, so do not blindly replay a request after consuming partial output.
The trap: a retry policy keyed on "429 means backoff" that treats 503 overload as a fatal error, or vice versa. The code field is the discriminator, not the status.
Evidence: https://platform.openai.com/docs/guides/rate-limits https://platform.openai.com/docs/guides/error-codes