tokensave Review: What Their 88% Covers

What is tokensave, and which one did you find?

tokensave is a Rust MCP server that indexes your codebase into a local semantic knowledge graph so an agent queries symbols instead of reading whole files. There are at least three unrelated projects using that name, and only one of them is this. Start here, because the search results do not separate them and installing the wrong one wastes an afternoon:

aovestdipaperino/tokensave — the one this page reviews. Rust, MIT, 618 stars, 62 forks, created 26 February 2026, last pushed 3 September 2026, current release v7.11.0 (30 August 2026). Its site is tokensave.dev.
choosenobody/TokenSave — a completely different tool: "a local-first auditor of recurring AI agent jobs", which looks for waste in cron and looped agent runs. 0 stars. Its site is tokensave.cloud.
Snowy-Girl-Labs/tokensave-public — a mirror carrying the same one-line description as the first. 0 stars.

There is also token-saver.ai, a separate product with a near-identical name that filters command output rather than indexing code. If you arrived from a search result and the thing you installed audits cron jobs, you found the second one. For the rest of this page, tokensave means the 618-star Rust MCP server.

What does tokensave actually do?

It parses your repository with tree-sitter into a libSQL graph with FTS5 search, then exposes that graph to your agent as MCP tools so a question about code is answered by a query rather than by reading files. The pitch behind every tool in this category is the same, and it is a good one: an agent asked "where is authentication handled" will otherwise grep, open six files, and pay for all six in input tokens. An index answers with the three functions that matter. Where tokensave differs from the rest of the category is breadth. The README claims 80+ MCP tools, 50+ languages across three feature tiers (lite / medium / full, chosen at compile time to control binary size), and 12+ agent integrations, naming Claude Code, Codex CLI, Gemini CLI, Cursor, OpenCode, Cline, Zed, Kilo and a dozen more. Install is brew, scoop, cargo or cargo binstall. Two capabilities are genuinely uncommon and worth naming:

Multi-branch indexing. Track a branch and it copies the nearest ancestor database, syncing only the differing files, so you can diff and search across branches without switching checkout. Nothing else in this category does that.
Atomic edit primitives with AST rewriting. Edits go through the parse tree rather than regex-and-shell-quoting, which removes a whole class of failure.

What does the 88% tokensave advertises actually cover?

It is their own figure, for retrieval against a full-file baseline, measured by them on their own repository. Read it as a claim about one step, not as a saving on your bill. A note on how this page treats any vendor number, tokensave's included. In this category the advertised percentage is almost always arithmetically true and rhetorically oversized: it is measured on the narrow slice the tool touches, then presented as though it applied to the whole job. The tool intercepts 12% of your traffic, saves 80% of that slice, and the headline says 80%. Nobody has lied. The conclusion a reader draws is still wrong by an order of magnitude. So no self-reported figure on this site is repeated as fact, and none is ever placed in the same column as a controlled measurement. With that said, here is what tokensave reports. tokensave bench runs a fixed set of 10 queries through the tokensave_context tool and compares the tokens returned against what reading the whole files would have cost. On their own repo with the shipped generic query set they report 88% mean retrieval savings — 142.8k tokens down to 5.5k across 10 queries, with dollar estimates from Sonnet input pricing, and describe the methodology as mirroring CCE. Shipping tokensave bench as a command is better than publishing a bare percentage, and it is worth saying so: you can re-run their query set instead of taking their word. That is a point about reproducibility, not about the size of the number. Because the headline still generalises. Three things it does not cover, and each one moves it:

It measures retrieval, not a session. The comparison is "querying the index" versus "reading whole files". A real agent session also re-sends conversation history, runs commands, reads their output, and re-reads files it already has. Retrieval is one line on that invoice.
It is self-measured on its own repo. A Rust codebase with a shipped query set tuned to "patterns present in most application codebases". The README says so plainly and tells you to run it on your own project, which is the honest framing. But a self-benchmark is not an independent one.
It has no control arm. It compares against a hypothetical worst case (read every file whole), not against the same agent doing the same task without the tool. That is the difference between "an index returns less text than a file" — which is arithmetic, and true — and "installing this made my sessions cheaper", which is an experiment.

What does 80+ tools cost you?

Every MCP tool definition is in the context window on every turn, including the turns that never touch the index. This is the part a feature count inverts. A tool list reads as capability, and each entry is also a fixed input cost paid per turn for the life of the session. Eighty tool definitions is a bigger standing charge than forty, and it is charged whether or not the agent queries the graph. Whether that trade wins depends on your session shape. On long sessions doing heavy code navigation, the retrieval savings dwarf the manifest. On short sessions, or ones spent running tests and reading logs, you are paying the manifest for a graph you never query. There is no universal answer, which is exactly why the arithmetic deserves to be visible instead of hidden behind a bigger number. The practical move is to keep the server connected for exploration work and disconnected for the rest, rather than leaving it on by default because it was on yesterday.

Who should use tokensave, and who should not?

Use it if your agent spends its tokens navigating a large, multi-language codebase. Skip it if your tokens go to command output and re-reads. Reach for it when: the repository is big, several languages are in play, you work across branches, and your sessions are long enough to amortise the tool manifest. The language breadth and the multi-branch indexing are real advantages and nothing else in the category matches both. Look elsewhere when: your bill is dominated by unfiltered command output, by the same files being re-read within one session, or by a context that never gets trimmed. An index does not touch any of those. tokensave does no output filtering, no re-read deduplication and no skeleton compression, and it does not claim to. That is the honest split, and it is why these tools are not substitutes. If you want the category laid out side by side, tokensave alternatives compares five of them, and tokensave vs codegraph takes the closest pairing on its own.

How to apply this today

Check you have the right project. github.com/aovestdipaperino/tokensave, 618 stars, Rust. If it audits cron jobs, that is a different tool.
Run tokensave bench on your own repository, not on theirs. The shipped query set is generic; --queries my.toml makes it yours.
Read the number as retrieval, not spend. It tells you what querying beats reading. It does not tell you what your month costs.
Measure the manifest. Note your per-turn input tokens with the server connected and disconnected. That difference is what 80+ tools costs you.
Decide per session, not per machine. Connected for navigation-heavy work, disconnected for test-and-log loops.

What goes wrong (anti-patterns)

Reading an advertised 88% as a bill reduction. It is their retrieval figure against whole-file reads. This is the single most common way a decent tool ends up looking like a broken promise, and it applies to every vendor percentage in this category, not only this one: ask what share of your traffic the tool even touches before applying its percentage to anything. Counting tools as features. Eighty tool definitions is eighty entries of input on every turn. The count is a cost as much as a capability, and the marketing convention of leading with it obscures that. Leaving the server connected out of habit. The manifest is billed on the sessions that never query the index, and those are usually the majority. Assuming an index fixes re-reads. It does not. If the same four files enter your context eleven times in a session, that is a different problem with a different fix — see how to measure agent token usage for catching it.

See also:

tokensave alternatives — five tools compared on measured cost effect
tokensave vs codegraph — the closest pairing in the category
Best Claude Code token optimizers — the wider field