Saved 99 % and didn’t notice a thing - two months with RTK

RTK - Rust Token Killer - I stumbled upon it via an AI newsletter, and with current token costs, curiosity quickly outweighed skepticism. I installed it and spent two months tracking what this thing actually does: on a Linux machine with Claude Code, in my personal projects. All numbers in this article come from that setup. The result at the end is something I didn’t expect - but not in the direction you’d assume.

The starting point is simple: when a coding agent spends half the day in the terminal, you pay for every line of boilerplate. For every git status with eleven lines of porcelain output, for every test run where 200 green lines scroll through and exactly one red line matters. The idea of putting a filter in between sounded obviously right at first.

What RTK actually does

The name is pretty literal. RTK is a CLI proxy: a single Rust binary with no runtime dependencies that sits between your command and the agent. git status becomes rtk git status. RTK runs the actual command, compresses the output, and only passes the condensed version to the agent.

The charm of it: you don’t have to do anything differently. A PreToolUse hook automatically rewrites the commands, and the agent doesn’t notice a thing. No account, no API keys, no telemetry, Apache 2.0 - the code lives on github.com/rtk-ai/rtk.

The whole thing is advertised with 60-90 % token savings. Keep that number in mind; we’ll come back to it.

Installation on Linux

The least spectacular part of this article, and that’s a compliment. Got the binary, dropped it in the PATH, done:

rtk --version

I’m running 0.37.2 at the moment. Then the Claude Code integration:

rtk init --global

That writes the hook into the Claude Code configuration. Restart Claude Code once, and from then on it runs. No config you need to understand, no tweaking, nothing. That’s exactly how a tool that wants to work in the background should be.

From then on, RTK ran with every command - and I kept checking the statistics over the weeks.

I use the same setup on my Windows machine with Claude Code too: same binary, same command, same process. But the numbers below come exclusively from the Linux system.

The numbers after two months

768 commands, 10.5 million input tokens, 10.4 million saved. 99.0 %. The efficiency bar glows green, and for roughly three seconds you feel amazing.

Then you look at the daily breakdown, and the picture flips.

The 99 % is a single day. June 15th: 116 commands, 9.9 million input tokens, 99.8 % saved. This one day accounts for roughly 95 % of my total savings. Everything else - 14 more days, 652 commands - comes to about 552,000 input tokens and 460,000 saved together. That’s 83 %.

Mind you: 83 % is a good value and sits squarely in the advertised range. It’s just not the same as 99 %.

The variance is enormous. My daily values range from 10.1 % to 22.1 % to 98.4 %. There’s no typical day. There are days when RTK pulls out a solid amount, and days when it barely does anything.

And what I find most interesting: The commands I run most frequently are the ones where there’s least to gain. rtk read tops the usage chart with 94 calls by a wide margin - and saves an average of 4.5 %. For rtk grep it’s over 53 calls with an average of 7.7 %. The savings come from the outliers: ESLint at 99.6 %, curl responses at 99.4 %, Vitest at 79 %.

Daily work brings little. The peaks bring everything.

June 15th

What specifically happened that day, I honestly can’t remember anymore. The number stuck with me, but there’s nothing special in my calendar, and reconstructing the workday retrospectively isn’t possible.

What I can reconstruct from the data: rtk grep ranks first in the command table with 9.9 million tokens saved - at an average savings of 7.7 %. That only works if a single grep produced absurdly much output, eclipsing everything else. Probably over a directory I should have excluded. node_modules, target, something on that scale.

And that’s the point where I view RTK differently than before. Those 9.9 million tokens wouldn’t just have made my context window expensive - they would have blown up the session. Context full, session over, possibly mid-something important.

So RTK doesn’t save me 80 % every day. It catches that one day when a single command would have exploded everything. That’s a different value proposition than advertised - but not a smaller one.

What the numbers don’t say

You have to be honest here: rtk gain measures how strongly RTK compressed the terminal output it touched. That’s not the same as “my session now costs 99 % less.”

JetBrains ran a paired A/B benchmark with Claude Code in July and came to a sobering result: at low reasoning effort, the run with RTK was 7.6 % more expensive, and at high effort the difference was zero. The quality of results remained unchanged in both cases.

That’s not a contradiction. Both numbers can be true at the same time. RTK demonstrably compresses strongly - but whether that makes the session cheaper depends on what fraction of total consumption terminal output is and whether the agent needs to ask again because information is missing. If it has to ask twice, the advantage is gone.

My own impression aligns with this: I didn’t notice anything in daily use. No noticeably longer sessions, no aha moment - and that despite paying attention to it. What happens is only visible in the statistics. For a background tool, that might actually be the best testimonial you can give - but don’t expect miracles.

The other worksite: VS Code with GitHub Copilot

Second strand, and it’s explicitly still experimental: RTK on Windows with VS Code and GitHub Copilot. None of the numbers above come from this setup - so far it’s just about whether I can get it running reliably at all.

Installation is also straightforward - binary to C:\Tools\RTK, folder into User-PATH, fresh PowerShell. Copilot integration then runs through its own switch:

rtk init --copilot --global --dry-run
rtk init --copilot --global

The dry-run is a good idea and shows in advance which files would be created - for me exclusively under %USERPROFILE%\.copilot. After that, close VS Code completely and restart it, otherwise Copilot won’t load the configuration.

That’s the theory. In practice, this was the considerably rougher part. The Claude Code integration was worlds simpler, and RTK seems to do more there too. With Copilot, on the other hand, I had cases where RTK apparently blocked requests to Copilot or their responses - the process just didn’t go through. I haven’t fully figured out what exactly goes wrong there.

Interesting: Claude Code runs on the same Windows machine without issues. “Windows is just Windows” as an explanation falls short - the difference seems to lie more with the Copilot integration than the operating system.

On Linux with Claude Code, RTK has been running smoothly for two months. With Copilot, it’s still on the workbench.

Conclusion

RTK is a well-built tool that addresses a real problem - just not quite the problem that marketing describes. If you expect the bill to be 80 % smaller starting tomorrow, you’ll be disappointed. If you understand it as a safety net against output explosions, you get exactly that.

With Claude Code it stays installed - on both machines. Setup takes two minutes, it doesn’t get in the way daily, and that one June 15th moment justifies it for me alone.

With GitHub Copilot it’s still an experiment. It stays installed, I’m still tinkering with it - but I can’t recommend it in this state, and there are no solid numbers from there either.

And a side effect I didn’t expect: rtk gain --daily is a surprisingly honest mirror of your own work habits. You see in black and white on which days the agent did meaningful work and on which days it mainly just read files. That alone makes checking it regularly worthwhile.