ccusage vs tokensave: measure it or index it?

Part of the reduce Claude Code token usage pillar. One of these tools has no published numbers, and the other is how you get some.

Is ccusage or tokensave what I need?

ccusage first, and in tokensave's case that is not the usual advice — it is the only way to evaluate it at all. tokensave publishes no benchmark. Not a weak one, not a vendor-flattering one: none. Its README describes 34 languages, 48 MCP tools and multi-branch indexing, and says nothing about what any of it saves. That is not unusual in this category and it is not an accusation. But it does mean the only figure that will ever exist for tokensave on your codebase is one you produce, and ccusage is the instrument for producing it. I maintain an open long-session benchmark and sell a competing tool. tokensave has not been through it either, so I have no number to offer you here — only a method.

What does ccusage actually do?

It reads your agent's local JSONL transcripts and reports what you spent. Roughly 15k stars, 15 supported agent sources, zero install — bunx ccusage or npx ccusage@latest. Daily, weekly, monthly and per-session reports, per-model breakdown, cache token tracking, JSON output that composes with other dashboards. For Claude Pro and Max subscribers the standout is the 5-hour billing block view, matching Anthropic's rolling limit window. It is read-only and reduces nothing, and it offers no counterfactual — observed spend only. The JSONL schema it reads is implicit rather than specified.

What does tokensave actually do?

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

Compiled. Fast startup, low memory, no runtime. Homebrew on macOS, Scoop on Windows, prebuilt binaries elsewhere.
Multi-branch indexing — diff and search across branches without switching checkout, which nothing else here does.
Subprocess isolation, so one parser crashing on a malformed file does not take the service down.
Atomic edit primitives with AST rewriting, so the agent renames through the tree rather than through a regex.

Gaps: no output filtering, navigation only with no semantic vector search, framework detection limited to fourteen hardcoded frameworks — and no published savings.

How do you produce the missing number?

Run a two-week A/B on comparable work, and read tool calls before you read cost.

Week one, no tokensave. Record daily spend from ccusage, and tool-call counts where your agent exposes them.
Week two, tokensave installed and the repository indexed. Change nothing else — not the model, not your other MCP servers, not your prompting habits.
Compare tool calls first. That is what an index mechanically changes, and it moves before cost does.
Then compare cost, knowing your own variance. Two ordinary weeks rarely cost the same. If your week-to-week swing is 20%, a 15% difference is not a result.

Step four is the one people skip, and it is why single-session comparisons in this category produce confident nonsense. ccusage gives you the variance for free: look at four normal weeks before you attribute anything to a tool.

The cost tokensave adds, that ccusage will show you

48 MCP tools is a large manifest, and it is billed on every turn. Tool definitions are sent as input tokens ahead of your first message, used or not. On a session that never queries the index once, that is pure loss — and it is exactly the kind of quiet, fixed charge a per-tool savings counter would never surface. ccusage will. If your input tokens rise on days you did terminal-only work, that is the manifest, and the fix is to disconnect the server on those sessions rather than to blame the index. This is the concrete reason to pair these two rather than treating the meter as optional.

What can the meter not tell you?

Why. ccusage reports that a session cost more than usual. It will not tell you that eleven of your last twenty tool calls re-read the same four files, that a stale index sent the agent down a wrong path, or which of your connected servers is carrying the manifest weight. It also cannot isolate a variable you did not isolate. Two changes in one week produce one uninterpretable result.

Which one should you pick?

Install ccusage regardless. Free, zero-install, read-only, and with tokensave specifically it is not optional — it is the only source of evidence. Install tokensave if you work across many languages, review branches often, or want the safer edit path AST rewriting gives. Then measure it, because nobody else has. Do not install tokensave expecting it to help a build-and-test loop. It is not on that path, and its manifest will cost you on exactly those sessions.

How to apply this today

Run npx ccusage@latest now and record four weeks of totals before changing anything. That is your variance baseline.
Count tool calls, not tokens, when judging the index.
Watch input tokens on terminal-only days. A large manifest shows up there and nowhere else.
Disconnect what you are not querying. Free money, and the meter is how you notice it was available.

What goes wrong (anti-patterns)

Judging an unbenchmarked tool by its feature list. 34 languages and 48 tools are facts about capability, not about savings. Comparing one session to one session. Your own week-to-week variance is usually larger than the effect you are looking for. Leaving a 48-tool manifest connected out of habit. Billed every turn, including the turns that never touch it. Treating ccusage as an optimizer. It saves nothing. Its entire value is what you do with the number.

See also: