Remove What No Longer Matters

Explain this chapter with AI

Copy this prompt into ChatGPT, Claude, Gemini, a local model, or another AI.

Apply this chapter with AI

Copy this prompt into ChatGPT, Claude, Gemini, a local model, or another AI.

Nine chapters have observed, classified, measured, ordered, priced, and architected around context without once deleting anything. That restraint ends here, and it should end nervously. 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. Two weeks later a migration guardrail the team believed was load-bearing starts failing silently. The deleted material contained the only record of a constraint the project file never stated, a decision reached mid-session and never written anywhere else. Nobody summarised it away. Nobody rewrote it. It was simply removed, by a rule that could not tell a redundant copy from a unique original.

This chapter is the book’s first destructive operation, and the burden of proof changes accordingly. Deleting 20,000 tokens is not a success unless the system can show what disappeared, why removal was safe, what happened to later behaviour, and what cache reuse the deletion destroyed. Every destructive decision in this chapter must answer two questions, and the chapter will return to them until they feel like reflexes:

Why is this safe to remove?

Why is this the right time to remove it?

What pruning is, and what it is not

The chapter needs a definition that holds for the rest of the book:

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.

In schematic form:

raw context
   โ†“
PRUNE
   โ†“
less raw context

No summary stands in for the removed material. No paraphrase preserves its gist. That absence is the firewall between this chapter and the next. Apply this boundary test to any operation: after it runs, does new prose or data attempt to preserve the removed item’s semantic content? If yes, the operation is compression or transformation and belongs to Chapter 11. If no, it is pruning and belongs here. Mechanical metadata, a note that something was removed and where it could be recovered, does not count as a semantic substitute; the placeholder section below explains why that line holds.

Pruning must also be separated from its neighbours in every other direction. It is not externalisation, which relocates information into system-maintained storage with a guaranteed recall path; Chapter 13 owns that machinery. It is not memory deletion, which concerns durable records across sessions; the Memory book owns that territory. And critically, it is not source deletion. Removing 8,000 tokens of read("src/server.py") output from the next model request does not delete the file, does not delete the tool event from the durable session record, and does not erase the provenance chain. The system may retain the original source, the event, the identifier, and the recovery path outside active context. Chapter 1’s separation does the work here:

not in current context
        โ‰ 
does not exist

Available information and session state persist. Only the current computation’s bundle shrinks. Forgetting this distinction turns every prune into a small amnesia; honouring it turns pruning into what it should be, a decision about this invocation’s membership.

Start where deletion is provable: exact redundancy

The chapter does not begin with an AI deciding what seems boring. It begins with the strongest case available. Suppose the agent reads the same immutable file three times:

read commit abc123:file.py โ†’ output X
read commit abc123:file.py โ†’ output X
read commit abc123:file.py โ†’ output X

If source identity is identical, source version is identical, arguments are identical, output is identical, and no later reasoning depends on the repetition itself, then keeping all three verbatim outputs is difficult to justify. The first pruning primitive follows:

Remove redundant representation while preserving the information.

One copy stays. The information survives completely. Nothing semantic is invented, which makes this safer than any summarisation by construction: there is no generated substitute to be wrong.

But the conditions carry the entire weight, and the most instructive failures come from dropping one. Consider the apparently identical case:

read("config.json") at 10:00
read("config.json") at 10:30

Same tool, same arguments. Different observations if the file changed between reads, different worlds if a migration ran, different meanings if an intervening edit reinterpreted the values. The same holds for git status, database queries, web requests, test runs, clocks: identical invocations of non-deterministic or state-dependent tools are not the same observation. DCP’s production deduplication, same tool plus same arguments keeping the most recent output, is a useful practical rule studied as a case below, never a proof of equivalence. The durable distinction is:

syntactic duplicate
        โ‰ 
semantic redundancy

A safe deduplicator needs more than string equality: source version, capture time, content hash, environment version, or knowledge of side effects, or else a weaker guarantee stated honestly. Byte-identical rendered copies with no versioned-source ambiguity sit at the safe end. Everything else moves down an evidence ladder the chapter now defines.

An evidence ladder for pruning confidence

Not all removals deserve equal trust, and the policy should know which rung each decision stands on:

Level 0: identical rendered copy.
  The exact same content appears multiple times
  and the repetition itself carries no meaning.

Level 1: same immutable or versioned source.
  Multiple observations provably refer to one source version.

Level 2: superseded observation.
  A newer observation demonstrably subsumes the older one
  under checkable ground truth.

Level 3: trajectory-complete residue.
  Material belongs to work known to be complete
  with no remaining dependency on it.

Level 4: predicted irrelevant.
  A heuristic or model predicts no future need.

Risk increases down the ladder, and the organising principle matters more than the labels:

Pruning must distinguish what is proven redundant from what is merely predicted unnecessary.

Levels 0 and 1 are proofs under stated conditions. Level 2 is a proof contingent on the subsumption evidence, which the fixture must make checkable rather than asserted. Level 3 depends on a definition of complete that the trajectory must earn: a subtask marked done by the agent that decided it is weaker evidence than closure verified against an external check. Level 4 is prediction wearing removal’s clothing, and the chapter treats it as the highest-risk class admitted at all, fenced by abstention rules below. A pruning system should be able to state its rung for every deletion. One that cannot has no confidence model, only deletions.

The useful residue of failed work

Failed tool calls look like the easiest deletion target in any trace. A 15,000-token input returns ERROR: invalid parameter, and several turns later the payload seems pure waste. The safe version of this instinct preserves the failure’s evidence while removing its bulk:

failed computation
        โ†“
preserve failure evidence
        โ†“
remove bulky failed input

What survives is small and specific: tool identity, error type, error message, diagnostic metadata. What goes is the payload that produced them. But the assumption behind even this careful version needs interrogation, because the input may explain the failure: a malformed parameter, an incorrect path, corrupted data, an earlier mistaken assumption visible only in the full text. Deleting the input deletes the diagnosis the next turn might need. So an errored-input rule must establish which residue survives, not merely that bulk goes. DCP’s production rule has exactly this shape, inputs pruned after a horizon with messages preserved, and the chapter adopts the shape while insisting on the residue question: a purge policy that cannot name what it keeps has mistaken deletion for understanding.

Completed work is not disposable

Coding traces accumulate searches, reads, logs, compiler output, subtask traces, and temporary hypotheses from work already finished. The temptation is to delete all of it at subtask close. The danger is that completion does not imply zero future relevance. A later regression may need why a choice was made, what failed previously, which alternative was rejected, the exact identifier a passing test depended on. This is Level 3 of the ladder at its most treacherous: completeness is real, dependency is merely dormant.

The safe structure separates two things the raw trace fuses:

raw operational trace
        โ‰ 
durable knowledge the trace established

The trace becomes removable once its unique contribution lives elsewhere: the decision recorded, the rejected alternative noted, the identifier extracted. Until then, removal destroys the only copy of something the trajectory may need. This is where pruning leans on another representation without building it. Do not redesign memory here. Establish only the dependency: safe pruning can depend on prior preservation, and a prune executed before its consequence is recorded elsewhere is premature regardless of how finished the work looks.

Age is not a policy, and stale needs two words

The cheapest pruning rule in existence is also among the least defensible: delete the oldest first. Age correlates with irrelevance often enough to feel wise and fails exactly where it matters. Old items include project rules, architectural decisions, user constraints, unresolved obligations. Recent items include duplicate logs, failed commands, irrelevant observations. Therefore:

old
โ‰ 
discardable

Age is a signal. It is never the policy alone. Chapter 12 will study age-graded fidelity in full; this chapter uses age only as one input among the ladder’s evidences, and any rule that deletes by timestamp without consulting redundancy or completion has left the ladder entirely.

Relatedly, the word stale needs splitting before it causes damage. Trajectory-stale means an observation no longer contributes to the active line of work because a newer equivalent observation or a completed transition superseded it. This chapter may act on trajectory-staleness under Level 2 evidence. World-stale means the underlying fact is no longer valid because the world or the source changed, which requires truth machinery this chapter must not build. Chapter 20 owns factual freshness. Pruning may rely on an already established newer observation inside a deterministic fixture. It must never infer truth from recency, and any rule shaped like “old therefore false” belongs nowhere in this book.

What the literature already shows

The chapter’s derived caution now meets independent evidence, and the meeting is encouraging for deletion-first policy. Lindenbauer et al., in a JetBrains study presented as a workshop paper, compared plain observation masking, older tool outputs replaced with a placeholder, against LLM summarisation on SWE-agent trajectories: masking halved cost relative to the raw agent while matching and sometimes slightly exceeding summary solve rates, with a hybrid of the two saving further. Their preliminary measurement motivates the whole comparison: environment observations constitute roughly 84 per cent of an average agent turn. When the bulk of context is observations, deleting observations is not a crude heuristic. It is surgery on the largest organ. The study’s status needs its label, a workshop paper rather than full peer review, on one scaffold family, but its shape, deletion matching transformation at lower cost, is exactly what this chapter’s firewall predicts.

Xiao et al.’s AgentDiet, peer-reviewed at FSE 2026, sharpens the picture on a top coding agent across two models and two benchmarks: input tokens down by two-fifths to three-fifths with task performance held level, and, crucially for this book, final cost down by a smaller fraction, one-fifth to one-third, with the authors explicitly attributing the gap to output tokens, reflection overhead, and invalidated caches. Three details deserve underlining because later sections inherit them. First, the cost-token gap is Chapter 9’s lesson reproduced independently: token reduction and cost reduction are different objectives. Second, the reflection acts only above a token threshold and after a step delay, a timing discipline this chapter generalises below. Third, the reflection module’s own compute is separately accounted, the decision-overhead honesty this chapter demands of every mechanism including itself.

Two further studies position the chapter by contrast. SWE-Pruner trains a small skimmer to filter file observations at admission time against agent-supplied goal hints, cutting agent-task tokens by a quarter to a half with success maintained. That is pruning at the environment boundary, before history exists, and its authors explicitly call it orthogonal to trajectory-history managers. The distinction matters: admission filtering decides what enters, this chapter decides what stays, and the two compose rather than compete. Self-GC, a 2026 preprint, operates closest to this chapter’s level with indexed context objects under fold, mask, and prune lifecycles, recoverable sidecars, safe commit boundaries, and cache-aware commits, reporting high no-impact continuation rates at substantial pruning depths. Its vocabulary, rehearsal before commit, planner proposes while harness disposes, independently rediscovers this chapter’s eligibility-versus-timing split. The preprint label stays attached; the convergence is still evidence that the split is natural rather than invented.

Protection derives from Chapter 7

Nothing in this chapter redesigns retention. Pruning consumes Chapter 7’s classifications, operating where items are demonstrably DISCARDABLE or where redundant copies exist beside an authoritative or recoverable original. At no point does the ladder ask for an importance score: apparent triviality never licenses deletion, and apparent significance never forbids it. The question is always redundancy, supersession, or completion under evidence, never rank. Some REFETCHABLE material may leave active context, but the chapter stops at removal decisions and builds no external artifact architecture; that machinery is Chapter 13’s. Protection, likewise, derives rather than invents. The categories worth protecting follow directly from the properties: PIN items by definition, user constraints and active plan state by authority, tool outputs holding unique evidence by recoverability, unresolved errors by pending diagnostic need, authoritative project rules by governance. DCP’s production protected-tool list is an implementation decision for one product, studied below as an instance, never adopted as doctrine. The policy question for each candidate is always why, answered in properties, never what, copied from a list.

Placeholders preserve identity, not content

Removal leaves a choice: show the model nothing, or show a mechanical marker. The three options differ semantically:

[older duplicate tool output removed]

[read output removed; source still available as src/foo.py@abc123]

[nothing at all]

A placeholder can preserve that something happened, what kind of thing it was, where to recover it, and why it disappeared, without preserving any content. That is why placeholders do not breach the Chapter 11 firewall: they carry mechanical metadata, never a generated semantic substitute. The provenance point follows. If an observation goes but its consequence stays, the system may still need the path back: source, revision, recoverability flag. Recording a path is not deciding when to walk it; re-admission timing, when pruned material should return, belongs to Chapter 14, and this chapter intentionally leaves that question unopened. Remove payload is a different act from erase identity, and placeholders are identity’s minimal form. The chapter prescribes no syntax. It prescribes the principle: what can be audited can be reversed, and silent gaps audit nothing.

Who decides: three control modes, no universal winner

Deletion authority comes in three forms with complementary failure modes. Deterministic automatic rules, same-version duplicates, aged error inputs past a horizon, are reproducible, auditable, cheap, and testable, but semantically blind. Agent-requested pruning is task-aware and notices completed work, but the model deciding what its future self may forget is judging its own future needs, unstable and capable of confident irreversible error. Human-triggered pruning carries strong intentionality at the cost of defeating automatic long-running operation. The chapter declares no winner because the right answer is staged, not single: the capstone begins with the safest deterministic subset, earns autonomy only where experiments show the agent’s judgement beating blind rules without raising false-prune rates, and keeps human triggering as the backstop for high-stakes sessions. DCP ships both autonomous strategies and manual controls in one product, which is itself evidence that production practice refuses the single-mode answer.

The irreversibility gradient

“Delete” covers operations of wildly different severity, and the chapter operates near the top of this gradient:

hide from this request
        โ†“
remove from active context
        โ†“
replace with mechanical placeholder
        โ†“
delete from session-visible history
        โ†“
delete source

Each step down is harder to reverse. This chapter removes from the active rendered context while preserving underlying evidence where possible: session records persist, sources persist, placeholders mark the absence. Nothing here deletes the archival record, and nothing touches sources. That restraint is also what keeps the Context and Memory boundary intact. The model forgets for this computation. The system remembers everything, in cheaper places, until a later chapter with stronger evidence says otherwise.

Cache economics are mandatory, timing follows

Every prune considered here inherits Chapter 9’s ledger in full. Recall its two sentences: a prune has two sizes, the material removed and the cached prefix disturbed, and any reported saving without both is unaudited. Removing 20,000 duplicate tokens near the start of a 100,000-token cached prefix can orphan 80,000 downstream tokens of reuse; the token-only report says 20K saved while the correct report asks what computation was invalidated. Mutation radius and first-divergence position accompany every deletion claim in this chapter’s experiment, without exception.

From that ledger follows the chapter’s most practical distinction after the ladder itself:

PRUNE ELIGIBILITY
Can this item safely leave active context?

PRUNE TIMING
When should that removal be applied?

Eligibility is an information-semantics question answered by the ladder, the residue analysis, and the protection rules. Timing additionally depends on cache state, context pressure, task boundaries, and request cadence, and the two answers need not coincide. A duplicate identified at turn six may be cheapest to remove at turn nine, after the cached prefix it sits inside has expired, or at a subtask boundary where the divergence it causes invalidates the least. Magic Context’s production design separates exactly these moments: the agent marks material for reduction while the runtime applies reductions at cache-safe points. The book adopts the distinction as canonical policy structure, not the implementation. Eligibility without timing is a saving mispriced. Timing without eligibility is vandalism scheduled politely.

Policy ladder, abstention, and asymmetric risk

The first conservative runtime policy can now be stated as a sequence of safeguards rather than a formula:

candidate item
    โ†“
is it protected or PIN?
    yes โ†’ KEEP
    no โ†“
is it mechanically redundant (Ladder 0-1)?
    yes โ†’ eligible
    no โ†“
is it recoverable and superseded (Ladder 2-3)?
    yes โ†’ possibly eligible
    no โ†“
does deletion need semantic judgement?
    yes โ†’ ABSTAIN for v1
eligible prune
    โ†“
estimate mutation radius and cache effect
    โ†“
apply now or DEFER

The decision vocabulary needs four words, and the fourth matters most. KEEP, PRUNE, and DEFER cover the decided cases. ABSTAIN covers the honest one: the system cannot establish safety, so it declines to delete. A pruner forced to classify everything deletable-or-protected will eventually delete what it should have questioned. Uncertainty needs a legal outcome, and abstention rates become a first-class metric of policy maturity: falling abstention with steady false-prune rates means growing justified confidence, while falling abstention with rising false prunes means growing recklessness.

The risk asymmetry justifies the conservatism. Keeping an unnecessary 2,000-token log costs tokens, latency, interference, and money, all bounded and measurable. Deleting the only copy of a critical constraint can cost the task, safe behaviour, and irrecoverable evidence. Precision therefore matters more than recall for early pruning, stated as a design bias to test rather than a universal truth:

Prefer few high-confidence prunes over maximum token reduction,

until experiments show a broader policy earning its risk. And the policy’s own price must appear on the ledger. A semantic pruning agent that saves 8,000 tokens at the cost of 3,000 classification tokens, an extra model call, and a cache invalidation may still win, but only counted honestly. Context management itself consumes context and computation, a principle this chapter states plainly because Chapters 11 and 12 will need it even more.

Proposed experiment: one mechanism at a time

The design isolates pruning mechanisms the way earlier chapters isolated variables: deterministic traces with known ground truth, one reduction per condition, downstream tasks that punish both timidity and recklessness. Context Lab does not exist yet; everything below is a frozen proposal.

Construct traces where the fixture knows exactly what each item is: byte duplicates under version control, same-call-different-observation pairs, errored calls with documented residues, superseded observations with checkable subsumption, completed subtasks with recorded consequences, exact constraints, identifiers, rejected alternatives, and trap items an aggressive heuristic would wrongly delete. Six conditions:

A  raw history: no pruning of any kind

B  exact duplicates only: byte-identical or mechanically
   equivalent removal under strict version controls

C  B plus errored-input pruning: large failed inputs removed
   with predefined diagnostic residues preserved

D  B plus C plus superseded observations: older items removed
   only where newer items demonstrably subsume them
   under fixture ground truth

E  aggressive semantic pruning: a heuristic or model decides
   what no longer matters; an upper-risk condition,
   never a proposed production policy

F  oracle prune: exactly the items the hidden fixture marks
   unnecessary for all downstream tasks; the available
   opportunity ceiling

Condition E may choose deletions but must never summarise them: mechanical placeholders are allowed, generated semantic substitutes cross into Chapter 11 and invalidate the run. After pruning, later tasks require active constraints, old diagnostic evidence, rejected alternatives, current file state, completed-subtask residue, and exact identifiers. Some tasks need information that was safe to remove, proving removal harmless. Others need information the aggressive condition likely destroyed, exposing false prunes. A deletion is safe only relative to future use, so nothing is scored at deletion time.

Measure in four groups, never collapsed into one number. Reduction: tokens and items removed by category, net of placeholder tokens introduced, where net active-context reduction equals removed payload minus introduced reference tokens, and where any classifier or policy context consumed by the decision itself is counted as overhead. Preservation: critical and protected items intact, recoverable references working, false-prune count and rate against fixture labels, reported separately from raw volume. Behaviour: downstream task success, critical-evidence recovery and use, unsupported claims, instruction adherence. Economics, inherited from Chapter 9: cache-read, cache-write, and miss tokens, mutation radius with first-divergence position, independently calculated input cost, latency where exposed.

Where ground truth permits, report prune precision, truly safe removals over all removals, and prune recall, safe removals achieved over safe removals available, with the oracle defining the denominator. Early production policy should show very high precision at modest recall; the experiment’s falsification clause is explicit. If exact deduplication yields no meaningful occupancy or cost benefit in realistic traces, if supposedly redundant observations prove behaviourally necessary, if cache-invalidation costs exceed pruning benefits under realistic economics, if deterministic classes cover too little to matter, or if semantic judgement proves so routinely necessary that the delete-without-transform boundary collapses in practice, the book reports that. The experiment is not designed for pruning to win. It is designed so that pruning’s wins and losses are both legible.

Deterministic fixtures establish correctness; they cannot establish relevance. Once the fixture experiment runs, the same policy ladder must be replayed against real long OpenCode traces from the observational corpus, looking for natural instances of every class the fixtures synthesise: repeated reads, duplicate searches, failed calls with huge inputs, old test logs, superseded observations, completed residue. Real traces supply no ground-truth labels, so they cannot score precision; what they supply is prevalence, the base rate of each prunable shape in the wild, and surprise, classes the fixtures never imagined. The separation is deliberate and permanent: fixtures prove a deletion safe, traces prove it matters. A mechanism validated only on synthetic traces is correct about a world nobody inhabits; one validated only on real traces is relevant about claims nobody verified.

The ladder’s rungs compress into one working view:

Candidate Why removal may be safe What must survive Main failure mode
Byte duplicate Proven same bytes, repetition meaningless One intact copy Version drift mistaken for identity
Versioned re-read Same immutable source revision Source reference and revision Mutable source re-read as identical
Failed input bulk Computation already judged; payload spent Error identity, message, diagnostics Input held the only diagnosis
Superseded observation Newer item subsumes older under evidence Subsumption evidence itself Subsumption assumed, never checked
Completed residue Work closed; consequence recorded elsewhere The recorded consequence plus its pointer Dormant dependency wakes later
Predicted irrelevant Heuristic judgement Nothing guaranteed; abstain by default Confident, irreversible error

Worked cases, kept in their place

DCP earns its worked-case status because the chapter derived each mechanism before meeting it. Session history preserved with pre-request placeholder substitution is the irreversibility gradient honoured in production. Same-tool-plus-arguments deduplication keeping the most recent output is Level 0 mechanised, with the chapter’s version caveat standing as the documented limit of string equality. Errored-input purging past a turn horizon with messages preserved is residue policy in its author’s clothes. Turn protection, protected tools and file patterns, and manual alongside autonomous modes are protection and control-mode policy as shipped. The documented cache trade-off, pruning invalidates forward prefixes, is Chapter 9’s ledger quoted back by its implementer. The ordering matters more than the coverage: derived first, recognised second. DCP’s heuristics stay its author’s under AGPL-3.0, studied independently, never copied, never promoted to law. Its separate lossy compress tool, range and message modes with nested summaries, is explicitly not this chapter’s solution; the product containing both deletion and summarisation is itself evidence for the book’s separation of Chapters 10 and 11, and the range machinery waits for Chapter 11’s analysis.

Magic Context earns its place differently, through timing rather than selection. Its agent-marked, runtime-applied reduction queue is the eligibility-versus-timing split running in production: marks propose, cache-safe moments dispose. The book adopts the split and leaves the scheduler, deferring nothing else from that codebase: historian summarisation, tiered compartments, decay rendering, and memory capture all belong to later chapters or the Memory book, cited in Chapter 7 and untouched here. Both codebases are MIT- or AGPL-licensed third-party implementations; the mechanisms enter this chapter as recognised instances of derived policy, with licences recorded and code never imported.

Decision records close the loop

Every destructive decision should be explainable after the fact, and the chapter makes that a structural requirement rather than an aspiration. A prune certificate names the item, the decision, the reason in ladder terms, the evidence consulted, recoverability, known protected dependencies, mutation radius, and application timing with policy version. The certificates live outside the model’s live context, in an append-only experimental record: what was removed, when, why, under which policy, on what evidence. Append-only matters because the audit trail must survive the very pressure that motivated the prune; a decision log subject to its own deletion policy is decorative. This maps directly onto Context Lab’s future records without implementing them: ContextItem describes what the item is, ContextBundle what was rendered, ModelInvocation what the provider did economically, and a new PruneDecision record carries item reference, decision among KEEP, PRUNE, DEFER, and ABSTAIN, reason code, evidence, recoverability, protection state, estimated and actual tokens removed, first-divergence position, mutation radius, application time, and policy version. Fields earn inclusion by experiment use, and every field above is consumed by the proposed measurements, which is the only admission test this book recognises.

What deletion cannot solve

Pruning removes what no longer needs representing. It cannot fix what was never correctly admitted, never correctly ordered, or never correctly classified, and it cannot recover information already destroyed upstream. A bundle admitting distractors needs selection, not deletion. A bundle with evidence in unusable positions needs layout, not deletion. A bundle whose compressor already ate its constraints needs Chapter 11’s post-mortem, not another pass of removal. Even at its best, pruning is bounded by what the trace contains: if deterministic safe classes cover only a few per cent of real coding-agent context, a negative result the chapter explicitly leaves room for, then the main solution lies further down the book, in transformation, externalisation, and better generation of tool outputs at the source. That possibility does not weaken this chapter. A mechanism that knows its ceiling is engineering. One that assumes the sky is method.

And when deletion stops working, when old material still matters but no longer deserves full fidelity, the remaining option is transformation. Summarisation preserves meaning at lower fidelity, which is exactly what pruning refused to attempt, and exactly where information can be destroyed while looking preserved:

Deletion stops working when old material still matters but no longer deserves full fidelity; then compression becomes necessary.

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.” Preprint, arXiv:2508.21433, October 2025 (DL4C workshop at NeurIPS 2025). Masking halves cost at matched solve rates; observations dominate turns. 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 (FSE 2026). Input tokens down two-fifths to three-fifths; cost gap from overhead and cache invalidation. 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, May 2026. Admission-time goal-hinted filtering, orthogonal to history pruning. 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. Fold/mask/prune lifecycles; sidecars; safe and cache-aware commit. https://arxiv.org/abs/2607.00692
  • Tarquinen. “Dynamic Context Pruning Plugin (DCP).” OpenCode plugin, AGPL-3.0-or-later, re-verified September 2026. Dedup, error-input purging, protection, placeholders, cache trade-off. https://github.com/Tarquinen/opencode-dynamic-context-pruning
  • cortexkit. “Magic Context.” Context plugin, MIT at review, verified September 2026. Queued cache-aware reduction; compartments and memory cited only as boundaries. https://github.com/cortexkit/magic-context
  • OpenCode. “Plugins.” Official documentation, verified September 2026. Message, tool-execute, session, and compaction event surface. https://opencode.ai/docs/plugins/