Context Rot: Why More Tokens Doesn't Mean Better Answers
It's tempting to think that sending Claude more information can only help, since the model can simply ignore whatever isn't relevant.
//
Search across all documentation pages
It's tempting to think that sending Claude more information can only help, since the model can simply ignore whatever isn't relevant.
In practice, padding a prompt with unnecessary or irrelevant material tends to degrade answer quality, not just waste tokens.
This effect has a name worth knowing: context rot.
Understanding it changes how you think about context engineering, from "cut context to save money" to "cut context because it also produces better answers."
A useful starting assumption, and a wrong one, is that a language model reads a prompt the way a search index does: it finds the relevant part and ignores the rest at no cost.
Context rot describes the observed pattern that this isn't quite true.
As a prompt fills with material that isn't relevant to the actual question, the model's answers can get less accurate, less focused, or more prone to picking up irrelevant details as if they mattered.
A simple analogy: imagine being asked a question in a noisy room versus a quiet one.
You can still hear the question in both cases, but your attention and accuracy are not identical, even though the words spoken to you were the same.
A prompt with a lot of irrelevant material is the noisy room.
# Same question, two prompts. The second buries the relevant line in noise.
focused_prompt = "What does validate_email() return for 'a@b'? \n\ndef validate_email(s): return '@' in s and '.' in s.split('@')[-1]"
noisy_prompt = f"{unrelated_500_line_file}\n\nWhat does validate_email() return for 'a@b'?"Both prompts contain the information needed to answer correctly.
Only one of them makes that information easy to find.
Context rot interacts with a few different aspects of how a model processes a prompt.
Signal-to-noise ratio is the simplest framing: if the relevant information is a small fraction of the total prompt, the model has to do more work distinguishing what matters from what doesn't, and that work is not guaranteed to be error-free.
Attention dilution is the related idea that a model's effective focus is spread across everything in the prompt, so a prompt dominated by irrelevant material leaves comparatively less capacity for the part that actually answers the question.
Distractor content is a specific failure mode: irrelevant material that happens to resemble the right answer, a similarly-named variable, a superficially related fact, can actively mislead the model rather than simply being ignored.
This is why context rot is not simply "wasted tokens."
Wasted tokens cost money but don't necessarily change the answer.
Context rot changes the answer, in either direction, sometimes for the worse, purely because of what else was in the prompt.
# A distractor: a same-named function elsewhere in the file that isn't the one being asked about.
distractor_prompt = """
def validate_email(s): # in module `legacy`, deprecated, different logic
return len(s) > 0
def validate_email(s): # in module `current`, the one actually asked about
return "@" in s and "." in s.split("@")[-1]
Which validate_email is used by the current signup flow?
"""A model reading this has to correctly determine which definition is relevant, a task made harder by including the deprecated one at all if it isn't actually needed to answer the question.
Context rot has a direct implication for how teams should think about context window growth.
As models support ever-larger context windows, it's tempting to treat "it fits" as equivalent to "it should be included."
Context rot is the argument against that equivalence: a larger window changes what's possible to send, not what's advisable to send.
The practical response is the same set of techniques covered throughout this section, applied for a second reason beyond cost.
Minimal-context prompting keeps the signal-to-noise ratio high by construction, since only relevant material is ever included.
Summarization reduces bulk while, done well, preserving the signal that matters, which can improve signal-to-noise even for material that can't be dropped entirely.
Dependency-graph trimming applies the same idea to code, using the graph's structure rather than manual judgment to decide what's actually relevant.
| Approach | Effect on Cost | Effect on Quality |
|---|---|---|
| Send everything "just in case" | Higher, scales with total material | Risk of dilution and distractor effects |
| Minimal-context prompting | Lower, scales with relevant material only | Generally improves focus, if selection is accurate |
| Summarization | Lower for reused documents | Depends on summary quality; can lose fine detail |
| No trimming, but a larger context window | Higher | Not solved by window size alone; rot is about relevance, not capacity |
It's worth being precise about what context rot does not mean.
It doesn't mean short prompts are always better than long ones, or that every long document is harmful to include.
It means relevance, not length, is the variable that matters, and that length without relevance carries a real cost on both sides of the ledger.
The tendency for irrelevant or excessive material in a prompt to degrade the quality of the model's answer, beyond simply costing more tokens.
No.
Not exactly; length isn't the variable that matters on its own, relevance is.
A long prompt made entirely of relevant material doesn't necessarily suffer from context rot the way a short prompt padded with irrelevant material can.
Irrelevant material that happens to superficially resemble the correct answer, such as a same-named variable defined twice, which can actively mislead the model rather than simply being ignored.
No, a larger window only changes how much can technically fit.
It doesn't change whether irrelevant material dilutes focus or introduces distractors once it's included.
Minimal-context prompting is the direct countermeasure: by including only relevant snippets, it keeps signal-to-noise high by construction, which addresses context rot and reduces cost at the same time.
Yes.
It can, when the summary preserves the relevant signal while dropping bulk that wasn't adding anything.
A poor summary that drops the actually-relevant detail replaces one problem with another, so summary quality still matters.
No, it applies to any prompt: a support ticket padded with unrelated account history, a legal question buried in an entire contract, or a customer question surrounded by unrelated prior conversation turns.
Those are separate levers.
Treat "should I include this" as a real question with a real cost on both sides, rather than defaulting to "more context can only help."
Stack versions: Written against the Claude model lineup current as of ~June 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (the default), and Claude Haiku 4.5 - and the official
anthropicPython SDK (latest 0.x release). Model names, pricing, and SDK versions move quickly - verify current specifics at platform.claude.com/docs before relying on them.
Reviewed by Chris St. John·Last updated Jul 16, 2026