Context Window Exceeded: The Same Error Returns 400, 429, and 403 Depending on Provider

Your prompt got too long. Every provider rejects it. They do not agree on how.

We sent an identical ~220,000-token payload to four providers and recorded exactly what came back. The differences matter more than you'd expect, because one of them will make a naive retry loop run forever.

What each provider returns

Three different status codes for the same mistake.

Anthropic gets this right

HTTP 400  invalid_request_error
prompt is too long: 220024 tokens > 200000 maximum

A 4xx that says it's your request, the exact token count, and the exact limit. You can compute how much to trim from the error message alone. This is the behaviour to expect from everyone and don't.

OpenAI's 429 is a trap

HTTP 429  "Request too large for gpt-3.5-turbo in organization org-…"

429 means rate limited. Every HTTP client, SDK and retry wrapper treats it as transient and retries with backoff. The Anthropic and OpenAI SDKs both retry 429 automatically by default.

But an oversized prompt is not transient. It will be exactly as oversized on the next attempt. So a standard retry policy turns one bad request into a backoff loop that burns your rate limit and never succeeds.

The reason is that OpenAI accounts for oversized requests through the same tokens-per-minute machinery as rate limiting — a request bigger than your TPM allowance is "too large," whether that's because your prompt exceeds the model's window or because you're over quota. Same code, two very different causes, and only one is worth retrying.

Mitigation: inspect the message before retrying. If it contains Request too large, treat it as a 400 and fail fast.

if (status === 429 && /request too large/i.test(message)) {
  throw new NonRetryableError(message);   // do not back off — it will never fit
}

Groq's 403 tells you nothing

HTTP 403  error code: 1010

That's an edge-layer rejection, not an API error — no JSON body, no error type, no mention of tokens or limits. Nothing in that response indicates the problem is prompt size. If you're debugging blind, 403 / 1010 reads like an authentication or permissions failure, and you'll go check your API key first.

Mitigation: count tokens client-side before sending to any provider whose errors you can't parse.

Prevention, in order of usefulness

1. Count before you send. Providers expose token counting — Anthropic's count_tokens, OpenAI's usage estimates — and it's cheap. For the rest, approximate at ~4 characters per token and leave headroom.

2. Budget the whole request, not just the prompt. The window covers system prompt + conversation history + tools + the current message + the reserved output. A long tool schema quietly eats context. On reasoning models, max_tokens also covers thinking tokens — which is its own failure mode.

3. Truncate deliberately, not accidentally. If you must trim, decide what to drop — oldest turns, least-relevant retrieved chunks — rather than cutting the string. A naive slice() can sever a JSON payload mid-object and turn an oversize error into a parsing bug.

4. Watch conversation growth. Multi-turn chat grows until it hits the wall. Compaction and context-editing features exist for this; the cheap version is capping history length and summarizing what falls off.

5. Classify errors by message, not just status. The whole lesson of the table above. Status code alone cannot distinguish "too large" from "too many requests" on OpenAI, or "prompt too long" from "bad credentials" on Groq.

The general point

Provider error surfaces are not standardised, and the differences are largest exactly where you least want ambiguity. If you're building multi-provider, you need a normalisation layer that maps each provider's idiom onto one internal taxonomy — and the mapping has to read the message body, not just the status.

Assume every provider will express the same failure differently, and test that assumption with real oversized requests rather than trusting the docs.

Try it yourself

• Run a prompt and see the token counts — no account, no API key

To compare error handling across providers on your own prompts, that's Promptster.

Measured 2026-08-11 with an identical ~220,000-token payload sent to each provider. Anthropic tested on claude-haiku-4-5 (200k window), OpenAI on gpt-3.5-turbo (16k), Groq on llama-3.1-8b-instant (128k), Google on gemini-2.5-flash-lite (1M — the payload fit, so no error was produced). Status codes and messages are quoted verbatim. Provider behaviour changes; re-verify before relying on this table.