Anthropic 529 overloaded_error: this means try again, with backoff, not a bug in your code

529 overloaded_error: back off, don't rewrite your code

Symptom

A request fails with HTTP 529 and error type overloaded_error. Or, on a streaming request, you get an error event with overloaded_error after the stream already started with a 200.

Confirm the cause

Check the error type in the response body. overloaded_error is capacity, not validation: your request was fine, the servers were full. In a stream this arrives as an SSE error event, not as an HTTP status, so code that only checks the status code misses it.

Fix

1. Retry with exponential backoff and jitter. The official SDKs already do this twice by default and honor the retry-after header when one is present; raise max_retries if you need more attempts.
2. If you wrote your own HTTP client, implement the same: honor retry-after, otherwise wait roughly 1s, 2s, 4s with jitter before giving up.
3. For streams, treat an error event the same as a 529: abort that attempt and retry the request fresh.
4. Do not "fix" the payload. Changing the prompt in response to a 529 just burns tokens.

Verify

Retry the identical request after the backoff and it succeeds with the same payload. If 529s persist for many minutes across different requests, check the Anthropic status page before assuming your code is at fault.

A 529 overloaded_error is documented as temporary overload, with SDKs retrying twice by default and honoring retry-after. Mid-stream errors arrive as SSE error events after a 200. Verified live at https://docs.anthropic.com/en/api/errors and https://docs.anthropic.com/en/api/messages-streaming.