Not All Tokens Are Equal

A coding session under capacity pressure holds six items. A project safety rule: never modify production migrations without explicit approval. A test summary: 917 passed, 3 failed. A compiler log of 18,000 tokens. An architecture decision: PostgreSQL is required for this event-store workload. The contents of a source file. An abandoned hypothesis: maybe the serializer is corrupting timestamps.

Pressure arrives, and the harness must yield tokens. The uniform policies on offer are all wrong in different ways. Summarise everything, and the safety rule becomes “be careful with migrations,” which no longer forbids anything. Delete the oldest material, and the architecture decision vanishes while yesterday’s abandoned hypothesis survives on recency. Truncate from the middle, and the file contents go while the log stays. Keep everything, and the request fails at the window. Each policy treats the six items as interchangeable tokens. They are not interchangeable, and the differences between them are exactly what a retention policy needs to know.

This chapter derives those differences. It answers one question, what retention requirements do different context items have, and stops before the next one, how exactly to reduce the context, which belongs to Chapters 10 through 13. Classification is the policy input. Transformation is someone else’s mechanism.

Retention properties, derived from the example

Before naming any classes, the chapter derives the properties that distinguish the six items. Each property is a question asked of an item, and only properties that change a retention decision earn their place.

Exactness. Must the wording or value survive verbatim? The safety rule fails if paraphrased into vagueness; a port number fails if rounded. The test summary survives paraphrase; the compiler log survives aggressive excerpting. Exactness is the property uniform summarisation violates most destructively, because a summary preserves gist by design and gist is precisely what a constraint is not.

Authority. Does the item constrain behaviour? The safety rule governs future actions; the architecture decision constrains technology choice. The abandoned hypothesis constrains nothing. Authority was banked as metadata in Chapter 2 and distinguished from salience in Chapter 6; here it becomes a retention input, because an item that governs behaviour must survive in a form that still governs. A compressed rule that reads as suggestion has lost its authority along with its tokens.

Recoverability. If removed, can the original be fetched again, cheaply and reliably? The source file can: the disk holds the truth and re-reading costs one tool call. The test summary can be recomputed by re-running the suite, at some cost in time. The ephemeral tool result, the vanished reasoning trace, the superseded observation, may be gone beyond reconstruction. Recoverability splits the six items more decisively than any other property: what can be re-fetched need not be carried, while what cannot must be preserved or deliberately abandoned.

Three sub-questions live inside recoverability rather than as separate properties, because they only matter through it. Is this the only copy of the information? Uniqueness raises the stakes of removal but changes no decision on its own. Will later steps need the original rather than a description? Provenance demand determines whether a reference suffices or the bytes must stay. How much does re-fetching cost? A cheap re-read and an expensive recomputation are different policies wearing the same label. Folded together, they keep the property list short while losing none of the decisions.

Relevance. Does the item still matter to the active task? The current failure’s log does; last week’s settled investigation does not. Relevance is task-relative and time-varying, which makes it the most perishable property here and the one most easily confused with importance. An item can be intrinsically significant and presently irrelevant, and retention must follow the latter.

Volatility. Does the item go stale quickly? Test results decay with every code change; architecture decisions decay with every migration. Volatility does not dictate removal on its own, Chapter 20 owns staleness, but it modulates the other properties: a volatile item’s exactness matters less the older it gets, while a stable rule’s exactness compounds.

Cost. How much context does the item consume? The 18,000-token log dominates the arithmetic; the one-line rule is nearly free. Cost never justifies a decision alone, cheap critical items and expensive trivial ones both exist, but it weights every decision: retention classes exist to spend cost where the other properties demand it.

Six properties, each earning its place against the example. Importance, notably absent, is discussed below as the one dimension the chapter refuses.

One item through all six questions

The properties prove their worth on the hardest item of the six: the 18,000-token compiler log. Exactness: no, beyond the failing assertions and their locations, which must survive precisely; the rest is fungible. Authority: none, the log constrains nothing, it reports. Recoverability: costly but possible, a rebuild reproduces it, so the only-copy question answers itself in favour of dropping once excerpted. Relevance: high while the fault is open, negligible the turn after the fix lands, which makes its class time-dependent in a way the rule’s is not. Volatility: high, every edit ages it. Cost: dominant, the single largest line in the bundle. The answers compose into a verdict no single score could reach: excerpt the failures exactly, keep the excerpts while the fault is open, discard the rest, and re-derive if the fault returns. That verdict is a retention policy for one item, and the chapter’s classes are what make such verdicts routine rather than artisanal.

The retention classes

With properties in hand, the placeholder’s five labels can be evaluated rather than inherited. Four survive essentially as proposed. The fifth needs a decision the placeholder blurred.

PIN. Must remain in active context in sufficiently exact form. Active safety constraints, critical current state, the identifiers and values the next actions depend on. Pinned items are exempt from the transformations other classes permit; pressure is relieved elsewhere first. Pinning is expensive and therefore specific: a pinned project file is a budget line, not a precaution.

COMPRESSIBLE. Meaning must remain, but lower-fidelity representation is acceptable. Test summaries, narrative history, background discussion. The class carries an obligation its name understates: compressible specifies what may be lost, never what must be kept, so every compressible item needs its keep-list alongside its class. Without one, compression drifts toward gist, and gist is where exactness goes to die.

EXTERNALIZABLE. May leave active context provided a durable reference and recovery path remain that the system itself maintains. The architecture decision with its rationale stored and reachable, the long specification with a live pointer. Externalisation presumes machinery, storage plus a pointer plus a recall path, which Chapter 13 will own. This chapter records only the requirement: the item’s value must be recoverable on demand through means the system guarantees.

REFETCHABLE. May be dropped outright because the source of truth persists outside the bundle and re-admission is cheap. The source file on disk is the canonical case: delete the contents, keep the path, re-read when needed. The chapter standardises on REFETCHABLE over the placeholder’s RETRIEVABLE because the mechanism is re-reading a known source, not retrieving a ranked candidate; retrieval machinery belongs to Chapter 14, while re-reading a path is an admission the harness performs itself. The distinction from EXTERNALIZABLE is the absence of system-maintained storage: nothing is moved, nothing is indexed, the world simply still holds the bytes.

DISCARDABLE. No expected future value for the active computation, safely removable. The abandoned hypothesis once settled, the duplicated observation, the superseded log. The class is explicitly task-relative: discardable means discardable-for-this-trajectory, not worthless in any absolute sense. An item discarded here may be another computation’s critical evidence, which is why the discard decision is recorded in session state rather than silently enacted. What can be audited can be reversed; what vanishes without a trace cannot even be regretted.

Applied to the opening six, the classification is immediate where uniform policy was helpless, summarised here in one view:

Reasonable people can dispute individual assignments; that disputability is the point. A classification argued over is still a policy. A uniform summariser admits no argument at all.

Retention is not importance

The chapter refuses one dimension deliberately, because the industry keeps offering it as the whole answer. An importance score, however computed, cannot substitute for the property list above. Three cases show why.

An item can be important but externalizable. A hundred-page specification may be the most significant document in the project and still have no business occupying every invocation; its significance argues for guaranteed recovery, not for permanent residence. Scoring it “high importance” and pinning it on that basis confuses value with required presence.

An item can be trivial but exact. A small identifier, a flag value, a port number carries no semantic weight and tolerates no mutation. Scoring it “low importance” and summarising it away destroys information whose value was never in its meaning. Exactness is orthogonal to importance, and any single score collapses the orthogonality.

An item can be highly relevant but refetchable. The current source file matters enormously to this task and can be re-read in one call. Scoring it “high importance” and carrying 18,000 tokens of it through forty turns spends budget for insurance the disk already provides.

Magic Context’s importance scoring is the honest case study here: tiered compartments with importance scores, deterministic age-tiered decay, agent-driven reduction queued at cache-safe moments. As product engineering it is serious work, and its cache-stable layout shows the authors reasoning about exactly the constraints this book tracks. But importance remains one input among several in a well-designed policy, not the policy itself. The book takes the mechanism as evidence that builders independently reached for heterogeneous treatment, and declines to take its scoring as the primitive. What remains after that refusal, the tiers, the decay rendering, the recovery path via transcript expansion, belongs to later chapters’ mechanisms, not to this chapter’s classes.

What uniform summarisation destroys

The retention classes would be mere prudence without evidence that the alternative fails. The Compaction Cliff study supplies it in the exact terms of this chapter’s opening example. Zerhoudi, Mitrovic, and Granitzer measured what Claude Code’s /compact prompt on Sonnet 4.6 does to production agent configurations: after one compaction round, 53 per cent of safety rules survived; after five rounds, 10 per cent. A safety rule and an episodic log competed for the same tokens, both were summarised at the same rate, and only the rule needed exact wording to remain enforceable. The paper’s status requires care: an August 2026 arXiv preprint whose page lists CIKM 2026 proceedings, unverified at time of reading, reporting its authors’ measurements on twenty production configurations. Taken with that reserve, it is the cleanest available demonstration of the chapter’s thesis: uniform treatment of heterogeneous items destroys exactly the items whose retention requirements were strictest.

The same authors’ Knowledge Triage proposal is independent convergence worth recording without adopting. TypeCompact rewrites items in place under per-type fidelity rules; TypeDecompose partitions oversized topics while replicating in-scope safety rules across partitions; TypeRetrieve fetches from external storage with in-scope rules pinned ahead of relevance-ranked results. Each operator is, in this book’s vocabulary, a typed-retention policy wearing an implementation: fidelity per class, replication for pinned items, authority before relevance in recall. The operators themselves, their thresholds, their reported multiples over uniform baselines, are evidence for later chapters to test, not findings this chapter imports. What this chapter takes is the structural point: researchers facing the cliff independently derived classification-then-policy, the same shape as PIN through DISCARDABLE.

A second preprint sharpens the premise from a different angle. Cim et al., studying parallel compaction for long-horizon agent serving, report three properties of generic LLM summarisation that motivate typed treatment: it is inherently lossy, prompt instructions exert weak control over what survives and at what volume, and retained knowledge fluctuates substantially run to run. An operator that cannot reliably say what a summary will keep is an operator that cannot be trusted with pinned items. The unpredictability finding also constrains Chapter 11 in advance: any compaction mechanism the book eventually keeps must demonstrate survival by category across repeated runs, not a single fluent summary.

Builders converged here independently

Two production codebases show practitioners deriving heterogeneous retention without reading this book, and the convergence is evidence for the problem even where their solutions stay theirs.

DCP, the AGPL-licensed OpenCode pruning plugin by Tarquinen, treats different material differently as a matter of course. Protected tools and file patterns survive compression passes; protected tool outputs, subagent and task-planning traces, are appended into summaries rather than dissolved; repeated tool calls are deduplicated to the most recent; errored tool-call inputs are purged after a configurable horizon while their error messages are preserved; pruned spans become placeholders rather than silent gaps. Every one of those is a retention judgment: this must stay exact, this may be summarised, this duplicate may go, this input may go but its verdict stays. The plugin also documents the cache trade-off of its own pruning explicitly, prefix invalidation forward from each edit, which is the honesty this book demands of every reduction mechanism. DCP’s heuristics remain its author’s, studied here as case material under its licence, never copied and never promoted to universal law.

Magic Context, MIT-licensed, converges from the opposite direction: not pruning rules but compartments, importance-scored chronological tiers with deterministic decay rendering, capture of durable knowledge into a typed project memory, PROJECT_RULES, ARCHITECTURE, CONSTRAINTS, CONFIG_VALUES, NAMING, and a transcript-expansion path that recovers original detail on demand. Read through this chapter’s vocabulary, the compartments are compressible tiers with keep-lists, the capture taxonomy is a durability classification orthogonal to live-context retention, and transcript expansion is the recovery path that makes aggressive tiering survivable. Its memory-across-sessions machinery belongs to the Memory book’s territory and to later chapters here; cited in this chapter only as far as live-context retention classes are concerned.

The pattern across the cliff study, the triage proposal, and both codebases is the same: nobody who operates long-horizon agents at scale treats all tokens alike for long. Uniform treatment is a starting position the field grows out of. This chapter gives that growth a vocabulary.

Proposed experiment: typed retention under pressure

The design compares policies, not mechanisms: uniform reduction against typed retention against the bounds that frame them both. The future Context Lab implements the bundle constructors; no result is claimed.

Construct a synthetic bundle containing known item classes: an exact rule whose violation is checkable, current state the task depends on, an architecture decision constraining the solution, a large recoverable file, a verbose tool log, a failed hypothesis with its resolution recorded, a duplicated observation, and ephemeral evidence needed exactly once. Later in the trajectory, tasks require specific subsets: obey the rule, use the state, respect the decision, re-derive from the file, ignore the failed hypothesis, use the ephemeral evidence before it expires.

Five conditions:

A  raw and full: no reduction of any kind (upper bound on survival)

B  uniform summarisation: the same summarisation policy applied to every item

C  uniform truncation: a simple age or size rule applied blindly

D  typed retention: items classified per this chapter, then preserved,
   compressed, externalised, refetched, or discarded per class,
   using only the class definitions, not tuned per task

E  oracle: exactly the information the later tasks require, nothing else

Condition D’s honesty constraint matters: its classifier runs before the later tasks are revealed, with no task-specific tuning, or the comparison tests clairvoyance rather than policy. Condition E bounds the achievable: no policy can beat keeping exactly what is needed, and the distance from D to E measures the classification headroom.

Measure survival by category before measuring behaviour: exact constraints retained verbatim, numeric identifiers intact, decision rationale present, recoverable-source references preserved with working paths, obsolete hypotheses excluded, duplicates removed. Then measure downstream task success. The two-stage scoring creates the distinction Chapter 11 will inherit:

information survived but was not used
        ≠
information was destroyed before it could be used

The first is a retrieval or reasoning failure downstream of intact retention. The second is a retention failure, and no downstream cleverness can recover from it. Uniform policies produce the second failure mode systematically against strict-exactness items; the experiment’s prediction, pre-registered, is that condition B loses exact rules while matching D on compressible narrative, and that condition C loses whatever sat in the wrong positions regardless of class. If D fails to beat B, the retention classes as defined have not earned their keep, and the honest report says so.

What each class hands forward

The boundary with the transformation chapters can now be drawn as interfaces rather than intentions. Each retention class specifies the input contract its future mechanism must satisfy, without specifying the mechanism:

• PIN hands to every later chapter a constraint: pinned items are exempt from reduction, and any mechanism that cannot prove exemption compliance fails the interface. Protection lists like DCP’s are one implementation; the requirement is the chapter’s contribution.
• COMPRESSIBLE hands to Chapter 11 a keep-list discipline: meaning may degrade, listed items must not. A summariser that cannot report survival by category has not met the contract.
• EXTERNALIZABLE hands to Chapter 13 a recovery-path requirement: relocation is permitted only with storage, pointer, and recall the system guarantees. A pointer nobody can follow is deletion with better documentation.
• REFETCHABLE hands to admission-time logic a re-read obligation: the path must be recorded and the source must still exist when needed. Staleness of the source is Chapter 20’s problem; the recorded path is this chapter’s.
• DISCARDABLE hands to Chapter 10 an auditability requirement: removals are recorded in session state with their reasons, so that a wrong discard is detectable and, where the source persists, reversible.

None of those sentences builds the mechanism. Each tells the mechanism’s future author what test it must pass. That is the most this chapter may claim over later territory, and it is exactly enough to make those chapters necessary: each now has a typed input waiting, with acceptance criteria attached.

The compiler’s view of an item

By this chapter’s end, the future Context Compiler conceptually receives items richer than anything earlier chapters described. A small record, prose rather than code, clarifies the model without implementing it:

ContextItem
  source        which subsystem placed it (Chapter 2)
  type          kind of material (Chapter 2)
  position      where it sits; group and adjacency (Chapter 6)
  token_cost    measured size (Chapter 2)
  authority     whose instruction it claims to be (Chapter 2)
  scope         what it claims to govern (Chapter 2)
  freshness     age and volatility state (Chapters 2, 20)
  recoverability  re-fetch cost and path, or none
  exactness     verbatim requirement, or compressible
  retention_class  PIN / COMPRESSIBLE / EXTERNALIZABLE /
                   REFETCHABLE / DISCARDABLE (this chapter)

No scoring formula accompanies the record. The compiler is many chapters away, and a formula now would pretend the weights are known. What the record establishes is the input contract: every later transformation, prune, compress, fade, externalise, recall, will read these fields and state which ones it consulted. A mechanism that cannot say which fields it used has not interfaced with the policy; it has merely deleted text.

Freshness appears above with a forward reference because volatility without staleness machinery is incomplete; Chapter 20 will own decay of validity, and this chapter claims only that volatility modulates retention, not that it resolves it.

What classification makes necessary

Uniform treatment having failed in evidence and typed treatment having earned its vocabulary, the pressure-relief question returns transformed. It is no longer “what can we cut” but “which transformation does each class permit”: removal for the discardable, summarisation for the compressible under keep-lists, relocation for the externalizable through guaranteed paths, re-reading for the refetchable, and exemption for the pinned. The transformations themselves are still unbuilt, deliberately so. But a second way to relieve pressure was deferred several chapters ago and never examined: instead of choosing more carefully what the runtime sends, change the machinery that processes it. Bigger, cheaper, longer-capable models alter every budget this book has drawn. That alternative deserves its hearing before the reduction chapters begin:

With information classes established, examine the other way to relieve pressure: change the model architecture itself.

References

• Zerhoudi, S., Mitrovic, J., Granitzer, M. “The Compaction Cliff in Long-Running AI Agent Memory.” Preprint, arXiv:2608.22752, August 2026 (page lists CIKM 2026 proceedings, unverified). Uniform compaction preserves 53% of safety rules after one round, 10% after five; Knowledge Triage operators. https://arxiv.org/abs/2608.22752
• Cim, M., Topcu, B., Das, C., Kandemir, M. T. “Parallel Context Compaction for Long-Horizon LLM Agent Serving.” Preprint, arXiv:2605.23296, May 2026. Summarisation lossy, weakly controllable, run-to-run unpredictable. https://arxiv.org/abs/2605.23296
• Tarquinen. “Dynamic Context Pruning Plugin (DCP).” Open-source OpenCode plugin, AGPL-3.0-or-later, verified September 2026. Protected tools/outputs/patterns; dedup; error-input purging; cache trade-off documented. https://github.com/Tarquinen/opencode-dynamic-context-pruning
• cortexkit. “Magic Context.” Open-source context plugin, MIT at review, verified September 2026. Tiered compartments; importance; deterministic decay; capture taxonomy; transcript expansion. https://github.com/cortexkit/magic-context
• Anthropic Applied AI team. “Effective context engineering for AI agents.” Published 29 September 2025. Smallest high-signal set; compaction and note-taking as long-horizon techniques. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents