AI Error WikiSearch

Claude API Error: 529 Overloaded

A documented temporary overload response from the Claude API.

Quick answer

Anthropic documents API 529 as overloaded_error: its API is temporarily overloaded. It is separate from 429 rate_limit_error. Save the request and check for partial work before retrying; the error does not say when capacity will return.

Exact message

API Error: 529 Overloaded

What it means

The API error reference says 529 can occur when traffic is high across users. It does not mean your prompt is invalid or that your personal limit has run out. The response identifies a temporary service condition, but it cannot tell you whether a long task had already written a file or called a tool before the failure appeared in your client.

What to try

  1. Check Claude status for an incident. Save the prompt, partial output, time, and request ID if shown.
  2. If the request may have changed files or external data, inspect those results before sending it again. For an API integration, retry a limited number of times with increasing delays; check whether your SDK is already doing that.
  3. If 529 keeps returning, send the request ID and timestamps to support. A shorter or simpler request can be a useful comparison, but it does not cure a documented overload.

User report

One Claude Code user posted a log of 322 529 Overloaded events across more than 13 days. That shows repeated failures in one person’s workflow. It is an event count, not a count of affected users or a measure of global traffic.

FAQ

Is 529 the same as a 429 rate limit?

No. Anthropic lists 529 as overloaded_error and 429 as rate_limit_error. If you have the API response, use its status and error type rather than the surrounding wording. A user may see both kinds of failure at different times, but a 529 alone does not establish that their account has reached a rate limit.

Does 529 mean my prompt is invalid?

The documented meaning is overload. If the prompt were invalid, you would expect a different response that names a request problem. Keep the prompt intact for a later attempt. If the same request then returns a different error, read that new message separately rather than treating it as another 529.

Should I keep retrying a long task?

First check whether the initial attempt produced any files, messages, or tool actions. Then allow limited retries with backoff, taking into account retries your SDK may have made already. If the task is expensive or changes an external system, stop after repeated failures and report the request IDs instead of leaving an uncontrolled loop running.

Sources