← all comparisons vs LeanCTX · updated 17 Sep 2026

TokenSavevsLeanCTX

These two are mostly complementary, and the honest headline is that running both is the best configuration on this page. LeanCTX is a gate on everything flowing into the model — file reads, shell output, the request itself. TokenSave is depth on one thing: the structure of your code. They meet at the edges and compete almost nowhere.

TokenSave v7.12.1 · LeanCTX / lean-ctx v3.10.2 (crates.io, Sep 2026)
Different layers, not rival products. LeanCTX describes itself as an AI Value Gate: it understands the task, routes and compresses context, remembers across sessions, and measures what that cost. Its centre of gravity is agent I/O — cached re-reads, command-output compression, a prompt-cache-safe proxy. TokenSave's centre of gravity is a symbol-level graph of your code: call edges, type hierarchies, impact radius, code health. Neither is trying to be the other. If your agent both reads too much and understands your code too little, those are two problems and these are two tools.

There is real overlap, and pretending otherwise would be dishonest: both do impact analysis, both keep a local savings ledger with a live dashboard (lean-ctx gain and tokensave gain are near-namesakes), and LeanCTX's map and signatures read modes cover some of what tokensave_module_api does. That overlap is a thin slice of either tool.

And the Rust argument does not work here. Everywhere else on this site, "single native binary, no runtime, fast enough to sit in the agent's critical path" is TokenSave's sharpest differentiator. Against LeanCTX it differentiates nothing: cargo install lean-ctx, Apache-2.0, same shape, same no-runtime install story. LeanCTX is also ahead on adoption — roughly 3,800 GitHub stars against 640, and about 17,600 crates.io downloads against 5,400.

At a glance

DimensionTokenSaveLeanCTX
ImplementationRust, single static binaryRust, single static binary
Runtime depsNoneNone
LicenseMITApache-2.0
Adoption~640 stars, ~5,400 crates downloads~3,800 stars, ~17,600 downloads
Centre of gravitySymbol-level code graphContext runtime for all agent I/O
MCP tools87~56, plus 95+ shell-hook patterns
File readsSymbol and module API queriesMode-aware reads: full, map, signatures, diff, entropy
Shell outputOut of scope — pair with RTK95+ compression patterns
SearchFTS5 + graph proximity, deterministicHybrid with embeddings
Persistent factsDecisions, code areas, FTS recallKnowledge facts with categories
Portable bundlesPer-branch DBs.lctxpkg, SHA-256 stamped
Graph depthCall edges, type hierarchy, complexity, DSM, Gini, test-riskGraph and impact analysis
Multi-branchPer-branch graphs, cross-branch diffNo
Edit primitives4 atomic writers, re-index in placeRead-oriented

What LeanCTX does that TokenSave does not

What TokenSave does that LeanCTX does not

Sustainability

Both projects are free, local and open source, and neither is metered. The difference is scale of contribution: LeanCTX has more people around it.

The fair flip side. No business model also means no funded roadmap, and on paper a bus factor of one. That is genuinely mitigated here, though not in the usual way: the author is proud of not having written a single line of TokenSave by hand. Every line was produced by Claude, working from a specification held and refined by a person who knows how the thing is supposed to behave. What the project depends on is not one person's hand-written code that nobody else can read — it is someone who understands the design well enough to explain it to an agent, and that is a transferable, reproducible skill rather than a private stock of knowledge locked in a single contributor's head. The code is regenerable. The understanding is the asset, and it is written down.

Which should you use

Reach for LeanCTX when…

the agent is reading too much: it re-reads unchanged files, drags raw cargo and git output into the window, and burns the budget before it gets to thinking. That is an I/O problem, and LeanCTX is built for it.

Reach for TokenSave when…

the agent does not understand the code: it greps, guesses, misses callers, and breaks things that depended on the symbol it just changed. That is a structure problem, and compression will not fix it.

Most people have both problems. Install both. They hook different parts of the agent lifecycle and neither's design conflicts with the other's — the only thing to watch is that you will end up with two savings ledgers measuring overlapping work, so do not add the two numbers together and believe the total.

Method

Every TokenSave figure on this page was verified against the source at origin/master (v7.12.1), not taken from its own README: