Skip to content
Multigrid

Error Code Lookup

Paste an error body, a status line or a stack trace and get the likely cause, whether it is retryable, and what to change.

Everything on this page runs in your browser. Nothing you paste is uploaded, logged, or written into the URL — only the settings are, so a configured tool can still be linked to. Error bodies carry request ids and sometimes fragments of your prompt. This one stays here.

Retry this request?
no — it will fail the same way

Everything recognised here is a statement about the request itself. Change the request, not the timing.

HTTP 400HTTP status (RFC 9110)

Bad Request — the server could not process what you sent.

Usual cause:
A malformed body, an unknown parameter, a parameter of the wrong type, or a request that exceeds a documented limit. On an LLM API it is very often the context window: prompt plus max_tokens over the model's limit.
What to change:
Read the message and the param field; this is the one class of error where the body usually tells you exactly what is wrong.
Retryable:
No. The identical request will fail identically.
invalid_request_errorerror code (a cross-provider convention)

The request was rejected before any model ran.

Usual cause:
A parameter problem. The param field names it.
What to change:
Read param.
Retryable:
No.
context_length_exceedederror code (a cross-provider convention)

The prompt plus the requested output does not fit the model's context window.

Usual cause:
Usually conversation history that grew, a retrieved chunk set that grew, or tool schemas nobody counted.
What to change:
Count what you are actually sending, including the system prompt and every tool definition. Trim history or retrieve less before reaching for a bigger model.
Retryable:
No — identical request, identical failure.
The message the server sent
This model's maximum context length is 128000 tokens. However, your messages resulted in 131204 tokens. Please reduce the length of the messages.
  • passthere is a request id here — req_3a91ff20 — which is the one thing support can look up. Put it in the ticket and in your own logs
  • errorover the context window by 3,204 tokens — 131,204 sent against a limit of 128,000, which is 2.5% too much

    Expected: at most 128,000 tokens including the system prompt, the full history, every tool schema and the space reserved for the output. Trimming 3,204 tokens of history is the smallest change that fixes this

What this checked: this reads what you pasted and nothing else. It pulls out an HTTP status, error code strings, transport-level error names, a request id, a Retry-After and the human message, then explains the ones it has an entry for. The HTTP half is RFC 9110 semantics, which every server is supposed to follow. The error-code half is a convention rather than a standard: these strings recur across providers because the APIs copied one another, and your provider's own reference is the authority. A code this page does not know is reported as unknown — it never guesses a meaning from the name. It contacts nothing, knows nothing about your account, and cannot tell you whether the failure is happening to anyone else.
What this assumes: that a three-digit number between 100 and 599 in your text is an HTTP status when nothing is labelled more clearly, which is a guess and is shown as one — a token count of 429 in a message would be mistaken for a rate limit. Retry advice assumes the operation is safe to repeat; a request that has already produced output and been billed is not made un-billed by a retry, and a timeout is the case where you most often pay twice for one answer.

4xx and 5xx are two different jobs

A 4xx is a statement about the request you sent: retrying it unchanged is guaranteed to fail again, and a retry loop around one is a way of turning a bug into a bill. A 5xx is a statement about their infrastructure: the same request may well succeed a second later. The only awkward member is 429, which is a 4xx that is genuinely transient — which is why it needs its own branch in every client, and why lumping it in with 400 is a mistake people make once.

The error you cannot see

Most of the entries above are recognisable because the server told you something. The expensive failures are the ones where it did not: a stream that ends early with a valid-looking partial answer, a response that arrives after your own timeout so you retried and paid twice, a 200 carrying a refusal your code stores as the answer. None of those produce an error to paste anywhere. Catching them needs assertions on the shape of a successful response — a finish reason of stop, a non-empty content, a usage block that adds up — which is what makes the response inspector in this family the companion to this page rather than a duplicate of it.

The reasoning behind this

Related tools

Error Code Lookup · Multigrid