rtk (Rust Token Killer)

Token-optimized CLI proxy that transparently rewrote shell commands (git, curl, find, grep, ...) via hooks in Claude Code, Gemini CLI, and Crush, claiming 60-90% token savings on routine dev operations.

Reviewed 2026-08-12, drawing on incidents from 2026-07-29 through today. Update, same day: fully disabled and removed from the machine after this review — see Resolution below.

Goals

Effectiveness

Mixed, trending negative. When it filters a command it recognizes well, it's invisible and presumably does save tokens. But across the last two weeks it has repeatedly produced wrong output, not just compressed output — the failure mode that actually matters for an agent that trusts its shell:

What made it effective (when it works)

Zero-overhead interception is the whole pitch — no special syntax to remember, and rtk gain gives real visibility into whether it's paying for itself rather than asking for blind trust.

Friction, pain points, surprises

The standing workaround, now workspace policy, is to route around rtk for anything where correctness matters: shell out via python3 -c "subprocess.run([...], capture_output=True, text=True)" instead of raw bash whenever git/find/grep output will be trusted, verified against, or written back into a file. That's an odd place to end up with a transparency tool — the reliable way to use it is to avoid it. Today's review cycle needed the Python bypass three separate times just to get accurate find results and confirm a cron directory's real contents. There's also a name collision with an unrelated Rust project also called rtk ("Rust Type Kit") — rtk gain failing on a fresh machine reads like a broken install, not a wrong-binary problem, and costs a debugging detour before the real fix (checking which rtk).

Resolution

Hours after this review went up, we pulled it entirely rather than keep routing around it. It turned out to be wired into three CLIs, not one — Claude Code, Gemini CLI, and Crush all had their own rtk-rewrite.sh hook — and a second, wider sweep found chezmoi quietly managing the Crush hook and the ~/.config/rtk directory as dotfile source state, which would have silently resurrected both on the next chezmoi apply if left alone. Full removal: hooks pulled from all three CLI configs, both binary installs (cargo + ~/.local/bin) and a stale mise shim deleted, ~/.config/rtk and its 11.2MB history.db purged, the local upstream-repo clone removed (clean git status, trivially re-clonable), 15 projects' worth of dead Bash(rtk ...) permission allowlist entries stripped, and the chezmoi source state fixed so dotfile sync can't bring any of it back.

The lesson that outlasts the tool: a transparency/optimization layer that occasionally substitutes wrong output for real output is worse than one that's merely slow or verbose, because the failure is silent and only surfaces when something downstream — a data file, a verification check, a decision made from a diff — turns out to have been built on fiction. "Route around it via Python for anything that matters" was a reasonable stopgap but not a stable end state; if the safe way to use a tool is to avoid it, that's the review talking.

Verdict: not adopted. Mandatory-by-hook with a silent-wrong-output failure mode spanning git, find, curl, and even unfiltered plain loops was never going to end anywhere but removal — it just took a second pattern of incidents (this same day) to make that the obvious call instead of the cautious one.