rtk read: truncation via --max-lines incorrectly counted as token savings, producing 250M+ saved tokens in one command

[kotofos]

Bug

When rtk read truncates output via --max-lines the dropped content is recorded as "saved tokens" in the
tracking database.
This inflates rtk gain numbers. In my case, a handful of large bioinformatics files (FASTA, SAM) pushed reported savings to 278M tokens — almost entirely fake.
Real data from my history — a few bioinformatics file reads dominate the entire dashboard:

rtk gain --tier pro -q
RTK Token Savings (Global Scope)
════════════════════════════════════════════════════════════

Total commands:    92
Input tokens:      278.1M
Output tokens:     6.0K
Tokens saved:      278.1M (100.0%)
Total exec time:   25.6s (avg 277ms)
Efficiency meter: ████████████████████████ 100.0%

By Command
────────────────────────────────────────────────────────────────────────
  #  Command                   Count   Saved    Avg%    Time  Impact    
────────────────────────────────────────────────────────────────────────
 1.  rtk read                     17  269.2M   88.1%   150ms  ██████████
 2.  rtk curl -sL https://...      1    8.8M  100.0%    1.8s  ░░░░░░░░░░
 3.  rtk ls                       27    2.8K   65.5%     1ms  ░░░░░░░░░░
...

Reproduction

Environment

• rtk 0.34.2
• Linux 6.12.0
• Claude Code with PreToolUse hook (rtk-rewrite.sh v3)

# 1. Create test file: 1000 lines, ~90KB                                                                                                     
python3 -c "for i in range(1000): print(f'line {i}: ' + 'x'*80)" > /tmp/test.txt                                                             
wc -c /tmp/test.txt   # 90890 bytes                                                                                                          
                                                                                                                                             
# 2. Read with --max-lines                                                                                        
rtk read --max-lines 1 /tmp/test.txt > /dev/null                                                                                             
                                                                                                                                             
# 3. Check tracking DB                                         
sqlite3 ~/.local/share/rtk/history.db \
  "SELECT input_tokens, output_tokens, saved_tokens, savings_pct
   FROM commands ORDER BY id DESC LIMIT 1;"                                                                                                  

# Result:                                                                                                                                    
#   input_tokens  = 22723    ← ceil(file_size / 4), from stat()
#   output_tokens = 9        ← actual output after truncation                                                                                
#   saved_tokens  = 22714    ← WRONG: this is discarded data, not savings                                                                    
#   savings_pct   = 99.96    ← meaningless    

Expected behavior

Does not count dropped data with --max-lines as saved, input_tokens should be derived from the content actually read

[Flipsi85]

Additional data point: rtk grep has the same inflation issue

rtk version: 0.35.0
OS: macOS (Darwin 25.3.0, arm64)

Same root cause, different command. My rtk gain dashboard:

Total commands:    119
Input tokens:      8.4M
Output tokens:     46.8K
Tokens saved:      8.4M (99.4%)

The per-command breakdown makes the bug obvious:

Command	Count	Saved	Avg%
rtk grep	14	7.7M	34.1%
rtk read	25	431.0K	33.8%

The math doesn't add up:

• If rtk grep saved 7.7M at 34.1% average, the raw input would have been ~22.6M tokens across 14 calls (~1.6M per grep). That's implausible for normal repo searches.
• The global "99.4%" contradicts the per-command averages (34%, 59%, 86%) — no weighted combination of those produces 99.4%.
• "Input tokens: 8.4M" and "Saved: 8.4M" are nearly identical, suggesting input_tokens includes data that was filtered/truncated before ever reaching the LLM.

This confirms the issue isn't limited to rtk read --max-lines — it affects rtk grep (and likely other commands) wherever output is filtered or truncated.

Suggestion: input_tokens should reflect what would have been sent without rtk (i.e., the raw command output), and output_tokens should reflect what was actually sent. The difference is the real saving. Currently input_tokens seems to come from stat() or a similar pre-filter estimate.

[pszymkowiak]

[w] wshm · Automated triage by AI

🔍 Automated Triage

🐛 Category	bug
🟡 Priority	medium
🎯 Confidence	95%

Summary

rtk read counts --max-lines truncated content as token savings, massively inflating reported metrics; PR #1076 already in progress.

This looks like a simple fix. Only repo maintainers can trigger auto-fix.

---

Triaged automatically by wshm · This is an automated analysis, not a human review.