AI SDK Error Decoder
Paste any provider error and get the cause, fix checklist and correct retry strategy.
Anthropic's API is under heavy load and is shedding traffic. Your request was valid; capacity wasn't there. This is the most Anthropic-specific status code.
Likely causes (ranked)
- 1.Provider-wide demand spike (common at US working-hours peaks)
- 2.Burst of parallel requests from your side landing in a congested window
- 3.Large-context requests during constrained capacity
Fix checklist
- Retry with exponential backoff and jitter — most 529s clear in seconds
- Reduce parallelism temporarily (halve concurrent agents on first 529)
- Use the Batch API for non-interactive work; it queues instead of failing
- Consider a fallback model/provider path for hard availability requirements
Retry & backoff
Exponential backoff with full jitter: base 1s, ×2 per attempt, cap 32s, up to 6 attempts. Do not hammer — synchronized retries extend the overload.
Other possible matches:
How it works
Every AI provider speaks HTTP, but each one fails in its own dialect. Anthropic returns a JSON body with an error.type like overloaded_error; OpenAI distinguishes a true rate limit from an empty balance inside the same 429 status; Gemini wraps Google RPC status strings like RESOURCE_EXHAUSTED around its codes. This decoder embeds a dataset of the common failure modes across all three providers and fuzzy-matches whatever you paste — a bare status code, an SDK exception, or a full stack trace.
The matching is deliberately simple and fully local: it scores explicit status codes, provider names, the provider's own error type strings, and a set of distinctive message fragments, then ranks candidates. The top match renders as a decoded card with the meaning, the most likely causes in ranked order, a fix checklist you can work through top to bottom, and — critically — whether the error is retryable and with what backoff. When the match is ambiguous, the runners-up are listed so you can pick the right one yourself.
The retryability call is the part teams get wrong most. Retrying a 400 or 401 wastes time and can trip abuse detection; failing to retry a 529 turns a two-second capacity blip into a user-facing outage. The guidance here follows each vendor's documented SDK behavior: honor retry-after when present, exponential backoff with jitter when not, and a hard ceiling on attempts so a real outage fails fast instead of hanging your agent loop.
Every decoded error links to a full reference page with a copy-pasteable TypeScript handler showing correct backoff for that exact provider and code — useful when you want the fix in a pull request rather than a browser tab. The dataset covers roughly three dozen provider-and-code combinations across Anthropic, OpenAI and Gemini, weighted toward the errors that actually show up in agentic coding workloads: rate limits, overloads, context overflows and authentication misconfigurations.
One honest caveat: error messages drift as providers ship API changes, so a paste that matches nothing is not necessarily exotic — check the raw status code against the related reference pages, and trust the provider's own message field, which almost always names the offending parameter precisely.
Frequently asked questions
Which errors are retryable and which are not?
As a rule: 429, 500, 502, 503, 504 and Anthropic's 529 are retryable — they signal load or transient infrastructure trouble, and a backoff-and-retry usually succeeds. 400, 401, 403, 404, 413 and 422 are not retryable: they describe a problem with your request or configuration, so an identical retry returns an identical failure. The one famous trap is OpenAI's 429 with code insufficient_quota — it looks like a rate limit but means your balance is empty, and no amount of retrying fixes billing.
What is the right backoff timing for retries?
Start with the retry-after response header when the provider sends one — it is exact, not advisory. Otherwise use exponential backoff with full jitter: a 1 second base, doubling each attempt, capped around 32 seconds, with a random factor so your fleet's retries do not synchronize. Five to six attempts is a sensible ceiling for overload errors; for plain 500s give up after three and surface the request ID. Synchronized retry storms are a leading cause of extended provider overloads.
Could the error be caused by an outdated SDK version?
Yes, more often than people expect. Providers add parameters, rename fields and retire models; an old SDK can serialize requests that the current API rejects with a 400, or fail to parse new error shapes entirely. If you see validation errors on parameters that the documentation says are valid, check your SDK version first — upgrading @anthropic-ai/sdk, openai or @google/genai resolves a surprising share of mystery 400s, and official SDKs also ship correct default retry behavior.
Where do I check if the provider itself is down?
Each provider runs a public status page: status.anthropic.com for Anthropic, status.openai.com for OpenAI, and the Google Cloud status dashboard for Gemini. If you see a burst of 500/503/529 errors across multiple requests, check the status page before debugging your own code — during incidents the fastest fix is a fallback model or simply waiting out the spike. The decoded card above links the right status page for whichever provider matched your error.
Does this tool send my error logs anywhere?
No. The matching runs entirely in your browser against a dataset embedded in the page — there is no network request, no logging and no analytics on your pasted text. That matters because stack traces routinely contain file paths, internal hostnames and occasionally fragments of API keys. You can verify the privacy claim yourself: open devtools, watch the network tab, and paste anything — nothing leaves the tab.
Built by FORG — AI cost observability for agentic coding. Free tools, no signup, nothing leaves your browser.
Learn about FORG