Is SuperCompress better than RTK?

For full agent context (Read/Grep dumps, RAG, chat history, mixed tool output), yes as the default: SuperCompress is query-aware and scores any context against the current question. RTK is excellent at compressing shell command stdout via hooks, but it does not compress most of the session (built-in Read/Grep, prompts, history). Measure your bill, not only bash-byte ratios.

What is the best RTK alternative in 2026?

SuperCompress is the RTK alternative when you need query-aware compression across the whole context window — MCP for Cursor/Claude Code/Codex, hosted API, and held-out answer-keep gates. Keep RTK if you only want transparent bash-output filters.

Can I use SuperCompress and RTK together?

Yes. RTK can shrink shell stdout; SuperCompress can still compress the remaining tool dumps and conversation against the query. They attack different layers — do not assume either alone is a 90% bill cut.

Does RTK cut 60–90% of my LLM bill?

Not automatically. RTK reports compression on bash output it intercepts. Independent evaluations (e.g. JetBrains skill trial) found session cost can stay flat or rise because bash is only part of input tokens and retries/cache can dominate. Always measure paired session cost.

RTK alternative · Updated 2026-08-20

SuperCompress vs RTK (Rust Token Killer)

Searching for an RTK alternative? RTK is a Rust CLI that intercepts shell command output and filters it before the agent reads it. SuperCompress compresses any context against the current query — Read/Grep dumps, RAG, chat, JSON, and shell — via MCP/API, with published answer-keep gates.

Verdict: Use SuperCompress when you care about the whole context window and whether the answer survives. Use RTK when you only want transparent bash/stdout filters. They can stack; neither is a guaranteed 90% bill cut on its own.

Different jobs

This is the comparison people get wrong:

RTK — PreToolUse / CLI rewrite for git, cargo test, logs, etc. Shrinks command stdout the agent sees.
SuperCompress — Query-aware compression of the context blob (MCP compress_context, hosted API, Python). Keeps answer-critical lines in original wording.

Claude Code built-ins like Read / Grep often bypass RTK hooks. Those dumps are exactly where SuperCompress helps.

Side-by-side

Factor	RTK	SuperCompress
Primary target	Shell / bash tool stdout	Any context + query
Mechanism	Command filters, grouping, truncate, dedupe	Query-aware evidence selection
Query-aware?	No (command-structure aware)	Yes — scores against the question
Read / Grep / RAG dumps	Usually out of scope	First-class
Install	Rust binary + agent hooks	`npx supercompress setup` / pip / API
Answer-keep gates	Stdout fidelity focus	Held-out ≥98% answer containment (primary suites)
Bill impact	Only the bash slice of input tokens	Any oversized context you send through it
Best default for	Noisy test/git/log spam	Agents + APIs that drown in mixed context

Why “60–90%” is not the same as your invoice

RTK’s own docs note that bash is only one contributor to input tokens, and input is only part of the bill. Independent skill trials have reported flat or higher session cost even when the tool’s scoreboard looked great — because of retries, cache reads, and the fraction of traffic the hook never sees.

Rule: measure paired session cost with and without the tool. Do not ship marketing that confuses “bytes of git status” with “dollars on the provider invoice.”

When RTK still wins

You want zero app changes and only bash is blowing up context.
You love a single Rust binary with per-command filters.
You’re already happy with hook-only adoption and don’t need RAG/API compression.

When SuperCompress wins

Cursor / Claude Code / Codex sessions full of file reads, greps, MCP, RAG.
You need a hosted API or Python library in front of every model call.
You care about answer containment on held-out suites, not only cut %.
You want one install that compresses the dump against the current ask.

Stacking (optional)

RTK can clean stdout; SuperCompress can still compress the remaining transcript against the query. Treat them as layers — not rivals for the same metric.

Get started

npm i -g supercompress-proxy && npx supercompress setup
# or
pip install supercompress

Coding agents: docs.supercompress.dev/coding-agents · Benchmarks: /benchmarks