In this article
What Is Context Rot?
Context rot is the gradual degradation of an AI assistant's answer quality during a long session. The longer you work, the more the context window fills with irrelevant material from earlier turns — and the less attention the model can pay to what actually matters right now.
The term "context rot" describes two related phenomena:
- Qualitative rot — answer accuracy drops as the session ages. The model starts missing errors, confusing similar files, and confidently generating wrong fixes.
- Economic rot — token costs compound because every request re-sends the entire bloated conversation history, including the irrelevant parts.
🔬 Research backing: The "Lost in the Middle" paper (Liu et al., 2023) showed LLMs perform significantly worse at retrieving information placed in the middle of long contexts — even when that information is explicitly relevant. Context rot exploits this vulnerability systematically.
Why It Happens: The Physics of Attention
Transformer-based LLMs process context using attention mechanisms. Every token attends to every other token — but not equally. The model's attention is distributed across all input tokens, and it has a finite budget of attention to spend.
As a session grows, the context window fills with:
| Content type | Relevance to current query | Token cost |
|---|---|---|
| Early conversation turns | ❌ Usually stale | High |
| Imported dependency files | ⚠️ Partially relevant | Very high |
| Shell command output logs | ❌ Usually irrelevant | Medium–High |
| Duplicate file reads | ❌ Redundant | High |
| The actual bug / the critical file | ✅ Critical | Low — crowded out |
The critical file — the one with the actual bug — gets pushed toward the middle of the context window where attention is weakest. The model sees it, but pays it less weight than the stale import logs at the beginning and the recent conversation at the end.
Result: the model answers based on the wrong evidence.
The 4 Stages of Context Rot
Context window is mostly empty. The model sees exactly what you show it. Answers are specific, accurate, and grounded in the actual code. Token costs are low.
30–40% of context used. Previous conversation turns, imported files, and command outputs start accumulating. The model occasionally confuses variable names across files. You chalk it up to a bad prompt.
60–80% of context used. Attention is diluted. The model starts referencing the wrong function, misidentifying which file contains the bug, or suggesting fixes for code it already fixed. You start restarting sessions.
Context window full. The tool either truncates early history (losing critical decisions) or hits a hard limit and forces a new session. Answers become generic. Hallucinations spike. You've lost the context of 2 hours of work.
How to Recognize Context Rot in Your Sessions
Context rot is insidious because it happens gradually. Here are the specific symptoms to watch for:
🔴 High-confidence wrong answers
The model generates a fix with total confidence — but the fix references a function signature that doesn't match your codebase. It's confusing code from an earlier file read with the current one. This is the hallmark of attention dilution.
🔴 "I don't see that in the code you shared"
The critical file was sent 20 turns ago and is now buried in the middle of the context. The model's attention has moved on. Even though the file is technically in the window, the model doesn't properly weight it.
🔴 Repetitive suggestions
The model keeps suggesting the same fix you already tried. It's not learning from your "that didn't work" responses because those responses are now in the crowded middle of the context.
🔴 Generic, non-specific answers
Instead of referencing your actual class names and function signatures, the model gives boilerplate code with placeholder names. It's generating from its training distribution, not from your context — because your context is too diluted to extract specific details from.
🔴 Autocompaction events (Claude Code)
Claude Code's automatic context compaction is a symptom of context rot, not the cure. Compaction truncates history, but it doesn't select the right history to keep — it just keeps recent content, which may not be the most relevant.
The Hidden Cost: It's Not Just Quality
Context rot has a direct financial cost. Every request in a long session re-sends the entire context — including all the irrelevant material.
A typical 3-hour Cursor session: Fresh start context: ~2,000 tokens → $0.006/request Session turn 50: ~80,000 tokens → $0.24/request Session turn 100: ~180,000 tokens → $0.54/request Developer doing 60+ requests/day at stage 3: Daily token cost: ~$14–32 Monthly cost: ~$350–800 With properly selected context (2,000 relevant tokens/request): Daily token cost: ~$0.36–0.72 Monthly cost: ~$9–18
⚠️ You are paying $350–800/month to send irrelevant code to Claude. The model isn't using it. The context rot is causing it to give worse answers, and you're paying more for those worse answers every turn.
How to Fix It: Information-Theoretic Selection
The naive fix — "start a new session" — works but loses all the decisions and progress from the current session. It's also manual and disruptive.
The right fix is information-theoretic context selection: before every LLM request, mathematically rank every available fragment by its relevance to the current query and send only the highest-value evidence.
This is fundamentally different from compression tools that just shrink whatever context you already chose. Correct context selection starts one step earlier:
❌ Naive approach: All files loaded → LLM call (irrelevant files included, relevant files crowded out) ❌ Simple compression: All files loaded → Compress → LLM call (still choosing the wrong starting set, just smaller) ✅ Information-theoretic selection: All files available → Rank by query relevance → Select under token budget → Compress supporting material → LLM call with highest-value evidence only
The ranking uses three signals:
- BM25 relevance — lexical match between the query and each fragment. The file that contains the error message scores highest.
- Shannon entropy scoring — high-entropy fragments (containing errors, anomalies, unusual patterns) are selected over low-entropy boilerplate.
- Dependency graph traversal — if the buggy function is selected, the functions it calls are included at lower priority. The model sees the full call chain, not an isolated fragment.
The budget allocation uses knapsack dynamic programming: given a token budget (e.g., 8,000 tokens), find the exact combination of fragments that maximizes total relevance without exceeding the budget. This is the theoretically optimal solution to the context selection problem.
Preventing Context Rot With Entroly
Entroly is an open-source local context OS that implements this selection pipeline as a transparent proxy for Claude Code, Cursor, Aider, and 35+ other tools. It runs locally — your code never leaves your machine for the optimization step.
pip install entroly cd /your/repo entroly simulate # See estimated savings before connecting anything
What Entroly does on every request:
- Intercepts the outgoing request before it reaches Claude/GPT
- Ranks all available fragments by BM25 + entropy + dependency relevance
- Selects the optimal set under budget using knapsack DP
- Compresses supporting material (evidence-locked — never compresses critical evidence)
- Emits a Context Receipt: what was sent, what was omitted, why, and what risks remain
- Verifies the model's answer against the evidence using WITNESS (0.844 AUROC, $0, 3ms)
✅ Result: Every request sees a fresh, optimally-selected context — regardless of session length. Context rot cannot accumulate because the selection is re-computed per query, not accumulated per turn.
Measured results on real workloads
| Budget | Token reduction | Accuracy retention |
|---|---|---|
| 8K tokens | 99.1% | 100% (NeedleInAHaystack) |
| 32K tokens | 96.7% | 103% (LongBench HotpotQA) |
| Average across workloads | 87.0% | Maintained or improved |
Accuracy retention above 100% on HotpotQA means Entroly's selected context actually produces better answers than the full context — because the model is no longer distracted by irrelevant material.
Stop Paying for Context Rot
Run entroly simulate to see exactly how much irrelevant context is in your current sessions — before connecting any API key.
Frequently Asked Questions
Is context rot the same as hallucination?
They're related but distinct. Context rot is a structural cause; hallucination is often the effect. When the model's context is diluted with irrelevant material, it can't properly ground its answers in the actual code — leading to confident but wrong outputs. Fixing context rot significantly reduces hallucination rates on code tasks.
Does starting a new session fix context rot?
Starting a new session resets the context window, which temporarily fixes context rot. But you lose all the decisions, fixes, and understanding built up during the session. Information-theoretic selection is a better approach: the model sees the right context every turn, without losing session continuity.
Does this affect Claude specifically?
Context rot affects all transformer-based models (Claude, GPT-4, Gemini, Llama). The severity scales with context window size — counterintuitively, larger context windows can make context rot worse by allowing more irrelevant material to accumulate before hitting the limit.
How is this different from RAG?
RAG (Retrieval-Augmented Generation) uses vector embeddings to retrieve semantically similar chunks. Context selection uses BM25 + entropy + dependency graphs, which outperform pure semantic similarity for code tasks (code is structurally diverse, not just semantically similar). Entroly also doesn't require an embeddings API or vector database — everything runs locally.