graphify vs token-optimizer: map the project or the file?

Part of the reduce Claude Code token usage pillar. Both tools replace content with a map of that content; they differ on scale, timing and who maintains it.

Is graphify or token-optimizer the better choice?

token-optimizer if your tokens go into reading files; graphify if they go into finding things across a project that is not all code — and the licence decides whether the first is even available to you. graphify indexes the whole project once — code, documentation, PDFs, images, video — into a queryable graph you re-run as things change. token-optimizer produces a structure map of a single file at the moment the agent needs it: 180K tokens become roughly 250. token-optimizer is PolyForm Noncommercial: free personally and for small teams, paid licence for commercial use. graphify is MIT. Settle that first if this is company work. Neither has been measured on my open long-session benchmark with a positive result — graphify shows no measurable session saving, token-optimizer has not been through it at all. I run that benchmark and sell a competing tool.

What does graphify actually do?

One map of everything, built ahead of time. Python, MIT, from PyPI, invoked with /graphify across Claude Code, Codex, opencode, Cursor, Copilot, Aider, OpenClaw and others. Its differentiator is reach: documentation, PDFs, images and video alongside source. Nothing else in this category ingests non-code assets, and in projects where a design document or a recorded handover holds the answer, that is a real gap filled. It leaves a persistent, inspectable artefact — graph.json, an HTML view, a Markdown report — so the graph is queryable later without re-reading the codebase, and a human can audit it instead of trusting it blind. Its costs: indexing is explicit and must be re-run as the project moves, a stale graph misleads quietly rather than failing loudly, it needs a Python runtime, and it is opt-in, so it is consulted only when something steers the session there.

What does token-optimizer actually do?

A small map of one file, built at the moment of use — plus three other layers:

AST structure maps. 180K tokens to roughly 250: signatures, symbols, shape. 95–99% compression on the payload that hurts most, and it works because the agent usually needs to know what is in a file rather than read it.
Smart compaction with progressive checkpoints, condensing session state as it grows.
A 7-signal quality score, watching for mid-session context degradation. Almost nothing else here models that at all.
A full HTML dashboard: per-turn costs, model mix, cache analysis, subagent breakdown, drift detection.

It runs on Claude Code, OpenCode, OpenClaw and Codex, with heavier setup elsewhere, a substantial local Python dependency, and no transparent API for third-party integration.

Ahead of time versus at the moment of use

This is the real axis, and it decides the maintenance burden. A project-wide graph is built once and consumed many times, which is efficient — until the project moves. Then it is wrong, and wrong quietly. Every graphify user eventually has to answer "when does this get rebuilt", and the honest answer has to be an event rather than an intention. A per-file structure map has no such problem. It is generated from the file as it exists at that moment, so it cannot be stale. The trade is that it is recomputed rather than reused, and it tells the agent nothing about files it has not opened. That difference maps directly onto what each is good for. graphify answers "where does this live and why", across material that is not all code. token-optimizer answers "what is in this file", cheaply, every time.

Do they compose?

Yes, and the pairing is coherent: one finds, one shrinks. graphify narrows a large project to the right file or the right document; token-optimizer makes reading that file cheap. Neither performs the other's step and there is no interference. The costs are the ordinary ones plus one specific to this pair: two Python installations. Both carry a local Python dependency, which is worth knowing if you were choosing either partly to avoid runtime management — neither helps you there.

What does neither of them do?

Command output at the tool boundary. graphify is not on that path; token-optimizer's compaction is session-level, not a per-command filter.
MCP manifests. Neither defers them.
Re-reads. A structure map makes each read smaller; a graph lowers the odds of a read. Neither deduplicates.
Conversation history. Neither compresses the window as it accumulates across turns.

Which one should you pick?

Resolve the licence first if this is commercial work. PolyForm Noncommercial means a paid licence, and that is the only irreversible decision on this page. Pick token-optimizer if you are an individual or small team on Claude Code and large file reads dominate. The structure map is the strongest single mechanism here, and it never goes stale. Pick graphify if your project's knowledge is spread across documents the agent cannot otherwise reach, and you are prepared to tie re-indexing to an event. Pick both if the licence allows and your sessions both hunt and read.

How to apply this today

Settle the licence question. Two minutes, and irreversible if you get it wrong at scale.
Ask where your tokens go: finding, or reading? That single question separates these two cleanly.
If you pick graphify, decide the re-index trigger before you rely on it — a branch switch, a daily run.
Find your largest file reads. If a handful of big files dominate, the structure map is the highest-leverage change available.

What goes wrong (anti-patterns)

Rolling out a noncommercial-licensed tool across a company. The most expensive mistake here, and nothing to do with tokens. Trusting a stale graph. Confident wrong answers cost more than no answer, and graphify has no staleness warning. Installing an opt-in graph and never invoking it. Wasted indexing that looks exactly like a broken tool. Reading 180K-to-250 as a bill reduction. Honest compression on one payload, at a scope smaller than your invoice.

See also: