rtk vs caveman: input side or output side?

Part of the reduce Claude Code token usage pillar. This page is the head-to-head, and it is the clearest input-versus-output comparison in the category.

Is rtk or caveman the better token optimizer?

They are not substitutes. rtk works on what enters the model, caveman on what leaves it — and for agent work, what enters is the larger number. In a typical coding session the inbound side dominates the outbound side by roughly an order of magnitude: file contents, command output, tool manifests and conversation history all flow in, while the model emits comparatively little. That asymmetry is the single most useful thing to know before choosing between these two. It does not make caveman pointless — output tokens are billed at a higher rate per token, and caveman also has an input-side trick — but it does mean the two tools are playing for different stakes. I maintain an open token optimizer benchmark and sell a competing tool. Neither of these shows a measurable session-cost saving on it, and the reasons are different enough to matter.

What does rtk actually do?

It filters command output at the shell boundary. A Rust CLI proxy with over a hundred command-specific filters — git, cargo, npm, pytest, docker, aws — and a transparent hook so you type commands exactly as before. It strips what a language model gains nothing from and passes on a compacted version. One binary, under 10 ms of startup overhead, no token cost for the integration itself. rtk gain reports savings per command from a SQLite store, and a TOML DSL lets you write your own filter rules. On noisy tools the reduction is large and visible: around 90% on cargo test, around 80% on git operations. Its structural limits: the hook only covers bash, so the agent's built-in Read, Grep and Glob go around it — and on most agents those carry the bulk of the tokens. No retrieval, no structural compression, no MCP deferral. No native Windows PowerShell.

What does caveman actually do?

It changes how the model speaks. A JavaScript skill or plugin for 30-plus coding agents that switches output to telegraphic "caveman talk", with four levels — lite, full, ultra, wenyan — selected by a /caveman slash command. The benchmark it publishes is unusually honest for this category: an average of 65% output reduction, range 22–87%, measured against raw Claude API receipts versus a concise baseline. Not a simulation, not a token counter — receipts. It ships two things beyond the style itself, and they are the parts people miss:

caveman-shrink, an MCP middleware that wraps any MCP server and compresses its tool descriptions. That is an input-side saving, and it targets exactly the standing per-turn cost most tools ignore.
caveman-compress, which rewrites CLAUDE.md and memory files into telegraphic form — around 46% input savings on a file that is re-sent on every turn.

Install is a 30-second curl or irm, with auto-detection across Claude Code, Codex, Gemini, Cursor, Windsurf, Cline and Copilot. A statusline badge shows lifetime savings, which sounds like a gimmick and is actually the thing that keeps people using it. The honest cost is in its own readme: style enforcement can degrade reasoning quality on nuanced explanations. You are trading fluency for tokens, and on work where the explanation is the deliverable that is a bad trade.

Which half of the bill is bigger?

The input half, for almost any agentic workload. The model reads a great deal more than it writes: whole files opened to change four lines, test runs piped back in full, MCP manifests loaded before your first message, and the entire conversation replayed on every turn. Output tokens are more expensive per token, which is why cutting them feels productive. But a large percentage of a small number is still a small number. Cutting output by 65% on a session where output is a tenth of the traffic moves the total by a few points. This is the reason both tools land at break-even on a long-session measurement while both publish real, verifiable savings on their own channel. They are each telling the truth about a slice. The exception worth flagging: if your usage is chat-shaped rather than agent-shaped — long generated explanations, documents, large amounts of produced text and little file reading — the balance shifts and caveman's territory becomes the larger one.

Do they compose?

Yes, and unusually well, because they barely touch. rtk intervenes before content reaches the model, caveman after. There is no shared state and no interference. If you run both, the parts to watch are caveman's input-side extras: caveman-shrink compresses MCP tool descriptions, and caveman-compress shrinks your memory file. Those are the two places where its savings and rtk's live on the same side of the pipe — and neither overlaps with rtk's shell filters, which is why the pairing is clean rather than redundant.

What does neither of them do?

Whole-file reads. The agent opens a 2 000-line file to change four lines. rtk never sees it (not a shell command), caveman does not touch tool results at all.
Re-reads. Same file, four times, four charges. Neither deduplicates.
Conversation history. Neither compresses the window that accumulates across a long session.
Semantic retrieval. Neither replaces a search with a targeted answer.

Which one should you pick?

Pick rtk if your day is builds, tests, containers and infrastructure commands, and you are on Linux or macOS. The saving on those blobs is real and you can verify it yourself with rtk gain. Pick caveman if your agent generates a lot of prose, or if you want caveman-shrink and caveman-compress specifically — those two are input-side wins that most optimizers in this category do not offer at all. Take the style levels seriously though: use lite on work where you will read the explanations. Pick both if you want the two ends covered cheaply. They are among the lowest-friction installs here and they do not conflict. Pick neither yet if you have not looked at your input/output split. It is one number, it takes a week with ccusage, and it answers this page better than any feature comparison.

How to apply this today

Get your input/output token ratio for one week. If input dominates by 10x — and it probably does — you now know which of these two to install first.
If you try caveman, start at lite and read the output. Decide whether the reasoning quality you get back is worth what you saved.
Install caveman-shrink even if you skip the style, if you run MCP servers. Tool descriptions are a standing cost and almost nothing else touches them.
If you install rtk, compare rtk gain to your total, not to itself.

What goes wrong (anti-patterns)

Optimising output first. It is the lever people reach for because it is visible, and it is the one that pays least on agent traffic. Running ultra on work you need to understand. The readme says style enforcement can degrade nuanced reasoning. Believe it before you debug a wrong answer. Expecting rtk to cover the agent's file tools. The hook is on bash by design. Reading a per-channel percentage as a session saving. 65% off output and 90% off cargo test are both true and neither is 65% or 90% off your invoice.

See also: