LLM API error reference

This page lists the errors an LLM API can answer with, in two kinds of row. Provider rows are the errors Anthropic, OpenAI and Gemini document. Salyro rows are the codes Salyro's own API and Behaviors answer with. Each row gives the HTTP status, what the error means and whether to retry it. It also says what to fix and what a Salyro caller receives in the error's place.

The Retry column reads Yes, Not as it is, Depends or Unknown. Not as it is means the same request will fail again until its cause changes. Depends means the answer rests on what the provider reported, as the Errors page says of a normalised provider error. Unknown means the source does not say. OpenAI's rows say what its SDK does instead: SDK retries by default or SDK does not retry.

Where the rows come from

Provider rows quote each provider's own page or schema, and the Source column gives the page and the day it was read.

• Anthropic: its errors page on platform.claude.com, which gives each error.type its status, meaning and fix.
• OpenAI: the error table and retry rules of its Python SDK's README on GitHub, by HTTP status. What each type and code in an OpenAI error body means is unknown. Its Retry cells say what the SDK does with the status by default, not that the error will clear. The SDK retries an insufficient_quota 429 like any other 429.
• Gemini: the canonical google.rpc.Code definitions on GitHub, whose names a Gemini error's error.status carries. They are Google's general meanings, not the Gemini API's own.

Salyro rows come from Salyro's contract in its shared code, the definitions the gateway answers with. They give each code's family and status. A Public API code also has a default message: the sentence Salyro writes when nothing more specific was written. A Behavior code's message is written where the error is raised. The Errors page explains the families.

The Through Salyro column is the gateway's own mapping from the HTTP status that reaches it to a Salyro code. Whether a provider's own status reaches Salyro unchanged depends on Salyro's routing layer, which this page does not claim. So each cell says what Salyro answers when that status reaches it. The mapping reads only the status. A provider's error body never reaches a Salyro caller, so its type and message do not change the answer.

When a failure comes after Salyro's stream has started, the 200 has already been sent. Salyro then writes one error frame instead. It carries the code the same status would have had when the failure reports a status. It is provider_timeout when Salyro's own clock ran out, and provider_error when the provider failed with no status, closed the connection or sent a malformed stream. The Salyro rows list these ways each code is sent, among others.

The LLM error decoder reads the same facts. Paste an error into it to see which row it is.

How often it is checked

Every provider fact has the day it was read. Each is due to be read again 90 days later, and Salyro's data report lists every fact with its re-check date. A fact past its date is flagged, not removed. Who re-reads the pages, and whether 90 days is the right interval, is still an open decision. Salyro's own rows change only when Salyro's code does, and the table is rebuilt from the data every time the site is built. Nothing in it is typed by hand.

What it does not know

• xAI's errors. Its page could not be read, so its row says unknown.
• OpenAI's error types and codes, such as insufficient_quota. Its error-codes guide could not be read, so only the SDK's status table is here, and What to fix is unknown.
• What an error means for the Gemini API in particular, such as which quota a RESOURCE_EXHAUSTED is. Gemini's troubleshooting page could not be read, so its rows give the general definitions, and most say unknown about retrying.
• Errors documented after the day shown.

Search by code or meaning, filter by source or retry verdict, sort by any column, and download the rows you see as CSV. Each row has its own link: select the error.