Coding agents waste a large share of their context window on CLI noise: verbose git logs, passing test output, directory listings nobody asked for. We started routing our agents’ shell commands through RTK AI, an open source CLI proxy that filters command output before it reaches the model. Measured on our own machines, RTK saved 49.6% of tokens across 1,457 commands, with no noticeable slowdown. This post covers how RTK works, our verified numbers from Claude Code, Codex, and OpenCode, and the honest limits we found along the way.
Why coding agents burn tokens on CLI noise
Every time Claude Code or Codex runs a shell command, the full output lands in the model’s context. A git log -p can be thousands of lines. A test suite prints hundreds of green checkmarks to tell you one thing: everything passed. The model has to read all of it, on every subsequent turn, until the session ends or the context is compacted.
Anthropic’s engineering team frames the problem directly in Effective context engineering for AI agents: context “must be treated as a finite resource with diminishing marginal returns”, and the goal of context engineering is finding the smallest possible set of high-signal tokens that gets the job done. Raw CLI output is the opposite of high signal. Most of it is ceremony.
This is not just a quality problem, it is a cost line. Anthropic’s own Claude Code cost documentation reports an average of about $13 per developer per active day, roughly $150 to $250 per developer per month at typical usage. The same page documents the exact pattern worth productizing: a hook that rewrites verbose commands into filtered ones can turn “tens of thousands of tokens into hundreds”.
An agent asked to ignore noisy output still pays to read the noise. The only way to actually save the tokens is to filter the output before it enters the context.
What RTK is and how it filters output
RTK AI (Rust Token Killer, rtk on the command line) is, in the project’s own words, a “CLI proxy that reduces LLM token consumption by 60 to 90% on common dev commands. Single Rust binary, zero dependencies.” It is Apache-2.0 licensed, written in Rust, and at the time of writing sits at 69,900+ GitHub stars with v0.43.0 as the latest release.
Mechanically, RTK sits between the agent and the shell. It runs the real command, then compresses the output with four strategies before the model sees it:
- Smart filtering: drop noise such as passing tests, progress bars, and verbose logs.
- Grouping: aggregate similar items instead of listing every one.
- Truncation: keep the relevant context, cut the rest.
- Deduplication: collapse repeated lines into one line with a count.
It covers the command families agents actually use: file operations (ls, find, grep, read, diff), git (status, log, diff, commit, push), test runners (pytest, vitest, cargo test), linters and builds (eslint, tsc, ruff, clippy), package managers, and cloud tooling (AWS, Docker, kubectl).
Filtering is lossy by design, so RTK ships an escape hatch: rtk proxy <cmd> runs any command as a raw passthrough when you genuinely need the full output, for example while debugging. One long-term user in a Hacker News thread on RTK called it “pretty solid” and named the one real friction point: occasionally an output you need for troubleshooting gets suppressed, and you rerun it raw. That matches our experience exactly.
How we wired it into Claude Code, and what the numbers say
Installation took two commands on a Mac:
brew install rtk
rtk init -gThe init step installs a PreToolUse hook into Claude Code’s settings. From then on, every Bash tool call is rewritten transparently before execution: the agent writes git status, the hook turns it into rtk git status, and the filtered output is what enters the context. Zero prompt overhead, no behavior change visible to the agent.
After a few weeks of daily use, rtk gain reports the verified totals from our machine:
The headline numbers, straight from the analytics:
- 1,457 commands routed through RTK.
- 1.3M input tokens filtered down to 645K, so 633.4K tokens saved (49.6%).
- Average execution overhead of under 800ms per command, most of which is the underlying command itself. Filtering added milliseconds, not seconds.
The per-command breakdown is where it gets interesting. File reads saved the most in absolute terms (333.7K tokens). But the most dramatic ratio was git log with patches: 98.4% of the output filtered away, because a patch log is almost entirely diff ceremony the model rarely needs. Grep calls, our highest-volume command at 444 invocations, saved a steady 20.9% each.
One honest caveat on what these numbers mean. RTK counts the difference between raw and filtered output tokens. That is not the same as your API bill shrinking by 49.6%: with prompt caching, cached input tokens already cost 0.1x the base price, so the billing effect of removed tokens varies by how often they would have been reread. The more direct win is context budget: every filtered token is context the agent can spend on code instead of ceremony, which means longer sessions before compaction and better focus. RTK’s own README says the same thing plainly: “Estimates based on medium-sized TypeScript/Rust projects. Actual savings vary by project size.” We appreciate a tool that hedges its own benchmark.
What rtk discover found in our history
RTK ships a second analytics command, rtk discover, which scans your agent history for commands that bypassed the proxy. On our machine it scanned 2,229 sessions and 37,238 Bash commands from the last 30 days and found roughly 4.3M more tokens we could have saved: thousands of grep, git, ls, and tail calls that ran raw because they predated the hook or slipped past it.
Scanned: 2229 sessions (last 30 days), 37238 Bash commands
grep -n 2682 calls ~1.7M tokens saveable
git -C 3353 calls ~1.0M tokens saveable
tail -n 709 calls ~489.8K tokens saveable
ls -la 1679 calls ~488.7K tokens saveableTwo takeaways from that scan. First, the savings compound with volume: an agentic team runs tens of thousands of shell commands a month without anyone noticing. Second, the hook has a documented boundary: it only intercepts Bash tool calls. Claude Code’s built-in Read, Grep, and Glob tools do not pass through the Bash hook, so a meaningful share of an agent’s file access never touches RTK. Worth knowing before you expect the full 60 to 90% from the README headline.
Beyond Claude Code: Codex and OpenCode on our cloud VM
We run part of our operations on an OVHcloud VM: unattended agent loops on Codex and OpenCode rather than Claude Code. RTK supports both, through different mechanisms, and the difference matters.
- OpenCode gets a real plugin (
rtk init -g --opencode) that interceptstool.execute.before, the same hard rewrite guarantee as the Claude Code hook. This is what we wired on the VM. - Codex has no hook mechanism, so RTK integrates via instructions in
AGENTS.md(rtk init -g --codex). The model is asked to prefix commands withrtkrather than forced to. In our experience prompt-level steering works most of the time and silently degrades when the model forgets, so we treat the Codex integration as best-effort.
The VM rollout is recent, so we do not have a month of accumulated numbers there yet, and we will not quote projections as measurements. The architecture point stands on its own: on a headless box running unattended loops, nobody is watching the context window, so output filtering is worth more where no human can notice the waste.
Should you install it?
If you run Claude Code, Codex, or OpenCode daily, the case is straightforward. RTK is free, open source, installs in two commands, and is trivially reversible (rtk proxy per command, or remove the hook). Our measured 49.6% saving is below the project’s 60 to 90% headline and above what we expected, which is about the right shape for a tool claim. The independent evidence base is still thin, mostly the project’s own estimates and a couple of quiet Hacker News threads, so run rtk gain after a week and trust your own numbers over anyone’s benchmark, including ours.
The broader lesson connects to something we wrote in Coding is no longer the bottleneck: when agents write the code, the constraint moves to everything around the code. Context is one of those constraints. A model reasoning over 23K tokens of signal outperforms the same model wading through 118K tokens of ceremony, and the cheapest token remains the one you never send.