TokenSavevsGraphify

Where they agree

At a glance

Rust is not a preference — it is what puts TokenSave in the critical path

$ otool -L $(which tokensave)
  /System/Library/Frameworks/IOKit.framework/…/IOKit
  /System/Library/Frameworks/Security.framework/…/Security
  /System/Library/Frameworks/CoreFoundation.framework/…/CoreFoundation
  /usr/lib/libiconv.2.dylib
  /usr/lib/libSystem.B.dylib
  # that is the whole list

Where Graphify is the better tool

• Non-code nodes

  Graphify ingests documentation, SQL schemas, config files and PDFs alongside source, so it can link a written spec to the function that implements it. TokenSave structurally cannot do this today — it indexes code, with Markdown headers as structural nodes. If your real context lives in design docs, this is the single biggest gap.

• Token budget as a retrieval primitive

  query_graph takes a literal token budget and the traversal honours it. TokenSave exposes max_nodes, max_code_lines and max_per_file — useful, but proxies for the thing you actually care about. For a tool whose entire pitch is token economy, that is a fair hit.

• Edge provenance on every edge

  Tagging an edge EXTRACTED, INFERRED or AMBIGUOUS inline is honest signalling an agent can reason about. TokenSave keeps ambiguity in a separate tool, so it is available but not in front of you.

• A small tool surface is itself a feature

  87 tool definitions cost tokens on every single request and give the model more ways to choose wrong. Ten tools do not. This cuts directly against TokenSave's own thesis, and it is the strongest argument Graphify has.

• PR triage

  list_prs and triage_prs combine CI status, review state and graph blast radius into a merge-risk ranking. TokenSave gives you the graph primitives to build that; Graphify ships it.

Where TokenSave is the better tool

• No model in the indexing path

  Graphify's INFERRED edges require an LLM, which means cost, nondeterminism, and a rebuild that is not reproducible. TokenSave's graph is a pure function of your source: index it twice, get the same graph.

• It can write, and the graph stays true

  Atomic edit primitives — unique-anchor replace, multi-replace, AST rewrite, anchored insert — re-index in place. Graphify is read-only, so the agent drops back to raw file edits and the graph is stale until the next update pass.

• Branches and worktrees

  Per-branch databases built by copying the nearest ancestor and syncing only the diff, plus cross-branch search and diff without switching your checkout. This is the thing that bites hardest in multi-agent work, and Graphify has no answer to it.

• Falsifiable savings

  tokensave bench ships a fixed query set and reports retrieval savings against a full-file baseline; an append-only ledger records every MCP call so tokensave gain can price the difference. The claim is checkable on your own repo rather than asserted.

• Staleness checked per call

  Every MCP call does an on-demand freshness check with a short cooldown, plus a catch-up sync when the server connects — rather than trusting that the last index still reflects the tree.

The incentive difference

Which should you use

Method

• 87 tools — asserted by test_tool_definitions_complete in src/mcp/tools/handlers/mod.rs; 86 when the optional ast-grep binary is absent from PATH.
• 60 languages — counted from the [features] tiers in Cargo.toml: 11 lite, 9 medium, 40 full. The README's "50+" is conservative.
• 0.24s — wall-clock real time for a complete tokensave status invocation, best of repeated runs on an Apple Silicon Mac. Your hardware and repo size will differ.
• Zero runtime dependencies — otool -L on the released binary; system frameworks only.
• No token-budget parameter — confirmed by searching src/mcp/ for token_budget and max_tokens; no matches. The gap above is real.
• Graphify figures — taken from its own published documentation, FAQ and MCP tool reference in September 2026, and not independently verified. If anything here is wrong or out of date, open an issue and it will be corrected.