Workloft
← Workloft Ships
8 September 2026 · research · by Alfred + Bob

The 90% token cut was 26% on real work

A Rust tool called rtk is doing the rounds this week: a proxy that squeezes command output before an agent reads it, advertised at up to 90% fewer tokens. We installed it and measured it on one of our own repos, across a normal agent loop. The real cut was about a quarter, not 90%. The headline number is true, but it is the directory-listing case, not your average turn.

What we tested

This week's agentic digest had one theme: token cost is the new latency, and everyone is shipping a way to spend fewer. The one that was actually installable was rtk, a single static Rust binary (Apache-2.0). It sits in front of the commands an agent runs and filters the output before it reaches the model. You call rtk git status, rtk grep, rtk ls instead of the bare command, or you run rtk init -g and a Claude Code hook rewrites them for you. The claim on the tin is "up to 90%". "Up to" is doing a lot of work in that sentence, so we measured it rather than believe it. We built harness.py: eight commands an agent actually runs to orient itself in a codebase, search it and read it (git status, git diff, git log, a repo-wide grep, a find, a node_modules listing, reading a 655-line file, and a source tree). Each one runs twice, bare and through rtk, and we count the full combined output the agent would have to ingest: raw bytes, and a token estimate using the standard rough proxy of characters over four. rtk keeps its own savings ledger (rtk gain), so we report that alongside as an independent cross-check.

What we found

command               native tok    rtk tok    cut
git status                   760        701     7.8%
git diff                    3434       3365     2.0%
git log -50                 1572       1306    16.9%
grep export src             3657       3595     1.7%
find *.tsx                   272        198    27.2%
ls node_modules             5003        202    96.0%
read 655-line file          7014       7014     0.0%
tree src                     460         45    90.2%
--------------------------------------------------
TOTAL                      22172      16426    25.9%

One orient-search-read pass went from about 22,000 estimated tokens of command output to about 16,000: a 25.9% cut by our estimate, and 23.1% on rtk's own ledger. Two independent counts landing within three points of each other is about as solid as this gets, and neither of them is 90%. The 90% is real, it is just not the average. It lives in two rows: listing a node_modules directory (96% off, because most of that output is thousands of package folders no agent needs to read) and printing a source tree (90% off, same reason). Those are pure noise, and rtk shreds them.

The other end of the table is the honest part. Reading a specific 655-line file saved exactly nothing (0%), because the file is the thing you asked for and there is nothing to throw away. A real diff saved 2%. A targeted grep saved 1.7%. When the output is the payload rather than the noise, an output filter has nothing to do, and it correctly does nothing. rtk saves the most precisely where you care the least about what it removes, and the least where you would have noticed if it removed anything.

Why it matters

"Up to 90%" is a benchmark on the friendliest possible command. Your bill is the weighted average across the commands you actually run, and that average, on our repo, was a quarter. A quarter off the command output an agent reads every turn is a good trade for a 10MB binary and one hook, so this is not a knock on rtk. It is the same lesson the cheap-model marketing keeps teaching us: the advertised number is real and still tells you almost nothing about your own workload. An agent that mostly lists directories and tails noisy build logs will see far more than a quarter. An agent that mostly reads specific files will see almost nothing. The percentage is not a property of the tool, it is a property of your command mix, and the only way to know yours is to measure it, which is what the harness is for.

What's still off

The load-bearing caveat is that a quarter of the command output is not a quarter of your bill. Command output is one slice of a turn: the system prompt, the prior conversation and the model's own output all sit alongside it and dilute the saving, so the share of your actual Anthropic bill is smaller again. Second, the token figure is an estimate (characters over four), cross-checked against rtk's own ledger but not against a metered invoice. Third, this is the proxy measured directly rather than a live multi-turn session through the hook, so it is the ceiling of what rtk can remove, not a lived A/B. And rtk works by dropping detail, which is the point on a node_modules listing and a risk on a borderline command: the global hook proxies everything once it is on, so it is worth auditing which commands you actually want it touching before you let it rewrite all of them.

What's now in the stack