很多人比较 coding agent 的成本时，第一反应是看模型单价：用的是不是同一个模型，每百万 token 多少钱。
但在长时间写代码的场景里，真正拉开账单差距的，往往不是模型本身，而是上下文怎么组织。
一个 coding agent 每轮请求模型时，并不只是发送“帮我改这个函数”这一句话。它通常还会带上系统提示、工具说明、仓库结构、已读文件、历史对话、测试结果、任务计划等内容。真正贵的，是这些反复出现的大段背景。
如果每一轮都把同一份项目背景当成新输入重新计费，哪怕用户只是让它改一行代码，账单也会像重新打开整个仓库一样膨胀。
prefix cache 解决的就是这个问题。
所谓 prefix cache，可以简单理解为：如果一段输入的开头和之前完全一致，模型服务可以复用已经处理过的部分，只对后续新增内容做计算和计费。这里的关键不是“意思差不多”，而是前缀要稳定。系统提示、工具说明、项目上下文、历史消息的顺序和内容越稳定，缓存命中率越高。
所以，一个省钱的 coding agent，通常不是每轮都聪明地“少发一点”，而是把上下文分层：
固定内容放在最前面，尽量不变；
历史记录只追加，不随便重排；
工具输出先摘要，再进入上下文；
临时推理、草稿状态、无用日志不要污染下一轮请求。
这样一来，第一轮可能很贵，因为它要读入整个任务背景。但后面的多轮修改、调试、跑测试，就可以复用前面的缓存。对用户来说，还是同一个模型；对账单来说，很多输入已经不是“冷启动”了。
这也是为什么有些 coding agent 看起来并没有换更便宜的模型，却能显著省钱。它省的不是智能，而是重复读取上下文的成本。
判断一个 agent 是否真的省钱，不要只看模型名和标价。更应该看三件事：它有没有缓存命中记录；固定上下文是否稳定；大段日志和文件内容是否会被反复原样塞回模型。
同样的模型，省钱的关键不在“调用更少”，而在“同一份背景别每轮重新付费”。
