提示缓存，从你的账单读起
怎么审计提示缓存到底省了多少：每条请求上的两个缓存列、一个你能自己算的命中率，以及悄悄毁掉节省的三种模式。
提示缓存被当成折扣来卖。而你的账单，是这笔折扣被证实、还是悄悄流失的地方。大多数讲解止步于机制；这篇教你读自己的数字——因为一个你没法验证的节省，只是另一个你仍在盲目相信的、更小的数字。
先说明：我运营 Teapot Router，一个 API 网关，工作台里能看到每条请求的费用、tokens 和缓存列，可导出。下面的审计方法适用于任何暴露同样数字的端点。
两个列决定你的折扣
缓存按两种特殊的 token 计数计费。缓存写入 tokens：稳定提示前缀的首次写入，按略高于普通输入价的溢价计费。缓存读取 tokens：同一前缀之后的每次复用，按深度折扣计费——通常比冷输入低一个数量级。具体倍数随提供商和模型不同；如果牌价表上没有写，这本身就是个发现。
机制是前缀复用：提示里稳定待在前部的内容——系统提示、项目上下文、此前的对话——只处理一次，之后每一轮都以低价重读。折扣不是优惠券，它是「提示前部没变」的算术结果。
值得算的那个数：命中率
拉一周真实请求，算一个比值：缓存读取 tokens 除以总输入 tokens。绝对值取决于负载形状——重度新会话的用户和长会话的 agent 会落在不同位置——所以趋势才是信号，而不是某个普适目标。命中率一周内持续下滑，通常说明价格上游的东西变了：你的提示、你的会话形状、或你的端点。
悄悄毁掉缓存的三种模式
当趋势下滑时，先找下面三种之一，再怪提供商：
- 不稳定的前缀。提示最前面放一个时间戳、一条轮换指令、或刚改过的系统提示，每一轮都让缓存前缀失效——你反复付写入溢价，却永远收不到读取折扣。提示的前部必须无聊。
- 中段的上下文翻搅。agent 在轮次之间粘贴巨大且不断变化的工具输出，会让前缀一直移动；取决于翻搅所在的位置，复用会崩掉。清理过期的工具输出，既是整洁决策，也是缓存决策。
- 比缓存寿命还短的会话。缓存寿命很短——是分钟级，不是天级。轮次之间空转太久会重置时钟，而一个被切成很多小段的会话，可能永远重读不到足以摊销写入溢价的量。更少、更长、更稳定的会话缓存效果更好。
可审计性问题
无论你用哪个端点，三个问题决定缓存折扣对你是真的：逐请求明细是否区分缓存写入、缓存读取和冷 tokens？缓存价格是否在机器可读的价目表里，而不只是一篇博客？能否导出足够的历史来看命中率趋势？任何一个答案是否，这笔节省就是一条你无法验证的营销话术——而未经验证的折扣总有办法蒸发。
工作台明细和公开价格端点，就是我们在自己服务上回答这些问题的方式：每条请求的缓存列、可导出、价格来自计算器读取的同一个 JSON：https://teapotrouter.com/en/claude-code-cost-calculator
提示缓存不是一个你打开的功能，而是一个你测量的行为。读那两列、算命中率、盯趋势、先修前缀再去找更便宜的费率。给你看列的提供商是在让你检查他们的作业——不给看的，是在让你闭着眼睛给自己的折扣打分。
常见问题
提示缓存总是省钱吗？
不。缓存写入比普通输入价略高，所以只用一次的前缀反而略贵。节省来自被多次重读的稳定前缀——长会话、大的静态系统提示、反复引用的文档。
怎么算缓存命中率？
从逐请求明细算：一周真实工作中，缓存读取 tokens 除以总输入 tokens。看趋势而不是单条请求——命中率下滑时，先指向提示或会话的变化，再指向价格。
缓存节省为什么消失了？
通常是三种之一：提示前缀不再稳定（前部被改动或有易变内容）、空闲间隔超过了缓存寿命、或端点改变了缓存的记账方式——最后这种只有明细区分了各列才能看出来。