rtk vs token-optimizer: one mechanism or four?

Part of the reduce Claude Code token usage pillar. This page is the head-to-head between the narrowest tool in the category and one of the widest.

Is rtk or token-optimizer the better choice?

token-optimizer covers more of the bill — and if you are a company, its licence decides this before any feature does. rtk filters shell command output and nothing else. token-optimizer stacks four mechanisms, the strongest of which turns a 180K-token file into roughly 250 tokens of structure. rtk is free under a permissive open-source model. token-optimizer is PolyForm Noncommercial: free for personal and small-team use, paid licence required for commercial use. That is the first thing to check, not the last. I maintain an open long-session benchmark and sell a competing tool. rtk lands at roughly break-even there; token-optimizer has not been measured on it.

What does rtk actually do?

One thing, well. A Rust CLI proxy with over a hundred command-specific filters — git, cargo, npm, pytest, docker, aws — behind a transparent hook. You type commands unchanged; rtk compacts what comes back. Single binary, under 10 ms of startup overhead, no token cost for the integration itself, and a TOML DSL for adding your own rules. rtk gain reports savings per command from a SQLite store. The reductions are large on noisy tools: around 90% on cargo test, around 80% on git operations. Its limits follow from its scope. The hook only covers bash, so the agent's built-in Read, Grep and Glob bypass it — and on most agents those carry the bulk of the tokens. No retrieval, no structural compression of source files, no MCP deferral, no native Windows PowerShell.

What does token-optimizer actually do?

Four layers, and they attack genuinely different things:

AST structure maps. A 180K-token file becomes roughly 250 tokens of structure — signatures, symbols, shape. That is 95–99% compression on exactly the payload that hurts most, and it works because the agent usually needs to know what is in a file rather than to read it.
Smart compaction with progressive checkpoints. Session state is condensed as it grows instead of being dumped and restarted.
A 7-signal quality score. It watches for context degradation mid-session — the slow drift where an agent's answers get worse because its window filled with noise. Almost nothing else in this category models that at all.
A full HTML dashboard. Per-turn costs, model mix, cache analysis, subagent breakdown, skill adoption, drift detection.

It runs on Claude Code, OpenCode, OpenClaw and Codex, though setup is heavier away from Claude Code, and it carries a substantial Python dependency locally. There is no transparent API for third-party integration.

What each one reports, and why it matters

These two have opposite reporting philosophies, and both are instructive. rtk gain reports one number honestly: of the bytes rtk filtered, how many did it remove? The denominator is rtk's own channel, so a big percentage there can coexist with a flat invoice. That is not dishonest — it is precise about a scope smaller than your bill. token-optimizer's dashboard reports across the session: per-turn cost, cache analysis, model mix. That is closer to what you actually pay, and it is the only tool in this comparison that will show you a quality signal alongside a cost signal. If you install rtk, pair it with a session-level meter or you will be reading a channel percentage as a bill percentage. If you install token-optimizer, you get both scopes in one place.

Where does each one leave tokens behind?

rtk leaves everything that is not a shell command. File reads through the agent's own tools, MCP manifests sent before your first message, conversation history replayed every turn. token-optimizer leaves the tool boundary. Its compaction is a session-level operation, not a per-command filter, so a verbose cargo test still arrives at full size before anything condenses it. It also does not defer MCP manifests, and it offers no semantic code retrieval. Between them the coverage is wide but not complete, and the two do overlap on nothing — which is the argument for running both, if the licence allows.

What does neither of them do?

MCP manifests. Every connected server ships its tool definitions before your first message, used or not. Neither tool defers them, and on a setup with several servers that is one of the largest standing costs you can remove without changing how you work.
Re-reads. The same file entering context four times in one session costs four times. A structure map makes each read smaller; nothing here notices the repetition.
Semantic retrieval. Neither replaces a search across the codebase with a targeted answer. token-optimizer's structure map tells the agent what is in a file it already decided to open; it does not help it decide which file to open.
The gap between "smaller" and "fewer". Both tools shrink payloads. Neither reduces the number of things the agent decides it needs, which is where a code index earns its keep and where both of these stop.

That last point is the honest ceiling on this comparison. Compression and filtering make each item cheaper; they do not change the agent's behaviour. Over a long session, behaviour is the larger term.

Which one should you pick?

Check the licence first if you work at a company. PolyForm Noncommercial means a paid licence for commercial use. Deciding that after a team-wide rollout is the expensive order, and it has nothing to do with tokens. Pick rtk if your day is builds, tests, containers and infrastructure work on Linux or macOS, or if you need something with no licensing question at all. It is the simplest, cheapest, most auditable thing here. Pick token-optimizer if you are an individual or small team on Claude Code and large files dominate your reads. The AST structure map is the strongest single mechanism in this comparison and the dashboard lets you see whether it worked. Pick both if your work has both shapes and the licence permits. They do not conflict.

How to apply this today

Resolve the licence question before anything else. Two minutes, and it is the only irreversible decision on this page.
Find your largest file reads. If a handful of big files dominate, a structure map is the highest-leverage change available to you.
If you install rtk, compare rtk gain to a session-level total, never to itself.
Change one thing at a time and measure for a week, not a task.

What goes wrong (anti-patterns)

Rolling out a noncommercial-licensed tool across a company. The most expensive mistake on this page. Reading rtk gain as a bill reduction. Precise number, smaller denominator than you think. Expecting rtk to cover the agent's built-in file tools. The hook is on bash by design. Assuming an unmeasured tool is safe. token-optimizer's absence from the open benchmark is missing evidence, not a clean result.

See also:

Reduce Claude Code token usage — the pillar, tool-agnostic
Best Claude Code token optimizers — the ranked field
headroom vs token-optimizer — token-optimizer against a window compressor
codegraph vs rtk — rtk against a code index
Token optimizer benchmark — the open measurement behind the rtk result