Anthropic API 529 overloaded_error
Anthropic’s API had more traffic than it could serve at that moment, so it turned your request away even though the request was fine.
Also appears as
- {"type":"error","error":{"type":"overloaded_error","message":"Overloaded"},"request_id":"req_011CSHoEeqs5C35K2UUqR7Fy"}
- event: error data: {"type": "error", "error": {"type": "overloaded_error", "message": "Overloaded"}}
Prompt to fix it
Our app’s calls to the Anthropic API sometimes fail with "529 overloaded_error". That means Anthropic is temporarily over capacity, so the fix is resilience in our code. Find where we call the API and make sure the SDK’s automatic retries are on, with more retries for background work. After retries run out, show users a clear “busy, try again” message, and fall back to a second model where it makes sense. Handle error events in streaming responses too. Don’t retry in a tight loop, and keep 400-level errors failing fast.
Paste into Layerwise or any AI coding tool.
What it means
A 529 with overloaded_error comes from Anthropic’s side: the API is temporarily over capacity because of high traffic across all users. Your request, key, and account are fine, and the same request usually succeeds a little later.
The official SDKs already retry it twice with exponential backoff. By the time your code catches this error, three attempts have failed in a row. For a user-facing feature, that’s the moment to show a clear “busy, try again” message, queue the work for later, or fall back to another model.
Keep it apart from 429 rate_limit_error, which is about your own organization’s limits and usually comes with a retry-after header. Streaming responses can also fail this way after they’ve started, as an error event in the stream, so stream handlers need the same care.
Common causes
- Anthropic’s API is under heavy load across all customers, and it’s shedding requests.
- The app retries with no delay, or not at all, so a short spike becomes a failure users see.
- A long streaming response hit a capacity spike midway and ended with an
errorevent.
How to fix it
- Check Anthropic’s status page for an ongoing incident.
- Keep the SDK’s automatic retries on, and raise
maxRetriesfor background jobs that can wait. - For user-facing calls, catch the error after retries and show a “busy, try again” message.
- Add a fallback, such as a smaller Claude model, for requests that must succeed.
- Handle
errorevents in streaming responses the same way as failed requests.
Example fix
import Anthropic from '@anthropic-ai/sdk';
// Background work can wait out longer spikes than the default 2 retries.
const anthropic = new Anthropic({ maxRetries: 5 });
export async function summarize(text: string) {
try {
return await anthropic.messages.create({
model: 'claude-sonnet-5-5',
max_tokens: 1024,
messages: [{ role: 'user', content: `Summarize this:\n\n${text}` }]
});
} catch (error) {
if (error instanceof Anthropic.APIError && error.status === 529) {
return null; // Still overloaded after retries: let the caller try later.
}
throw error;
}
}Related errors
All errors429 Too Many Requests
The service is rate limiting you: too many requests arrived in a short time, so it refuses more until the limit resets.
500 Internal Server Error
The server’s code threw an error or crashed while handling the request, and the real error message is waiting in the server logs.
Context length exceeded
The text sent to the model, including chat history, documents, and tool results, is more than the model can read in one request.
You exceeded your current quota
OpenAI refused the request because the account or project behind the API key is out of credit or has reached a spending limit.
Build with an agent that checks its work
The Layerwise agent clicks through the live preview and reads the console, so it catches errors before you do.