AI API 429/529/503 Error Retry Rules: OpenAI, Claude, Gemini, and Bedrock in Practice

When calling AI APIs, 429, 529, and 503 errors appear frequently, but the meanings behind the error responses and the retry strategies differ by provider. Blindly retrying can increase quota consumption or trigger stricter rate limiting. Based on official documentation, this article outlines the differentiated retry rules for OpenAI, Claude, Gemini, and Bedrock, and explains how to build a typed wrapper that automatically skips quota errors to improve application stability.

Error Types and Retry Principles

429 (Too Many Requests) indicates that a rate limit or quota has been exceeded and usually requires waiting; 529 (Service Unavailable) is an overload error specific to Anthropic, indicating that the service is temporarily unavailable; 503 (Service Unavailable) is commonly seen with temporary server-side failures. The core principle of retrying is: distinguish retryable errors (such as 503 and 529) from non-retryable errors (such as quota-exhaustion 429s), and follow the Retry-After field in the response headers.

Exponential backoff and jitter: Exponential backoff means the wait time before each retry grows exponentially (e.g., 1 second, 2 seconds, 4 seconds, 8 seconds), avoiding continuous high-frequency requests during server-side failures. To prevent a large number of clients from retrying at the same moment and causing a "thundering herd" effect, random jitter is usually added to the backoff time—for example, multiplying the calculated wait time by a random factor between 0.5 and 1.5. AWS's "Full Jitter" strategy recommends a wait time of random(0, min(cap, base * 2^attempt)). For AI APIs, it is advisable to set a maximum number of retries (e.g., 3–5) and a maximum wait cap (e.g., 30 seconds) to prevent unlimited retries from exhausting resources.

Idempotency and retry safety: Before retrying, confirm whether the request is idempotent. For text-generation APIs, repeated calls may incur additional costs or produce duplicate content, so retries should be combined with a business idempotency key or deduplication logic. Providers such as OpenAI support the Idempotency-Key request header to ensure that the same request submitted multiple times is executed only once, but not all APIs support this—check the corresponding documentation.

Detailed Retry Rules by Provider

OpenAI: Distinguish Rate Limits from Quota Exhaustion

OpenAI's 429 errors can be caused by rate limits or quota exhaustion. Rate limits usually indicate the wait time via the Retry-After header and are retryable; quota-exhaustion errors (such as insufficient_quota), however, should not be retried—check the account balance or upgrade the plan. It is recommended to use exponential backoff and set a maximum number of retries.

Claude (Anthropic): 529 Overload and Retry-After

A 529 error returned by the Anthropic API indicates that the service is overloaded and is usually accompanied by a Retry-After header. The official guidance is to retry 529s, but follow a backoff strategy. 429 errors may involve rate limits or quotas and likewise need to be distinguished: rate limits are retryable, while quota issues require manual intervention.

Gemini (Google): Backoff Strategy for 429 and 503

A 429 error from the Google Gemini API indicates a rate limit, and 503 indicates service unavailability. Both are retryable, but 429 requires following Retry-After, while 503 suggests using exponential backoff. Note that Google's quota management is relatively strict, and frequent retries may lead to longer ban periods.

Bedrock (AWS): Differentiated Handling of 503 and 429

A 429 error from AWS Bedrock may be caused by throttling or quotas, and 503 is a server-side error. Bedrock documentation recommends retrying 503s, while 429s require checking the throttling configuration. Because Bedrock quotas are tied to IAM policies, confirm the remaining quota before retrying.

How to Correctly Read the Retry-After Header

The Retry-After header has two formats: seconds (e.g., Retry-After: 120) or an HTTP date (e.g., Retry-After: Wed, 21 Oct 2026 07:28:00 GMT). When parsing, prefer the seconds format; if it is a date, calculate the difference from the current time. If the response does not provide this header, use exponential backoff (e.g., start at 1 second, multiply by 2 each time, up to a maximum of 30 seconds).

Notes on parsing the HTTP date format: The HTTP date format of Retry-After follows RFC 7231 and uses IMF-fixdate (e.g., Wed, 21 Oct 2026 07:28:00 GMT). When parsing, use a library that supports this format (such as Python's email.utils.parsedate_to_datetime), convert it uniformly to UTC, and compare it with the current UTC time to avoid wait-time calculation errors caused by local time zone offsets. If parsing fails or the date has already passed, fall back to the exponential backoff strategy. Some proxies or gateways may modify or strip this header, so setting a reasonable default backoff on the client side is equally important.

Typed Wrapper: Automatically Skipping Quota Errors

To reduce repetitive code, you can build a typed wrapper that decides whether to retry based on the error type when catching exceptions. For example, for OpenAI's RateLimitError, check whether the error code is insufficient_quota, and if so, throw it directly; for 529 and 503, retry according to the backoff strategy. The wrapper can handle the Retry-After header uniformly and log retries for easier monitoring.

Error classification and exception mapping: Different SDKs wrap HTTP errors in different ways. The OpenAI Python SDK maps 429 to RateLimitError, whose code field may be insufficient_quota or rate_limit_exceeded; the Anthropic SDK uses APIStatusError and exposes status_code; the Google Gemini SDK (such as google-generativeai) throws ResourceExhausted (corresponding to 429) and ServiceUnavailable (corresponding to 503); AWS Bedrock returns Error.Code via botocore.exceptions.ClientError (such as ThrottlingException and ServiceUnavailableException). A typed wrapper should first route by exception type, then check the error code or status code, and finally decide whether to retry or throw directly. It is recommended to define a separate error classification function for each provider to avoid cross-SDK coupling.

Best Practices and Summary

• Always read the Retry-After header first and avoid fixed-interval retries.
• Distinguish quota errors from rate-limit errors; quota errors should not be retried.
• Configure a separate backoff strategy for each provider to avoid cross-service interference.
• Use a typed wrapper to unify error-handling logic and improve code maintainability.

By following the differentiated rules in official documentation and combining them with automated retry mechanisms, you can significantly reduce AI API call failure rates and ensure application stability.

One-line Summary

Outlines the differentiated retry rules of OpenAI, Claude, Gemini, and Bedrock for 429/529/503 errors, along with typed wrapper best practices.

Paragraph Summary

Based on official documentation, this article systematically compares how the four major AI API providers—OpenAI, Claude, Gemini, and Bedrock—handle and retry 429, 529, and 503 errors. The core points are: 429 errors require distinguishing rate limits (retryable) from quota exhaustion (non-retryable); 529 is an overload error specific to Anthropic; and 503 is a temporary server-side failure. The article emphasizes reading the Retry-After header first (supporting both seconds and HTTP date formats) and using exponential backoff when the header is absent. Given the differences in exception types across provider SDKs, it proposes building a typed wrapper that automatically identifies and skips quota errors and unifies retry logic and backoff strategies, thereby reducing call failure rates and improving application stability.