Skip to main content
FB.
Share on LinkedIn

3/6 · Mapping the token-reduction toolbox

Compare RTK, Tokenade, Headroom and prompt caching by mechanism, integration and evidence. Smaller tool output does not establish a cheaper completed task.

Jump to summary
• 14 min read • Updated Oct 1, 2026
Florian Bruniaux

Written by Florian Bruniaux

AI Founding Engineer at Méthode Aristote, 13 years scaling engineering teams from developer to CTO. Builds open-source developer tools, see what else I've shipped.

TL;DR

I use RTK and find it very effective on CLI output: its own counter reports 48% to 81% of CLI output tokens saved per full month from July to September 2026 on my machine (read on 2026-10-02), which is not my bill. I expect agents to get more efficient while we hand them more work and subscriptions give less quota for the same price, so cost per accepted task, not compression ratio, is the number to track.

TL;DRWhat to check
MechanismFiltering, selecting, delegating and caching change different parts of a session
CoverageA shell hook, an MCP proxy and a model gateway cannot automatically reach the same traffic
EvidenceCompare complete tasks, including retries and quality, rather than headline compression ratios
OwnershipRTK publishes its source; Tokenade distributes a proprietary engine behind a public installer

Disclosure: I contribute to RTK. The same standard applies to its claims and its competitors: name the workload, the denominator and the evidence boundary.

A shorter tool response can help an agent finish with less context. It can also make the agent read the original again. The useful comparison starts with the work that changed, then follows every model call needed to finish the task.

The earlier version of this article grouped tools into four exclusive layers. That was too rigid. Tokenade combines command filtering, code navigation, context controls and output instructions; Headroom exposes different integration modes. A product can occupy several rows of the map.

Four interventions: filter tool output, select relevant context, delegate to a worker model, and reuse a cached prefix.
These interventions affect different parts of the work. A reused prefix can still occupy the model’s context window.

The mechanism map

The four interventions in the figure expand into the mechanisms below. A tool may appear in several categories; compare its integration surface before comparing its savings.

MechanismExamples to investigateWhat needs measuring
Command-output filteringRTK, Snip, Distill, TokenadeOutput retained, missed details, raw retries
Selective reads and navigationlean-ctx, Serena, Token Savior, TokenadeIndex cost, correct retrieval, extra calls
Pre-read middlewareOpenWolfWhether the agent requests the original when needed
Tool discovery and executioncontext-mode, Cloudflare MCP, mcp2cliLoaded schemas, result size, execution and recovery costs
Documentation retrievalContext7Relevance and freshness of retrieved documentation
Prompt compressionLLMLinguaInput reduction and downstream task quality
Output instructionsCaveman, claude-token-efficient, SuperClaudeOutput length, readability, omitted requirements
Compression and recoveryHeadroom, Context GatewayCache effects, storage lifetime, retrieval behavior
Gateway servicesLiteLLM, Bifrost, EdgeeFeatures enabled and traffic actually routed through them
Visual representationpxpipeImage billing, exact-string recall, supported models
Delegated workSpotify Portal pluginsWorker cost, latency and verification by the main agent

This inventory identifies approaches, not independently tested integrations. LLMLingua prunes input before inference; it does not belong in a category that only shortens the model’s answer. Monitoring tools such as ccusage and ccboard help inspect usage; their presence alone does not reduce it.

Deep-dive 1: RTK and command-output filtering

RTK filters command output before the agent consumes it. For example, a test run can retain failures while collapsing passing cases. Its Claude Code Bash hook rewrites supported shell commands; native Read, Grep and Glob calls do not pass through that hook. The CLI also exposes compact file reading, including signatures-only output. RTK documentation

rtk gain reports local before/after estimates for the commands it processed. It does not measure the cost of a counterfactual session without RTK. A lower monthly filtering ratio can result from a different command mix or filter behavior; the model’s growing output share does not directly explain a change in this command-only denominator.

Keep the raw result accessible during evaluation. If a filter hides a diagnostic, count the extra read and the time spent recovering it. RTK’s documentation distinguishes reductions in Bash output from reductions in the bill and explains its byte-based token estimate. How RTK savings work

Tokenade covers more surfaces, with a proprietary engine

Tokenade combines filtering with code navigation, MCP proxying, deduplication and instructions for concise answers. Its published Claude Code benchmark configuration includes hooks around tool use and compaction, plus rules encouraging batched operations. This is a broader intervention than a command filter. It also means an aggregate improvement cannot be attributed to one mechanism without testing the components separately. Benchmark integration manifest

The public npm repository contains an installer and launcher. Its LICENSE explicitly describes the software as proprietary, despite the FAQ describing a MIT core. Treat the distributed engine as proprietary until that contradiction is resolved. A public installer does not make the engine auditable. Tokenade licence

Tokenade’s own comparison understates parts of RTK: RTK documents compact file reads and native Windows support. The difference is broader integrated coverage, not the complete absence of file-reading support in RTK. Conversely, a signatures-only reader is not a repository-wide semantic index.

Compatibility must be checked for the exact client. Tokenade’s current table distinguishes Codex CLI from the Codex desktop app, where coverage is mainly through MCP. A check mark for the CLI is not evidence that the app’s native reads or shell calls are intercepted. Product integration table

What the Tokenade benchmark establishes

THOL is maintained by Tokenade’s author, who discloses that relationship. In its published Claude Code 2.1.206 campaign, Tokenade 0.8.13 has a cost ratio of 0.768 against control, versus 1.052 for RTK 0.42.3. Their respective intervals are 0.647–0.900 and 0.913–1.190. I do not take the RTK figure at face value: the campaign is run by the author of a competing tool, and RTK’s interval includes no effect. Both report 170 successful runs across 17 tasks. The aggregate is a geometric mean of per-task cost ratios. Published results

Those results support a gain for Tokenade within that campaign. RTK’s interval crosses 1; it establishes neither a definite penalty nor equivalence. The experiment compares complete configurations, including behavior-changing instructions. It does not establish which component caused the difference, or predict savings on another model and workload. No independent reproduction is presented here.

Deep-dive 2: the MCP tax

Tool schemas have a context cost, but the amount depends on the client, server and discovery mode. It is incorrect to assign a fixed token tax to every connected server or assume every schema is fully loaded on every turn. Claude Code supports deferred tool discovery. Inspect what the session loads before estimating overhead. Claude Code cost controls

CLI conversion, lazy discovery and code execution are different options. A CLI moves some discovery into commands; an execution tool lets the agent compute over data and return selected results. Both still require usable descriptions, execution time and enough feedback to detect mistakes. A skill can reduce eager instruction loading, but its discovery metadata and invoked content also consume context.

Deep-dive 3: output

Concise responses can reduce generated tokens. They can also omit the explanation a reviewer needs. Ask for short routine confirmations while preserving assumptions, failures and evidence boundaries. Measure whether brevity changes task completion or review effort before treating it as free savings.

Subscription authentication does not make every gateway technically impossible. Support depends on the client’s routing and authentication interfaces and the gateway’s documented integration. Usage estimates are also different from the fixed subscription charge or usage-credit bill. Verify the exact supported path rather than infer compatibility from the presence or absence of an API key.

Prompt caching: before the tool layer

Caching reuses provider computation for a matching prefix. It does not necessarily remove that prefix from the model’s context window. A compressor that rewrites an established prefix can trade fewer tokens for more cache writes or misses. Evaluate both together.

Keep stable instructions before changing task data where the client allows it. Record fresh input, cache writes, cache reads and output separately, using the provider’s current rates and retention rules. There is no single cache lifetime or pricing multiplier that applies to every provider and model.

Headroom’s recovery approach adds another dependency: retaining an original is useful only if it remains available and the agent retrieves it when needed. TTL, eviction and retrieval failures belong in the test. A smaller compressed payload is insufficient evidence for unchanged answer quality. Headroom source and documentation

What doesn’t work, and measuring first

A byte or character count divided by four is a heuristic, not an OpenAI tokenizer. Its error depends on language and content and need not point in one direction. Use provider usage for billed requests, or identify the tokenizer used for an offline estimate.

Avoid universal pie charts assigning fixed shares to shell output, file reads and model responses. Their shares change by task, and token volume is not cost. Likewise, savings from separate mechanisms cannot simply be added: they may target the same content or change the agent’s subsequent behavior.

Nested scopes show filtered tool output inside a session, inside an accepted task that includes attempts and rework.
A reduction in processed output is a local measurement. Compare accepted tasks before claiming overall cost or productivity savings. View full-size image.

What to do Monday

  1. Select representative tasks with a checkable outcome, including one where an exact detail must survive compression.
  2. Record the unmodified agent’s usage and result over repeated runs.
  3. Test one optimizer configuration at a time with the same model, task inputs and cache policy.
  4. Count failed attempts, retries, worker calls, setup costs and any optimizer subscription.
  5. Keep the configuration only if the improvement survives at acceptable task quality.

A smaller local payload is useful evidence about a filter. A lower cost per accepted task is evidence about the workflow. On a subscription, also measure usable capacity and review effort rather than promise a lower fixed monthly fee.

Part one covers the context problem; part two covers maintenance. The guide’s context reference tracks the wider ecosystem.

Keep token savings beside cost per accepted task. Include unsuccessful attempts, retries, review and rework; keep human minutes separate from money unless their valuation is explicit. If no task is accepted, the ratio is undefined. A smaller context bill can coexist with more expensive verification.

YSNK

  • Tools can operate at several points in the same session; classify mechanisms and integration surfaces separately.
  • RTK’s local estimates are not an invoice or a complete-session counterfactual.
  • Tokenade publishes a broader configuration and favourable vendor-run results, while distributing a proprietary engine.
  • Native tool discovery and provider caching affect the cost of third-party optimizers.
  • Evaluate complete tasks, including failures and recovery, before combining tools.
Contact