Compression ratio well below target — averaging ~2% instead of documented 40%

We benchmarked RTK against 41 shell commands across 5 repos (4 Go, 1 JS) using Claude Sonnet 4.6 and Opus 4.6. The methodology target is ≥40% average compression, but actual results show mean cost savings of +0.2% (Sonnet) and +2.7% (Opus) — essentially noise.

Only 7 of 41 commands exceeded 5% savings. 34 of 41 commands fell within ±2%.

Environment

• RTK version: brew install rtk-ai/tap/rtk (latest as of 2026-05-17)
• Agent: Claude Code SDK (Sonnet 4.6 / Opus 4.6)
• Repos: Go monorepos + 1 JS repo
• Commands: go test, go build, go vet, make *, git *, pnpm *

What we expected

RTK compresses command output before it enters the agent context. For verbose commands (go test -v, go test -race, lint output), we expected significant token reduction in cache_creation_input_tokens.

Key data points

Where RTK works (>5% savings):

• go test -race ./... — 10-18% savings (race detector output is highly compressible)
• go test -tags=ut -race ./... — 8-14% savings
• go test -v ./internal/usecases/agents/... — 5-7% savings (verbose flag = more output)
• go vet ./... on genaihub — 6-12% savings (large codebase = many findings)

Where RTK does nothing or hurts (±2%):

• All git commands — output is already terse
• All go build / make build — success output is minimal
• go list ./... — package names are already compact tokens
• pnpm install / pnpm run test — output is short
• make test (wrapped targets) — Makefile absorbs verbose output
  Questions

1. Is RTK doing anything for short output? When cache_write baseline is ~5,300 tokens, RTK shows 0% delta. Is there a minimum output threshold below which RTK should bypass compression entirely to avoid overhead?
2. Compression strategy for Go test output: The only consistent wins are commands with -race or -v. Standard go test ./... (PASS/FAIL summary only) gets no benefit. Is RTK's compression tuned for verbose/repetitive patterns specifically, or should it also be summarizing structured output?
3. Cache write token counts are nearly identical between baseline and RTK for most commands.
   Example: git status baseline=9,542 cache_write vs RTK=9,523 cache_write. The difference is just the response text variation, not actual compression. Is RTK actually intercepting and compressing these commands, or is it passing through when output is below some threshold?
4. What output volume (tokens) does RTK need before compression becomes effective? Our data suggests the breakeven is somewhere around 1,000+ raw output tokens. Below that, RTK is neutral-to-negative.

Reproduce the reported benchmarks with go test, go build, go vet, git, make, and pnpm commands, comparing short and verbose output. Then trace RTK's command interception and compression behavior for outputs below and above the reported 1,000-token breakeven. Done means the pass-through behavior, effective threshold, and compression gap are explained and a concrete scope for correction is established.