為什麼你的AI賬單比實際應支付的更大

一次287美元的除錯會話促使一位工程師重新思考我們如何向大語言模型（LLM）提供資料，其結果已在五個月內為使用者節省了約70萬美元。

Tejas Chopra在除錯GPU故障時，按常規流程提取日誌並讓Claude識別問題，但發現單個提示消耗了整個上下文視窗的兩倍。他意識到模型多次讀取整個日誌檔案，處理所有內容後才提取出真正相關的三行。當他彙總月度賬單時，個人專案工作花費了287美元。

解決方法是重寫提示以忽略INFO行，僅關注警告和警報。響應時間縮短，token成本下降，但Chopra仍然感到困擾。他認為不能期望每個開發者都手動策劃提示，因此開始探索自動化流程。

結果就是Headroom，一個面向LLM的開源上下文最佳化層。在Linux開源峰會上展示該專案時，Chopra發現這一想法引起了廣泛共鳴。在停止收集統計資料前，Headroom在五個月內為其使用者節省了約70萬美元，並回收了2000億token。這一早期成功促使Chopra離開高階工程師職位，創立了Headroom Labs。

Headroom的壓縮流程經歷了三個不同階段。首先針對JSON，透過去除空格、逗號、引號和巢狀縮排，在不丟失任何資料的情況下實現30%的節省。其次，它尋找值之間的統計相似性進行壓縮。例如，如果陣列中有88/90個值在0到1之間，另外兩個是異常值，則只傳輸異常值和摘要。最後，每個壓縮負載都由快取條目支援，快取鍵由會話ID和原始資料雜湊組成，避免跨會話汙染。原始資料儲存在本地Redis或SQLite中，預設TTL為5到30分鐘，企業部署時可使用RDS或Bigtable等資料庫。

壓縮的風險在於模型可能需要被丟棄的資料。Chopra的解決方案是在壓縮輸出中留下一個工具呼叫，模型可以呼叫它以獲取完整的原始資料。這種情況發生在不到1%的案例中，因為統計壓縮應足夠保守，且模型足夠智慧。

Headroom為不同上下文型別使用不同的壓縮器：程式碼使用抽象語法樹，鎖檔案有專門處理，網頁（如文件、API參考）另有方法，而非結構化文本則由一個名為Kompress Base的小型開源模型處理，該模型透過判斷刪除每個詞是否改變語義來學習壓縮語法。

Headroom目前僅壓縮輸入，輸出壓縮正在開發中。本地檔案讀取（約佔典型編碼代理流程中上下文的60%）不進行壓縮，而是透過與Serena或CodeMCP等工具整合，減少需要讀取的檔案面。

另一個有趣的功能是“learn”機制，它挖掘歷史代理會話中的重複失敗模式，並自動將修正寫入CLAUDE.md檔案。這解決了代理在多個會話中重複犯相同錯誤的問題。

構建Headroom的主要挑戰是整合。每個LLM提供商的API方言不同，路由層（Bedrock、Vertex AI、Azure）又引入變體。此外，編碼代理和工具的多樣性使相容性矩陣更加複雜。Headroom對Claude和Codex提供一級支援，其他為實驗性。

Chopra建議將token衛生視為新的工程學科。透過像管理計算信用一樣管理token預算，並在資料到達提供商之前進行壓縮，團隊可以獲得提供商無動力提供的AI支出可見性。