「輸出壓縮 90%」不等於 coding agent 成本降低 90%
我是 Tura 的維護者，也是這份分析的作者。這次我想討論的不是產品發布，而是 token-saving 外掛的測量方式：如果只看某一段輸出被壓縮多少，很容易把局部效果誤當成整個 coding agent 任務的成本節省。
實作與基準資料：github.com/Tura-AI/t...
問題在分母
一個指令的輸出即使縮短 90%，coding agent 完成任務時仍要支付快取與未快取輸入、模型推理與輸出、工具呼叫、重試、失敗執行、額外往返，以及總耗時。因此更合理的比較單位是「每個成功完成任務的總成本」，並同時報告成功率、總 token、總成本、往返次數和時間。
Repository rewrite 實驗
任務是把 Rust CLI eza 改寫成行為相容的 Python 實作，以 52 個 harness assertions 評估。模型為 GPT-5.6-sol High，環境為 Codex CLI 0.144.1。每個條件執行兩次：
無外掛：通過率 78.85%，平均 6.660M tokens，$5.282，62.5 rounds，895 秒。
Ponytail：通過率 80.77%，平均 6.156M tokens，$4.813，61.0 rounds，1,016 秒。
RTK：通過率 76.92%，平均 7.539M tokens，$5.661，90.0 rounds，1,259 秒。
Ponytail 的觀測 token 減少 7.56%，推估成本減少 8.87%，但時間增加 13.51%。RTK 則增加 13.20% token、7.18% 成本、44% rounds 與 40.69% 時間。
這裡每個條件只有 n=2，所以不是信賴區間，也無法證明因果效果。條件內成本範圍相對平均值分別是基準 43.25%、Ponytail 51.69%、RTK 30.78%；執行間變異可能比局部壓縮效果還大。
先算理論上限
另一組 140 次 Codex 執行資料中，快取輸入占觀測 token 的 96.46%，輸出只占 0.38%。這個分布能直接說明，壓縮某一小段輸出不可能移除主要成本。
Ponytail 的規則約 569 tokens。就算每一輪都不切實際地省下 90%，總成本節省上限也只有約 0.44%。
最終 production code 只占全部 tokens 的 0.0568%。理想地減少 80%，總成本上限約 1.81%。
RTK 可處理的 shell 輸出占全部 tokens 的 0.1618%。即使完美壓縮 90%，直接可歸因的節省也只有約 0.96%。
這不代表壓縮完全沒用，而是主張的範圍必須和實際測量範圍一致。
我建議任何 token-saving 工具至少一起公開：
1. 任務完成成功率
2. 每個成功任務的總 token 與總成本
3. 耗時與 rounds
4. 重試、失敗和排除的執行
5. 相同任務的重複實驗與條件內變異
再次揭露：我是 Tura 維護者，也是連結分析的作者。完整方法、原始計算與限制請見：