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] 联系团队部署相关事宜。