RTK's Savings Number Is Measured Per Command, and Labelled an Example

RTK — Rust Token Killer — is a standalone binary that intercepts a shell command, runs it, filters the output, and returns far fewer tokens to the model without losing the signal. ECC installs it, wires it, and reports it. It does not fork it or copy its code; RTK is Apache-2.0, written by its own team.

The number you'll see quoted — 60 to 90 percent — is real and measured. It is also easy to misread. This post is about how it's measured, and why ECC prints the headline figure next to the word "example."

The hook, not a wrapper you remember to type

You don't run rtk yourself. ECC installs a PreToolUse hook into your AI tool's config. When the tool tries to run git status, the hook rewrites it to rtk git status transparently. RTK executes the real command, filters the output with command-specific rules, and returns the compressed result. The model sees only the compressed output — it never knows the raw output existed.

Bash tool: git status
        │  PreToolUse hook rewrites →  rtk git status
        ▼
   RTK filter  (strips ANSI, timestamps, duplicated lines, formatting noise)
        ▼
   compressed output → model context

A hundred-plus commands are covered — git, ls, tree, grep, cargo, pytest, docker, kubectl, npm, gh, and more. RTK describes itself, in its own --help, as a proxy that filters and summarizes system output "before it reaches your LLM context."

rtk gain measures bytes, per command

The saving is not estimated. RTK keeps a ledger, and rtk gain reports it from real byte counts: for each command, the raw bytes it received versus the compressed bytes it returned. ECC's dashboard reads it straight through, with rtk gain --all --format json, whose summary carries exactly these fields:

{
  "summary": {
    "total_commands": 1285,
    "total_input":    7964612,
    "total_output":   2858501,
    "total_saved":    5107394,
    "avg_savings_pct": 64.1,
    "total_time_ms":  ...,
    "avg_time_ms":    ...
  }
}

total_saved is total_input - total_output, summed across every command RTK has filtered. ECC synthesizes none of it — the savings() wrapper is a thin read of RTK's own ledger. Check your own wiring at a glance:

kodelythecc rtk status

RTK: rtk 0.42.4
ECC-installed IDEs: claude-home, codex-home, gemini-home
RTK integrations:
  [ok] Hook: rtk hook claude (native binary command)
  [ok] settings.json: RTK hook configured
  [--] Cursor hook: not found

The headline figure is an example, not a promise

That 64.1 percent above is one maintainer's machine at one point in time. ECC prints it next to an explicit caveat, because it is a property of the commands that were run, not a guarantee the tool makes:

Run rtk gain to see your numbers. The figure above is an example, not a promise — savings depend entirely on which commands you run.

A session dominated by huge, un-cached git log and cargo test output will land near the top of that range. A session that mostly runs small commands will land well below it. The only honest number is the one your own ledger reports, which is why the dashboard reads live rtk gain rather than hardcoding a figure.

Bytes off the wire are not dollars

One more honesty, worth stating plainly: tokens removed is a volume number, not a billing number. Providers charge a fraction for cached input, and a lot of repeated shell output lands in cache within a few turns — so a 64 percent volume cut can translate to a much smaller spend cut on long interactive sessions. That gap has its own post: Tokens Saved Is Not Dollars Saved. Keep RTK on regardless — the volume saving still buys you rate-limit headroom and context-window room, which cache discounts don't.

The rtk that isn't RTK

A detail that only matters because getting it wrong would be silent: there is a different binary also named rtk (Rust Type Kit). Wiring or measuring it as if it were Rust Token Killer would mean ECC patches hooks and then reads a gain ledger that doesn't exist — and reports nothing, forever, with no error.

So before wiring or measuring, ECC confirms it's the real one by probing a command only Rust Token Killer has:

// Rust Token Killer is the only `rtk` with a `gain` subcommand.
execFileSync('rtk', ['gain', '--help'], { stdio: 'ignore' }); // exit 0 → it's RTK

The decision is a pure function of two probe results, so it's unit-tested without spawning a binary. Guarding a name collision with a side-effect-free probe beats parsing version strings that upstream can change.

Using it

RTK installs automatically with ECC (opt out with --no-rtk). The rest:

kodelythecc rtk install              # install the binary (brew or curl)
kodelythecc rtk enable --all         # wire it into every ECC-installed IDE
kodelythecc rtk gain                 # your own measured savings
kodelythecc rtk status               # binary version + active integrations

RTK is Apache-2.0 by rtk-ai/rtk. ECC's wrapper — the install, the per-IDE wiring, the name-collision guard, and the ledger read — is thin MIT Node in scripts/rtk/index.js. Full details in RTK Integration, and the output-side companion in Terse Mode.

npm i -g kodelyth-ecc && kodelythecc --target claude-code