# Remove What No Longer Matters
# Book: Context From First Principles
# Chapter URL: https://programmer.ie/books/context/10-chapter/
# Prose fingerprint (sha256, normalized): ed736530c444d76398947361387f94fac1bc1d8877e6c57aae50e85808615153
# Snapshot generated at build time by Hugo. This is the complete rendered prose
# of the chapter; it is not a transcript of the source file.

Nine chapters have observed, classified, measured, ordered, priced and architected around context without deleting anything. That restraint ends here, and it should end nervously.
Here is an illustrative scenario, not a result. A team ships an automatic cleanup pass over its coding agent’s history: exact-duplicate tool outputs go, failed calls older than four turns go, anything the model flags as done goes. Token counts fall by a third. Later in the same continuing workflow, a migration guardrail starts failing silently. The deleted material had contained the only accessible record of a constraint established mid-session and written nowhere else. Nobody summarised it away. A rule that could not tell a redundant copy from a unique original simply removed it.
This is the book’s first destructive operation. Keeping is not free, since retained material occupies capacity and may add interference, so the argument is not that deletion is always worse. Destructive operations need evidence proportional to the cost of being wrong. Every decision here has to answer two questions:
Why is this safe to remove?
Why is this the right time to remove it?
What pruning is Pruning removes an item, or part of an item, from the context presented to the model without replacing its semantic content with a generated substitute.
The boundary test is operational: after the operation runs, does it create or select a representation intended to preserve the removed content’s meaning? If so, it is compression or transformation and belongs to Chapter 11. If not, it is pruning. Deleting duplicate rows may be pruning. Keeping a pre-existing diagnostic field while dropping unrelated fields may also be pruning. Selecting sentences specifically to substitute for the meaning of removed material is extraction, even if no new prose is generated.
Pruning is a decision about active-context membership:
source or durable state → candidate information → active context prune: item ∈ context → item ∉ context By definition it does not modify the source or durable records that already exist. But the absence of an independent record can make the removed observation unrecoverable in practice; pruning does not create persistence or preserve provenance automatically. Removing 8,000 tokens of a file read from the next request does not delete the file. Chapter 1’s separation applies:
not in current context ≠ does not exist
Pruning is not externalisation, which relocates information into system-maintained storage (Chapter 13). It is not memory deletion, which concerns durable records across sessions and belongs to the Memory book. And it is not forgetting. The operation defined here leaves durable records and sources unchanged where they already exist. Chapter 10 does not guarantee that everything has durable storage.
Safety is counterfactual An item is not safely removable because it looks duplicated, old, finished or low in relevance, or because it has not been referenced lately. The same discipline applied to bloat in Chapter 5 applies here. Three claims of safety are different:
Structural safety. Under declared structural assumptions, removal preserves the required representation or information obligation. For example, a fixture establishes that an exact redundant copy remains and that repetition itself carries no required meaning. Behavioural safety. A controlled evaluation shows required behaviour survives removal, roughly $B(C) \approx B(C \setminus x)$ under stated acceptance criteria, not literal equality if the evaluation is stochastic. Predicted safety. A policy predicts the item will not be needed. They are not equivalent, and no removal is globally safe. Safe removal is task- and obligation-relative: safe under declared fixture obligations and downstream tasks. A log irrelevant to one task can be essential to another. The following questions move from the easiest check toward the claim the evaluation ultimately needs. They are not a logical implication chain: identical representation does not prove identical contribution, and equal contribution under one task does not establish safety for another:
same representation? → same information contribution? → safe to remove for this task? looks unnecessary ≠ safe to remove
An evidence ladder for pruning Not all removals deserve equal trust, and a policy should know which rung each decision stands on. The numbered levels organise possible grounds for a decision, but are not a monotonic ranking of evidential strength: a verified source identity answers a different question from verified dependency closure, and a correct identity claim need not make a deletion safe. It is not an ontology of information.
Level Basis Establishes Does not establish Principal failure 0 Representation identity The same rendered payload appears more than once Behavioural equivalence Representation identity mistaken for information or behavioural equivalence 1 Source identity Observations come from one immutable or versioned source state That every rendered copy has the same contextual effect A mutable source re-read as identical 2 Checked subsumption A newer observation demonstrably covers an older one under checkable ground truth Irrelevance outside the checked assumptions Subsumption assumed, not checked 3 Verified closure A dependency is currently closed and its required consequence is preserved That it will never reopen A dormant dependency wakes later 4 Prediction A heuristic or model estimates no future need Safety Confident, irreversible error Even exact duplication establishes only duplicate representation. Removing one copy changes total length, the position of later material and adjacency (Chapter 6), so byte equality does not guarantee equivalent behaviour. In a fixture that declares repetition semantically irrelevant, removal can be treated as safe by construction, and elsewhere it is a hypothesis to test. The syntactic-semantic distinction is the first half of a longer one:
syntactic duplicate ≠ semantic redundancy ≠ behaviourally safe deletion
The conservative policy developed here abstains by default on Level 4, and the experiment below is what could earn predictive pruning broader standing. A system should state the rung for each deletion. One that cannot has deletions and no confidence model.
Same tool with the same arguments is not the same observation. A read of config.json at 10:00 and at 10:30 can differ, and so can git status, queries, requests and test runs. A deduplicator must distinguish repeat execution from identical captured output, and check source version or immutable identity where it claims the same source state. A content hash can establish captured byte identity but not equivalent effect from removing one occurrence; a timestamp records when observations were made but does not prove they agree. Tool side effects and task obligations also matter. If these checks are unavailable, the rule must state a weaker guarantee.
The residue of failed work A failed 15,000-token call looks like an easy deletion. A candidate reduction keeps the available diagnostic residue—tool identity, error type, error message and any structured fields needed for the task—while proposing to remove bulk that has been checked against the active obligation. Those fields may be insufficient: arguments, excerpts of input, stack traces or the order of events can be decisive. But the input may explain the failure, so a purge rule has to name what it keeps. There is also a boundary. Retaining existing structured metadata is still pruning. Generating an explanation of why the call failed is transformation, and selecting excerpts of the payload to preserve its diagnostic meaning may already be Chapter 11’s territory. Residue must not smuggle compression into pruning.
Pruning repeated attempts and irrelevant state The multi-turn study by Laban et al. (2025) shows that models anchor to their own early answers and that requirement consolidation helps but does not fully recover single-turn performance. That result motivates a pruning hypothesis rather than proving that deleting old attempts helps an agent. It suggests distinguishing: a context that contains the model’s own rejected hypotheses and premature solution attempts is not the same as one containing only the accumulated requirements and decisive evidence. Pruning should distinguish between:
The model’s own earlier attempts (which may be wrong and anchor future reasoning) User-provided requirements and constraints (which may be revised or withdrawn) Decisive environment observations (which carry evidence) Earlier model-generated attempts become candidates for pruning when their current contribution is demonstrably redundant, rejected, superseded or recoverable elsewhere. Their origin alone does not establish deletion safety; some contain successful partial work, valuable negative evidence, or unresolved alternatives. It requires that the system can identify which items were generated by the model versus received from the environment or the user, and which generated items were later contradicted by evidence. Chapter 15’s epistemic inheritance and Chapter 11’s status preservation are the machinery that makes this possible. Without it, pruning risks removing the only record of a decisive failed experiment while keeping the hypothesis that led to it.
Completed work Coding traces accumulate searches, reads, logs and hypotheses from finished work. Three things are separate:
task complete ≠ dependency complete ≠ future irrelevance A later regression may need why a choice was made, what failed earlier, or an exact identifier a passing test used. The trace should be kept apart from what it established:
raw operational trace ≠ durable knowledge the trace established A completed trace is prune-eligible only to the degree that any required consequence has been preserved elsewhere or is independently recoverable. Once required contributions survive elsewhere, the trace may become eligible to leave active context. This chapter builds no representation for that knowledge. It records the dependency: a prune executed before a necessary consequence is recorded or made recoverable elsewhere is premature. Even a recorded consequence may omit details needed by future tasks, so closure must be checked against the stated obligations.
Age and staleness Deleting the oldest first is among the least defensible rules. Old items include project rules, decisions and unresolved obligations, and recent items include duplicate logs. In the pruning policy developed here, age alone does not establish safe removal:
old ≠ discardable
The word stale needs care. This chapter uses trajectory-superseded locally: an observation no longer contributes to the active line of work because a checked newer observation or completed transition replaced it. That is a different notion from world-staleness, where the underlying fact has changed. Chapter 20 owns factual freshness, and nothing here redefines it or infers truth from recency.
What the literature shows The related evidence is workshop, peer-reviewed and preprint work on coding-agent trajectories, each in its own setting. No figure below is a general result, and the Self-GC and SWE-Pruner results are preprints.
Source Evidence type Reported result Chapter adopts Refuses to infer Lindenbauer et al. Workshop paper (DL4C at NeurIPS 2025) On SWE-bench Verified with SWE-agent and five model configurations, replacing older observations with placeholders halved cost against the raw agent and matched, sometimes slightly exceeded, the solve rate of LLM summarisation; a hybrid saved further Removal is worth testing before lossy transformation That masking always matches summarisation, or anything beyond the tested scaffold Xiao et al. (AgentDiet, FSE 2026) Peer-reviewed On two models and two benchmarks, input tokens fell by 39.9 to 59.7 per cent, or final cost by 21.1 to 35.9 per cent, with agent performance maintained; the reduction uses a separate reflection model with its own cost Token reduction and cost reduction are different quantities, and a mechanism’s own overhead has to be counted That the same reductions hold on other agents or tasks SWE-Pruner Preprint A 0.6-billion-parameter model selects the code lines relevant to an explicit task goal, reporting 23 to 54 per cent token reduction on agent tasks with success maintained or improved That filtering incoming observations is a different decision from pruning history, as this chapter reads it Any result for history pruning Self-GC Preprint A side-channel planner proposes fold, mask and prune actions over indexed context objects, and the harness enforces recoverable sidecars, safe commit boundaries and cache-aware commits; the authors report the share of future continuations left unaffected by pruning Separating proposal from commit is a natural structure Its impact figures for other settings As a proposed sequence, and not an empirical law: remove what is demonstrably unnecessary before transforming what may still matter.
Retention boundary Chapter 7 concluded that retention outcomes are derived policy states and not intrinsic classes, and that retention obligation is separate from admission requirement:
retention obligation ≠ admission requirement
A PIN-governed item that is admitted may not be reduced below its fidelity floor, so pruning must not violate the applicable floor. Whether it must be admitted at all is a separate, task-relative question. Nothing here asks for an importance score:
importance ≠ deletion safety
Deletion safety comes from redundancy, preservation obligations, recoverability, dependency and evidence. Protection is derived from properties already declared, not from a list. For each candidate, ask whether the current task requires it, whether it holds a unique unrecoverable contribution, whether it is an active unresolved dependency, whether a fidelity obligation applies, and whether a declared policy prohibits removal. What authority is, and what stale means, belong to Chapters 19 and 20, and admission and selection to Chapters 22 and 23. Chapter 10 consumes what they establish.
Placeholders Removal leaves a choice: show the model nothing, or a mechanical marker. A placeholder can carry an item identifier and type, the removal reason, a source and version pointer, a timestamp and a declared recovery-capability flag. Those fields must come from recorded metadata or a checked source, not guesses generated from the deleted payload. It must not carry generated prose meant to preserve the item’s meaning, or it is Chapter 11’s. Three distinctions follow:
placeholder ≠ semantic substitute auditable ≠ reversible recovery pointer ≠ successful recovery A log can record an irreversible deletion perfectly, and recovery, as Chapter 7 said, has to be tested. “Delete” also covers operations that differ along several dimensions and do not form one monotonic scale:
Operation In active context? Durable record survives? Source survives? Recovery path? Omit from this invocation No Yes Yes Depends Omit and leave a placeholder Marker only Yes Yes Depends Delete the durable record No No Depends Reduced Delete the source No Depends No No This chapter operates on the first two rows.
Decision modes and outcomes Pruning can be initiated in three modes, and none is declared best. Deterministic rules are reproducible, auditable and cheap, and semantically blind. Agent-requested pruning notices completed work, but a model deciding what its future self may forget is judging its own future needs. Human-triggered pruning is intentional and gives up automation. The proposed staging is to begin with the safest deterministic subset and extend only where experiments show broader judgement earning its risk. DCP is one implementation combining autonomous strategies with manual controls, and nothing about production practice follows from one product.
Four outcomes are defined precisely:
KEEP. Current evidence supports continued membership in active context. PRUNE. Removal is permitted and applied now. DEFER. Removal may be eligible, and timing postpones it. ABSTAIN. The available evidence cannot establish eligibility. KEEP is an affirmative policy result under the currently declared obligations; it need not mean that retaining the item is beneficial. ABSTAIN is an epistemic result: the available evidence is insufficient to authorize removal. A pruner forced to call everything deletable or protected will eventually delete what it should have questioned.
Eligibility and timing PRUNE ELIGIBILITY Can this item safely leave active context? PRUNE TIMING When should the eligible removal be applied? eligible now ≠ apply now
Eligibility is an evidence question. Timing can consider context pressure, task boundaries, request cadence, recovery availability and, where reuse exists and telemetry makes it observable, the reuse effect of an edit. The book adopts eligibility and timing as separate decision variables in its proposed pruning model. Magic Context’s README describes queuing stale-content removal to apply at cache-safe moments, an instance of the separation and not its proof.
Chapter 9 fixed the status of the economic side. Token reduction does not by itself determine economic effect, and structural reuse effect is not realised cache loss. Mutation radius is a proposed accounting concept. Where meaningful cross-request reuse exists and the provider exposes enough telemetry, pruning should record first-divergence and reuse effects as part of its economic accounting. Where reuse doesn’t exist, has expired, or telemetry is insufficient, it is not required. A removal can move the first divergence before tokens that were structurally reusable, and whether that becomes realised cache loss depends on eligibility, availability, routing and telemetry.
Timing is a trade-off, not a rule. As a hypothetical, a duplicate found at turn six might be cheaper to remove after a cached prefix expires than while it is still being reused, but keeping it until then costs occupancy and possible interference, which is why timing requires measurement. The policy’s own cost belongs in the accounting too: a semantic pruning agent that saves 8,000 tokens at the price of 3,000 classification tokens and an extra call must be counted honestly.
flowchart TD C["Candidate"] --> Q1("Required by a declared<br/>current obligation?") Q1 -->|yes| KEEP["KEEP"] Q1 -->|no| Q2("Mechanically redundant<br/>or checked superseded?") Q2 -->|yes| E["Eligible"] Q2 -->|no| Q3("Verified closed, with required<br/>consequence preserved?") Q3 -->|yes| PE["Possibly eligible"] Q3 -->|no| Q4("Needs a prediction<br/>of future need?") Q4 -->|yes| AB["ABSTAIN under<br/>conservative policy"] E --> T("Timing: pressure, task boundary,<br/>recovery state, observable reuse") PE --> T T -->|apply| PR["PRUNE"] T -->|postpone| DF["DEFER"] Risk, and what is measured Keeping an unneeded 2,000-token log costs bounded, measurable resources. Deleting the only copy of a constraint can cost the task. As a design bias to test, and not a universal loss function, early pruning prefers precision to recall. A deployment with a bounded-cost sandbox might choose differently, and the experiment should expose the trade-off.
A false prune is a removal the policy labelled safe that violates a declared fixture preservation obligation, or that fails a specified counterfactual behavioural test because required information was removed. An ordinary downstream failure after pruning is not, by itself, proof of causation: the unpruned comparison may fail too. No one metric establishes maturity. Abstention rate, coverage and false-prune rate are tracked together, since abstention can fall because the fixtures got easier, the task mix changed or the classifier grew overconfident.
Proposed experiment Nothing here has been run. The companion repository holds a design in which safe removal is one rung of a typed ladder, and a separate optional design for cache-aware reduction.
Ecological gate. Before spending inference budget, inspect real traces descriptively for how much active context appears to be exact duplicates, repeated immutable-source reads, failed-input bulk, checked superseded observations and completed-work residue. That describes candidate volume and does not establish safe removal, and its heuristics must not become deletion labels. The corpus of real sessions is empty, so this chapter has no evidence about the prevalence or expected leverage of its pruning classes:
safe mechanism ≠ common opportunity
Unit and labels. The unit is a deterministic trajectory fixture. Item states, obligations and the oracle are frozen before any condition runs, so the experiment tests a pruning policy and not a classifier the book has not built. The oracle removes exactly the items that fixture ground truth marks unnecessary for all declared downstream obligations, and is never built from a model’s later answer.
Conditions. Layer A ablates single mechanisms against the raw history: exact redundancy, errored-input residue, checked supersession, verified-completion pruning, and predictive semantic pruning as a labelled upper-risk condition and not a proposed policy. Layer B then applies the conservative ladder cumulatively. The ablations identify marginal effects of each rule under the tested fixtures, while the cumulative ladder tests interactions and overall policy behaviour. Where rules overlap, record their application order and which rule actually removed each item.
Resource accounting. Conditions remove different amounts, so budgets are not matched. Report raw tokens, removed tokens, placeholder tokens, management overhead and final tokens, and compare safety at the achieved reduction and reduction at a fixed safety threshold, so a policy does not win merely by deleting more.
Measures, never collapsed. Preservation: declared obligations, unique evidence, required residue, recovery pointers and provenance. Pruning quality: precision and false-prune rate among applied removals, coverage among eligible candidates, and abstention rate among decisions. Report denominators explicitly; an empty applied-removal set has undefined precision, not perfect precision. Behaviour: task success, constraint violations, unsupported claims and recovery failures. Resources: tokens removed, overhead, latency and provider cost. Reuse, only where relevant and observable: first divergence and provider-reported cache telemetry. Where an item is safe to remove because it is recoverable, a pointer-resolution and identity check tests that assumption.
Outcomes.
Mechanical redundancy removes meaningful volume with no obligation failures: this supports conservative pruning. The mechanical classes are safe but remove little: pruning is valid and low-leverage. Checked supersession fails: narrow or reject that rung. Completed-work pruning loses later dependencies: the closure evidence is insufficient. Predictive pruning raises the false-prune rate substantially: the abstention boundary stands. Reduction is large but overhead and cache effects remove the economic benefit: no economic win is claimed. Behaviour improves after pruning: interference may have fallen, but the mechanism is not inferred without a design for it. No advantage appears: pruning may not help in the tested setting. Inspect this in the Context Viewer The viewer scene for this chapter works a three-snapshot reduction end to end: accumulation, then removal of superseded output from the observed set while a compact summary and an anchor remain and the constraint record stays protected. Open the scene and follow each item across the snapshots. What to examine: what was retained, what left the observed representation, what was protected or deferred, and what each removal’s annotated cause actually establishes. This exercises the comparison instrument on a constructed fixture; it is not a validated pruning pass, and removal here proves nothing about safety.
Before-and-after comparison with retained, removed, protected and deferred material distinguished. Constructed illustration. Open the pruning comparison in the Context Viewer
Worked cases DCP is one implementation of the ideas above. Its repository, licensed AGPL-3.0-or-later, describes protecting a default set of tools and configurable file patterns, deduplicating repeated tool calls with the same tool and arguments by keeping the most recent output, purging the inputs of failed calls after a configurable number of turns while keeping the error messages, appending protected tool outputs to its compression summary, and replacing pruned content with placeholders before requests, leaving session history unmodified. It also states that pruning can increase cache misses. One correction matters. Same-tool-plus-arguments deduplication does not satisfy this chapter’s Level 0, which requires an identical rendered payload, since outputs can differ when state changes. It resembles the redundancy problem with a weaker guarantee, which is why the chapter derived a stricter model. DCP’s separate summarising tool is not pruning and belongs to Chapter 11.
Magic Context, licensed MIT, is an instance of timing separated from selection: its README describes queuing stale-content removal to apply at cache-safe moments. Its summarisation, tiers and memory capture belong to later chapters and the Memory book. Both are third-party implementations, studied as instances and not copied or promoted to policy.
The decision record Every destructive decision should be explainable afterwards, and the audit record must stay independent of the active context it modifies. It must not disappear merely because the pressure that triggered the prune also applies to it, so audit retention needs its own bounded policy, separate storage where appropriate, and protection against unbounded log growth. The chapter prescribes the invariant and not a storage design.
Mandatory fields may explicitly record UNKNOWN or UNOBSERVED when the runtime cannot establish the value. Absence of evidence must not be converted into a fabricated identity or recovery guarantee. The fields are: item identifier, the decision, policy version, reason and evidence rung, declared obligations consulted, recoverability status, source and provenance identity, application time, and any placeholder or pointer. Optional where relevant and observable: first divergence, reuse telemetry, mutation-radius accounting and economic effect. Mutation radius is not made structurally mandatory, because Chapter 9 has not promoted it.
Chapter 23’s compiler records, for each candidate, why it was or was not admitted. Pruning is not a pass of that compiler, but the discipline is the same.
What deletion cannot solve Preventing a distractor from entering is an admission and selection problem, and removing it after admission is pruning. Evidence in an unusable position is a layout problem, though deleting surrounding material can interact with it. A bundle whose compressor already destroyed its constraints needs Chapter 11. Pruning is also bounded by what the trace contains: if deterministic safe classes cover only a small share of real context, a result the design leaves room for, the main solution lies further on. A mechanism that knows its ceiling is engineering.
Pruning stops where information still carries a preservation obligation but that obligation permits a lower-fidelity representation:
no preservation obligation → pruning may be possible preservation obligation survives + lower fidelity permitted → compression candidate A lower-fidelity candidate is not thereby something that should be compressed, and Chapter 11 has to test whether it should:
When information cannot safely disappear but its obligation does not require the original representation, deletion has reached its limit. What can survive transformation instead?
References Lindenbauer, T., Slinko, I., Felder, L., Bogomolov, E., Zharov, Y. “The Complexity Trap: Simple Observation Masking Is as Efficient as LLM Summarization for Agent Context Management.” arXiv:2508.21433, 2025; DL4C workshop. Workshop paper, camera-ready for the 4th DL4C workshop at NeurIPS 2025. https://arxiv.org/abs/2508.21433 Xiao, Y.-A., Gao, P., Peng, C., Xiong, Y. “Reducing Cost of LLM Agents with Trajectory Reduction.” Proc. ACM on Software Engineering 3, FSE (July 2026), article FSE056; arXiv:2509.23586. Peer-reviewed. https://dl.acm.org/doi/10.1145/3797084 Wang, Y., Shi, Y., Yang, M., et al. “SWE-Pruner: Self-Adaptive Context Pruning for Coding Agents.” Preprint, arXiv:2601.16746, January 2026. https://arxiv.org/abs/2601.16746 Hao, X., Meng, H., Yin, X., Zhu, J., Cao, C. “Self-GC: Self-Governing Context for Long-Horizon LLM Agents.” Preprint, arXiv:2607.00692, July 2026. https://arxiv.org/abs/2607.00692 Tarquinen. “Dynamic Context Pruning Plugin (DCP).” OpenCode plugin, AGPL-3.0-or-later, verified September 2026. Implementation facts only. https://github.com/Tarquinen/opencode-dynamic-context-pruning cortexkit. “Magic Context.” Context plugin, MIT, verified September 2026. Implementation facts only. https://github.com/cortexkit/magic-context Laban, P., Hayashi, H., Zhou, Y., Neville, J. “LLMs Get Lost In Multi-Turn Conversation.” arXiv:2505.06120, May 2025. Preprint. https://arxiv.org/abs/2505.06120