HTTP 429

The Retry-After header in an HTTP 429 response is used by the server to inform the client of the number of seconds to wait, and reading this value takes priority over calculating it independently.

In agent frameworks such as CrewAI or LangGraph, an unhandled HTTP 429 immediately terminates the entire execution run, destroying the accumulated context and wasting token costs.

Different error types (such as 429 rate limiting versus 500 internal errors) call for completely different retry strategies and fallback plans.

Free tiers usually have rate limits (such as RPM, TPM, RPD), context length limits, or feature limits, and typically return HTTP 429 when triggered.

HTTP 503 indicates temporary unavailability on the provider side and is usually unrelated to call frequency; 429 indicates the caller exceeded the per-unit-time quota, and the response headers often carry Retry-After. 503 is suited to exponential backoff retries, while 429 is better handled by switching to a backup model or deferring to the next period.

A receiver that silently drops data is worse than one that outright rejects it, because a 429 status code can tell the sender to retry.

HTTP 429 indicates that the client has sent too many requests within a given time, usually accompanied by a Retry-After header indicating how long to wait before retrying.

A 429 (Too Many Requests) error indicates the rate limit or quota has been exceeded, and usually requires waiting.

AWS Bedrock documentation recommends retrying 503, while 429 requires checking the throttling configuration, because Bedrock quotas are tied to IAM policies.

OpenAI's 429 errors may be caused by rate limiting or quota exhaustion, and quota exhaustion errors (such as insufficient_quota) should not be retried.

During development the author encountered HTTP 413 and 429 errors, and the fix strategy had three steps: reduce the amount per request (process only one language group of one game at a time), limit max_tokens, and wait 70 seconds between requests (240 seconds when idle).

Services that conform to HTTP semantics often include a Retry-After response header when returning 429, indicating the recommended number of seconds to wait, and clients should prioritize following that value.

TTS services usually limit the number of requests per minute, and exceeding the limit returns 429 Too Many Requests.

When a data source returns 429, it means you are being rate-limited, and countermeasures such as backoff, increasing caching, or adding a second key can be taken; 429 is not a model problem.

The HTTP 429 status code is defined by RFC 6585 as 'Too Many Requests,' is a retryable status code, and is fundamentally different from 401 (authentication failure) and 403 (insufficient permissions).

For HTTP 429, the Retry-After header should be checked, and if present, its value should be used instead of the computed backoff delay.

HTTP status codes that should be retried include: 429, 502, 503, 504, as well as network-layer failures such as connection resets and timeouts.

A 429 status code usually indicates that a specific model under that key has reached its limit, rather than the entire key being used up, so other models under the same key can be tried.

HTTP status code 429 indicates server-side rate limiting, usually accompanied by a Retry-After header; HTTP 403 indicates access is directly denied, possibly due to an IP blacklist, a User-Agent identified as a crawler, or missing authentication information.

The article points out that HTTP 429 is an infrastructure tax rather than a model failure, and the orchestration layer should implement exponential backoff, a token bucket, or cross-run quota scheduling to handle it.