rtk vs tokensave: two Rust binaries, two channels

Part of the reduce Claude Code token usage pillar. This page is the head-to-head between the two compiled tools in the category.

Is rtk or tokensave the better choice?

Whichever one is on your bigger channel — and that is a question about your sessions, not about the tools. rtk shrinks what your shell commands return. tokensave gives the agent a symbol index so it stops opening files to find things. They share an implementation language and a distribution story, and nothing else. Both are free, both are compiled Rust with no runtime to install, and both are among the fastest installs here. On my open long-session benchmark rtk lands at roughly break-even; tokensave has not been measured and publishes no benchmark of its own. I run that benchmark and sell a competing tool, so read the mechanism.

What does rtk actually do?

It filters command output at the shell boundary. Over a hundred command-specific filters — git, cargo, npm, pytest, docker, aws — behind a transparent hook, so you type commands unchanged and rtk compacts what comes back. Under 10 ms of startup overhead, no token cost for the integration itself, and a TOML DSL for your own rules. rtk gain reports savings per command from a SQLite store. On noisy tools the reduction is large and immediately visible: around 90% on cargo test, around 80% on git operations. Its limits are structural, not sloppy. The hook only covers bash — the agent's built-in Read, Grep and Glob bypass it entirely, and on most agents those carry the bulk of the tokens. No retrieval, no structural compression, no MCP deferral, and no native Windows PowerShell.

What does tokensave actually do?

It builds a symbol index and serves it over MCP. A semantic knowledge graph in libSQL with FTS5, built by tree-sitter extraction across 34 languages, exposing 48 MCP tools. Four things distinguish it:

Multi-branch indexing. Diff and search across branches without switching checkout. Nothing else in this category does that, and it removes a whole class of context-burning git checkout round-trips.
Subprocess isolation. One parser crashing on a malformed file does not take the service down, which matters when 34 grammars are in play.
Atomic edit primitives with AST rewriting. The agent renames a symbol through the tree rather than through a regex, avoiding the shell-quoting and partial-match hazards that make agentic edits fail quietly.
Distribution. Homebrew on macOS, Scoop on Windows, prebuilt binaries elsewhere — including the Windows support rtk lacks.

Its gaps: no output filtering, so command output arrives at full size; navigation only, with no semantic vector search and no structural compression; framework detection limited to fourteen hardcoded frameworks; and no published savings numbers.

What does each one cost you to run?

rtk costs essentially nothing. The hook adds no tokens and the binary adds no measurable latency. Its only ongoing cost is the risk of over-filtering: a filter that strips a line you needed sends the agent back for it. tokensave costs a manifest on every turn. MCP tool definitions are sent as input tokens before your first message, used or not, and 48 tools is a large surface. That is a standing charge nothing in its own reporting shows you, and it is a reason to disconnect it on sessions that are pure terminal work. That asymmetry does not decide the comparison, but it does mean the two are not equally free. rtk is free to leave installed. tokensave is free to use and costs something to leave connected.

Do they compose?

Yes, cleanly. rtk works at the shell boundary, tokensave answers MCP queries. Neither rewrites what the other produced, there is no shared state, and both are single binaries with negligible operational overhead. If your work genuinely mixes heavy terminal loops with heavy code navigation, running both is coherent. The costs are two installs, one index to keep fresh, and the 48-tool manifest on every turn.

What does neither of them do?

Whole-file reads for editing. The agent still opens the file to change it. An index says which one; a shell filter never sees it.
Re-reads. The same file entering context four times in one session costs four times. Neither deduplicates.
MCP manifests. Neither defers them; tokensave adds a large one.
Conversation history. Neither compresses the window, which on a long session is the biggest single accumulation.

That list is why per-channel savings and session savings diverge, and why two well-built tools can both leave your invoice roughly where it was.

Which one should you pick?

Pick rtk if your day is builds, tests, containers and infrastructure commands, on Linux or macOS. The saving is real, immediate, and you can size it yourself with rtk gain inside a week. Pick tokensave if you work across many languages, review branches often, or want the safer edit path that AST rewriting gives you. It is also the one of the two that works on Windows. Pick neither yet if you have not split your spend between shell output and file operations. One week with ccusage settles this page better than any feature table.

How to apply this today

Split one week of spend into shell output versus file operations. That ratio decides the comparison for you.
If you install rtk, compare rtk gain against your total, not against itself. A large percentage of a small channel stays small.
If you install tokensave, count tool calls before and after — that is the metric an index actually moves.
Disconnect what you are not querying. A 48-tool manifest on a terminal-only session is pure loss.

What goes wrong (anti-patterns)

Expecting rtk to cover the agent's file tools. The hook is on bash by design. Expecting tokensave to help a noisy build loop. It is not on that path at all. Leaving a large MCP surface connected out of habit. It is billed on every turn including the ones where you never touch it. Treating "not benchmarked" as "does not work". tokensave publishes no figure; that is missing evidence, not evidence of failure.

See also: