How should an AI agent retry OpenAI 429 slow_down vs 503 server_is_overloaded errors in 2026?

An OpenAI 429 slow_down and a 503 server_is_overloaded are different failure meanings, not interchangeable bad statuses. OpenAI documents slow_down as a signal that requests are increasing too quickly, and server_is_overloaded as a temporary model-capacity condition. Build retry control around that distinction: honor Retry-After when either response includes it, otherwise use exponential backoff — then let the two codes diverge in what happens next.

429 slow_down: the client's own ramp is the pressure

OpenAI's error-codes guide defines slow_downand prescribes gradual traffic reduction. Read literally: this is a client-side signal about the client's own request pattern, not a generic rate-limit rejection. After honoring Retry-After (or backing off exponentially when it is absent), the correct next move is to reduce the request ramp — not just wait once and resume at the same rate — then increase traffic gradually again.

That gradual re-increase matters because OpenAI's rate-limits guide documents limits at multiple dimensions: organization, project, model, and metric (for example requests-per-minute versus tokens-per-minute). A ramp that recovers instantly back to peak rate can trip the same limit again immediately. Recovering slower is the deliberate tradeoff, not an oversight.

503 server_is_overloaded: a temporary provider-capacity condition

server_is_overloadedsignals temporary overload on OpenAI's side, not a property of the client's traffic shape. The same first step applies — honor Retry-After if the response carries it, otherwise use exponential backoff — but there is no ramp to diagnose or reduce here, because the client did not necessarily do anything wrong.

Keep the retry idempotent and record what happened

Both paths converge on the same operational requirement: the retried request must be safe to repeat, and the attempt itself must be legible after the fact. That means the retry should reuse the same idempotent tool-call discipline used elsewhere in an agent harness — a retried call after slow_down or server_is_overloaded should not double-execute a side effect just because the first response was a failure rather than a timeout.

Record, per attempt: the error code returned, the Retry-After value if one was present, the attempt number, and the outcome. That log is what lets you tell, after the fact, whether a client kept ramping into repeated slow_down responses versus absorbing a run of provider-side server_is_overloaded responses — two very different incidents that a single retry-count metric would blur together.

The tradeoff: slower ramp recovery, less prolonged throttling

Reducing ramp after slow_down and then re-increasing it gradually means a client takes longer to get back to its prior request rate than if it just resumed immediately after the wait. That is the deliberate tradeoff: repeatedly pushing back to peak rate right after a slow_down response is exactly the pattern that produces more slow_down responses, which prolongs the throttled state longer than a slower, monotonic ramp-up would. This is the same operating posture as not treating every OpenAI 429 the same — the documented error code decides the response, not the HTTP status by itself.

None of this is a substitute for capacity or cost controls upstream of the retry layer; it is the boundary-level discipline that keeps those controls from fighting the provider's own signals. That separation of provider signal, retry policy, and logged outcome is the same posture covered in AgentOps.