Field test · October 14, 2026

Does rtk actually save tokens?

Two Claude Opus 5.5 agents got the same coding task in the same repo at the same commit. One ran with rtk's Claude Code hook, which compresses shell output. The other ran without it. This page shows what each one actually spent.

Shell output sent to the model
−16%with rtk

50,148 → 42,028 characters across every Bash call. rtk's own tracker counts 1,482 tokens saved.

Total input tokens processed
+14%

The rtk agent made 2 more requests, and each request re-sends the whole conversation.

Cost at API list price
$0.77 vs $0.77

Even: $0.7669 without rtk, $0.7695 with it.

How it was run

Headless Claude Code (claude -p) runs, so token counts come straight from the API usage records.

Same startTwo fresh git worktrees of a real production monorepo at one commit, each with a clean npm ci.
Same agentClaude Code 2.1.287 with claude-opus-5-5, the same project instructions and the same MCP setup.
One differenceThe rtk side got rtk 1.0.0's PreToolUse hook and RTK.md instructions, exactly what rtk init -g installs.
Same promptBoth ran in parallel. Both hit an account usage limit partway and were resumed with the same “continue” prompt.
Task: Add tests/calendar-care.test.ts covering every guard branch and the success path of a payment-enrollment module, following existing test conventions. Run it, make `npm run check` pass (typecheck + boundaries + ~445 tests), and commit.

Outcome: both succeeded. Each wrote 11 passing tests (436 lines without rtk, 576 with it), got a green check and made one commit.

Without rtkWith rtk

Context size per request

The rtk run's context grows more slowly, but it runs two more requests.

Cumulative input tokens

Each request bills its full context again, so the two extra requests outweigh the smaller outputs.

Where the tokens went

Almost all input is served from the prompt cache. Output (the test file the agent wrote) is the same size on both sides.

Every tool call, in order

Bar height is the size of the result returned to the model. Hatched bars are file writes, which rtk doesn't touch.

Without rtk
With rtk

What each Bash call returned

Most of the cost comes from exploration (cat, sed, grep), where rtk changes little. Test and check runs were already piped through tail / grep by the agent.

rtk's own ledger

From rtk gain after the run. 22 rewritten commands, because the hook rewrites each part of a && chain.

CommandRunsSavedRate

Takeaways

From one run per side. Read them as signals, not a verdict.

  • rtk did compress. Directory listings shrank 62–75%, and every Bash call returned 16% less output overall.
  • Frontier agents already filter. Opus piped noisy commands through tail -40 or grep on its own, leaving rtk little to cut on the expensive calls.
  • Request count matters more than output size. Each extra request re-reads about 60K cached tokens, so two extra requests cancelled out all of rtk's savings.
  • Caching blunts the savings. 89–92% of input was cache reads at a fraction of the normal price, so smaller outputs barely change the bill.
  • Where rtk should do better: long unfiltered output such as full builds, cargo test, large git log or docker logs, or agents that don't trim output themselves.

Caveats

One run per side. The agents' paths diverge after the first step, so the differences mix rtk's effect with ordinary run-to-run variation. Wall time (190s vs 210s) includes a shared queue for heavy commands, because both ran npm run check at the same time. Usage figures are cumulative totals from each session's final result.