Figures on this page were verified 31 August 2026 against the providers' own documentation. Pricing, context windows and rate limits change without notice, so confirm any number against the provider before you rely on it. Tell us if something here is out of date.
Most LLM API failures come down to one question: is this error mine, or the provider’s? Get that right and the handling follows automatically. Errors that are yours are deterministic and must never be retried. Errors that are the provider’s are transient and should be retried with backoff and jitter. Almost every bad integration we see gets this boundary wrong in one direction or the other.
This is a working reference for the errors you will actually hit, with the cause, the fix, and runnable code for each. Every figure is checked against the provider’s own documentation and carries the date it was verified.
The decision table
If you implement nothing else from this page, implement this. It is the whole of correct error handling for these APIs.
| Status | Error | Whose fault | Retry? |
|---|---|---|---|
| 400 | context_length_exceeded | Yours | Never. Shrink the request |
| 400 | Malformed request | Yours | Never |
| 401 | invalid_api_key / authentication_error | Yours | Never |
| 429 | rate_limit_exceeded / rate_limit_error | Yours (pacing) | Yes, with backoff |
| 429 | insufficient_quota | Yours (billing) | Never. Add credit |
| 400 | Tool arguments will not parse | Usually yours | Once, returning the error |
| 413 | Image or payload too large | Yours | Never. Resize first |
| – | Stream closed mid-response | Usually infrastructure | Yes, after fixing timeouts |
| 500 | Internal server error | Provider | Yes, cautiously |
| 503 | Service unavailable | Provider | Yes |
| 529 | overloaded_error | Provider | Yes |
The errors
context_length_exceeded
Your prompt plus the output you reserved is larger than the model’s context window. Covers the arithmetic, five fixes ordered by what they cost you, and a verified table of current context limits for Claude and GPT models.
429: rate limits and quota errors
Two completely different failures share one status code. Covers how to tell them apart, which rate-limit axis you are actually hitting, the response headers that tell you when to retry, and backoff with jitter.
401: invalid API key
Almost never a wrong key. Five mechanical causes in order of likelihood, the header differences between providers, and a one-line diagnostic that settles it.
529: overloaded_error
Not your fault and nothing in the request to fix. Covers retrying without worsening the outage, capping total latency rather than attempt count, and designing so saturation is survivable.
Response cut off (stop_reason: max_tokens)
Not an error at all. The call returns HTTP 200 with a stop reason saying the output ceiling was hit, so code that only checks for exceptions never notices the reply is incomplete.
Model returned invalid JSON
Usually the JSON is not invalid, it is incomplete or wrapped in prose. Covers the three causes and why constrained output beats regex repair.
429 insufficient_quota
The 429 that is not a rate limit. Your account has no usable credit or has hit a spending cap, so backoff will never clear it. Covers how to branch on it before your retry logic sees it, and the four causes.
Tool call arguments that will not parse
Almost always truncation, a permissive schema, or parsing a stream before it finished. Covers how to tell which, and why constraining the schema beats rewording the prompt.
Streaming connection closed mid-response
Usually a proxy or platform timeout rather than the model. Covers how to spot an incomplete stream that raised no exception, which timeouts to change, and when resuming beats restarting.
Image payload too large
Two different failures that look alike: too many bytes in the request, or too many tokens in the window. Covers how to tell them apart, what size to resize to, and how to budget images like text.
Three rules that prevent most of them
- Catch specific exceptions, not a broad parent. A single
exceptaround every API call turns a permanent 400 into an infinite loop. Every SDK ships typed exception classes. Use them. - Measure before you send. Counting tokens locally converts a failed billable request into a branch in your code.
- Budget total time, not attempts. Five retries with exponential backoff is over thirty seconds of sleeping. Decide the latency you can afford first, then derive the attempt count.
Related tools
Token volume drives both your rate limits and your bill. The LLM API cost calculator prices any token workload across every major model and ranks them cheapest first, so you can see what trimming a prompt is actually worth. The context budget planner does the same for the context window, showing where a conversation will break.
How we source and verify everything here is set out in our editorial standards.
Frequently asked questions
Is an LLM API error my fault or the provider's?
The HTTP status tells you. A 4xx means your request: a bad key, too many tokens, a malformed body, or requests sent too fast. Retrying it unchanged will fail identically. A 5xx, including Anthropic's 529, means the provider is failing or saturated, and is usually safe to retry with backoff.
Which LLM API errors are safe to retry?
429 rate_limit_error, 500, 502, 503 and 529 overloaded_error are retryable with exponential backoff and jitter. 400, 401, 403 and 404 are not, because they will fail the same way until you change the request. The trap is insufficient_quota, which arrives as a 429 but means billing rather than pace, so retrying never succeeds.
Why does the same failure have different names on OpenAI and Anthropic?
The two APIs use different error taxonomies. OpenAI returns a JSON body with an error.type such as invalid_request_error or insufficient_quota; Anthropic returns type values such as rate_limit_error or overloaded_error. Branch on the HTTP status first, because it is the one signal that means the same thing on both.