rtk vs graphify: opposite ends of the same problem

Part of the reduce Claude Code token usage pillar. This page is the head-to-head, and the short version is that these two tools are not really competing.

Is rtk or graphify the better choice?

They intercept different channels, so the honest answer depends on where your tokens actually go. rtk sits on the shell and shrinks what commands return. graphify sits on your project and builds a queryable map of it, including the documentation, PDFs, images and video that code tools normally ignore. If your sessions are dominated by cargo test and docker build, rtk touches your problem and graphify does not. If they are dominated by the agent hunting through a large, document-heavy project, it is the reverse. I maintain an open token optimizer benchmark and sell a competing tool, so read the mechanism rather than the ranking. On that benchmark neither of these shows a measurable cost saving over running nothing, and the reasons differ enough to be worth separating.

What does rtk actually do?

It is a Rust CLI proxy that filters command output before it reaches the model. You type git status, cargo build, pytest; rtk intercepts, strips what a language model gains nothing from, and passes on a compacted version. Over a hundred command-specific filters — git, cargo, npm, pytest, docker, aws — plus a hook that intercepts automatically, so your typing does not change. The engineering is genuinely good: a single binary, under 10 ms of startup, no token cost for the integration itself, and rtk gain reports what it saved per command. On noisy tools the reduction is large and easy to see — around 90% on cargo test, around 80% on git operations. Its limits are structural:

The hook only covers bash. It does not touch the agent's built-in tools — Read, Grep, Glob — and in a typical agent session those carry most of the tokens. That is the main reason a large per-command saving does not become a large per-session saving.
Output filtering only. No retrieval, no structural compression of source files, no deferral of MCP manifests.
No native Windows PowerShell.
Installed manually via brew, curl or cargo, rather than auto-detected per agent.

What does graphify actually do?

It maps the whole project into a knowledge graph so the agent queries the graph instead of grepping files. Python, MIT licensed, installed from PyPI, invoked as a /graphify slash command across a wide agent range — Claude Code, Codex, opencode, Cursor, Copilot, Aider, OpenClaw and others. Its distinguishing move is coverage. Most tools in this category index source code and stop. graphify ingests documentation, PDFs, images and video as well, which matters in the kind of project where the answer to "why is it done this way" lives in a design document rather than in a function. Two more things worth knowing:

It produces a persistent artefact. graph.json, plus an HTML view and a Markdown report. The graph can be queried later without re-reading the codebase, and the HTML view means a human can audit the index rather than trusting it blind.
Indexing is an explicit step. You re-run it as the project moves. That is the flip side of the artefact: a stale graph does not fail loudly, it misleads quietly.

Why do both land at break-even on a long session?

Different reasons, and the difference is the useful part. rtk lands there because it optimises a real channel that is usually not the biggest one. Cutting 90% off cargo test is a genuine saving on a line item that may be a small fraction of the session. The rest — file reads, re-reads, tool manifests, conversation history — passes through untouched. graphify lands there because a query-the-graph workflow only pays off if the agent uses it. A slash command is opt-in by design: the agent does not consult the graph unless something in the session steers it there, and the indexing pass itself has a cost. Add a graph that has drifted from the working tree and the agent can spend tokens reconciling the two. Neither result is a verdict on the engineering. It is a statement about how much of a whole session each one is in a position to affect.

Do they compose?

Yes, and this is the pair where composing makes the most sense. They sit at different points and neither rewrites what the other produced: rtk works at the shell boundary, graphify works on a pre-built index the agent queries. Running both is coherent in a way that running two code indexes is not. The costs of doing so are honest ones — a Python runtime and a Rust binary to keep installed, and one more index to keep fresh — but there is no interference between them.

What neither of them covers

Whole-file reads, re-reads, and MCP manifests.

Whole-file reads. The agent opens a 2 000-line file to change four lines and the other 1 996 are billed. graphify tells it which file; rtk never sees the read at all, because it is not a shell command.
Re-reads. The same file entering context four times in one session costs four times. Neither tool deduplicates.
MCP manifests. Every connected server ships its tool definitions before your first message, used or not. That is a standing cost on every turn and it is invisible in both tools' reporting.

This is the gap that makes per-command savings and per-session savings diverge, and it is why a tool can be well built, honest about its numbers, and still not move your invoice.

Which one should you pick?

Pick rtk if your day is terminal-heavy: builds, tests, container work, infrastructure commands. The saving on those specific blobs is real, immediate and measurable with the tool's own rtk gain. On Linux and macOS it is close to zero-friction. Pick graphify if your project's knowledge is not all in the source — architecture documents, specifications, recorded walkthroughs, PDFs from a vendor. Nothing else in this category ingests those, and an agent that can query them stops asking you. Pick neither yet if you have not measured where your tokens go. A week with ccusage or your agent's own usage panel will tell you whether your spend is shell output, file reads or conversation history — and those three point at three different tools.

How to apply this today

Split one session's spend into shell output versus file reads. That single ratio decides this comparison for you, and no amount of feature comparison substitutes for it.
If you install rtk, read rtk gain after a week and compare the saving against your total. A large percentage on a small channel is still a small number.
If you install graphify, decide when the index gets rebuilt before you rely on it. Tie it to something — a branch switch, a daily run — rather than to remembering.
Audit what is connected. Every MCP server you are not using is paying rent on every turn, and neither tool will tell you.

What goes wrong (anti-patterns)

Reading a per-command percentage as a per-session percentage. −90% on cargo test is true and it is not −90% on your bill. Trusting a stale graph. graphify's index is explicit. When it drifts, the agent gets confident wrong answers, which is more expensive than no index. Expecting rtk to cover the agent's own tools. The hook is on bash. Read and Grep go around it, and on most agents that is where the volume is. Installing both and measuring neither. They compose, but two tools with unverified savings is not better evidence than one.

See also: