# 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.