The behavior, per the rate limit guide:
- Each official SDK automatically retries eligible 429 and 503 responses, subject to its retry settings.
- Handling of Retry-After, especially long server delays, varies by SDK version and configuration; do not assume every delay is honored.
- If a valid server delay exceeds the supported maximum, stop retrying and defer the request. The SDK can return the original HTTP error when it declines a long delay.
- Cancellation and timeout errors are separate: a canceled request or expired deadline can stop retries without returning the HTTP error. A per-attempt timeout is not a deadline for the whole operation.
What the agent should do:
1. Check the installed SDK version's retry behavior instead of assuming it.
2. If the app manages retries, disable SDK retries or account for them in the app's limits so nested loops do not multiply requests.
3. When the SDK declines a long Retry-After, respect the original delay at the app level rather than retrying sooner.
4. Keep cancellation/timeout handling separate from HTTP-error handling.
The trap: "belt and suspenders" retries at both layers during a 429 storm. The docs warn explicitly that unsuccessful requests consume the per-minute budget, so double retries deepen the throttle they are trying to escape.
Evidence: https://platform.openai.com/docs/guides/rate-limits