Context Length Exceeded
Three disguises — the last one is the hardest to catch
Exceeding the context window shows up three ways: an explicit 400, a silent truncation, or an outer 200 with an empty stream — the third is the one most often misdiagnosed as something else.
Four key facts
Explicit error (easiest to catch)
The error body literally contains context_length_exceeded or maximum context length — the cause is obvious.
Part of your input quietly gets cut
Some clients/gateways auto-drop the earliest messages when nearing the limit instead of erroring — the model sees less context than you think, and output starts looking like it 'forgot' things.
The hardest one to catch
HTTP status is a clean 200, but the streaming connection ends immediately with zero tokens — easy to misdiagnose as a network blip or client bug.
The actual fix
Chunking long context, summarizing or using retrieval-augmented generation (RAG), or switching to a model with a larger context window — these fix all three disguises at the root.
What each disguise actually looks like
First, an explicit 400: the response body literally contains context_length_exceeded or maximum context length, the whole request is rejected — easiest to locate. Second, silent truncation: some SDKs, proxy layers, or history-management logic auto-drop the earliest messages when nearing the limit instead of raising an error — the model still responds normally, but because it can't see the dropped context, output starts looking like it 'forgot' earlier turns or contradicts itself. Third, an outer 200 with an empty stream: HTTP-level everything looks fine, status 200, but the streaming connection ends immediately after opening with zero tokens output — this is most often misdiagnosed as network jitter, a timeout, or a client parsing bug, when the real cause is usually that the request already exceeded the context window and failed server-side before streaming even started, just without a 400 error body propagated into the streaming protocol.
Why this is showing up more often lately
As agentic/sub-agent workflows spread, it's increasingly common to stuff an entire codebase, full conversation history, and multiple rounds of tool-call results into a single request, which sharply raises the odds of exceeding the context window. Different clients and gateways also handle overflow inconsistently — some error, some silently truncate, some go empty-stream — which makes diagnosis harder.
Timeline
context_length_exceeded is a long-standing standard error type across major model APIs, as old as the concept of a context window itself.
Agentic/sub-agent workflows significantly increase the context volume packed into a single request, raising how often the limit gets hit.
The hardest-to-catch 'outer 200, empty stream' disguise is showing up more in fully agentic workflows and is the most commonly misdiagnosed case.
Confirmed vs. common misreading
Confirmed
All three disguises (explicit 400, silent truncation, outer-200 empty stream) are documented across public developer discussion and various SDK/gateway implementations; the root cause is always the same — request content (history, tool-call results, system prompt) exceeding the model's context window.
Common misreading
Many people's first instinct on hitting an empty stream is to suspect network or client issues and repeatedly retry or switch networks — if the real cause is context overflow, none of that helps, it just wastes debugging time.
How to quickly tell if this is the cause
Check request size first
Count the actual token count this request carries (system prompt + history + tool-call results + new input) and compare it to the model's stated context window — near or over the limit is a strong signal.
Then check the response shape
An explicit 400 confirms it directly; silent truncation shows up as the model 'forgetting' things; an outer-200 empty stream shows up as the streaming connection ending with zero tokens almost immediately, not as a timeout.
Steps to locate and fix it
Step 1: estimate this request's total token count (using an official tokenizer or a third-party estimator) and compare it against the model's context window. Step 2: if it's near or over the limit, the priority isn't retrying — it's trimming the input: summarize/compress history, keep only the most recent turns, or switch to retrieval-augmented generation (RAG) that pulls only relevant snippets instead of the whole history. Step 3: if the task genuinely needs long context, consider switching to a model tier with a larger context window. Step 4: for the 'outer 200, empty stream' case specifically, add a dedicated check — if the streaming connection opens and no tokens arrive within a short window, treat it as an overflow, not a plain network timeout to retry.
What to do on QCode
QCode's model lineup includes families with different context window sizes; the same key lets you switch to a larger-context model tier based on task size, without applying for or configuring anything extra for long context.
FAQ
How do I know if I've hit this issue?
First count this request's total token count and compare it to the model's stated context window; if it's near or over the limit and the response is an explicit 400, contradictory/forgetful output (suspected truncation), or a streaming response ending with zero tokens, that confirms it.
Why doesn't silent truncation raise an error?
It's fault-tolerance logic some clients/gateways implement themselves — when overflow is detected, they choose to drop the earliest messages rather than fail the whole request, to make the conversation 'appear' to continue, at the cost of the model losing the dropped context.
Is an outer 200 with an empty stream a network issue?
Usually not. The common root cause is the request already failed server-side due to overflow, but the underlying system didn't propagate a standard 400 error body into the streaming protocol, so the client sees 'connection succeeded, but no content.' Retrying the same oversized request will most likely produce another empty stream.
How do I estimate how many tokens a request actually used?
Count the system prompt, full message history, tool-call results, and new input together, using an official tokenizer or a third-party estimator; agentic/sub-agent scenarios are especially easy to underestimate, since each tool-call round's results get stuffed back into the next request.
Does switching to a bigger-context model solve this permanently?
It helps but isn't unlimited — a larger context window usually costs more per request, and even the largest window has a ceiling. The more robust approach is trimming input at the same time (summarization, RAG), treating window size as headroom rather than the only dependency.
Is this the same kind of thing as 429/529 errors?
No. 429/529 are rate or capacity issues unrelated to request content size; context_length_exceeded means the request content itself exceeds what the model can process — slowing down or backing off won't fix it.
Sources
The three disguises are compiled from public developer discussion and the standard error-type descriptions across model APIs; this page doesn't assert claims about any single vendor's private implementation details, only cross-vendor patterns and how to tell them apart. Compiled 2026-08-27.
Don't let context overflow slow down delivery
One QCode key switches to a larger-context model tier based on task size.
Related reading
Four causes of a stream closing before completion
Another commonly misdiagnosed streaming failure — a useful comparison.
The complete long-context coding guide
How to systematically manage long-context tasks.
Claude 529 vs 429 vs Weekly Limit
Another set of easily-confused errors, told apart.
This page is general cross-vendor technical explanation and makes no claims about any single vendor's private implementation. Actual behavior is governed by the specific model and client you use.