why use many token when few token do trick
was the cover-line of caveman, one of the most hyped Claude Code skills there is to date.
It essentially lets your agent talk like a caveman: short, concise, grammatically incorrect, but who cares?
Caveman
I tested caveman for a while and did not like it much. I understand the appeal of a less chatty agent harness. Its output is easier to review, and it is easier to stay in the loop. But I want actual discussions, not the feeling that I am talking to a literal caveman.
Caveman works by telling Claude Code to drop articles, filler words, and everything else that makes a conversation sound natural. The main skill consists of 74 lines of markdown. That is it.
/btw: The /caveman-review skill, also available separately, is still useful to me. It is fast, points out mistakes and fragile code, flags bug risks, and does it in a one-liner.
RTK & the output/input paradox
I found another solution that works completely differently. RTK, short for Rust Token Killer, removes noisy output from CLI tools the agent is using and replaces it with a shorter, still fully informative version. This means it kills the input tokens the agent receives, not the output tokens it generates.
Output tokens usually cost more: on my daily driver, Claude Sonnet 4.6, input costs $3 per million tokens and output costs $15. That is a 5x difference.
Output looks like the obvious target. But in a real coding session, input tokens outnumber output tokens by roughly 3:1. A typical 100k-token session has about 75k input and 25k output. Only a fraction of that output, maybe 6k tokens, is prose caveman can compress. Saving about 65% there removes roughly 4k tokens.
RTK instead attacks hundreds of CLI command outputs on the input side, compressing each by 60-90%. The absolute savings are much larger despite the lower price per token.
| model | input | output |
|---|---|---|
| gpt-5.5 | $5.00 | $30.00 |
| claude-opus-4.7 | $5.00 | $25.00 |
| claude-sonnet-4.6 | $3.00 | $15.00 |
The table makes caveman look strong on paper. But input tokens are the bigger pile in every session. That is where RTK works.
RTK does this through four strategies:
- smart filtering
removes comments, whitespace, boilerplate - grouping
aggregates similar items like files by directory or errors by type - truncation
keeps relevant context, cuts redundancy - deduplication
collapses repeated log lines with counts
It is a single Rust binary with zero dependencies. Its hook transparently rewrites Bash commands before the agent sees their output. Claude never knows it is running through a proxy.
Backed by benchmarks
Ever since switching to Pi, I have already noticed I am burning way fewer tokens per session and therefore spending less money overall. Since adding RTK via the pi-rtk-optimizer plugin, even extensive research sessions with hundreds of CLI tool uses almost never cost me more than a dollar, maybe a bit more when I reach for a smarter model.
Running rtk gain after a week of normal work is a reality check. The numbers are hard to argue with.
Patrick Szymkowiak, RTK's creator, posted his own stats on Hacker News after 15 days of daily use: 7,061 commands processed, 24.6 million tokens saved, 83.7% reduction.
Biggest surprise was
rtk find: directory listings are insanely wasteful.
The per-command savings are where it gets concrete:
| command | raw | compressed | savings |
|---|---|---|---|
cargo test (262 passing) |
4,823 tokens | 11 tokens | 99% |
git diff HEAD~1 (large change) |
21,500 tokens | 1,259 tokens | 94% |
cat src/main.rs (1,295 lines) |
10,176 tokens | 504 tokens | 95% |
git status |
~2,000 tokens | ~400 tokens | 80% |
ls / tree |
~2,000 tokens | ~400 tokens | 80% |
The cargo test result is the most eye-opening. The agent does not need 262 passing test names. It needs to know the tests passed. RTK gives it that without removing data the agent needs.
A 30-minute Claude Code session on a TypeScript or Rust project can burn through around 118,000 tokens on routine shell commands before a single line of new code is written. With RTK, the same session lands closer to 45,000. The context window stays cleaner, sessions run longer before they hit limits, and the model has less boilerplate to sift through before it reaches the three failing assertions it needs to act on.
Combining both
You can definitely combine both, and in a sense they solve different problems.
RTK cuts the noise coming from the shell: test output, git diffs, directory listings, logs, all the stuff and fluff that floods the agent's context between actual decisions. Caveman cuts the agent's own prose, so the replies stay short and easier to scan. One attacks input from tools, the other attacks output from the model.
The combination works because RTK shrinks the big, repetitive context you never wanted. Caveman keeps the assistant from spending tokens on polish, filler, and overexplaining. Together they reduce both the volume and cost of a session.
I do not love caveman's speaking mumbling style, so I would not run both permanently. But if raw token efficiency is the goal, RTK + caveman is hard to beat right now.
Caveman changes what the agent says. RTK changes what the shell sends back.