TokenPad

12 errors

LLM API errors, explained properly

The failures that break a build at four in the afternoon. Each page carries the verbatim message, the causes ranked by how often they are actually the cause, a numbered fix, and the tool that stops it recurring.

How these pages are organised

Every page opens with the exact message, because that is what you pasted into a search box and that is what you need to recognise before reading anything else. Several providers word the same failure differently, so where that happens both are shown.

Causes are ranked by how often they turn out to be the cause, not by how interesting they are. The first one listed is the one to check first, and on most of these pages it accounts for the majority of cases.

The fix is a numbered procedure, and each step links to whichever of the 102 tools does that step — measuring a request, sizing a ceiling, validating a payload. The last section is about prevention, because an error you fix twice is an error you have not fixed.

Two things worth knowing before you start

A 429 is two different errors. A rate limit means you sent too much too fast and should retry with backoff. An insufficient quota means you have run out of credit and retrying will never help. They share a status code and need opposite handling, which is why they have separate pages.

Some failures are not errors. A truncated response and a refusal both arrive as successful requests. If your code only branches on exceptions, it treats both as valid answers and shows them to a user — which is how a cut-off sentence reaches production with nothing in the logs.