AI API Errors Explained: 429, 500, 503 and 529
AnyRouter4 min read
TL;DR
A 429 means you are sending too much or have run out of quota. A 500, 503 or 529 means the provider has a problem. Retry the second group with exponential backoff, and move to another provider if retries do not help. Do not retry 400, 401, 403 or 404, because the same request will fail the same way.
What do AI API status codes mean?
| Status | Meaning | Your fault? | Safe to retry? |
|---|---|---|---|
400 | The request is invalid | Yes | No |
401 | The key is missing or wrong | Yes | No |
403 | The key is not allowed to do this | Yes | No |
404 | The model or path does not exist | Yes | No |
429 | Rate limit or quota reached | Usually | After waiting |
500 | Provider internal error | No | Yes |
503 | Provider temporarily unavailable | No | Yes |
529 | Anthropic API overloaded | No | Yes |
What does 429 mean?
A 429 is about your account, not the provider's health. There are two different cases, and they need different fixes.
Rate limit. You sent too many requests or tokens in a short window. Wait and retry. If the response has a Retry-After header, use its value instead of guessing.
Quota exhausted. On OpenAI this shows up as insufficient_quota. Retrying cannot fix it, because the account is out of credit. Add credit or raise the limit.
Read the error body before you add a retry. Code that treats every 429 the same way will spin on a quota error forever.
What does 529 mean?
529 with overloaded_error is an Anthropic status. It means the API is short of capacity across all users, so your key and your request are fine. Overloads are usually short, which is why a retry with backoff fixes most of them.
What do 500 and 503 mean?
A 500 is an unexpected failure on the provider side. A 503 means the service cannot take the request right now. Both are worth retrying. If they continue, check the status page of the provider, because the cause is outside your code.
How do you retry safely?
Use exponential backoff with jitter. The growing delay gives the provider room to recover, and the random part stops many clients from retrying at the same moment.
import randomimport time import openai RETRYABLE = (openai.RateLimitError, openai.InternalServerError, openai.APIConnectionError) def call_with_backoff(make_request, attempts=5): for attempt in range(attempts): try: return make_request() except RETRYABLE: if attempt == attempts - 1: raise time.sleep(min(30, 2**attempt) + random.random())Set a limit on attempts and on total time. A user waiting on a chat reply would rather see an error after 20 seconds than a spinner for two minutes. Official SDKs also retry by themselves, so check the default before you wrap them, or the two layers will multiply each other.
Streaming needs one more rule. It is only safe to retry before the first byte has reached your user. After that, a retry would repeat text that is already on the screen.
When should you fail over to another provider?
Retries help with short failures. They do not help when one provider is down for an hour. Failover sends the request to another upstream that serves the same model, and the usual triggers are:
- Connection failures and timeouts before the first byte.
- Repeated
5xxor529responses from one upstream. - A
429on one upstream key while others still have room.
An AI API gateway can do this for you. AnyRouter turns off SDK retries on its outbound calls and handles failover itself. It stops sending traffic to an upstream for a cooldown period after repeated failures, and it only switches a stream before the first byte, so you never get a duplicated reply.
Frequently asked questions
Is a 529 error my fault?
No. A 529 means the provider is overloaded. Your key, plan and request are fine, and the same request usually works a few seconds later.
What is the difference between 429 and 529?
A 429 is caused by your own usage or quota. A 529 is caused by total demand on the provider. Slowing down helps with a 429, while a 529 needs a short wait or another provider.
Should I retry a 400 error?
No. A 400 means the request itself is wrong, so it will fail again. Fix the request. A common cause is a context that is longer than the model allows.
Next steps
- See how failover and routing fit together.
- Check the request FAQ for gateway-specific errors.