RTK 代幣儲蓄：基準測試揭示 AI 編碼中成本節省有限

RTK 無法為 AI 編碼代理提供普遍的成本節省

Rust Token Killer (RTK) 的設計目的是透過在終端輸出傳送到 AI 代理之前進行過濾與壓縮，以降低 AI 編碼的成本。然而，根據 Terminal-Bench 2.1 的實證基準測試顯示，RTK 並未持續降低總成本。對於某些模型，它甚至可能因迫使代理需進行更多回合才能完成任務，而實際增加開支，從而抵消了單一提示較短所帶來的任何節省。

基準測試方法：Terminal-Bench 2.1

為評估 RTK 的影響，研究人員使用 Claude Code（搭配 Fable 5.0）與 OpenCode（搭配 DeepSeek V4 Pro 0813）在 Terminal-Bench 2.1 上進行了 1,740 次測試。基準測試專注於代理通常能成功的任務，因為成本優化僅對成功完成的任務才有意義。

成本與通過率結果

結果顯示總支出幾乎沒有改善或甚至為負面影響：

• Claude Code (Fable 5.0)： 總成本下降 5%（基準 $731 對比使用 RTK 後 $698），但其中大部分節省來自單一任務（winning-avg-corewars）。若排除此異常值，節省不到 1%。
• OpenCode (DeepSeek V4 Pro 0813)： 總成本上升 5%（基準 $51 對比使用 RTK 後 $54）。在任務層級測量中，平均每個任務的成本上升了 17%。

通過率大致穩定，使用 RTK 時略有下降（Fable 為 1%，DeepSeek 為 2%）。

為何「rtk gain」是具有誤導性的指標

RTK 報告了一個稱為 rtk gain 的指標，該指標計算原始與過濾後命令輸出的位元組差異，再除以四。這並非計費代幣的數量，也無法反映實際省下的金錢。

基準測試顯示，rtk gain 可能被嚴重高估。例如，在某個任務中，RTK 因將 head 的有限讀取與完整檔案大小進行比較，即使原始命令永遠不會返回完整檔案，仍聲稱節省了 2.41 億個代幣。由於 rtk gain 未考慮代理後續反應或額外回合的成本，可能使一次高成本的嘗試看起來像是經過優化。

「代幣通膨」效應：更多回合，更高成本

減少單回合輸入大小，並不能保證總帳單降低。在代理式編碼中，上下文通常會被快取，使得後續讀取終端輸出的成本顯著降低（Fable 為 1/10，DeepSeek 為 1/30）。

當 RTK 壓縮輸出時，可能導致模型混淆或移除關鍵資訊，進而產生「代幣通膨」問題：代理需更多回合才能達成相同結論。對於 DeepSeek，RTK 嘗試在 58 個任務中需要更多回合，其中 44 個任務總成本更高。DeepSeek 平均回合的輸入少了 7%，但總回合數增加了 18%，導致總成本淨增加。

技術風險與限制

工具不相容與迴圈問題

RTK 會重寫 shell 命令，可能引入錯誤。一次基準測試嘗試陷入連續 339 次錯誤的迴圈，原因是 rtk find 不支援標準 find 命令所支援的特定旗標。代理不斷重複嘗試同一個失敗命令，導致成本是基準的 9 倍。

避開機制

RTK 僅作用於 shell 命令。許多 AI 編碼平台使用獨立工具執行 Read、Grep 和 Glob 操作，這些操作完全避開 RTK。此外，前沿模型越來越擅長自行使用終端，通常會手動使用 head、tail 或 wc 來限制輸出。

社群見解與替代方案

產業實務者與開發者提出了多項反對意見與替代方案，以取代原始輸出壓縮：

"如果輸出不符合預期，LLM 可能會發出比以往更多的工具呼叫，因為它會認為工具出錯……這會消耗更多代幣。"

"我只會啟動一個最便宜範圍的子代理（例如 flash-lite）來總結工具使用。根據我的基準測試，這是唯一有效的方法。"

部分使用者認為，RTK 可能仍對特定高度冗長的工具（如 Maven 或 Cargo）有用，因為其輸出總是重複。但他們也同意，包裝所有終端輸出通常適得其反。其他人建議使用明確的代理規則（例如 COMMAND 2>&1 | head -c 4000）來限制輸出，而不透過第三方封裝改變命令行為。