你以為 token 是被 AI 的思考燒掉的。其實不是。

跑一個長時間的 Claude Code 會話，打開帳單看一下，你會發現大部分 token 花在「讀」而不是「想」。更精確地說，花在讀 shell 吐回來的那坨東西——git diff 的路徑前綴、pytest 的進度條、docker logs 的時間戳、一堆空行跟重複行。這些資訊對 LLM 來說毫無意義，但每一個字元都在燒你的錢。

118k token 的會話，真正有用的資訊大概只有 24k。

剩下的 94k 是噪音。

RTK 在幹嘛

RTK（Rust Token Killer）是一個用 Rust 寫的 CLI 代理層，架在 Claude Code 跟你的 shell 之間。想像一下你家水管接了一個濾水器——水還是會流過去，但泥沙會被擋住。RTK 就是那個濾水器，只是它過濾的不是泥沙，是 token。

每次 Claude Code 要執行 shell 指令，RTK 會先攔截輸出，用針對特定指令的壓縮模組把冗餘資訊砍掉，只留下 LLM 真正需要的部分，再傳回 context window。壓縮率大概在 60-90%，取決於指令類型。git status 的壓縮效果跟 docker logs 差很多，這很直覺。

它內建了 100+ 個指令模組——git、pytest、jest、docker、kubectl、terraform，基本上你在開發中會用到的指令都有。不是通用壓縮，是每個指令有自己的規則。知道什麼該留什麼該砍。

怎麼裝進去

macOS 推薦 Homebrew：

1
brew install rtk

裝完跑一行設定：

1
rtk init -g --auto-patch

這行會幫你設好 Claude Code 的 PreToolUse hook。之後所有 Bash 指令都會自動走 RTK 代理，你什麼都不用改。

有幾個常見的坑要先避開。npm install -g rtk-ai——npm 上沒這個套件，裝了會炸。cargo install rtk——crates.io 上有同名套件，但那是完全不同的東西。只有 Homebrew 跟官方安裝腳本是對的。

它怎麼知道該砍什麼

這是最聰明的部分。RTK 不是瞎砍，它知道每個指令的輸出結構。

跑 git diff 的時候，它會砍掉那些又臭又長的路徑前綴（a/src/main/java/com/company/project/module/submodule/...），但保留變更的行數跟內容。跑 pytest 的時候，進度條（...........）直接消失，但測試結果和失敗的 traceback 原封不動。Docker logs 的重複行會被折疊成「×N」的格式，但第一次出現的完整內容會保留。

這就像你在茶水間跟同事轉述 log 一樣——你不會把每一行時間戳都念出來，你會說「這個 error 出現了 47 次」然後念一次完整的 stack trace。RTK 就是在做這件事，只是它做得更快、更穩定。

有個安全機制：12 行以下的輸出自動跳過不處理。 小型輸出通常每一行都是關鍵資訊，壓了反而會掉東西。

80% 是怎麼來的

數字不是亂喊的。

我自己跑一個典型的 Claude Code 開發會話——改 code、跑測試、看 diff、查 log——原本一個 session 下來 token 消耗 118k。裝上 RTK 之後，同樣的工作流，24k。省了接近 80%。

這個差距的來源很好理解。一次 git diff 輸出可能有 2000 行，但真正有意義的變更可能只有 200 行。一次 docker logs --tail 500 裡面可能有 400 行是重複的 health check。一次 pytest 的完整輸出裡，進度指示器佔了一半的字元數。這些東西疊起來很恐怖。

API 費用是按 token 計費的。少送 80% 的 token 進去，就是少付 80% 的錢。數學就這麼簡單。

什麼時候不該用它

壓縮是有損的。這三個字很重要。

RTK 砍掉的東西在大多數情況下是垃圾，但不是所有情況。追查 production incident 的時候，每一行 log 的時間戳和順序都是線索。對 trace ID 的時候，被折疊的重複行裡可能藏了一個微妙的差異。做 performance 分析的時候，你需要看到完整的 latency 分佈。

這時候用 rtk proxy：

1
rtk proxy docker logs mycontainer --since "30 min ago"

rtk proxy 會繞過所有壓縮邏輯，原封不動地把輸出傳回去。Claude Code 的 Read、Grep、Glob 這些內建工具本來就不走 Bash，所以 hook 也攔不到它們——直接用就好。

老實說，日常開發 95% 的時間走壓縮都沒問題。只有在精確除錯的場景才需要繞過去。

兩個好用的子指令

1
rtk discover

這個會掃描你的 shell 歷史，找出哪些指令的輸出特別肥、特別適合壓縮，然後告訴你預估能省多少 token。裝完之後先跑一次，心裡有個底。

1
2
rtk gain
rtk gain --history

查看累積省下多少 token 和費用。--history 會列出每個指令的歷史壓縮率。這個數字看了會真香——你會知道自己到底省了多少錢。

背後就兩條線

軟體工程裡有一個被低估的問題：我們送給工具的資訊裡，有多少是真正需要的？

大多數人優化 LLM 的思路是「讓模型更聰明」或「讓 prompt 更精確」。但 RTK 指向的是一個更基礎的槓桿點——在資訊進入模型之前，先把噪音砍掉。這不是什麼新觀念。Unix 哲學的 pipe 和 filter 就是在做這件事。grep、awk、sed 存在了幾十年，本質上就是在回答同一個問題：什麼是訊號，什麼是噪音。

RTK 只是把這個古老的問題帶到 LLM 時代。

而且答案出乎意料地明確：你的 shell 輸出裡，六到九成都是噪音。

相關連結