claude-thermos：给 5 分钟 Prompt Cache「续命」，长时 Claude Code 的账该怎么算

Claude Code 主 Agent 等子 Agent 跑了六分钟。子 Agent 回来，主 Agent 继续说话。屏幕上什么都没坏，账单却可能突然鼓起一块。

原因是 Prompt Cache 过期了。

Anthropic 的默认缓存 TTL 是 5 分钟。命中缓存时，读取价格按基础输入价的 0.1 倍算；新写入 5 分钟缓存，则是 1.25 倍。请求每次命中都会刷新 TTL。问题出在多 Agent 工作流：子 Agent 的 system prompt、工具集合和上下文前缀不同，它自己的请求不会替主 Agent 刷新那份缓存。主 Agent空闲超过 5 分钟，再恢复时就可能把整段长上下文重新编码。[1]

开源工具 claude-thermos 专门盯上了这条缝。

它把 Claude Code 放到一个本机反向代理后面，通过 ANTHROPIC_BASE_URL 让请求先经过 loopback。代理按「模型 + 工具集合 + system text」区分 lineage，识别哪条是主 Agent、哪些是子 Agent。主 Agent 进入空闲，且子 Agent 仍在运行时，工具会重放主 Agent 最后一条真实请求：缓存前缀保持完全一致，max_tokens 压到 1，不走流式输出。生成的那一个 token 被丢掉，目的只是用一次便宜的 cache read 把 TTL 重新推回去。[2]

默认参数很克制：

• 主 Agent 空闲 270 秒后开始预热；
• 每 270 秒最多再刷一次；
• 一次空闲期最多 4 个预热周期；
• 540 秒内有活动的子 Agent 才算仍在工作；
• daemon 模式默认监听 127.0.0.1:8787，会话闲置 3600 秒后清理。

省钱证据有多硬？

作者统计了大约 185 个本地会话，声称缓存重建占总账单约 22%，单次重写常落在 20 万到 50 万 token。这个数字只能当项目作者的工作负载样本，不能外推到所有团队。短会话、少用子 Agent、上下文没那么长，收益会小很多。频繁预热也不是免费：每次仍要付 0.1 倍 cache read，再加极少量输出 token。

更稳妥的算法是看项目自己记录的三个数：预热读了多少 token、避免重写多少 token、两者按 0.1 与 1.25 加权后还剩多少净节省。它会把事件写到本机 ~/.claude-thermos/logs/，包括预热触发、缓存读取量和估算节省，团队可以拿自己的十几个长会话做 A/B，而不是照抄「省 22%」。

还有两条边界

第一，这是一层第三方本地代理。它必须看见并转发 Claude 请求，等于多了一段供应链和一处本机高权限进程。敏感代码环境里，应固定版本、审源码、限制 loopback 访问，确认日志不落正文。

第二，Anthropic 原生就提供 1 小时 TTL，写入价是基础输入的 2 倍。子 Agent 经常跑十几分钟的团队，可以直接比较「1 小时缓存」和「5 分钟缓存 + thermos 预热」两种账。后者更灵活，前者少一层代理。没有万能答案。

claude-thermos 最有意思的地方，不是一个省钱小技巧。它把 AI coding 的成本问题从「选哪个模型」搬到了「怎样管理缓存生命周期」。长程 Agent 越普及，这类不起眼的运行时工程越值钱。

资料来源

1. Anthropic Prompt Caching 官方文档 2. claude-thermos GitHub 仓库与 README