RTK: a thin filter between your CLI and your agent's context window

If you've run an AI coding agent through a real session, you've watched the context window fill up with things that have nothing to do with the problem you're solving: a hundred lines of cargo build compiler warnings, a full npm install tree, a git log dump you only needed the last three lines of. None of that helps the model reason. All of it counts against the window.

RTK ("Rust Token Killer") is a small open-source tool built specifically for that gap. It doesn't touch your code or your agent's reasoning. It sits between the command you run and the output your agent sees, and strips the noise out of that output before it ever reaches the context window.

How it works

RTK installs as a hook, not a wrapper you have to remember to invoke. For Claude Code specifically, rtk init --global drops a PreToolUse hook into your settings: every Bash tool call gets rewritten to pass through RTK automatically, with no change to how you or the agent issue commands.

The mechanism is straightforward. RTK runs the command, parses the output for the tool it recognizes (it currently covers 125+ commands across build tools, test runners, git, package managers, and search), and returns a condensed summary instead of the raw stream. The project's own example is a good illustration: a cargo build that would normally dump 1,042 lines (dependency compilation, two warnings buried in the middle, a final status line) comes back as four.

$ rtk cargo build
✓ build finished in 32.4s
· 214 crates compiled
· 2 warnings: filter.rs:214, tree.rs:87

Nothing about the underlying command changes. You're still running cargo build. RTK is only deciding what's worth putting in front of the model afterward.

Why the risk is low, with one real caveat

Rust, Apache 2.0, a CLI-hook-and-proxy architecture. There's no black box making the filtering decisions, and the codebase is small enough to actually read if you want to check what it strips. The free CLI processes output on your own machine, so your code and command output don't need to leave the box for it to do its job, and it doesn't touch what the underlying command actually runs. RTK filters what the agent sees, not what executes; the raw output is still sitting in your terminal's own scrollback, so nothing is being blocked, only summarized before it's forwarded. The project claims under 20ms of overhead per call, which is the right order of magnitude for a filter step that's supposed to stay invisible.

The one place to actually pause is the quick-install path: curl | sh, piping a remote script straight into a shell. That deserves the same scrutiny any fetch-and-execute install does, no matter how trustworthy the source looks. Read the install script first, or use the Homebrew tap or a pinned release binary instead, so you know exactly what's landing on your machine before it runs. That's an install-hygiene question, not a knock on RTK's design.

Worth separating out: RTK Pro, the paid team tier, adds a control plane that aggregates usage and applies guardrails across a team, which by definition means more than local, single-machine processing. Everything above is scoped to the free, open-source CLI. A team layer changes the trust boundary and deserves its own look before adopting it.

The improvement

The pitch is a context-budget argument, and it holds up. In the project's own example session, CLI output and logs alone accounted for 18% of a Claude Code context window that was already at 86% used, close enough to auto-compaction to be actively costing reasoning quality. Filtering that output down dropped total usage to 73% in the same session, without losing anything the agent actually needed to see.

Less context spent on noise means more of it available for reasoning, and auto-compaction, which resets accumulated context, kicks in less often. Over a long session that adds up: fewer resets, fewer tokens spent on warnings nobody was going to act on, and an agent that isn't hunting for the one relevant line in a 1,000-line build log.

It's a small idea, delivered as an install-and-forget hook instead of a workflow change. That's probably why it's worth trying instead of just reading about.