rtk Alternatives: 6 Tools Compared

What should you use instead of rtk?

If you want the bill to move, use Tokenade: it is the only one of the twelve tools in the open THOL benchmark that measurably lowered what a session costs, and rtk itself landed at no measurable saving. If you like rtk's mechanism and only want it broader, squeez is the closest swap.

rtk is good at what it does. It ships 100+ command filters in a Rust binary, supports 18 AI coding tools, and has the easiest install in the category. The reasons people look elsewhere are narrower than "it doesn't work".

• It only sees shell commands, not the agent's built-in file reads, search or MCP results.
• Its savings counter measures bash output, not the bill. Its own README says the reduction "dilutes at every step".
• The default download now ships its compression engine under BUSL-1.1, next to an Apache-2.0-only rtk-oss edition.

Disclosure before the ranking: I maintain the THOL benchmark and I build Tokenade. The benchmark is public and reproducible, and it includes results that don't flatter my tool, but it is not an independent third party.

Features and prices read on each project's page on 2026-10-14. Session-cost verdicts come from the published THOL campaign (Claude Code 2.1.206), the only one this site quotes.

If you already have one rival in mind rather than a shortlist, each pairing has its own page:

• headroom vs rtk for whole-message compression against shell filtering;
• rtk vs caveman for the input side against the output side;
• rtk vs token-optimizer for one mechanism against four;
• rtk vs tokensave and codegraph vs rtk for filtering the shell against indexing the code;
• rtk vs graphify when your project's knowledge lives in documents;
• rtk vs ccusage if what you need first is a meter.

The short list

How we picked

Five criteria, applied identically to every entry including mine:

• Measured session cost. End to end, against a no-tool control, from THOL. All six tools here and rtk were in the same published campaign, which makes this list unusually comparable. Vendor figures stay in prose, attributed, with the scope they were measured on.
• Reach beyond bash. rtk sees shell commands. File reads through the agent's own tools, MCP results and conversation history are outside it.
• Install weight. A single binary, a Node runtime, an account and a hosted gateway are four different commitments.
• Agent coverage. One agent, or your whole stack.
• Licence, and where your traffic goes. Local-only and gateway-routed tools carry different privacy surfaces.

Two families are left out on purpose. headroom finished last in THOL, measurably more expensive than running nothing. Code indexers such as codegraph solve a different problem; they have their own CodeGraph alternatives page.

1. Tokenade — the one measured to lower session cost

Tokenade is the strongest rtk alternative on the criterion that matters most: it is the only tool of the twelve in the open benchmark that measurably reduced what a session costs.

• What it is: a binary between your AI agent and its tools that combines output filtering, structure-first file reads, on-device semantic code search, sandboxed execution and MCP result folding, with a savings dashboard.
• Strengths: on the open token optimizer benchmark it cuts session cost by 39% on long sessions against running no tool at all. Filtering applies to every tool's output, not only bash, so the agent's own reads and searches are covered too.
• Install: one tokenade install detects your agents and registers the hooks. What each agent supports is on the compatibility matrix. Compaction runs on your machine, and tokenade uninstall --dry-run shows the teardown before you need it.
• Limitations: it's my product, so weight this accordingly. It is freemium and not open source, where everything else here is free or has a free core. Like any compactor it can fold output you needed; tokenade raw <cmd> reruns a command uncompacted.
• Best for: anyone who wants the bill to move, on more than one AI agent. The attribute-by-attribute view is on Tokenade vs rtk.

2. squeez — rtk's mechanism, with more reach

squeez is the closest like-for-like rtk alternative: one Rust binary that compresses shell output before it enters context, and file reads too where the host exposes them.

• What it is: a hook-based compressor with smart filtering, cross-call deduplication, log-template compaction and relevance-based truncation. Apache-2.0, no runtime dependencies.
• Strengths: compression is reversible, because the original bytes are kept locally and the agent can pull them back. A preservation guard keeps the verbatim original when a heavy cut would drop file paths, error markers or test verdicts. Install by curl, npm or cargo; squeez setup detects your CLIs.
• Limitations: in THOL it showed no measurable saving, the same verdict as rtk. By its own documentation it cannot compress sub-agent return values, top-level prompts or skill files loaded at session start, and support varies by host.
• Best for: rtk users who want the same layer done more carefully. The side-by-side with ours is Tokenade vs squeez.

Two independent tools on the same layer, one narrow and one broad, both landing on no measurable change is the clearest hint in this list: output filtering alone is not where an agentic bill lives.

3. lean-ctx — the widest open-source toolkit

lean-ctx is the pick if you want rtk's shell compression plus caching, retrieval and a proxy in a single open-source binary, and you're willing to configure it.

• What it is: a Rust binary working on two planes. On the read path, an MCP server exposes ctx_* tools (read modes, caching, deltas, search, memory) beside a shell hook. On the wire path, an opt-in local proxy can trim prompts, history and tool results.
• Strengths: the read cache makes repeat reads cheap, and the proxy reaches conversation history, a surface hook-only tools like rtk never touch. Install by curl, brew, npm or cargo. Its savings report is candid: it labels its baseline as simulated, not a second measured run.
• Limitations: no measurable saving in THOL; it measured slightly more expensive than no tool, though not significantly. A large MCP tool set carries a fixed cost every session. The licence is mixed, with enterprise controls under separate terms.
• Best for: tinkerers who want one tool for cache, compression and retrieval, and will tune it. See Tokenade vs lean-ctx.

4. caveman — both sides of the session, one npx

caveman is the broadest-coverage rtk alternative: one install that shortens what the agent says and, since 4.0, what it reads, across 30+ agents.

• What it is: a Node CLI (npx @caveman-ai/cli@latest, Node 22.13+) that bundles a terse output voice, read-side compression of logs, JSON, CSV and test output, a model picker and smaller fixes. Apache-2.0.
• Strengths: caveman advertises 33.2% fewer input tokens per session for its read-side compression. That was measured on six test files that each hide one record in 61–72 KB of noise, over three runs, and its README flags that HTML got worse. Originals stay on disk.
• Limitations: the published THOL campaign shows no measurable saving for caveman. I haven't re-measured 4.0, so treat that verdict as covering the version tested. It needs a Node runtime, its optional model picker needs a free account, and the voice isn't to everyone's taste.
• Best for: multi-agent stacks that want a cheap experiment. The mechanism split is on rtk vs caveman and Tokenade vs caveman.

5. claude-token-efficient — the lightest possible test

claude-token-efficient is the rtk alternative with nothing to install: one CLAUDE.md file, and it placed second of twelve in THOL.

• What it is: a drop-in file of compact behaviour rules against filler, restated questions and over-engineering. MIT.
• Strengths: no binary, no hook, nothing to uninstall. The project is unusually honest about scope: it reports output-token reductions of about 4% on Haiku, 12% on Sonnet and 7% on Opus for its current minimal file, and warns the file adds input tokens on every turn.
• Limitations: second place still meant no measurable saving against the control. It works on a different layer from rtk entirely and never touches command output, file reads or MCP manifests.
• Best for: a zero-risk first step, or a base layer under something that reduces input. See Tokenade vs claude-token-efficient.

6. edgee — rtk's idea, moved to a gateway

edgee is the rtk alternative for teams that want routing and spend control more than a local filter: per its own README, its trimming engine is derived from rtk.

• What it is: an AI gateway. edgee launch claude routes your agent through a hosted gateway that trims tool outputs before they reach the model. The CLI is Apache-2.0.
• Strengths: gateway features a local tool can't offer — fallbacks, model reroutes, team usage tracking, and spend caps on the paid tier. It installs on Windows as well as macOS and Linux, and edgee stats shows per-session savings.
• Limitations: no measurable saving in THOL. Your agent traffic transits a third-party gateway, you sign in with edgee auth login, and compression stops if the service is unreachable. Team controls are paid per developer.
• Best for: teams that need routing and budgets. Individual developers who only want local compression are pointed back to rtk by edgee's own README, which is a fair call. See Tokenade vs edgee.

At a glance

Why does rtk's counter disagree with your bill?

Because rtk gain measures the bash output it shrank, and that is a slice of a slice. rtk's README is explicit about it: bash output is one contributor to input tokens, next to your prompt, the system prompt and history, and input is only part of the bill.

Its token counts are also estimated as bytes divided by four, since rtk ships no tokenizer. So a big percentage on cargo test is real for that command and says little about the session. The full reading of the two numbers is on rtk vs ccusage.

There's a second effect THOL makes visible. When lossy compression drops the bytes the model needed, the agent reruns the command, often around the tool. That costs turns, and turns are what you pay for. Every alternative above should be judged on the same session-level question, mine included.

Which one should you choose?

• You want the bill to go down, on more than one AI agent: Tokenade. The method and the full table, including entries that don't favour it, are on the THOL leaderboard.
• You like rtk and want the same layer, reversible: squeez.
• You want cache, compression and retrieval in one open-source binary: lean-ctx, with time to configure it.
• You run many agents and want a cheap experiment: caveman.
• You want to change nothing but a file: claude-token-efficient.
• You need routing, fallbacks and spend caps for a team: edgee.
• You're staying on rtk: reasonable if noisy builds and tests dominate your sessions. Read rtk gain as bash-output savings, not as your bill.

Tokenade's free tier covers a lot of solo work outright; current plans are on the pricing page.

FAQ

Is there a free alternative to rtk?

Yes. squeez, caveman and claude-token-efficient are free and open source, and lean-ctx is free for local use. edgee and Tokenade both have free tiers. Free is not the same as cheaper, though: in the published THOL campaign none of the free tools showed a measurable drop in session cost.

What is the difference between rtk and rtk-oss?

Per rtk's README, the default rtk download combines Apache-2.0 and BUSL-1.1 code and includes the compression engine. rtk-oss is Apache-2.0 only, with the hooks and filters but no engine. Both install a binary named rtk, so you uninstall one before installing the other. Production use is free for both.

Does rtk break prompt caching?

No, according to its README: it filters each command's output once, and the result is cached normally on later calls. Tools that rewrite the conversation history on every turn are the ones that break the cached prefix, which is part of why headroom finished last in THOL.

Can I run an rtk alternative alongside rtk?

You can, but two tools compressing the same command output add overhead and make both savings counters unreadable. Pick one tool per layer. Pairing a shell filter with something that handles file reads or retrieval makes more sense than stacking two filters.

Is edgee built on rtk?

Partly. edgee's README says the token trimming engine in its gateway is derived from rtk, with the original copyright kept. The difference is where it runs: rtk compresses locally, edgee compresses on a hosted gateway your agent traffic passes through.

---

See also:

• Tokenade vs rtk — the two side by side, attribute by attribute
• Token optimizer benchmark — the five numbers behind this ranking, and how they were measured
• Best Claude Code token optimizers — the full field, same methodology
• Headroom alternatives — the same question for message compression
• tokensave alternatives — the same question for compiled code indexes
• ccusage alternatives — the same question from the measurement side
• Cut Claude Code costs, keep the model — the levers ranked by what they're worth