codegraph vs graphify: two graphs, two consultation models

Part of the reduce Claude Code token usage pillar. This page is the head-to-head between the two graph-building tools, which turn out to differ most in a place neither README emphasises.

Is codegraph or graphify the better choice?

codegraph, unless your project's knowledge lives outside the source — and the deciding factor is not what they index, it is whether the agent asks. codegraph runs as an MCP server. Its tools are in the agent's toolbox from the first message, so when the agent needs to know where a function is used, querying the index is simply available. graphify is invoked as a /graphify slash command, which means the graph is consulted when something steers the session there — and not otherwise. That distinction outweighs almost every feature difference between them. An index that is not consulted saves nothing, however good it is. I maintain an open long-session benchmark and sell a competing tool. Neither of these shows a measurable session-cost saving on it; codegraph publishes its own −35% cost and −71% tool calls across seven repositories.

What does codegraph actually do?

It indexes your source and answers structural questions over MCP. tree-sitter parses into an FTS5 SQLite knowledge graph covering 20-plus languages and 14 frameworks: impact analysis, call graphs, symbol lookup. Three practical strengths:

A bundled Node.js runtime, so no version management and no virtualenv, plus an interactive installer that detects eight agents — Claude Code, Cursor, Codex, opencode, Hermes, Gemini, Antigravity, Kiro — and writes their MCP config itself.
Framework-aware routing across fourteen frameworks, including uncommon ones like Drupal and Vapor.
A debounced file watcher with staleness banners, so the agent knows when its answer may be behind the working tree instead of answering confidently from stale data.

Its gaps: source only, so documentation and other assets are invisible to it; FTS5 keyword search with no semantic retrieval; no output filtering; and its MCP manifest is itself a standing per-turn cost.

What does graphify actually do?

It maps the whole project, not just the code. Python, MIT, installed from PyPI, invoked with /graphify across Claude Code, Codex, opencode, Cursor, Copilot, Aider, OpenClaw and others. It ingests documentation, PDFs, images and video alongside source, which is the thing no other tool in this category does. In projects where the answer to "why is it built this way" lives in a design document, a vendor specification or a recorded handover, that is a real gap being filled. It also produces a persistent, inspectable artefact: graph.json, plus an HTML view and a Markdown report. The graph can be queried later without re-reading the codebase, and a human can audit the HTML rather than trusting the index blind — which is rarer than it should be, and genuinely useful when you suspect the index rather than the agent. Its costs: indexing is an explicit step you re-run as the project moves, a stale graph misleads quietly, it needs a Python runtime, and it does not touch command output.

Automatic versus invoked: why it matters so much

Both tools save tokens the same way — by replacing reads with a query — and that only happens if the query happens. An MCP server is ambient. The agent sees find_usages in its tool list and can choose it without you thinking about it. That is why codegraph's −71% tool calls figure is plausible: it is measuring a behaviour change that occurs by default. A slash command is deliberate. /graphify builds or consults the graph when someone asks. In a long autonomous session, that someone has to be you, or a rule in your project instructions that reliably steers the agent there. Neither design is wrong. Ambient means always paying the manifest cost; invoked means paying nothing until used, and getting nothing until used. If you pick graphify, plan for how it gets invoked — a line in your agent instructions is usually enough, and without it the tool is installed rather than working.

What does neither of them do?

Command output. Neither is on that path. cargo test, npm install, a stack trace: all arrive at full size.
Whole-file reads for editing. Both say which file; neither shrinks the file the agent then opens.
Re-reads. The same file four times in a session costs four times. Both lower the odds; neither deduplicates.
Conversation history. Neither compresses the window as it grows across turns.

That list is the reason a tool can publish a credible −71% tool calls and still land at break-even on total session cost: navigation is a real channel and it is not the only one.

Which one should you pick?

Pick codegraph if your project's knowledge is in the source, you want the lowest-friction install here, and you value an index the agent will consult without being told to. Pick graphify if documentation, PDFs or recordings hold answers your source does not. Nothing else in this category ingests them, and the browsable HTML graph is a real auditing advantage. Pick both if you have a document-heavy project and also want ambient code navigation. They do not conflict; you are then maintaining two indexes and paying one manifest. Pick neither yet if most of your spend is command output. An index is not on that channel, and installing one will teach you nothing about the bill.

How to apply this today

Count tool calls, not tokens, for one session. It is the metric a graph moves and the one you can verify yourself in an afternoon.
If you pick graphify, write the invocation into your agent instructions. An index nobody queries is a cost with no benefit.
Tie re-indexing to an event — a branch switch, a daily run — rather than to remembering.
Check where your spend actually is before blaming the tool. Neither of these covers shell output, and that is often the surprise.

What goes wrong (anti-patterns)

Installing a graph and never invoking it. The most common failure mode for slash-command tools, and it looks exactly like the tool not working. Trusting a stale index. Confident wrong answers cost more than no answer, and only one of these two warns you. Running both indexes over the same source. You double the maintenance and answer the same question twice. Reading −35% as a promise. It is a vendor median over seven repositories with visible run-to-run variance. Good faith, still a sample.

See also: