Ace Sidecar：本地 AI 程式設計效率最佳化工具

AI 編碼代理正成為工程組織中最昂貴卻又最不透明的開銷之一。你知道每月的 API 賬單，卻不知道這些費用來自哪些會話、有多少是重複讀取上下文、代理在等待審批上停了多少時間，或者最佳化路線圖上的某個改動是否真的值得。Ace Fleet 團隊用五週時間，對一個開發者的 Claude Code 會話做了逐請求測量，並公佈了結果：42 億個提示 Token、按目錄價 3,035 美元、其中 90.5% 是已經傳送過的輸入——而更多理論上看很大的最佳化槓桿，在實測面前紛紛失效。

他們因此構建的測量工具現在開放了。ACE sidecar 是一個本地反向代理，位於編碼代理和模型提供商之間。它原樣轉發流量，為每個請求計價，讀取磁碟上已有的會話記錄，並在 127.0.0.1 的儀表盤上展示整體情況。無需賬號，無需上傳，除了一個環境變數外，不改變任何工作方式。

儀表盤會顯示一組“艦隊級”數字：輸入輸出 Token、請求數、交還使用者的次數、每輪成本、每會話成本、每會話提交數、每提交 Token 數。下方的分佈表通常最引人注意：第 25 百分位的請求已經攜帶超過 10 萬 Token 的上下文。沒有一個便宜的分位——所以按請求調整載荷的最佳化，永遠不如減少上下文大小的工作有效。儀表盤還註明，提交歸因是基於時間視窗的，落在視窗內的提交未必由該會話產生。

工作量形態部分展示每日 Token、每日提交數和空閒天。該資料集的日環比中位變化為 −12.2%，四分位距為 −48% 到 +76%——相鄰兩天的工作量通常會減半或翻倍。這一圖表直接否定了一整類工作：任何基於變化率的告警或預算都會頻繁觸發且毫無意義。只有針對週期預算的累計上限才能適應這種形態。

成本部分包含費用、快取節省、快取命中率、峰值上下文，以及費率卡和實際計算公式。每條費率來自版本化目錄，並連結到供應商定價頁及檢查日期。人們通常注意到的兩點是：快取節省大於賬單（本資料集為 6.1 倍），而且這部分節省是提供商已經實現的，儀表盤明確標註，不將其歸功於自身；快取讀取約佔提示量的 98%，這也是整頁討論的核心。

最關鍵的最佳化評分部分分為兩張記分卡，因為它們是兩類問題：企業場景追求最小化美元支出，會計類槓桿有效；個人使用者追求在 Token 上限下最大化餘量，會計類槓桿被排除，因為它們只轉換價格而不減少 Token。每個槓桿表都帶有風險列，結果可能令人不適：本資料集中最大的槓桿 ttl_keepalive（佔成本 6.4%）不會移除任何 Token，而真正移除 Token 的槓桿都很小。所有模擬結果都帶有 SIMULATED 徽標。

時間維度同樣重要：87.7% 的牆鍾時間處於空閒，其中 233.8 小時（204 次，每次約 69 分鐘）是代理持有一個待處理的工具呼叫。儀表盤會將其作為即時警報提出，且不需要分類器就能判斷正確，因此不會產生誤導。它被標註為“上限”而非“節省”，因為會話記錄無法區分人類是否本來就會更早回來。

ACE sidecar 不會上傳任何內容——不傳提示、路徑、程式碼、會話識別符號或遙測。它讀取 ~/.claude/projects 並寫入本地 SQLite 檔案，沒有賬號、沒有 API 金鑰、也沒有除已有模型提供商之外的其他網路目標。它不改變流量，當前版本僅做測量，中繼請求不變，並在健康端點報告 "levers": []。所有最佳化槓桿將在後續階段提供，且強制執行前會先經過影子模式。它不持有你的憑據，ace up --no-key 不儲存任何內容，只中繼呼叫者傳送的內容，並繫結迴環地址且拒絕代理頭。它也不把提供商的節省據為己有，提示快取帶來的 6.1 倍節省在儀表盤上顯示並標註，但不會計入任何評分卡。

它也不能自動批准工具呼叫。團隊仔細研究後認為 sidecar 在結構上無法做到：許可權決定永遠不會經過 API。模型發出 tool_use 塊，客戶端在本地決定是否提示，位於 /v1/messages 的代理不在這個迴圈中。Claude Code 的自動模式已經內建了自動批准器，但缺少測量——自動模式不報告批准了什麼、阻止了什麼、節省了什麼。時間部分填補的正是這一空白。

執行只需兩條命令和一個環境變數：uv pip install -e . 和 ace up --no-key。啟動後橫幅會顯示代理指向 https://api.anthropic.com，認證為迴環信任，憑據由呼叫者提供。設定 ANTHROPIC_BASE_URL 指向本地埠，然後 eval "$(ace env)" 後啟動 Claude；儀表盤會立即填充歷史資料，因為它讀取磁碟上已有的會話記錄。GET /api/report 還返回一個脫敏、可共享的 JSON 摘要，只有聚合資料，沒有會話細節。

路線圖按順序排列，且順序本身就是重點：前兩項已交付（會話時間分解、等待審批檢測與警報）；第三項是影子模式下的每輪風險著色；第四項是 Shell 段解析器，用於讀取當前無分類器可讀的 44.5% 呼叫；第五項是確定性允許列表規則生成器；第六項是上下文耗盡預測與本地檢查點；第七項是 Bash 截斷，保留頭部和尾部，預計可節省約 1.7% 的成本。第六項的出現是因為實測改變團隊的想法：162 個會話中只有 3 次速率限制錯誤，真正的瓶頸是上下文耗盡，而自動壓縮已能處理，但壓縮產生的有損摘要會隨會話結束而消失，磁碟上的恢復摘要不會。第七項之所以有信心，是因為分析表明 Bash 輸出中 90% 的價值來自 sed/cat 轉儲、grep 彙總和 git 差異，保留首尾並豁免診斷類輸出，就能以接近零風險獲得大部分價值。

團隊還提到，原本想優先做的“去重檔案讀取”槓桿最終被放棄——在 36 天裡僅值 0.33 美元，因為 97.6% 的“重複讀取”請求的是不同行範圍，並不是真正的重複。這個案例恰恰說明，在最佳化器之前先有測量儀器的重要性。

Sidecar 目前與 Claude Code 配合工作，完全在本地執行，上傳為零。團隊正分批開放測試，最希望從測試使用者那裡得到第二個語料庫：目前所有發現只來自一個開發者在 36 天內的使用。成本結構應當能夠泛化，但數值屬於單個艦隊，他們寧可透過更多資料知道在何處失效。有興趣的使用者可留下郵箱獲取測試版，或透過 [email protected] 聯絡團隊部署相關事宜。