The First Half of the Promise: What Headroom Actually Changes
Headroom can now be judged as more than a collection of compressors. Its content routing, preservation rules, and deliberate passthroughs form a single question: what should remain visible for the model’s next action, and under what contract? This checkpoint connects those ideas so you can evaluate a proposed transformation by its structure, likely usefulness, fidelity, and evidence—not by its compression ratio alone.
The answer is necessarily conditional. A large JSON result may benefit from a compact representation that keeps every row. A repetitive log may benefit from retaining failures and collapsing routine successes. A source file may need an outline for broad reasoning but exact bytes for an edit. The same number of removed tokens can represent a safe structural fold in one case and an unacceptable omission in another.
A block is more than a token count
A practical judgment starts with four questions.
What is the block’s structure? ContentRouter distinguishes arrays, logs, search results, diffs, source code, prose, and mixed material because each form exposes different kinds of redundancy. Repeated field names are not the same problem as repeated “test passed” lines. A diff’s unchanged context can often be reduced, but its changed hunk cannot be paraphrased casually. A code file has syntax and interfaces that a generic text compressor may not understand.
What is the model expected to do with it? The model may need to identify an anomaly, explain a failure, locate a file, reason about an interface, or copy exact text into an edit. Relevance is therefore not an intrinsic property of a row or sentence. It is a relationship between the content and the task. Headroom can use user context and tool-call arguments in some routes, but missing or weak context limits what a relevance-aware choice can know.
Which fidelity contract is required? A byte-exact result preserves the source representation. An information-preserving result may change its form while retaining the underlying data or structure. A CCR-recoverable result may omit detail from the visible prompt while keeping an original in local state. These are useful contracts for different actions; none should be used as a vague synonym for “the model will get the same answer.”
What happens across turns? A result can be locally smaller and still be a poor session-level choice if it rewrites a provider-cached prefix. Conversely, preserving an earlier prefix byte-for-byte may be more valuable than squeezing a few more tokens out of it. The local compressor, CCR store, and provider cache are connected parts of the context path, but they optimize different things.
This gives a more reliable interpretation of a no-op. If the block is small, malformed, instruction-bearing, already cached, patch-sensitive, or not actually shrinking, leaving it unchanged can be the correct result. Headroom’s current design does not delete conversation messages to make a request fit; it changes eligible content blocks and leaves the message list intact. “Nothing changed” can therefore mean that a protection rule won, not that detection failed.