Best Claude Code Token Optimizers (2026)

Which Claude Code token optimizer actually cuts your bill?

There are roughly two kinds of tools in this space. Focused tools nail one mechanism — output filtering, prompt compression, semantic search, skeleton compression — and do it well. Combined tools stack several mechanisms behind a single install. Which type wins depends on your bottleneck: if you have one specific pain (noisy logs, huge file reads), a sharp focused tool is clean and low-overhead; if token waste shows up everywhere in your sessions, installing four separate tools is overhead in itself. This roundup covers every tool that is actually deployed and used by developers in 2026 — ranked on four real criteria, with honest limitations for every entry, including our own. TL;DR — the ranked picks:

Tokenade — broadest coverage, one install, savings dashboard.
rtk — outstanding command-output filtering; the focused tool to beat.
claude-context — production-ready semantic search; requires external vector DB.
codegraph — deep symbol + call-graph indexing; strong published benchmarks.
tokensave — same mechanism as codegraph in Rust; no published numbers.
token-optimizer — comprehensive multi-layer compression; PolyForm license.
ccusage — measures usage, does not reduce it; include it anyway.

Arrived here from a usage meter rather than an optimizer? ccusage alternatives covers the same field from the measurement side — what replaces ccusage, and what actually lowers the number it shows you.

How we ranked these

Four criteria, weighted for solo-developer Claude Code use:

Savings — how much it actually trims, on what work, and how reproducibly those claims are backed.
Coverage — how many sources of token waste it addresses (a single mechanism vs many).
Setup — install time, external dependencies, ongoing config burden.
Quality-safety — does it cut tokens without dropping the signal the model needs to write correct code?

Tools are ranked on the combination. A focused tool that is trivially correct (can't corrupt your code) scores well on quality-safety even if coverage is low. A broad tool that requires a cloud vector database scores down on setup.

1. Tokenade — broadest coverage in one install

Tokenade ranks first because it stacks the same mechanisms the other tools do individually — output filtering, symbol indexing, semantic search, skeleton compression, MCP optimization — behind a single binary with no external dependencies and a zero-config install. Tokenade combines several layers in a single binary: pre-execution command rewriting (terser flags before the shell runs), per-format output filtering covering git/cargo/docker/kubectl/Terraform and more, on-device semantic code search that surfaces only the relevant files (no external vector database, no API key, no model download), skeleton compression for code/YAML/Markdown/Terraform (−64% on file reads with every top-level declaration preserved), MCP optimization that works with any connected server and keeps unused tools out of the context, SERP and HTML compaction, and a tokenade dashboard showing live measured savings. What matters isn't how much a tool compresses one file — it's what a whole session ends up costing you. That's what the open THOL benchmark measures, and Tokenade is the only one of the twelve tools tested that measurably lowers the bill:

What was measured	Result
A long session — the kind that eats your limit	39% cheaper than using no tool at all

Every other tool in the benchmark either made no measurable difference to what a session cost, or made it worse. Two of them ended up more expensive than running nothing at all. Quality score was 1.00 (no regression) across all adversarial tests on three of four mixes; navigation-heavy dropped to 0.94. Install. Run tokenade install — it auto-detects Claude Code, Cursor, Codex, Copilot, Kilo Code, Windsurf and merges the MCP config without overwriting yours. The embedder is bundled, so there's no first-run download and no API key. Pricing. Freemium: free up to ~10 million tokens/month (no card required), then Pro at $24.90/mo excl. tax. Genuine limitation. If you have a single, known bottleneck (e.g. only noisy build logs), the relevant focused tool below is lighter. Tokenade is also not yet on crates.io or Homebrew — you build from source. And like any compactor, it can in theory fold output a command returned correctly; the escape hatch (tokenade raw <cmd>) exists for that case. Best for: developers who want most of the savings without assembling and maintaining their own stack.

2. rtk — the best focused tool for command-output filtering

rtk is the sharpest single-mechanism tool in this roundup: it wraps CLI commands and compacts their output before it reaches the model, covering 100+ commands with a Rust binary that adds under 10 ms of startup overhead. According to the project's README (source: reports/rtk.md in Tokenade's internal analysis), rtk claims "60–90% token reduction" with per-command breakdowns: cargo test −90%, git operations −80%, and similar wins on npm, pytest, docker, aws, and terraform. It supports 13 AI coding tools including Claude Code, Cursor, Copilot, and Gemini CLI. The hook-based integration is transparent — you don't need to prefix commands manually. A rtk gain subcommand tracks per-command savings in SQLite so you can verify the actual reduction on your own sessions. Read that counter against a session-level meter rather than on its own: rtk vs ccusage is about what the gap between the two numbers tells you. A useful design detail: on filter failure, rtk falls back to raw output and saves the full log via a tee mechanism. That means a missed filter costs you nothing worse than you'd have had without rtk. Install. brew install rtk or a one-line curl installer or cargo install. No external services. One of the easiest setups in this list. Genuine limitation. rtk operates at the shell boundary — it only touches commands, not file reads, MCP tool manifests, or prompt content. In a session dominated by file reads rather than noisy commands, it won't move the needle. The hook also works on bash but not on Claude Code's built-in Read or Grep tools. And if you're already running Tokenade, rtk's output-filtering mechanism is subsumed. Best for: sessions dominated by verbose build, test, and infrastructure output; developers who want a proven, focused tool with zero external dependencies.

3. claude-context — production-ready semantic search with a managed hosting option

claude-context is the most complete semantic code search implementation in the field, combining tree-sitter AST chunking, hybrid BM25 + dense vector search, and incremental Merkle-tree indexing — with a production-ready managed option via Zilliz Cloud. The tool (by Zilliz, the team behind the Milvus vector database) reports "~40% token reduction under the condition of equivalent retrieval quality" in its own evaluation. It chunks code at AST boundaries (never splits a long function between chunks), supports 13+ languages, and allows multiple embedding providers: OpenAI, VoyageAI, Ollama, Gemini. Its incremental indexing only re-indexes changed files. There is both an MCP server package (npx @zilliz/claude-context-mcp@latest) and a VSCode extension. The retrieval mechanism directly addresses the biggest single source of token waste in navigation-heavy sessions: agents reading entire files to find one function. Semantic code search replaces that with a ranked retrieval over chunks, so the model sees the three relevant blocks instead of thirty files. Genuine limitation. Unlike the Rust tools in this list, claude-context requires an external vector database: either a self-hosted Milvus instance or a Zilliz Cloud account. That's a real dependency — setup overhead, an external service to keep running, and (for Zilliz Cloud) a second bill. An embedding API key is also required unless you run Ollama locally. The tool focuses exclusively on the retrieval mechanism; it does nothing for command output, MCP manifests, or file structure. Best for: teams with existing Milvus/Zilliz infrastructure, or developers whose primary bottleneck is file-read-heavy navigation on a large codebase.

4. codegraph — deep call-graph indexing with the strongest published benchmark

codegraph is the best-benchmarked pure navigation tool: its published results across 7 repositories show −35% cost, −57% tokens, and −71% fewer tool calls at the median, with framework-aware routing across 14 frameworks. codegraph builds a SQLite + FTS5 knowledge graph from tree-sitter extraction, covering 20+ languages. Its framework detection spans Django, Flask, Express, NestJS, Laravel, Rails, Spring, Axum, and others, including rare ones (Drupal, Vapor). A bundled Node.js runtime means zero installation complexity. A debounced file watcher keeps the index current as you edit, with per-file staleness banners so the agent knows which files are pending. The interactive installer auto-detects 8 agent environments. Among the pure-navigation tools, codegraph has the clearest, most verifiable benchmark methodology (4 runs per repo across 7 repositories), which is why it ranks above tokensave despite similar architecture. The two are close enough that the choice comes down to a handful of specifics: tokensave vs codegraph goes through them. Genuine limitation. The mechanism is powerful for navigation but covers only one dimension of token waste. It won't help with noisy command output, fat MCP manifests, or file reads that aren't navigational. That first gap is exactly rtk's territory, and codegraph vs rtk is about which of the two channels your own sessions lose tokens on. The TypeScript/Node.js runtime adds a dependency relative to compiled Rust tools. Token savings numbers are real but derive from 4 runs per repo — a larger battery would strengthen the claim. Best for: large multi-language repositories where the agent's bottleneck is "I don't know where X is defined, so I'll read 10 files to find out".

5. tokensave — same mechanism as codegraph, compiled in Rust

tokensave delivers the same call-graph indexing architecture as codegraph in a compiled Rust binary — 34 languages, multi-branch indexing, subprocess isolation — but publishes no benchmark numbers. The technical depth is impressive: 34 languages via feature-gated tiers, libSQL graph DB, multi-branch indexing (diff/search across branches without checkout), subprocess isolation so a single tree-sitter parser crash doesn't kill the service, atomic edit primitives with AST rewriting, and 48 MCP tools. Framework routing matches codegraph's 14-framework coverage. The Rust foundation gives it a fast startup and low memory footprint relative to the Node.js tools. Genuine limitation. No published benchmark. "Fewer tokens · Fewer tool calls · 100% local" is the whole claim, which is honest but doesn't let you predict the savings on your codebase before installing. As with codegraph, the mechanism is navigation-only. Best for: developers who prefer a compiled binary and the broader language/branch support, and are comfortable evaluating the saving themselves.

6. token-optimizer — comprehensive multi-layer compression with a quality dashboard

token-optimizer (by alexgreensh) is the most feature-complete Python-based solution: it combines AST structure maps, session continuity checkpoints, 16 bash output handlers, a quality score, and a per-turn HTML dashboard — but the PolyForm Noncommercial license is a meaningful restriction for commercial use. The reported savings are striking: 180,000-token files compressed to roughly 250 tokens via AST-based structure maps (Python/TypeScript, 95–99% claimed compression). Over 30 days and 942 sessions, the developer reports "$1,500–$2,500/month" savings — a self-reported figure without public reproducibility, but the mechanism is coherent. The 7-signal quality score (context fill, stale reads, bloated results, compaction depth, duplicates, decision density, agent efficiency) is a thoughtful anti-regression guard. A Coach mode runs 11 waste detectors to audit your CLAUDE.md and session patterns. Genuine limitation. The PolyForm Noncommercial license means you can't use it in a commercial product without a separate agreement. Setup is more complex than the Rust binaries above — Python 3.9+, TypeScript adapters for non-Claude-Code platforms, an HTML dashboard to configure. The savings numbers are self-reported. This is a powerful tool for personal or research use, but the license matters. If you are weighing it against the other tool in this field with an honest published benchmark, caveman vs token-optimizer puts the two side by side — they work opposite sides of the pipe and only one of them has a licence question. Best for: hobbyists and researchers on Claude Code who want the most comprehensive instrumentation and don't have commercial restrictions.

7. ccusage — measures usage; doesn't reduce it

ccusage is not a token optimizer, but it belongs in this list because you should run it first: it tells you exactly where your tokens are going before you decide which optimizer to reach for. ccusage reads the JSONL transcripts that Claude Code writes locally and produces daily, weekly, monthly, and session-level reports with per-model breakdowns and cache tracking (separate columns for cache-creation vs cache-read cost). It supports 15 agent environments and distributes as a platform-specific binary (bunx ccusage or npx ccusage@latest). About 15,000 GitHub stars makes it the de-facto standard in the measurement category; a half-dozen other trackers (codeburn, Claude-Code-Usage-Monitor, tokscale) are essentially UIs built on top of it. The correct workflow: run ccusage, understand whether your expensive sessions are build-heavy (rtk or Tokenade's output filter wins), navigation-heavy (semantic search or codegraph), or a mix (Tokenade). Don't optimize blind. Genuine limitation. It is purely a meter. It reports what you spent; it does not reduce that spend by one token. Pair it with one of the tools above. Best for: everyone — run this before deciding which optimizer to install.

8. squeez — rtk's mechanism, measured and unmoved

squeez does what rtk does — compress shell output and file reads before they enter context — as a single Apache-2.0 Rust binary with no runtime dependencies. It was measured in the open benchmark and showed no measurable saving. The design is the more ambitious of the two. Beyond filtering, it deduplicates identical content across calls, compacts repeated log templates into a single line, and truncates by relevance rather than by position, keeping the folded bytes locally so nothing is lost. On paper that is a strictly larger surface than command-output filtering alone. It made the published campaign, and the verdict was the same as rtk's: no measurable saving against the control. That result is worth sitting with rather than explaining away. Two independent tools attacking the same layer, one narrow and one broad, both land on no measurable end-to-end change — which is the clearest evidence in this roundup that output filtering alone is not where an agentic bill lives, however well you do it. Genuine limitation. Same boundary as rtk, and the same consequence: it never sees whole-file reads that the agent performs through its own tools, nor MCP manifests. A broader compressor on a narrow surface is still a narrow surface. Best for: anyone who wants the mechanism as one dependency-free binary, provided they read the measurement first. The full side-by-side is here.

At a glance

Tool	Mechanism(s)	Coverage	Setup	License
Tokenade	Output filter + semantic search + skeleton + lazy MCP + web compact	Broad (13 layers)	One binary, build from source	Freemium
rtk	Command output filtering	Focused	`brew install`	OSS
claude-context	Hybrid BM25 + vector search	Focused	External vector DB required	Apache-2.0
codegraph	Symbol + call-graph index	Focused	Node.js, bundled runtime	OSS
tokensave	Symbol + call-graph index	Focused	Rust binary, build from source	OSS
token-optimizer	Structure map + session compress + dash	Broad	Python setup	PolyForm NC
ccusage	Usage measurement	Diagnostic	`bunx ccusage`	MIT
squeez	Output compression + dedup + log templates	Focused	Single Rust binary	Apache 2.0

How to choose

If your transcripts are full of build logs and command noise: rtk is the simplest, most battle-tested fix, and squeez is the more ambitious take on the same mechanism. Note that neither moved the end-to-end number in the benchmark. If you want output filtering plus everything else, Tokenade covers it. If your agent reads too many files to find what it needs: claude-context (managed hosting available) or codegraph (best published benchmark) are the right focused tools. Tokenade's built-in semantic search runs fully on-device if you'd rather not add a separate service. If you want broad coverage without assembling a stack: Tokenade installs as one binary, applies output filtering, semantic search, skeleton compression, and lazy MCP loading automatically, and shows you the saving on every session. The freemium tier (free up to ~10M tokens/month, no card) lets you verify the impact before committing. Start with measurement: run ccusage to understand your session profile, then match the tool to the bottleneck. The full breakdown of which lever to apply to which waste pattern is in How to reduce AI coding agent token usage.

Methodology note

Tool facts come from each project's README and the Tokenade internal competitor analysis (reports/ directory) as of 2026-06-02. Savings numbers are as-claimed by each project; where methodology was available (codegraph's 7-repo median, claude-context's controlled evaluation), that is noted. Tokenade's own figures come from the open token optimizer benchmark, which measures whole-session cost rather than isolated compression. Self-reported numbers without public reproducibility are labelled as such. No tool was paid to appear in this list; Tokenade is our own product and is ranked on the same criteria as the rest.

Frequently asked questions

Do these tools make the agent's answers worse?

Done right, no — and often the opposite. What they remove is low-value context: raw command output, file bodies the agent never needed, tool schemas it never calls. Models attend least to material buried in a bloated context window, so a leaner window usually raises answer quality. The failure mode to watch for is a tool that compresses something load-bearing, which is why structure-first reads should keep every function signature and output filters should keep the actual error.

Can I run two optimizers at once?

Technically often yes, practically it's a bad idea. They overlap — most cover the same few levers — and stacking them makes it impossible to attribute a change to either one. Worse, two layers rewriting the same context can fight: one compresses what the other expects to find. Pick one, measure it, and switch if it disappoints.

Do they only work with Claude Code?

Most of the mechanics are agent-agnostic, because every transcript-re-reading agent has the same problem — but support varies by tool. Some are Claude Code–specific by design; others sit at the shell or MCP layer and work anywhere. Check the tool's own compatibility list rather than assuming, since the ones built around Claude Code's config format usually don't port cleanly.

Is a free or open-source optimizer enough?

For many people, yes. The core levers — filtering noisy command output, not reading whole files, pruning unused MCP servers — don't require anything paid, and doing them by hand costs nothing but discipline. What paid tooling buys is consistency and measurement: the levers applied automatically on every turn, and a number telling you whether it worked. If you'd apply them reliably by hand, the free route is honest advice.

How do I know it's actually saving anything?

Measure before and after on the same task, not on vibes. Run /context at the start of a fresh session to see your standing overhead, then compare a representative session with and without the tool. Any optimizer that can't show you its own numbers is asking for faith — measuring agent token usage covers how to get a baseline that isn't the vendor's.