How to fix: context length exceeded / maximum context length
Last verified: June 2026· All LLM providers
Where this shows up
All LLM providers
How it shows up
The same root cause surfaces in a few different ways. If any of these match, you're in the right place.
- An error naming a token count that exceeds the model's maximum, usually including both your input and the room reserved for output.
- Failures that appear only for long-running conversations or large documents, while short requests succeed all day.
- An agent that worked fine for the first several steps and then fails partway through a task as its transcript accumulates.
- Sudden failures after a prompt change that added retrieved context, with no change in user behaviour.
Diagnose it first
Confirm which cause you actually have before changing anything — most wasted time here comes from fixing the wrong one.
| Check | What the result tells you |
|---|---|
| Count the tokens in the actual request with the target model's tokeniser. | Character or word estimates are unreliable, and differ between providers for identical text. Code, non-English text and structured output all split less efficiently than prose, often by a wide margin. |
| Break the count down by component: system prompt, retrieved context, conversation history, current message. | One component is almost always dominant, and it is rarely the one people assume. Retrieved context and accumulated tool output are the usual answers. |
Confirm whether max_tokens is reserved from the same budget. | The window covers input plus output. A large max_tokens reservation can push a request over the limit even when the prompt alone would have fitted comfortably. |
| Check whether the failure correlates with conversation length. | If it does, this is an accumulation problem and the fix is a truncation or compaction strategy rather than a bigger window. |
The fix
- 1Count tokens with the target model’s tokenizer — not a word count or another model’s tokenizer — to see how far over you are.
- 2Trim the input: remove redundant context, summarize long history, or retrieve only the most relevant chunks (RAG) instead of stuffing everything.
- 3Lower
max_tokensif you reserved more output room than you need — output counts against the window. - 4For long conversations, enable compaction or context editing so older turns are summarized or cleared automatically.
- 5If you genuinely need more room, switch to a model with a larger context window.
Provider-specific behaviour
The error means roughly the same thing everywhere, but each provider signals it differently.
- Input and output share the window
- The advertised context length is the total. Requesting a long completion reduces the room available for the prompt, so the practical input ceiling is lower than the headline figure by whatever you reserved for the answer.
- Tool results count
- In agent workflows, tool output is appended to the conversation and billed and counted like any other content. A verbose test run or a large file read can consume more of the window than the code being worked on.
What doesn't work
Common fixes for this error that look right and aren't.
Moving to a larger-context model and changing nothing else.
It buys headroom rather than fixing the accumulation, so the same failure returns later and costs more in the meantime, since you are paying for every token of a much larger prompt on every turn.
Truncating the oldest messages first.
The oldest message is usually the original task statement and the constraints, which is exactly what must survive. Naive truncation produces an agent that forgets what it was asked to do.
Summarising the entire conversation into one blob.
Summarisation blurs the specifics — file paths, identifiers, exact error strings — that the remaining work depends on. Keep decisions and drop the evidence that produced them, rather than averaging everything.
Prevent it
Design retrieval and compaction in from the start so requests stay well under the limit regardless of conversation length.
Common variations and related errors
You'll usually hit this same root cause under a few different names. Same fix.
- "context_length_exceeded"
- "maximum context length"
- "prompt is too long"
- "context window exceeded"
- "reduce the length of the messages"
- openai.InvalidRequestError: context_length_exceeded
- anthropic.InvalidRequestError: prompt is too long
Frequently asked questions
What causes “context length exceeded / maximum context length”?
The prompt plus requested output exceeds the model’s context window (measured in tokens).
How do I prevent “context length exceeded / maximum context length” from recurring?
Design retrieval and compaction in from the start so requests stay well under the limit regardless of conversation length.
What actually counts toward the context limit?
Everything in the request plus the space reserved for the response: the system prompt, every message in the conversation so far, any retrieved documents, the results of every tool call, and your `max_tokens` reservation. In agent workflows tool output is usually the largest and least-noticed component — a verbose test run can be bigger than the source file being repaired.
How should I trim a conversation that has grown too long?
Keep the original task and constraints, keep the decisions and conclusions the run has reached, and discard the raw evidence that produced them. A compacted state written that way is frequently a few hundred tokens and loses almost nothing operationally. Also cap tool output at the source — return the head and tail of a long run rather than all of it — which shrinks the problem before compaction is needed.
Will a larger context window solve this?
It raises the ceiling and does not change the trajectory. Input tokens bill on every turn and an agent re-sends its accumulated context each step, so an unmanaged loop in a larger window simply costs more before it fails. A model's ability to use a specific fact also degrades as competing material grows, so a filled large window is not equivalent to a well-curated small one.