codegraph vs rtk: index the code or filter the shell?

Part of the reduce Claude Code token usage pillar. This page is the head-to-head: two of the most competently built free tools in the category, aimed at different halves of the same bill.

Is codegraph or rtk the better token optimizer?

Neither dominates — they cover different channels, and the split of your own traffic decides it. codegraph indexes your code so the agent stops reading files to find things. rtk filters what your shell commands return before the model sees it. Almost nothing overlaps. The one thing they share is a benchmark result: on my open long-session benchmark, both land at roughly break-even — sessions cost about what they cost with no tool at all. I run that benchmark and I sell a competing tool, so read the mechanism rather than the placing. In this case the mechanism explains the tie, and it is the useful part.

What does codegraph actually do?

It replaces file-hunting with a query. tree-sitter parses your source into an FTS5 SQLite knowledge graph exposed over MCP, covering 20-plus languages and 14 frameworks. Instead of opening four files to find where a function is used, the agent asks the index and gets a list — impact analysis, call graphs, symbol lookup. It is the easiest thing in this category to install. A bundled Node.js runtime means no version management and no virtualenv, and the interactive installer detects eight agents — Claude Code, Cursor, Codex, opencode, Hermes, Gemini, Antigravity, Kiro — and writes their MCP config itself. The file watcher is debounced and shows a staleness banner when files are pending re-index, so the agent knows when its answer may be behind the working tree. It publishes a benchmark too: −35% cost and −71% tool calls, median over seven repositories. The tool-call half is the more solid of the two — it follows mechanically from having an index and you can check it in a single session. The cost half shows real variance, including a four-run spread on Tokio in codegraph's own reporting.

What does rtk actually do?

It shrinks command output at the shell boundary. A Rust CLI proxy with over a hundred command-specific filters — git, cargo, npm, pytest, docker, aws — plus a transparent hook, so you keep typing commands the way you always did and rtk compacts what comes back. The engineering is tight: one binary, under 10 ms of startup overhead, no token cost for the integration itself, and rtk gain reports savings per command backed by a SQLite store. On noisy tools the reduction is large — around 90% on cargo test, around 80% on git operations — and there is a TOML filter DSL for adding your own rules.

Why do both land at break-even?

Each covers a real channel that is usually not the biggest one. For rtk the reason is precise and documented: the hook only works on bash. It does not intercept the agent's built-in tools — Read, Grep, Glob — and on most agents those carry the bulk of the tokens. So a 90% cut on cargo test is genuine and lands on a slice of the session, while the larger slice goes past untouched. For codegraph the reason is the mirror image. The index removes navigation reads, which is real, and then leaves everything else alone: no output filtering, so verbose shell output still arrives at full size; FTS5 keyword search only, no semantic retrieval; no deferral of MCP manifests; no compression of the files the agent does open to edit. Put crudely, rtk owns the shell and ignores the code, codegraph owns the code and ignores the shell. Each is roughly half a solution, and half a solution measured over a whole session looks like break-even.

Do they compose?

Yes, cleanly, and this is the pair where it makes the most sense. They sit at different points and neither rewrites what the other produced. Running codegraph's MCP server alongside rtk's shell hook creates no interference and no double-counting. The costs are the ordinary ones: two installs to maintain, one index to keep fresh, and codegraph's MCP manifest as a standing per-turn input cost. If your sessions genuinely mix heavy terminal work with heavy code navigation, that is a reasonable trade.

What does neither of them do?

Whole-file reads for editing. The agent still opens the file to change it. An index tells it which; a shell filter never sees it.
Re-reads. The same file entering context four times in one session costs four times. Neither deduplicates.
MCP manifests. Every connected server ships its tool definitions before your first message. codegraph adds one; rtk does not touch the category.
Conversation history. Neither compresses the window, which on a long session is the largest single accumulation.

That list is why a tool can be well built, honest about its numbers, and still not move your invoice. It is not a criticism of either project. It is the difference between optimising a channel and optimising a session.

Which one should you pick?

Pick rtk if your day is builds, tests, containers and infrastructure commands. The saving on those blobs is immediate and you can verify it yourself with rtk gain inside a week. On Linux and macOS the friction is close to zero — there is no native Windows PowerShell support. Pick codegraph if the agent spends its time finding things in a large codebase, or if you want the lowest-friction install to put in front of a team. The bundled runtime and eight-agent installer are the best onboarding story in the category. Pick both if your sessions genuinely have both shapes. They compose without conflict, which is not true of most pairs here. Pick neither yet if you have not measured the split. A week with ccusage or your agent's usage panel answers this comparison better than any feature table.

How to apply this today

Split one week of spend into shell output versus file operations. That single ratio decides this page for you.
If you install rtk, read rtk gain against your total, not on its own. A large percentage of a small channel is still a small number.
If you install codegraph, count tool calls before and after. That is the metric it actually moves, and the one you can verify.
Check what else is connected. Every unused MCP server is paying rent on every turn, and neither tool reports it.

What goes wrong (anti-patterns)

Expecting rtk to cover the agent's own file tools. The hook is on bash. Read and Grep go around it by design. Expecting codegraph to help with a noisy build loop. It is not on that path at all. Reading a per-command or per-repository percentage as a per-session one. Both tools publish honest numbers at a scale smaller than the thing you pay for. Installing both and measuring neither. They compose, but two unverified savings do not add up to evidence.

See also: