Failure modesAntipatternProven

Context rot

Also called: context decay, session sediment

Context rot is the gradual decay of a long session as stale, superseded, and irrelevant text accumulates in the window. Nothing breaks at any single step, which is why it is usually diagnosed as the model getting worse.

James Phoenix
Understanding Data Updated July 26, 2026

A long session accumulates sediment. The file you read twenty turns ago and then rewrote. The approach you abandoned. Three failed attempts and their error output. The plan that changed. All of it still sits in the window, and all of it still competes for attention with the two things that currently matter.

Nothing fails at any individual step, which is what makes context rot hard to spot. The session just gradually gets worse: the model forgets a constraint it respected earlier, re-suggests something already rejected, edits a stale version of a file.

Why it degrades quality rather than just costing tokens

  • Contradiction. The window now holds the old decision and the new one. The model has no reliable way to know which is current, so sometimes it picks the old one.
  • Attention dilution. Relevant text is a shrinking fraction of a growing window, and lost in the middle means the buried middle is where things go to be ignored.
  • Stale state read as current. The most damaging case. A file's earlier contents are still verbatim in the history, so an edit gets computed against a version that no longer exists.

Reading the symptoms

You are looking at context rot when the model was doing well an hour ago and is now:

  • repeating a suggestion you already rejected
  • ignoring a constraint it previously honoured
  • editing code that does not match what is on disk
  • getting vaguer as the session gets longer

What actually helps

Compaction condenses old history into a summary and reclaims space. Done well it preserves the *trajectory*, the decisions and their reasons, rather than just the last few messages.

Clearing wipes the window and restarts from a short written statement of current state. Blunter, and frequently the right call: a fresh session with a good handoff note beats a long one carrying an hour of sediment.

Externalising state avoids the problem instead of managing it. Decisions in a file, progress in a document, plan on disk. The window holds pointers to durable state rather than being the state.

Tip
The instinct is to fight rot by summarising more. Often the better move is to end the session. If you can write down what matters in ten lines, a fresh window holding those ten lines will outperform a compacted one holding a lossy version of everything.

Related terms

Engineering context for real systems?

Getting the right information into the window at the right time is most of the job. If you want that thinking applied to your product, that is what I do.

See how I can help