我的编码智能体上周花了 $1,064,其中 44% 是缓存在反复重写自己

本文是英文原文的简体中文翻译。如有出入,以英文原文为准。

范围说明,2026-10-23:下面的数字是另一套本地环境、按 API 价格做的历史估算,不是账单,也不是公开版 Off the Wall 测得的节省。本文没有测试 OTW 的纠正回溯。

我整天都在运行编码智能体,所以我把自己一周的 API 用量加了起来:19,733 次 Claude 调用,按 API 价格约 $1,064。最大的一项既不是输出,也不是缓存读取,而是缓存写入:$469,占账单的 44%。

缓存写入,是某个前缀第一次被看到时要付的钱。在长对话中,几乎全部都应该是读取。写入这么大,意味着智能体一直在为已经付过钱的对话重复付费。

泄漏 1:一条”保护缓存”的备注

这个智能体搭配了一个上下文插件,它会给每个提示词加一小段备注(路由提示、记忆)。它把这段备注加在请求最后一条消息之后,代码注释说这个位置能保护提示词缓存。

在自动缓存下,缓存断点就是请求的末尾,所以缓存条目恰好写在这段备注处。下一个提示词不再带这段备注,于是它发送的内容没有任何部分与已缓存的内容吻合,整段对话又被重新写入。

同一会话中的三个一个词的提示词:

把备注改为只在对话历史中存一次,同样的三个提示词:

在一周的真实使用中,这是我的日志里导致整段重写的最大单一原因:355 次。

泄漏 2:系统提示词上没有断点

项目里每开一个新会话,都会发送相同的工具和系统提示词,约 3 万个 token。如果请求末尾只有一个断点,新会话就没有可读的内容:它的消息与之前任何会话都不同,所以共享的部分没有自己的缓存条目。间隔一分钟新开的两个会话,各自写入约 35k,读取 0。

在最后一个系统块上再加一个断点(API 允许 4 个):

重启、新会话和子智能体都从这个前缀开始,所以这份节省每次都会重复出现。

我从中得到的

两处泄漏,都是为了保护缓存才放在那个位置的,注释也都说得过去。两者都没有被测量过。用量估算就是测量。

我也在做 Off the Wall,它会回溯过去的纠正。那是一个与这次缓存层调查无关的独立项目。