AI Performance

What Is Context Rot?
The Hidden Reason Your AI Gets Dumber Over Time

Your AI assistant gives sharp, accurate answers at the start of a session. An hour later, it's hallucinating function names and confusing files. This isn't a model problem. It's context rot — and it's costing you real money.

📅 Updated July 2026 ⏱ 8 min read 🏷 Claude, GPT-4, Cursor, Claude Code

In this article

  1. What is context rot?
  2. Why it happens: the physics of attention
  3. The 4 stages of context rot
  4. How to recognize it in your sessions
  5. The hidden cost: money, not just quality
  6. How to fix it: information-theoretic selection
  7. Preventing context rot with Entroly

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:

  1. Qualitative rot — answer accuracy drops as the session ages. The model starts missing errors, confusing similar files, and confidently generating wrong fixes.
  2. 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 typeRelevance to current queryToken cost
Early conversation turns❌ Usually staleHigh
Imported dependency files⚠️ Partially relevantVery high
Shell command output logs❌ Usually irrelevantMedium–High
Duplicate file reads❌ RedundantHigh
The actual bug / the critical fileCriticalLow — 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

1
Fresh Session — Peak Performance

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.

2
Accumulation — Early Signs

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.

3
Congestion — Noticeable Degradation

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.

4
Overflow — Context Compaction / Quality Collapse

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:

  1. BM25 relevance — lexical match between the query and each fragment. The file that contains the error message scores highest.
  2. Shannon entropy scoring — high-entropy fragments (containing errors, anomalies, unusual patterns) are selected over low-entropy boilerplate.
  3. 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:

  1. Intercepts the outgoing request before it reaches Claude/GPT
  2. Ranks all available fragments by BM25 + entropy + dependency relevance
  3. Selects the optimal set under budget using knapsack DP
  4. Compresses supporting material (evidence-locked — never compresses critical evidence)
  5. Emits a Context Receipt: what was sent, what was omitted, why, and what risks remain
  6. 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

BudgetToken reductionAccuracy retention
8K tokens99.1%100% (NeedleInAHaystack)
32K tokens96.7%103% (LongBench HotpotQA)
Average across workloads87.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.

Get Entroly free → Read the docs

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.