Misleading analytics: gain over-counts "tokens saved"; discover under-counts adoption when hook rewrites are in play

Hi — first, thanks for the project. Hook is genuinely useful as a defense against catastrophic payload bursts. Filing this because I dug into the numbers today and the two analytics commands (rtk gain + rtk discover) gave me confidently wrong impressions of RTK's actual contribution, and the discrepancy was big enough that it sent me chasing a phantom problem.

Environment: rtk 0.36.0 on macOS, Claude Code Max plan, hook installed and verified working via manual rtk rewrite tests.

Issue 1: rtk gain reports impossible "tokens saved"

Total commands:    7467
Input tokens:      11994.2M
Tokens saved:      11989.9M (100.0%)

That's ~1.6M tokens saved per command on average. For rtk read alone (964 calls, 11518.1M saved), it's ~12M tokens per call. No Claude tool call ingests anywhere near 200K tokens, let alone 12M — Claude's context limit truncates first.

What I think is happening: gain counts the raw size of the file/output RTK chose not to forward (e.g., reading a 50MB log via rtk read reports "50MB worth of tokens saved"). But that volume would never have hit Claude under any scheme — Claude's tool-result cap would have truncated it regardless.

Effect on users: the "100% efficiency" headline creates a strong impression that RTK is preventing massive Claude usage. When I checked my Claude Max weekly quota anyway (87% used) and asked "wait, how can both be true?", the math didn't add up. The metric measures local processing volume, not Claude-quota impact.

Suggested fix: either

• Cap the per-call "saved" attribution at a realistic upper bound (e.g., 25K tokens — Claude Code's default tool-result limit), OR
• Rename the metric to "raw bytes processed locally" so users don't conflate it with Claude quota savings, OR
• Add a footnote: "savings are local-processing volume, not Claude-billed-token impact."

Issue 2: rtk discover reports near-0% adoption when hook is actively rewriting

Already using RTK: 163 commands (0%)

…across 17,564 Bash commands in 1,652 sessions over 30 days.

But manual testing of rtk rewrite on every common command in the "missed savings" list shows clean rewrites (exit 0):

rtk rewrite "ls -la"               → rtk ls -la
rtk rewrite "tail -30 /tmp/foo"    → rtk read /tmp/foo --tail-lines 30
rtk rewrite "grep -n foo bar.py"   → rtk grep -n foo bar.py

The PreToolUse hook (rtk-rewrite.sh) is installed correctly, sha matches, and Claude Code's logs show the hook fires on every Bash call. So those 17,564 commands SHOULD mostly have been rewritten in real time.

What I think is happening: discover reads the Claude Code session transcripts (~/.claude/projects/*/*.jsonl) and likely inspects the pre-hook command field (the original user-issued command). After the PreToolUse hook modifies tool_input.command via hookSpecificOutput.updatedInput, Claude Code likely logs both the original and the modified form, and discover is reading the original.

Effect: users see "0% adoption" and conclude the hook is broken when it's actually working — they go on a wild goose chase looking for hook misconfig (which is where I ended up).

Suggested fix: in discover, when parsing jsonl entries, prefer the post-hook updatedInput.command over the original command if present. Or, if Claude Code's hook output isn't logged in the jsonl, document that limitation in rtk discover --help.

Why I'm filing this

The two metrics together give a story like "we save you ridiculous amounts of tokens but you're barely using us" — which is internally contradictory. Either RTK is saving 100% AND adoption is 0% (impossible), or one (or both) of the metrics is wrong. Today I traced it to both being wrong, in different directions.

The functional product is fine. The dashboard is what's misleading. Pruning the over-claim on gain and fixing the post-hook counting in discover would make RTK's actual value (which is real but modest) legible.

Happy to test patches if you ship them — rtk 0.36.0 user, daily Claude Code on a Max plan, decent corpus of historical sessions to verify against.

Start with the rtk gain and rtk discover entry points, then inspect rtk-rewrite.sh and the JSONL files under ~/.claude/projects/*/*.jsonl. Verify how raw output size is attributed and whether post-hook commands are available during transcript parsing. Done means both commands report metrics that match hook behavior and no longer imply contradictory savings and adoption.