為什麼你的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支出可見性。