RTK: The Tool That Puts Your AI Agent on a Diet
Your coding agent is drowning in terminal noise. RTK strips it out before the LLM ever sees it. Here’s what it actually does, where it shines, and where it quietly makes things worse.
If you use AI coding agents (Claude Code, Cursor, Gemini CLI, any of them) you’ve probably watched this happen:
The agent runs cargo test. 200 lines pour back. 195 of them are progress indicators, ANSI color codes, and “ok” confirmations. The five lines that matter, the three failures and the two warnings, are buried somewhere in the middle.
The agent reads all 200 lines. Every single one counts against its context window. Every single one costs tokens. And here’s the part that should bother you: the agent doesn’t need 195 of those lines to do its job. It needed the failures. It needed the file paths. It needed the error messages. The rest was noise it politely ingested and you quietly paid for.
This is the problem RTK solves. And the way it solves it is worth understanding, because the design is sharper than the name suggests.
What RTK Actually Is
RTK stands for Rust Token Killer. It’s a single Rust binary with zero dependencies and under 10ms of overhead, sitting between your AI agent and the terminal. A proxy.
When the agent runs a command, RTK intercepts the output, compresses it, and passes the compressed version back. The agent never sees the raw output. It sees the signal without the noise.
The mental model is simple:
Without RTK, the agent reads everything the terminal spits out. With RTK, the agent reads a filtered summary of what the terminal spits out.
That’s it. No magic. No LLM-on-LLM inference. Just pattern-matched compression, written in Rust, running locally, faster than you’d notice.
The Four Moves
RTK applies four strategies, chosen per command type:
1. Smart Filtering. Strips comments, blank lines, ANSI escape codes, decorative formatting. The stuff that’s there for human readability but is pure waste for a model.
2. Grouping. Aggregates similar items. Instead of listing 47 modified files one per line, it groups them by directory. Instead of 30 individual lint errors, it groups by rule and file. Same information, fraction of the tokens.
3. Truncation. Keeps what matters, cuts what’s redundant. A git log with 500 commits becomes the 10 most recent with one-line summaries. A successful build’s celebration output becomes ok.
4. Deduplication. The same warning repeated 40 times in a build log becomes Warning: unused import (x40). One line instead of forty.
These aren’t heuristics applied blindly. RTK ships with command-specific filters for over 100 tools: git, cargo, npm, pytest, docker, go test, ruff, prettier, and dozens more. Each command gets a filter tuned to what that command’s output looks like.
A git status that was 30 lines becomes 5. A cargo test with 150 lines of passing output and 3 failures becomes just the 3 failures. RTK claims 60–90% reduction in bash output, and for the commands it knows well, that number checks out.
The Design Decision Worth Noticing
Here’s the part that’s easy to miss if you just install it and move on.
RTK is not a general-purpose text compressor. It doesn’t summarize arbitrary text. It doesn’t use an LLM to compress LLM input (that would be beautifully absurd). It’s a command-aware filter that knows what git diff output looks like, what matters in it, and what doesn’t.
This is the Unix philosophy applied to the agent-tooling layer: know your input format, do one thing to it, do it fast.
The zero-dependency, single-binary design is deliberate too. RTK adds under 10ms of latency. That matters when your agent runs 50–100 commands in a session. A slow proxy would turn savings into overhead. A Rust binary with no runtime doesn’t have that problem.
And it ships as a shell hook, not a manual prefix. Run rtk init -g and every bash command your agent executes gets transparently rewritten. git status becomes rtk git status without the agent or you doing anything. The compression is invisible.
Where It Earns Its Keep
RTK shines in specific, measurable situations:
Noisy test suites. If your test runner produces 300 lines of output for 2 failures, RTK strips it to the 2 failures. The agent wastes no context on the passing tests. This is the use case where the 90% number is real.
Build logs. Cargo, webpack, Next.js. Build tools are chatty. RTK collapses the chatter to errors and warnings. If the build succeeded, you get ok. If it failed, you get the failures. Nothing else.
Large git operations. A git diff across 20 files produces enormous output. RTK condenses the diff to the semantically important changes. A git log of your entire history becomes the recent commits that matter.
Long agent sessions. The compounding effect is the real story. One compressed command saves a few hundred tokens. Fifty compressed commands over an hour-long session can save tens of thousands. In a context window that’s finite and expensive, that compounds into real money and better agent performance, because the context that does remain is higher-signal.
The Part Nobody Wants to Talk About
Now, let me be honest. RTK is not a silver bullet, and the marketing leans harder than the reality in some places.
“60–90% reduction” is bash output, not your bill. RTK’s own documentation says this clearly, but most articles quoting the number don’t. Your total token bill is bash output plus your prompt, plus the system prompt, plus conversation history, plus output tokens. RTK only compresses one of those inputs. The actual reduction on your monthly bill is real but more modest, especially for tasks where the agent thinks more than it runs commands.
The measurement is approximate. RTK estimates tokens as bytes / 4. It ships no tokenizer. The percentages are directionally right, but the absolute token counts on the rtk gain dashboard are rough estimates, not ground truth.
Aggressive compression can backfire. This is the subtle one. If RTK strips a detail the agent actually needed, say a warning that hinted at the root cause or a path that was relevant but looked like boilerplate, the agent has to run the command again to get it. Or worse, it makes a wrong decision based on incomplete information. One JetBrains benchmark found that for low-effort tasks, RTK actually increased costs by about 7.6%, because the overhead of re-running commands exceeded the savings.
The general lesson: any tool that removes information to save money is making a bet that the removed information was worthless. That bet is right most of the time with RTK. But when it’s wrong, the failure mode is an agent that’s faster at being confused.
It only intercepts bash tool calls. If your agent uses built-in tools (like Claude Code’s native Read, Grep, or Glob tools), those don’t go through the shell hook. RTK never sees them. The savings only apply to commands that flow through bash.
The Broader Point
RTK is interesting to me not because of the token savings (though those are real) but because of what it reveals about where we are with AI coding agents.
We’re at a point where the interface between the agent and the system it’s working on is a bottleneck. The agent is smart enough to do the work, but it’s being fed raw, unfiltered data from tools that were designed for human eyes. Terminal output was never meant to be consumed by a model. It was meant to be scanned by a person.
RTK is essentially an adapter layer. It translates terminal output from human-readable to model-optimal. And the fact that this translation saves 60–90% of the output tells you how wildly different those two formats are.
This is probably not where the ecosystem ends up. Eventually, the tools themselves (git, cargo, npm) will likely ship model-friendly output modes natively. Or the agents will get smart enough to selectively ignore noise without a proxy. But right now, in mid-2026, that adapter layer is genuinely useful, and RTK is the best implementation of it I’ve seen.
Getting Started
If you want to try it:
# Install via Homebrew
brew install rtk
# Set up the global hook for your agent
rtk init -g # Claude Code / Copilot
rtk init -g --agent cursor # Cursor
rtk init -g --gemini # Gemini CLI
rtk init --agent antigravity # Antigravity
# Check your savings after a session
rtk gainThat’s it. Restart your agent, work normally, and check rtk gain after an hour.
The Takeaway
RTK does one thing well: it stops your AI agent from reading terminal noise you’re paying for. It does it fast, it does it transparently, and for command-heavy workflows it saves real money.
But the sharper lesson is the one underneath the tool:
The most expensive token is the one that teaches your agent nothing.
Most of what your terminal outputs is noise. RTK kills the noise. Whether that matters for your workflow depends on how noisy your workflow is. Try it, run rtk gain, and the number will tell you.
Find the RTK repository here: github.com/rtk-ai/rtk