AI编程代理六周成本审计：缓存读取占66%，新版模型迁移节省被高估5.5倍

当团队每月在LLM API上花费数千美元时，"换用更便宜的模型"往往是最直觉的省钱手段。但一份针对AI编程代理（coding agent）真实使用日志的重新定价审计显示，这种直觉可能严重偏离实际——而且真正的成本大头，藏在大多数人忽略的地方。

这份审计覆盖了46天（其中35天活跃使用）的单人编程代理运行记录，共计61,955次请求。由于没有现成发票可供核对，分析者采用供应商公开发布、标注日期的价格表（获取于2026-10-16），对每一次请求重新定价。所有金额均为API等效成本，而非实际账单金额。最终总额为**$7,882**——这个数字本身不是重点，真正有价值的是它暴露出的三个反直觉发现。

发现一：三分之二的成本花在"重读上下文"上

最令人意外的数字是：66%的成本来自缓存读取（cache reads），99%的输入侧token都是缓存命中。而人们精心优化prompt所影响的输出（output，含thinking），只占12%。

成本类别	占比
缓存读取（每轮重读已有上下文）	66%
1小时缓存写入	20%
输出（含思考过程）	12%
5分钟缓存写入	2%
全新输入	~0%

支出由"上下文有多长 × 在其上运行了多少轮"决定，而非prompt是否巧妙。更极端的是，单个项目贡献了63%的总成本。这意味着真正的优化杠杆是控制上下文长度和会话卫生（session hygiene），而不是反复雕琢提示词。用户越是让agent在同一个超长会话里持续工作，缓存读取成本就越是线性堆积。

什么是prompt缓存（prompt caching）？ 主流LLM API（如Anthropic Claude、OpenAI等）允许把一段已经处理过的输入前缀缓存在服务端，下一轮请求若以相同前缀开头，就只需按远低于正常输入的价格"读取"这部分缓存，而不用重新计算。缓存通常有生存期（TTL），常见为5分钟和1小时两种，写入缓存本身要额外付费：1小时缓存的写入单价通常明显高于5分钟缓存，因为它占用服务端资源更久。对编程代理来说，系统提示、工具定义、历史对话、已读文件内容在每一轮都会被重新作为前缀发送，这正是"缓存读取"占据成本大头的根本原因——上下文越长、轮数越多，缓存读取的计费量就越大。

为什么说"会话卫生"是成本杠杆？ 编程代理一般在一个持续会话内累积上下文：每次工具调用、每段被读取的代码、每次模型输出都会追加进历史，下一轮全部重新发送。由于缓存读取按"上下文长度×轮数"计费，一个持续数小时、上下文膨胀到十万token级的会话，其每轮成本会显著高于重新开启一个干净会话。所谓会话卫生，指的是适时清理无关历史、拆分任务到新会话、避免让代理在超长上下文中反复空转，以及把可独立的子任务交给子代理处理等实践。这些操作直接影响被重复计费的上下文体积，比在系统提示里删几个词有效得多。

发现二："迁移到新版模型"的节省被高估了5.5倍

新版模型通常单token价格更低。如果把所有运行在旧版模型上的请求，按新版费率重新定价，表面上可以"节省"$1,625（20.6%）。

但这个数字有一个致命漏洞：大部分请求发生在新版模型上线之前。只统计新版模型可用之后发出的请求，实际节省仅为**$293（3.7%）**。两者相差5.5倍。

这个逻辑看似简单，却极易被忽视：一个你在当时根本无法选择的价格，不能算作"可节省"。很多成本优化报告正是栽在这里——用事后价格回溯历史用量，得出一个漂亮但无意义的节省数字。该审计脚本专门加入了"available-at-the-time"检查，确保每一项节省都建立在当时真实可选的基础上。

"当时是否可用"（available-at-the-time）检查的原理。 做成本回溯时一个常见错误，是用今天的价格表去给过去所有请求定价，然后宣称"如果早点换模型就能省这么多"。但历史请求发生时，新版模型可能尚未发布，或尚未在用户所在地区、所用工具链中开放，用户当时根本无法选择。正确的做法是：对每条请求，先查询其时间戳，确认新版模型在当时是否已经可被使用，只有可用的请求才计入"可迁移"集合，再按新版价格重算。这一过滤会把大量"虚假节省"剔除，剩下的才是真实可获得的收益。该审计正是通过加入这一层时间戳校验，把表面20.6%的节省压缩到3.7%。

发现三：看起来更贵的设置，反而是对的

85%的缓存写入token使用了1小时prompt缓存，它的写入单价比5分钟缓存更贵。直觉上，改用更便宜的5分钟缓存应该能省钱。

分析者做了反向测试：假设所有缓存写入都走5分钟缓存，那么任何闲置超过5分钟的会话，都需要按写入价格重新写入上下文。实际数据显示，只有2.5%的缓存读取token发生在这样的空闲间隔之后——但这些请求携带的上下文极大。综合计算下来，5分钟缓存反而会多花$1,781（+22.6%）。

结论是：保留1小时缓存。那种"单价更贵"的直觉，在真实的会话空闲分布面前站不住脚。

顺带一提，把子代理（subagent）工作迁移到更便宜的模型，只省下$62——分析者认为这点钱不值得承担质量风险。

这份审计能做什么，不能做什么

需要明确边界：这是基于token计数器的重新定价（re-pricing），不是已实现的节省。审计没有评估输出质量。此外，子代理的token流在测量空闲间隔时被合并处理，因此这些间隔看起来比实际更短。仓库中的聚合CSV允许任何人核对总额，脚本也可以从你自己的使用日志中复现这些数字。

换句话说，它是一面镜子，映出"如果按公开价目表计费，钱会流向哪里"，而不是一张真实账单。

用你自己的日志跑一遍

分析脚本已开源（MIT协议），完全确定性，不进行任何LLM或网络调用：

https://github.com/zbl1998-sdjn/llm-spend-audit-toolkit

工具支持四项核心能力：从编程代理日志中提取每请求用量（仅token计数器）；按类别用带日期的公开价目表定价；用"当时是否可用"检查测试迁移新版模型的节省；以及测试5分钟与1小时缓存的反事实场景。

对于希望审计自身账单的团队，作者给出了四条原则：仅导出数据（不需要API密钥、prompt或生产访问权限）；确定性分析（脚本跑在你的数字上，而非模型读取你的数据）；先对账（重算支出必须与实际账单在±3%内吻合，才计入任何节省）；只保留保守、去重、当时可用的发现——给出的是下限值，并附带每个数字的公式。

什么是"确定性"分析？ 这里的确定性（deterministic）指脚本完全由固定规则和算术驱动：读取日志中的token计数，乘以价目表中对应项的价格，再求和。相同输入永远得到相同输出，不依赖模型的随机采样，也不把日志内容发送给任何LLM或云端。与之相对，如果用LLM来"阅读"日志并估算成本，结果会因模型版本、温度、上下文窗口等因素波动，且存在把敏感代码或对话外传的风险。确定性审计的优势在于可复现、可核对、可审计：任何人都能在同一份数据上跑出同一组数字，这也是该类工具能被财务或合规流程接受的前提。

为什么这份审计值得关注

LLM API成本管理正在从"选便宜模型"的粗放阶段，进入"理解真实支出结构"的精细化阶段。这份审计用一个小样本（单人、六周、约8千美元）清晰地展示了三件事：缓存机制对成本的支配性影响、事后价格回溯的统计陷阱、以及直觉与实际最优之间的差距。

对于每月LLM API支出超过$3,000的团队，这类确定性审计提供了一个低风险、可验证的成本可见性起点——前提是接受它的边界：它衡量的是等效成本流向，而非真实节省。

披露：该分析脚本与本文写作均由AI辅助完成（Claude Code）。