RTK's examples make an odd pair: a 200-line failed test log can lose its passing cases while keeping the failures, but a two-line git push result can lose the repository destination that gave it meaning. a useful compressor has to preserve the evidence for the agent's next decision. RTK and Headroom approach that choice with different information in hand.

1. use the command while you have it

RTK's Bash hook can rewrite a supported command before it runs. for a test command, the command itself is useful context: rtk test cargo test collapses passing cases while keeping failure details. the wrapper also preserves the exit code. a short failure must still be a failure.

$ rtk test cargo test
FAILED: 2/15 tests
test_edge_case: assertion failed
test_overflow: panic at utils.rs:18
schematic output from RTK's test example: passing lines collapse; failure details remain.

the command is a clue, not a guarantee. an agent's built-in Read or Grep call never passes through the shell hook. an open RTK proposal shows a two-line git push origin main result losing its destination repository after compression. the raw output was already short. token count alone would have called that a win.

2. work with the content you actually have

Headroom's proxy or SDK sees the assembled request to the model. that includes file reads and tool results that never reached RTK's Bash hook. the request may not say which shell command produced a block, so Headroom has to recognize what is in it.

ContentRouter routes logs to a filter that keeps errors and stack traces. for JSON arrays, SmartCrusher first tries a compact table with every item; if that saves too little, it selects items such as errors and query matches. short blocks pass through. eligible content changes inside a message; the messages themselves stay in order.

3. keep the omitted lines reachable

the failure line may be enough for the first fix. if it is not, rerunning the test just to retrieve context is wasteful. RTK's recall system saves full output for failed or trimmed commands. rtk recall <hash> reads it without rerunning the command; rtk proxy <command> skips filtering up front. in Headroom's proxy mode, Compress-Cache-Retrieve stores the original block under a hash and lets the model fetch it with headroom_retrieve before it expires. the direct SDK stores the original too, but leaves retrieval wiring to the application.

Headroom proxy's compress, cache, retrieve path In proxy mode, one tool result becomes a short version with a hash marker for the model and a full original saved locally. If the model needs more detail, it calls headroom_retrieve with that hash, and the full result returns from the local store. one result, two versions short result hash=abc123 · sent to model full original saved locally under the hash later, only if more detail is needed headroom_retrieve model asks for hash=abc123 full result returned from the local original
through the proxy, the short result points back to the full original.

the same rule applies to source code. Red Hat's Ripwire shows a map first and expands the full code on demand; its own guidance says to skip the map when one grep would do.

4. leave the cached prefix alone

a provider can reuse an unchanged prefix of the next request. rewrite an old message to shave off a few tokens and the match breaks at that point. the shorter request may cost more because a cheap cache read became fresh processing.

a frozen prefix beside a live compression zone on a repeated request, an unchanged prefix can be read from cache while the live zone is processed. rewriting an earlier byte breaks the match and makes the changed prefix and everything after it uncached. same prefix on the next request frozen prefix byte-identical · cache read live zone compress new output here rewrite an earlier byte changed prefix cache miss from the change onward live zone processed as usual
shrinking an old message can turn a cache read into fresh processing.

Headroom's default cache mode leaves earlier turns alone and compresses only new content. RTK filters shell output before it enters the conversation. for the failed test, the useful rule is concrete: keep the assertion, keep a path back to the full log, and leave the cached prefix untouched on the next call.