A production system making Claude API calls observes three distinct error patterns over 24 hours: (1) sporadic 529 errors during business hours, (2) 429 errors with a retry-after header at peak load, and (3) 500 errors on roughly 0.1% of requests at random times. How should the retry and alerting strategy differ for each error type?

The correct strategy is the one that treats each error type according to its distinct cause: 529 overloaded errors warrant exponential backoff with capacity-aware retry, 429 rate-limit errors require respecting the retry-after header before retrying, and 500 API errors should be retried once immediately and then with backoff, with persistent 500s triggering an incident alert because they indicate a service-side issue. A 529 means Anthropic's infrastructure is at capacity, so exponential backoff with jitter prevents thundering-herd amplification. A 429 means the client has exceeded its quota, so the correct behavior is to wait exactly the retry-after duration before retrying, not to backoff independently. A 500 is a transient service fault, so one immediate retry is reasonable, followed by backoff, but a sustained pattern of 500s indicates a service-side issue requiring an alert. The option that applies the same exponential backoff with jitter and five retries to all three error types is wrong because treating them identically can worsen 429 situations by ignoring the retry-after header and can delay incident response for persistent 500 patterns. The option that treats 429 errors as a rate-limiting configuration bug requiring manual intervention is wrong because 429 errors are expected in high-throughput systems and are handled correctly by respecting rate limits. The option that ignores 529 errors as temporary and self-resolving is wrong because 529 errors under sustained load will not self-resolve without backoff and require active retry management.