Anthropic or Gemini API 429 and overloaded errors

What it means in plain English

The model provider refused the request because of volume, spend, or load. Your app code did not get a completion. Anthropic and Gemini use different names for that refusal, so read the status and the error type before you change billing or add retries.

Likely causes

• Anthropic 429 with type rate_limit_error. The errors guide says this is a rate limit, the usage tier's monthly spend cap, or a spend limit on the Claude Code workspace. A spend-cap 429 has no retry-after header and keeps failing until access resumes.
• Anthropic 529 with type overloaded_error. The API is temporarily overloaded. Anthropic says this happens when traffic is high across users.
• A sharp jump in Anthropic traffic. Anthropic says that can surface as a 429 from acceleration limits, and the way they name to avoid it is to ramp traffic gradually.
• Gemini 429 with status RESOURCE_EXHAUSTED. Gemini's rate-limit guide says you hit a limit if you exceed any of requests per minute (RPM), input tokens per minute (TPM), or requests per day (RPD). Limits are per project, not per API key. RPD resets at midnight Pacific time. Their example: an RPM limit of 20 means the 21st request in that minute errors even if TPM is fine.
• Gemini also returns 429 RESOURCE_EXHAUSTED for a spend-based limit on a rolling 10-minute window, for accounts where that limit applies. Gemini's troubleshooting page pairs 429 RESOURCE_EXHAUSTED with 503 UNAVAILABLE as responses you should retry.
• The key is in the browser, so anyone can spend the quota. See Anthropic API key in front-end code. The OpenAI version of a 429 is OpenAI API 429.

How to fix it, step by step

1. Read the status and the error type in the server log. Do not treat a Claude 529 and a Gemini 429 as the same billing problem.
2. For an Anthropic spend-cap 429 with no retry-after header, stop retrying. Anthropic says it keeps failing until access resumes. Check the spend cap in the Claude console.
3. For other Anthropic 429s and for 529, retry with backoff. The official SDK retries connection errors, rate limits, and 5xx errors twice by default, and it honors retry-after when that header is present. max_retries changes that.
4. For Gemini 429 or 503, use exponential backoff and add jitter. Gemini says the official SDKs already retry timeouts, network errors, and rate limits. The Python SDK, as documented, retries up to four times, starting around 1 second and capping at 60 seconds. Do not copy those Python numbers onto a different SDK unless that SDK's docs say the same thing. Gemini says not to retry a 400.
5. If Gemini's 429 is the spend window, wait and send cheaper requests, or request a limit increase from Google. Sending the same prompt in a tight loop will hit RPM again.
6. Keep the provider key in a server environment variable. One call per user action, not a call from a React render.
7. Paste this to the AI tool:

Model calls fail with Anthropic 429 rate_limit_error, Anthropic 529 overloaded_error, or Gemini 429 RESOURCE_EXHAUSTED. Retry transient 429 and 5xx responses with exponential backoff and jitter, and honor retry-after when it is present. If an Anthropic 429 has no retry-after header, do not retry; surface a spend-cap message. Call the provider from the server only. Do not put the API key in client code or in a VITE_ or NEXT_PUBLIC_ variable. Do not call the model inside render.

How to check it worked

• A single user action produces one provider request, then a completion or a clear message to wait.
• Logs no longer show a burst of identical 429s from a render loop.
• The deployed JavaScript does not contain the provider key.

Sources

• https://docs.anthropic.com/en/api/errors (opens in a new tab)
• https://ai.google.dev/gemini-api/docs/troubleshooting (opens in a new tab)
• https://ai.google.dev/gemini-api/docs/rate-limits (opens in a new tab)