AI news · Tools
RTK vs. Headroom:
input compression compared.
DE Auf Deutsch lesen
Both tools attack the same spot: before a tool output, a log, or a file reaches the model. RTK is a shell hook written in Rust that I've been running in production for months. Headroom is a larger, ML-driven proxy from a former Netflix engineer. I installed both and compared them with real numbers.
audit-reads, which works without a running proxy and evaluates real Claude Code
transcripts. Both datasets are genuinely measured, just at different points in each tool's
pipeline.
What both tools do
| RTK | Headroom | |
|---|---|---|
| Form | Shell hook (Rust), rewrites commands transparently | Library, local proxy, or MCP server (Python) |
| Approach | Rule-based trimming per command (Bash, Grep, Read, Git, …) | ML-driven compression: embeddings, semantic caching, compressors per content type |
| Operation | lightweight, no model of its own | own service with an ONNX embedder, optional code-graph indexing |
| Origin | standalone tool, in use for months | open source, former Netflix engineer |
| Claimed savings | 60–90% depending on command | 60–95% on JSON, roughly 20% for coding agents in general |
RTK: the real production numbers
Transparent trimming per command
Rust CLI proxy · switched in transparently via a hook before Bash commands
RTK automatically replaces commands like git status or npm test
with a filtered variant, without me consciously invoking it day to day. The overall balance
across all projects, as of this post:
| Metric | Value |
|---|---|
| Total commands | 7,253 |
| Saved | 1.1M tokens (38.3%) |
rtk read | 809 calls, avg. 9.9% saved |
rtk grep | 1,154 calls, avg. 17.5% saved |
rtk vitest run | 13 calls, avg. 94.0% saved |
rtk git diff HEAD~3 HEAD | 1 call, 90.6% saved |
A concrete example from practice: a verbose test run in the PlantWiz backend
(vitest run --reporter=verbose, 205 tests across 27 files, each with its own
result line) produced 25,259 characters of raw output. RTK automatically trimmed it to about
2,000 characters, with a pointer to the full log file in case the details are needed after all:
A real test run, trimmed automatically
PlantWiz backend, without being asked to.
Headroom: audit-reads as a safe entry point
Compression layer with its own model
PyPI package headroom-ai, version 0.37.0 · CLI with over 30 subcommands
Headroom is much more than a compressor: headroom --help lists commands for
memory management, cost budgets, semantic caching, code-graph indexing, and a learning mode
that extracts patterns from past traffic. The actual compression runs through
headroom proxy, a service that sits between the client and the Anthropic or
OpenAI API (ANTHROPIC_BASE_URL=http://localhost:8787 claude). An independent,
command-level number comparison like the one for RTK above would need that service running
continuously, which wasn't in scope for this post.
Headroom does bring a second, lightweight command that works without a running proxy:
headroom audit-reads reads only local Claude Code transcripts and estimates how
many bytes accrue per tool and how much of that would be addressable. A dedicated PlantWiz
transcript directory doesn't exist, because I work there through an additional working
directory rather than a session of its own, so the command instead evaluated all 216 locally
stored sessions across projects:
| Tool | Share of tool bytes |
|---|---|
| Bash | 45.5% (5.5 MB, approx. 1,372K tokens) |
| Read | 20.1% (2.4 MB, approx. 607K tokens) |
| WebSearch | 13.6% (1.6 MB, approx. 409K tokens) |
| Browser automation | 7.7% (929 KB, approx. 232K tokens) |
| WebFetch | 3.9% (465 KB, approx. 116K tokens) |
Bash output is clearly the biggest chunk at 45.5%, exactly the commands RTK already
intercepts. Among the Read calls, audit-reads found a gap RTK doesn't
close: 44.9% of the bytes read came from stale reads, files that were read and then
edited, with the old version still sitting in context. RTK trims individual command output but
doesn't track whether an earlier file has gone stale due to a later edit.
Direct comparison
| RTK | Headroom | |
|---|---|---|
| Operating overhead | lightweight hook, no model of its own | full proxy with ONNX embeddings, own service |
| Basis for measurement | real production use, 7,253 commands | own analysis command on 216 sessions, no live proxy |
| Largest measured saving | −94.0% on test runs | no own compression rate measured, distribution only |
| Known gap | no read-lifecycle tracking | live operation is heavier than a shell hook |
| Reach | anything that runs through the shell | additional library/MCP mode for non-shell paths, e.g. API responses handled directly in code |
Which tool for which situation
No compression hook in place yet
RTK or a comparable lightweight shell hook is worth adopting first, because it hits exactly the biggest cost center, Bash output, with no added operational overhead.
A shell hook is already running
Headroom's read-lifecycle feature (detecting stale reads) is the concrete gap a pure command hook doesn't close. Before installing the full proxy, it's worth asking whether this one feature justifies the operational overhead.
Contexts outside the shell
API responses handled directly in your own code, such as JSON from an external interface, are out of reach for a shell hook. Headroom as a library would be the more natural fit there; RTK stays unused in that path.
Which tools does your team actually need?
I evaluate token tools and Claude Code configurations against real project code before a team pays for them. A 30-minute intro call, free of charge.