Headroom、Caveman、RTK：三種 LLM 省 token 工具的分工、原理與公開效果

你用 Claude Code 跑了幾次測試，或者開 Cursor 掃了幾遍 codebase，一轉頭發現今天的大模型額度已經被扣了快一半。在 Agent 開發時代，token 就是真金白銀，如何把上下文壓榨到極致，成了每個人都在想的課題。

這三個工具都在講「省 token」，但它們省的層次其實不一樣：

• Headroom：壓 整個上下文層。
• Caveman：壓 Agent 說話方式。
• RTK：壓 shell / 工具輸出。

如果把複數 Agent 工作流拆成三層，它們剛好各站一層：

1. 你送進模型之前的上下文
2. 模型回你時的文字風格
3. 模型看見的命令結果

這篇直接把三者重新對齊，順便看公開社群裡大家實際踩坑後回報的效果。

先講結論

如果你要的是完整工作流，最合理的配置通常是：

• Headroom 當主幹：管上下文壓縮與回取。
• RTK 當工具層：管命令輸出壓縮。
• Caveman 當表達層：管回覆語氣與冗字。

三者不是完全互斥，而是補不同洞。

---

Headroom：壓上下文，不是只壓摘要

Repo：chopratejas/headroom

Headroom 的定位很明確：它是 Agent 的 context compression layer。README 直接把它描述成「在 LLM 看見之前先壓縮」的中介層，目標是讓同樣的 request 用更少 token 完成。

主要用法

你可以用 library 方式直接嵌入程式，或是啟動一個 proxy：

headroom proxy --port 8787

這行指令會在本機啟動一個 proxy 伺服器，監聽 8787 埠號。你只要把原本打 API 的 endpoint 改指向這裡，它就能在 request 送出前自動幫你做 token 壓縮。

你也可以用 wrap 方式直接包住現有的 Agent 工具：

headroom wrap claude

這個命令會包裝指定的 CLI 工具（例如 Claude Code）。當工具對外發送請求時，Headroom 會在中途攔截並壓縮 context，對你的開發流程完全透明。

節省方式

Headroom 的壓縮不是單一路徑，而是分流：

• ContentRouter：先判斷內容類型。
• SmartCrusher：壓 JSON。
• CodeCompressor：壓程式碼 AST。
• Kompress-base：壓一般文字。
• CacheAligner：穩定前綴，讓 provider cache 更容易命中。
• CCR：保留原始內容，需要時可回取。

原理

它的重點不是把字變短而已，而是把內容當成不同資料型態處理：JSON 就用 JSON 壓法，code 就用 code 壓法，prose 就用文字壓法，而且壓完後還保留原文以利還原。這比較像 LLM 基礎設施層，不是單純摘要器。

官方效果

README 的公開 benchmark 主打：

• 60–95% fewer tokens
• code search：92%
• SRE incident debugging：92%
• GitHub issue triage：73%
• codebase exploration：47%

它的賣點很完整：壓 prompt、壓 tool output、壓 RAG chunk、壓 file，還能留回取路徑。

---

Caveman：壓回答口氣，不壓腦袋

Repo：juliusbrussee/caveman

Caveman 的核心不是壓工具輸出，而是讓 Agent 講話變短。它是一個給 Claude Code、Windsurf 等 Agent 用的 skill，目標是把回覆從「完整解釋」壓成「高密度短句」。

主要用法

你可以直接在對話裡下指令切換模式：

/caveman ultra

這是 Caveman 的斜線指令，切換到極致壓縮模式。它會直接叫 Agent 用最精簡的電報體回覆，省去所有冗長的寒暄和解釋。

你也可以針對特定的 memory 檔案進行壓縮：

/caveman-compress memory.md

這會叫 Caveman 去掃描並重寫指定的 Markdown 檔案。它會把檔案內重複、囉唆的句子過濾掉，但保留所有的核心程式碼與系統狀態。

節省方式

Caveman 的壓縮方式比較像「文風壓縮」：

• 刪 filler。
• 刪寒暄。
• 刪重述。
• 保留關鍵結論。
• 保留 code / path / error string。
• 盡量用更短語法說同一件事。

它甚至強調：語言本身不變、內容不變，變的是冗詞與口氣。換句話說，它不是要模型變笨，而是要模型少廢話。

原理

Caveman 比較像一個 輸出風格控制器：你給的是普通自然語言任務，它把 Agent 的回答風格往更短、更碎、更像電報的方向推，對 code / command / path 類資訊則盡量不動。

官方效果

README 的公開說法是：

• 平均約 65% output reduction。
• caveman-compress 對 memory files 的平均壓縮約 46%。

README 裡也有很直觀的 before/after：同一個技術解釋，句子可以從十幾行縮成兩三句。

公開社群回饋

但公開世界不是只有官方數字。GitHub issue #251 就是個很直接的例子：

• 使用者在問：能不能看 token savings statistics？
• 背景是：兩個小任務就燒掉了約 35% 的 5 小時 token limit。

這代表 Caveman 的實際效果，至少在某些人手上，未必有 README 那麼漂亮。所以 Caveman 的結論比較像：風格壓縮很有效，但是否真的省到你想像的程度，要看任務類型 and 原始 prompt 密度。

---

RTK：壓 shell 與工具輸出

Repo：rtk-ai/rtk

RTK 的定位很像命令列世界的 token optimizer。它的重點不是改模型怎麼講話，而是把 command output 先縮過，再送進 LLM context。

主要用法

首先需要在專案目錄下進行初始化：

rtk init --agent hermes

這會初始化 RTK 並指定對應的 Agent。它會偷偷在你的 shell 加上 hook，之後只要跑 CLI 指令，輸出的 log 就會先被過濾壓縮後才送給 LLM。

接著你可以像平常一樣下指令，它會自動被 hook 攔截：

rtk git status

這是透過 RTK 包裝後的 Git 指令。它會把 git status 吐出來的冗長文字重新整理，只留下真正被修改的檔案路徑，減少模型閱讀不必要資訊的負擔。

節省方式

RTK 在 README 裡列得很清楚，主要靠四招：

1. Smart Filtering：去噪音、去 boilerplate。
2. Grouping：把同類項合併。
3. Truncation：保留關鍵上下文。
4. Deduplication：重複行折疊成計數。

它最常壓的就是這種東西：ls、git status、git diff、pytest、docker ps。

原理

RTK 更像 shell proxy / hook layer：Agent 下命令，RTK 攔到命令與輸出，先做重寫與裁切，再把精簡版送回模型。所以它壓的是 工具結果的體積，不是 prompt 本身，也不是 model 回答風格。

官方效果

RTK README 的 30 分鐘 Claude Code session 範例宣稱：

• 總體約 80% savings。
• 很多常見命令有 -70% 到 -90% 的省量。

但這裡要特別看公開反例。GitHub issue #2001 直接說：

• 在 41 個 shell commands、5 個 repo 的測試裡，平均 savings 只剩 +0.2%（Sonnet）、+2.7%（Opus），幾乎是噪音。

另外 issue #2299 還指出：

• rtk discover 可能把 hook rewrite 的命令算成 missed savings，代表它的量測系統本身也可能失真。

所以 RTK 的判讀要保守一點：方向是對的，工具層壓縮很實用，但實際節省高度依賴你的 command 型態與工作流。

---

三者怎麼分工

可以直接這樣記：

Headroom = 上下文中介層

• 壓入模之前的資料。
• 管 JSON / code / text。
• 重點是可逆、可回取、可路由。

Caveman = 回覆風格層

• 壓模型怎麼講。
• 讓回答更短、更像人腦掃讀版。
• 重點是少廢話，不是少資訊。

RTK = 命令輸出層

• 壓 shell / CLI / test output。
• 讓工具結果更乾淨。
• 重點是少垃圾行、少重複、少噪音。

---

如果要一起用

我會這樣配：

• Headroom 放最外層，先處理上下文。
• RTK 放工具層，先壓 command output。
• Caveman 放表達層，讓回答收斂。

這樣的分層比較合理，因為每個工具都管不同東西：Headroom 管「輸入長什麼樣」，RTK 管「工具回來長什麼樣」，Caveman 管「模型最後怎麼說」。如果三個一起用，最怕的是把資訊壓過頭，導致 debug 的細節消失。

來源

• Headroom
• Caveman
• RTK
• Caveman issue #251
• RTK issue #2001
• RTK issue #2299