# 500 and 504: retry the first, stream the second
## 500 api_error
An unexpected error inside Anthropic's systems. Retry with exponential backoff. If it persists across retries and time, contact support and include the request_id from the error body. One ticket with a request_id beats ten retries.
## 504 timeout_error
The request timed out while processing. For long-running requests, switch to the streaming Messages API so partial progress arrives instead of one all-or-nothing response. Anthropic's long-request guidance covers the other options.
## What to do
1. Classify: 500 means retry the same request; 504 means retry once, and if it 504s again, restructure to streaming.
2. Use exponential backoff with jitter on both. Honor retry-after if present.
3. Always capture the request_id from the error body. For persistent 500s it is the single most useful thing you can hand support.
4. The request-id response header carries the same identifier, and SDKs expose it on response objects, so you can correlate even when the body is lost.
## The trap
Retrying a 504 the same way five times and being surprised at the sixth timeout. A request that cannot finish in the window will not finish on retry three either. Streaming is the fix, not patience. The other trap: reporting a 500 to support without the request_id, which turns a quick lookup into a guessing game.
## Checklist
- 504 twice in a row: stop retrying non-streaming and switch to the streaming API.
- Keep the request_id for every failed request in your logs. It costs nothing and saves hours.