Overall verdict: RTK is working correctly ✅
The hook now rewrites ~100% of today's commands (rtk prefix everywhere). Across 97 commands:
| Metric |
Value |
| Input tokens |
105,839 |
| Tokens saved |
76,045 (71.8%) |
This is healthy. Before yesterday's fix, rtk discover reported only 5.3% coverage over 30 days (12,874 commands bypassing RTK); today it's reversed - the hook captures everything.
Breakdown by command (today)
| Command |
n |
Saved |
% |
rtk lint eslint |
1 |
33.5k |
100% |
ps aux (via filters.toml) |
1 |
36k |
98% |
rtk grep |
60 |
5.8k |
18% |
rtk ls |
7 |
358 |
51% |
rtk git |
10 |
184 |
12% |
rtk read / find / wc / mypy |
~12 |
~150 |
low |
The big wins (eslint, ps aux) pull the average up. grep is the bulk of the volume (60 calls) at only ~18%, but that's expected: grep output is already dense and barely compressible.
The only two real inefficiencies today
1. Two grep calls into bundled .d.ts files in node_modules — RTK could compress almost nothing because the matching lines themselves are huge:
grep -n DateFieldRootProps … reka-ui/dist/index.d.ts → 13,238 tok, 0.2% savedgrep -n TimeFieldRootProps … index4.d.ts → 5,189 tok, 1% saved
➡️ ~18k tokens essentially wasted. For minified TS declaration files, prefer a more restrictive pattern or read a targeted line range instead of grepping a definition that emits giant types.
2. A few docker commands fell back to passthrough (fallback-ok — executed safely but 0 savings):
docker ps --format …, docker logs --tail 30/40 …
➡️ RTK doesn't yet handle these flag variants (--format, --tail) on its docker subcommand. Harmless (the command still runs), but no optimization. Worth an rtk-ai/rtk issue if you use docker logs --tail often.
Summary
Nothing to fix on the usage side: your commands do use RTK correctly, and yesterday's fix resolved the coverage problem. The only "misses" are structural (grep over large generated files + unsupported docker flags), not RTK bypasses.
Overall verdict: RTK is working correctly ✅
The hook now rewrites ~100% of today's commands (
rtkprefix everywhere). Across 97 commands:This is healthy. Before yesterday's fix,
rtk discoverreported only 5.3% coverage over 30 days (12,874 commands bypassing RTK); today it's reversed - the hook captures everything.Breakdown by command (today)
rtk lint eslintps aux(via filters.toml)rtk greprtk lsrtk gitrtk read/find/wc/mypyThe big wins (eslint, ps aux) pull the average up.
grepis the bulk of the volume (60 calls) at only ~18%, but that's expected: grep output is already dense and barely compressible.The only two real inefficiencies today
1. Two
grepcalls into bundled.d.tsfiles innode_modules— RTK could compress almost nothing because the matching lines themselves are huge:grep -n DateFieldRootProps … reka-ui/dist/index.d.ts→ 13,238 tok, 0.2% savedgrep -n TimeFieldRootProps … index4.d.ts→ 5,189 tok, 1% saved➡️ ~18k tokens essentially wasted. For minified TS declaration files, prefer a more restrictive pattern or read a targeted line range instead of grepping a definition that emits giant types.
2. A few
dockercommands fell back to passthrough (fallback-ok— executed safely but 0 savings):docker ps --format …,docker logs --tail 30/40 …➡️ RTK doesn't yet handle these flag variants (
--format,--tail) on itsdockersubcommand. Harmless (the command still runs), but no optimization. Worth anrtk-ai/rtkissue if you usedocker logs --tailoften.Summary
Nothing to fix on the usage side: your commands do use RTK correctly, and yesterday's fix resolved the coverage problem. The only "misses" are structural (grep over large generated files + unsupported docker flags), not RTK bypasses.