Half of your context belongs to threads you're not working on — and dragging all of it along is as often harmful as helpful.
23 July 2026
Every mainstream coding agent — Claude Code and the rest — keeps your conversation as a single linear, append-only list. Everything you and the agent have said, and every tool result, piles into one shared context window until a compaction step summarizes it away. That linear shape is an assumption, and it turns out to be the wrong one. This is a two-part study of what that context is actually made of, and what you can safely remove.
Real sessions are braids pretending to be lines: you start task A, detour into a question, jump to task B, come back to A. Every prompt then drags along context that belongs to other threads.
I started from a hypothesis I liked and then killed it. The idea: explanation turns (“explain this,” “why?”) are the safest thing to evict, because the model can always regenerate an explanation. I measured it on my own real Claude Code history. Verdict: pure-comprehension turns are only 2.3% of stored tokens — 84% is action and tool output. Evicting explanations is not worth building. A clean negative result, and a useful calibration for what is worth removing.
The positive result was structural. Segmenting each session into topical threads and checking how often they interleave:
So the tax is real: roughly half of what a coding agent reads at any moment is about something you're not currently doing. The academic framing calls the resulting quality decay “logical context poisoning.” The question is whether you can cut that half without breaking anything.
A pilot suggested that if you scope context to the active thread but keep a mined entity ledger (files, commands, decisions) of the other threads, quality holds. But the pilot was underpowered — one judge, a ±2-item noise band. So I ran a pre-registered, four-arm, blinded ablation (design frozen and committed before any result was seen).
At 21 real thread-return moments — the danger points, where scoped context drops the intervening threads entirely — I replayed the actual next user prompt under four context constructions, and a three-judge panel scored each against the assistant's real historical response, with the arms shuffled per item:
| Arm | Context | Equivalent | Dep-fails | Preferred | Worst |
|---|---|---|---|---|---|
| FULL (linear) | — | 12/21 | 11 | 8 | 10 |
| STUBS | −48% | 12/21 | 11 | 4 | 3 |
| ENTITIES | −43% | 12/21 | 10 | 3 | 3 |
| DECISIONS | −45% | 13/21 | 11 | 3 | 3 |
Majority of 3 blinded judges; inter-judge agreement 73% (chance = 25%). Excluding one degenerate item gives an identical pattern.
1. Scoping works. Thread-scoped context matches full linear context on every objective measure — task-equivalence, dependency-failure, and a hard file-recall metric — at 43–48% less context. The pre-registered primary criterion passed.
2. Full context is polarizing. This is the striking one. FULL is the preferred arm most often (8/21) and the worst arm most often (10/21). The scoped arms are rarely worst. Dragging the whole history along sometimes surfaces the one useful cross-thread fact — and just as often buries the answer in noise. That is context poisoning caught in the act: full context is not safer, it is higher-variance.
3. The recipe doesn't matter as much as I thought. Entities, decisions, and even bare stubs performed alike. At this power I cannot claim entities are the necessary ingredient — which tempers my own pilot. The thing that matters is simply scoping to the thread; the exact condensation format is second-order.
This is a single-user corpus, N=21 return points, with LLM replayers and LLM judges — a rigorous feasibility result, not a population estimate. The preference gaps sit within the judge-disagreement band and are not statistically significant. Nobody has shipped a cache-adjusted, live-agent version, and a real router still has to be built (and it needs a small model, since lexical routing already failed). What raises this from feasibility to conference-grade is exactly what it lacks: more users, human judges, larger N.
I'm publishing the negative parts — eviction is pointless, lexical routing fails, the entity claim didn't replicate — as prominently as the positive one. That's the point of pre-registration: the design can't be bent to the result after the fact.
Linear conversation history is the wrong data structure for coding agents, and you can act on that today: scope context to the active thread and you cut it roughly in half with no measurable quality loss — while full context is as often a liability as an asset. The durable contribution here isn't a mechanism; it's a method — a pre-registered, blinded, honestly-reported measurement of what agent context is made of and what can safely be removed.