TokenSave vs OpenWolf

TokenSavevsOpenWolf

OpenWolf is the odd one out, and the comparison is mostly a category error worth clearing up. It is not a code graph. It is a portable project-memory layer plus honest token accounting, hooked into several agents at once. It overlaps TokenSave at the edges and competes with it almost nowhere.

TokenSave v7.12.1 · OpenWolf v2.5.2 (npm, Sep 2026)

These two compose rather than compete. OpenWolf remembers what your project's conventions are and what a session actually cost. TokenSave knows what calls what. Running both is coherent: nothing in either design conflicts, and they hook into different parts of the agent lifecycle. If you are choosing between them you have probably mis-framed the question — the real question is whether you need memory, a graph, or both.

At a glance

Dimension	TokenSave	OpenWolf
Category	Code knowledge graph	Project memory + token accounting
Implementation	Rust, single static binary	Node.js
License	MIT	AGPL-3.0-only
MCP tools	87	Lifecycle hooks rather than a tool surface
Unit of knowledge	Symbols, call edges, type relations	Conventions, fixes, a project map in `.wolf/`
Cross-agent portability	Per-agent config; graph lives in `.tokensave/`	One `.wolf/` shared across agents
Token accounting	Per-call estimate + savings ledger	Read from harness transcripts
Cross-session memory	3 tools: decisions, code areas, recall	The entire point of the product
Code analysis	60 languages, full AST extraction	File and symbol map with line ranges
Network	Optional anonymous counter, opt-out	No API calls, no telemetry

Where OpenWolf is the better tool

Token accounting that is actually measured

OpenWolf reads real usage out of the harness transcript. TokenSave's savings ledger is an estimate — a before/after token count per call against a modelled baseline. Both are useful, but only one of them is counting what the provider actually billed you for, and it is not TokenSave.

Memory that follows you between agents

One .wolf/ directory carries conventions, bug fixes and a project index across Claude Code, Codex and OpenCode. TokenSave's session memory lives in its own project database and does not travel.

It remembers the things a graph cannot derive

"The test command is this." "We tried that approach and it broke." "This module's owner is X." None of that is recoverable from an AST, at any depth of parsing.

Lifecycle hooks as the integration point

Rather than exposing tools and hoping the model calls them, OpenWolf attaches to session and tool events and restores saved context automatically.

Where TokenSave is the better tool

It actually understands the code

A project map with descriptions, line ranges and import relationships is not a call graph. "Who calls this?", "what breaks if I change it?", "how deep is this inheritance chain?" are outside OpenWolf's scope by design.

Licensing

TokenSave is MIT. OpenWolf is AGPL-3.0-only, which carries obligations that many companies will not accept for a tool embedded in their development workflow. Worth checking before you adopt it, not after.

Native binary, no Node

OpenWolf is a Node.js package. TokenSave is a single binary with no runtime.

TokenSave has memory too, if a narrower kind

record_decision, record_code_area and session_recall persist design decisions and touched areas across sessions with FTS5 search over them. It is a fraction of what OpenWolf does, but it is not nothing, and it sits next to the graph.

Which should you use

Choose OpenWolf if…

your pain is forgetting rather than searching: the agent keeps relitigating settled decisions, you switch between Claude Code, Codex and OpenCode, and you want token numbers you can trust because they came from the transcript. AGPL must be acceptable in your setting.

Choose TokenSave if…

your pain is the agent not understanding the code: it greps, it guesses, it misses callers, it breaks things it did not know depended on the symbol it changed. Or run both — they do not overlap.

Method

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

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.

OpenWolf figures — npm openwolf v2.5.2 metadata and project documentation, September 2026.

Where this page is wrong or has gone stale, open an issue and it will be corrected.