Putting My AI Agent on a Token Diet: 36,000 Commands Through RTK

The Hidden Bill in Agentic Coding

When an AI coding agent works, the loop looks like: run a command, read the entire output, decide, repeat — hundreds of times a session. And raw terminal output is spectacularly wasteful for a model to read. A vitest run prints a progress bar, per-file timing, and a wall of green checkmarks; the agent needs roughly one line of it. ps aux prints every process on the machine; the agent wanted one.

Tokens are the metabolism of this workflow: every wasted one is money, latency, and context-window space that could have held actual code.

So everything my agent runs goes through RTK ("Rust Token Killer") — a CLI proxy that executes the real command, then filters and compresses the output before the model sees it. A Claude Code hook rewrites commands transparently (git status becomes rtk git status), so the agent doesn't even know it's on a diet.

---

The Numbers, Straight From rtk gain

Months in, the analytics say:

Total commands:    36,424
Input tokens:      4.7M
Output tokens:     2.0M
Tokens saved:      2.7M (58.3%)
Avg exec overhead: 1.2s

58% of everything my agent would have read never reached it. The per-command breakdown is where it gets interesting:

Command	Savings	Why
vitest run	88%	Test output is ceremony; the agent needs failures and the count.
ps aux	99%	Almost pure noise. One 800K-token category collapsed to ~8K.
eslint	99.9%	A clean lint run compresses to, effectively, "clean."
git log -p	97%	Full patch history → the parts that matter.
grep	21%	Already dense; grep output is signal, little to trim.
read (file reads)	10%	Code can't be summarized away before the model reasons on it — rightly conservative.

That last pair is the sanity check: a good filter saves the most where output is most redundant and almost nothing where output is already information-dense. If grep savings were 90%, I'd be worried it was eating results.

---

The Two Gotchas

Honesty section — a middleman between your agent and your shell has failure modes, and I hit both:

1. The stale success. RTK once intercepted a git push and reported "up-to-date" from a cached code path without the push having actually gone through. The agent believed it, I believed the agent, and ten minutes later I was staring at a CI run testing last week's commit. Anything with side effects should pass through raw — filtering is for reads.

2. The swallowed destructive flag. A find … -delete got rewritten and intercepted by the wrapper in a way that didn't do what the raw command would have. Harmless in my case, but the lesson generalizes: the wrapper needs an explicit bypass (rtk proxy <cmd>) and the discipline to use it whenever a command mutates rather than reports.

Both were fixable with configuration; neither was obvious until it bit.

---

Is It Worth It?

2.7M tokens is nice, but the bigger win is subtler: context-window headroom. My agent sessions stay coherent longer because they aren't 40% test-runner progress bars. Long agentic sessions degrade when the window fills with junk — compressing tool output is the cheapest form of context management there is.

Would I recommend it? With the two rules above tattooed somewhere visible: filter reads, never writes — and audit what the filter drops before you trust it with anything that matters.