“Claude Sonnet 5.5 Prompt Cache Reads 降价 50%”这个消息传出来之后我看到的第一个反应是群里一堆人兴奋地算账“这回不得省一大半” 结果真把账单拉出来一核对不少人懵了缓存命中量明明很高账单下降的幅度却远没有 50%。这个落差恰恰说明很多人对 Prompt Cache 的计费结构理解得不够细。这篇不聊营销解读也不去争论这个版本到底算不算“史诗级升级”就讲清楚一件事这次降价到底让你的真实成本降了多少以及这笔账应该怎么算才靠谱。目标读者是正在用 Claude API 做多轮对话、批量文档处理、Agent 编排并且已经被 API 账单折磨过的开发者。读完你至少能拿到一套可直接复用的核算公式以及判断自己业务“该不该高兴”的方法。1. 这次降价真正改的是哪一环节提示缓存的三级计价结构1.1 read、write、base 三档价格差在“对 token 做了什么”Prompt Cache提示缓存的计价不是一档而是三档。很多人只看公告里的“Input/Output”两个数字忽略了真正的计价维度导致后续怎么算都是糊涂账。以 Claude 系列 API 的通用计价规则来看输入侧存在三种价格基础输入价base、缓存写入价cache write、缓存读取价cache read。它们的相对关系大致是base按正常输入价格计费模型需要完整处理这些 tokencache write通常是 base 的 1.25 倍因为模型不仅要处理还要把计算好的状态保存到缓存层cache read通常是 base 的 0.1 倍左右因为模型直接从缓存把已经计算好的状态取出来用不需要重新跑一遍完整的前向计算。这次公告把 cache read 的价格下调 50%也就是把原本已经很低的那档费用再砍一半。为了便于后文统一算账我采用一组常见比例做演示计费类型相对输入基准价降价前的 cache read 假设base input1.0×P—cache write1.25×P—cache read降价前0.1×P—cache read降价后0.05×P下降 50%具体每百万 token 的绝对价格以你账户所在区域的官方定价页为准这里只用相对倍数讲清楚机制。因为这次降价的动作发生在“读缓存”这个环节所以它对账单的影响完全取决于你原本的账单里 cache read 费用占了多大比重。1.2 50% 只是针对 read对账单全局的影响取决于 read 费用占比这是全文最关键的一个认知。很多人听到“Prompt Cache Reads 降价 50%”下意识认为“API 总成本能降 50%”其实完全不是一回事。我们做一个简单的数学推演假设你上一个月的 API 账单里cache read 的计费金额占总账单的 20%那么 cache read 降价 50% 之后总账单的降幅就是 20% × 50% 10%。这一点换算关系极其重要但也是最容易被忽略的。换句话说只有当你账单里的 read 计费占比足够高这次降价才对你构成实质性利好。如果 read 费用只占 5%那整体账单降幅只有 2.5%几乎感觉不到。先记住这个结论后面所有算例都建立在这个逻辑之上。2. 别直接看总账单先给“等效无缓存成本”建立基准2.1 加缓存后 App 调用模式也会变总账单对比不可靠核算真实节省时最容易犯的错误是这个月加了缓存优化下个月看总额发现只省了 10%于是得出结论“缓存没用”。这个对比本身就有问题。加了缓存之后业务代码往往会跟着调整。以前不敢在每次请求里塞大量历史上下文现在敢了以前每轮对话都做截断现在为了质量会把完整历史都发过去。结果就是虽然单位 token 价格变低了但总 token 消耗量变大了两个变量混在一起总账单自然无法说明任何问题。正确做法是建立一个“等效无缓存成本”基准还是同一批请求还是同样的 token 消耗假设一个缓存都没有开按全价计算要花多少钱再按开了缓存的实际计费规则计算要花多少钱。两者相减才是缓存带来的真实节省。2.2 四类 token 计数与一套可复用的核算公式要做上述对比需要从每条请求里拿到四个数字。Claude API 响应中的 usage 结构一般包含input_tokens本次请求中没有命中缓存的输入 token 数cache_creation_input_tokens本次请求写入缓存的 token 数cache_read_input_tokens本次请求从缓存读到的 token 数output_tokens输出 token 数。有同事第一次看usage会困惑“为什么input_tokens这么小我明明发了好几千 token 过去。” 原因是被缓存覆盖的前缀部分被统计到了cache_read_input_tokens或cache_creation_input_tokens里而不是input_tokens里。这三个输入侧数字加起来才是你真实发送的物理 token 总量。有了这四个数字核算公式就非常清晰。设输入基准价为 P输出价为 P_outcache write 价为 P_writecache read 价为 P_read则等效无缓存成本 (input_tokens cache_creation_input_tokens cache_read_input_tokens) × P output_tokens × P_out实际缓存成本 input_tokens × P cache_creation_input_tokens × P_write cache_read_input_tokens × P_read output_tokens × P_out这两个数字一对比“缓存帮我省了多少钱”就水落石出了。注意 price 单位必须一致建议统一换算成“每百万 token”价格再乘。2.3 从 usage 字段到每日看板最小采集示例核算不能靠手工复制粘贴日志应该做成一条自动链路。下面这段 Python 代码不依赖任何特定 SDK逻辑就是累加每天的四类 token 数量然后代入计价公式。你只需要把自己的请求日志解析成下面的Usage结构即可。from dataclasses import dataclass dataclass class Usage: input_tokens: int 0 cache_creation_input_tokens: int 0 cache_read_input_tokens: int 0 output_tokens: int 0 def calculate_bill(records, p_input, p_output, p_write, p_read): records: 一天内所有请求的 Usage 列表 p_input / p_output / p_write / p_read: 每百万 token 价格 返回 (等效无缓存成本, 实际缓存成本) base_tok creation_tok read_tok out_tok 0 for r in records: base_tok r.input_tokens creation_tok r.cache_creation_input_tokens read_tok r.cache_read_input_tokens out_tok r.output_tokens cost_without_cache ( (base_tok creation_tok read_tok) * p_input out_tok * p_output ) cost_with_cache ( base_tok * p_input creation_tok * p_write read_tok * p_read out_tok * p_output ) return cost_without_cache, cost_with_cache实际落地时把每条请求的usage写入日志系统然后用这类聚合函数按小时、按天、按业务线统计即可。成本优化的前提是可观测这一步无论如何都值得先做。3. 三种典型流量下的真实节省测算附完整算例有了核算基准下面看三类最典型的调用模式。你会直观感受到同一个利好消息在不同业务上带来的收益差距能有多大。3.1 多轮对话write 占大头read 降价帮不上太多忙假设一个客服机器人固定 system prompt 有 6000 token每轮用户提问 500 token助手回复 800 token连续对话 10 轮。为简化假设每轮都发送完整历史且缓存命中一切正常。指标无缓存缓存降价前 read0.1P缓存降价后 read0.05P输入计费 token123.5k18.2k write 105.3k read同左输出计费 token8k8k8k总成本163.5P73.28P68.02P相对无缓存的节省—55.2%58.4%这里有个很反直觉的现象多轮对话的缓存命中 token 量其实巨大105.3k 的 read 比 18.2k 的 write 多得多但 read 降价只让总成本从 73.28P 降到 68.02P降幅只有 7.2%。原因很简单read 单价本来就只有 base 的 0.1 倍即使再降 50%在总账单里的分量也不高。真正压住成本的是 write 和 output。3.2 固定前缀高频复用read 占比接近满格降价收益最明显再来看另一种场景某个批量任务每次请求都携带 20k 的固定前缀比如同一份规则说明、同一个知识库片段每次只追加 200 token 的动态问题输出 200 token总共执行 1000 次。指标无缓存缓存降价前 read0.1P缓存降价后 read0.05P输入计费部分20.2M base20.2k write 0.2M base 19.98M read同左总成本21.2P3.22P2.22P相对无缓存的节省—84.8%89.5%这个场景下的 read 费用占了旧账单接近 62%所以 read 降价 50% 后总账单直接又下降了约 31%。这才是这次降价真正的“甜区”大量请求重复消费同一段长前缀而且动态部分很短。3.3 长文档增量分析介于两者之间取决于追加节奏第三类是长文档增量分析。比如把一份 30k 的文档作为主前缀每隔一段时间追加一小段分析指令。这类业务的特点和 3.1 有些重叠但又有区别如果追加的节奏快、间隔短前缀会持续命中read 费用会慢慢爬升如果每次追加很长时间间隔很长缓存过期重建反而让 write 费用剧增。实操层面我建议这类业务不要认死账直接把每天的 usage 统计跑出来看三件事write 费用占比、read 费用占比、output 费用占比。架构上它往往是三类业务的混合体必须用数据说话。3.4 一张表快速预判read 费用占比与整体降幅的关系把前面所有算例抽象成通用规律就是这一张表旧账单中 read 费用占比本次 read 降价 50% 后整体账单降幅10%约 5%30%约 15%50%约 25%70%约 35%90%约 45%下次再看到“降价 50%”这类消息先别激动打开看板看一眼 read 费用占比就能立刻知道这次降价对你是毛毛雨还是及时雨。4. 四个让核算失真、让缓存失效的隐形因素算账方法清晰了但实际操作中有四个坑任何一个都会让前面的公式失真甚至让缓存完全失效。4.1 缓存命中不是免单而是按低价续费最常见的误解是“既然命中缓存这些 token 是不是就免费了”。不是。缓存命中后的 token 仍然按 cache read 计费只不过单价很低。如果你把它当成免费核算时就会高估节省决策时也会误判性价比。拿 3.1 的多轮对话算例来说105.3k 的缓存命中 token 在降价后仍然产生 5.27P 的费用。对大体量业务这个数字并不小。4.2 前缀中混入动态内容双倍成本的产生过程Prompt Cache 是按前缀精确匹配的。只有当两次请求的开头 token 序列完全一致时缓存才能命中。如果你的 system prompt 里拼了时间戳、随机数、用户 ID、会话元数据并且这些内容放在非常靠前的位置那么每次请求的前缀都不一样缓存永远无法命中。最糟糕的情况下成本反而会翻倍一方面旧缓存由于前缀变化无法复用需要重新按全价处理另一方面如果代码里声明了 cache_control 块还会额外产生一次 write 计费。等于钱没省还多花了。提示固定信息放前面动态信息放后面。这是所有缓存类接口的第一设计铁律。动态用户 ID、trace ID 之类的内容要么放到请求末尾要么放到不被 cache 标记控制的区域。在 Anthropic 新版本的自动缓存策略下系统提示词和工具定义如果超过一定长度会被自动纳入缓存。但“自动”不意味着“万能”如果你的 system prompt 里嵌入了每次都在变的内容它照样会被排除在可命中范围之外。4.3 TTL 过期、网关改写与跨会话复用缓存不会永久保留。早期版本的提示缓存是固定 5 分钟 TTL后来的版本演进为动态过期策略核心逻辑都是如果一段时间内没有再次命中缓存就可能被淘汰。上一轮多轮对话如果间隔太久下一次恢复时所有上下文都得重新 write那一刻的账单会非常难看。另一个隐蔽的坑在网关层。不少团队会在 API 前面套一层自己的代理网关用来做鉴权、限流、日志注入。如果网关在转发请求时往 system prompt 前面插入了一段统一的元数据或者对请求做了重写原本匹配的好好的前缀就会被打乱缓存命中率骤降。跨会话复用同样值得留意从平台的设计逻辑来看只要前缀完全一致不同业务线之间的请求理论上也可能命中同一份缓存。所以千万不要把带敏感信息的动态内容编进可被缓存的前缀里这是一条隐私边界问题不只是性能问题。4.4 output 和思考 token 不因 read 降价而变便宜最后别忘了read 降价只管输入侧的缓存命中部分输出 token 依然按原价计算。如果业务大量使用长输出、又开了 extended thinking扩展思考这部分费用可能才是账单真正的大头。我在前面的算例里一直把输出单独列出来就是这个原因。很多团队反复调参后觉得“账单怎么没降”最后拉明细一看原来是输出 token 金额占了 60% 以上。这种情况下把注意力集中在压缩输出、缩短回答长度上比研究 cache read 降价有效得多。5. 降价之后值得做的事清理缓存设计而不是追加缓存看到降价后的第一反应不该是“赶紧把所有东西都丢进缓存”而是重新检查现有缓存设计是否合理让每一分命中率都花在刀刃上。5.1 重新审视 Prompt 布局把固定前缀尽量向前提拿一个典型的 RAG 应用举例。多数人写的 prompt 是动态用户问题动态检索到的知识片段固定指令固定输出格式。这样的布局对缓存极不友好。固定指令放在最后意味着前缀始终在变化缓存命中率会非常难看。更好的布局是固定指令固定输出格式动态知识片段动态用户问题。前面两块完全恒定可以被稳定缓存后面两块是请求差异的来源不参与缓存或者只参与小范围缓存。很多人做完这个调整命中率从 20% 涨到 80%而代码逻辑一行没变只是换了一下拼接顺序。5.2 按 read 占比给业务分档决定优化优先级把监控先做起来然后按业务线或按请求类型统计 read 费用占比分成三档read 占比超过 60%本次降价让你的这类业务直接受益可以进一步扩大固定前缀的数量和长度read 占比在 20%60%有受益但有限优先优化 write 费和 output 费比如压缩历史上下文、精简 system promptread 占比低于 20%这次降价基本和你无关不要为了追热点盲目增加缓存标记把精力放回业务本身。这个分类方法比“大家都说缓存好所以我全都要开”要靠谱得多。5.3 上线前用“三连发”验证缓存生命周期行为最终上线前建议做一个最简单的冒烟测试连续调用三次完全相同的请求观察 usage 字段的四个数字。第一次cache_creation_input_tokens 应该很大因为缓存被创建第二次和第三次cache_read_input_tokens 应该对应增大input_tokens 明显变小如果三次都显示 cache_creation 很大而 read 接近 0说明你的前缀里有动态内容或者请求被网关改写了。这个测试耗时五分钟却能避免“上线后才发现缓存从未命中”的灾难。每次升级模型版本或调整网关逻辑后都值得重跑一遍。回到账面本身这次下调 50% 的意义在于把“读缓存”这个动作的边际成本压到了极低。对固定前缀高频复用的业务来说这是一次实打实的红利对多轮对话型业务来说影响有限重点还是压 write 和 output。我个人体会是不要把希望寄托在某一次降价上而是把 usage 四字段的采集、核算、看板做扎实之后任何价格变动、任何模型升级你都能在十分钟内算出它对账单的真实影响。这套能力比追某一个版本的新闻有用得多。