tokensave vs graphify: always on, or only when asked?

Part of the reduce Claude Code token usage pillar. Both build a graph of your project; they differ most in what they cost when nothing is happening.

Is tokensave or graphify the better choice?

tokensave if the agent should reach for the index without being told; graphify if you would rather pay nothing on the sessions that do not need it. tokensave runs as an MCP server exposing 48 tools. They are in the agent's toolbox from the first message, which is why the agent will use them unprompted — and why their definitions are billed as input tokens on every turn, including the turns that never query the index. graphify is invoked with /graphify. Zero standing cost, and zero benefit until something in the session reaches for it. Neither shows a measurable session-cost saving on my open long-session benchmark — tokensave has not been measured at all and publishes no benchmark. I run that benchmark and sell a competing tool, so read the mechanism.

What does tokensave actually do?

A Rust MCP server over a symbol index. A semantic knowledge graph in libSQL with FTS5, built by tree-sitter extraction across 34 languages, with 48 MCP tools. Its strengths are engineering ones:

Compiled, so fast startup, low memory, no runtime to install. Homebrew on macOS, Scoop on Windows, prebuilt binaries elsewhere.
Multi-branch indexing — diff and search across branches without switching checkout, which nothing else in this category offers and which removes a class of context-burning git checkout round-trips.
Subprocess isolation, so one parser crashing on a malformed file does not take the service down. With 34 grammars that matters.
Atomic edit primitives with AST rewriting, so the agent renames through the tree rather than through a regex.

Its gaps: source only, no output filtering, no semantic vector search, framework detection limited to fourteen hardcoded frameworks, and no published savings figures at all.

What does graphify actually do?

A whole-project knowledge graph, behind a slash command. Python, MIT, from PyPI, invoked as /graphify across Claude Code, Codex, opencode, Cursor, Copilot, Aider, OpenClaw and others. Its differentiator is coverage beyond code: documentation, PDFs, images and video. In projects where the answer to "why is it built this way" lives in a design document or a recorded handover, nothing else in this category can reach it. It also produces a persistent, inspectable artefact — graph.json, an HTML view and a Markdown report — so the graph is queryable later without re-reading the codebase, and a human can audit it rather than trusting it blind. Its costs: indexing is an explicit step you re-run as the project moves, a stale graph misleads quietly rather than failing loudly, and it needs a Python runtime.

The idle cost, and why it decides more than it should

48 tool definitions on every turn is the largest standing charge in this comparison, and it is invisible. MCP manifests are sent as input tokens ahead of your first message. On a session that is pure terminal work — a build loop, an infrastructure task — tokensave contributes nothing and still charges you. That is not a defect; a large tool surface is the product. But it is a reason to disconnect it deliberately rather than leaving it connected out of habit. graphify has the opposite profile. Idle, it costs zero. The risk is the mirror image: an index nobody invokes is the indexing pass wasted and nothing else gained, and from the outside that looks exactly like a tool that does not work. Neither profile is better in the abstract. Ambient suits work where you cannot predict which sessions need navigation. Opt-in suits work where you can, and where a large share of sessions plainly do not.

What does neither of them do?

Command output. cargo test, npm install, a stack trace: both let it through at full size.
Whole-file reads for editing. Both say which file; neither shrinks the file the agent then opens.
Re-reads. Same file, four times, four charges. Both lower the odds; neither deduplicates.
Conversation history. Neither compresses the window as it grows across turns.

Which one should you pick?

Pick tokensave if you work across many languages, review branches often, want a compiled binary with no runtime, or value the safer edit path AST rewriting gives. Then disconnect it on terminal-only sessions. Pick graphify if documentation, PDFs or recordings hold answers your source does not, or if you want an index with no per-turn cost. Then write the invocation into your project instructions so it actually gets used. Pick neither yet if most of your spend is command output. Neither is on that channel, and installing one will teach you nothing about your bill.

How to apply this today

Check your input tokens on a terminal-only day. That is where a large manifest shows up, and nowhere else.
If you pick graphify, write /graphify into your agent instructions, tied to the questions it should answer.
Tie re-indexing to an event — a branch switch, a daily run — rather than to remembering.
Judge either one on tool calls first. That is the metric an index moves; cost follows with more variance than people expect.

What goes wrong (anti-patterns)

Leaving 48 tools connected out of habit. Billed every turn, including the many that never touch the index. Installing an opt-in graph and never invoking it. Wasted indexing, and it looks identical to a broken tool. Trusting a stale index. Confident wrong answers cost more than no answer, and neither of these has a staleness banner. Judging an unbenchmarked tool by its feature list. 34 languages and 48 tools are capability facts, not savings.

See also: