Anthropic 这次调价，最狠的一刀没落在输入 token 上。Claude Opus 5.5 的缓存读取价格砍掉 60%，输入和输出各降 20%，官方给出的口径是：典型按 token 计费的工作负载，运行成本比 Opus 5 低约 40%。这个四成不是平均降价的算术结果，它更像一道暗号——指向 Claude Code 那类越聊越长、上下文越滚越大的编码会话。
四成降幅，藏在哪个齿轮里
缓存读取被砍掉六成，这是主刀口
要理解 60% 的分量，得先看清长会话的钱是怎么花掉的。每一轮对话，模型都要重读一遍之前的全部上下文；prompt 缓存的作用，就是把这部分重复内容存住，后续直接命中读取，省掉重新计算的开销。缓存写入通常比普通输入更贵，缓存读取则便宜得多，而在一场持续数小时的编码会话里，真正撑起账单的恰恰是后者。谁的读取量大，谁就吃到最多折扣。这一刀落在缓存上，等于直接落在重度用户的钱包上。
输入输出只降两成，是刻意留的余地
首轮输入、全新代码、模型生成的每一行输出，这些用量躲不开缓存，也就没什么优化空间。20% 是个体面的数字，但它不是这次的主角。把三类价格拉开差距，本身就在传递信号：厂商愿意为"复用"让利，不愿意为"重复投喂"买单。你若每次都把整个代码库原封不动塞进去，命中率上不去，账单也不会自己变好看。
平均值不等于你的账单
那 40% 建立在"典型工作负载"这个假设上。什么叫典型？大概就是上下文够长、前缀够稳定、缓存能持续命中的那类调用。短问答、一次性脚本生成、偶尔问两句的用法，命中次数有限，感受不到太大变化。同一份价目表，不同的人读出来的数字能差出几倍。这不是定价不透明，是计费结构本身在筛选使用方式。
Claude Code 把上下文变成了长期负债
一轮编码任务，钱烧在哪几步
读文件、定位函数、跑一次测试、看报错、改三行、再跑一遍。听起来是十几个小动作，落到计费上却是同一段历史被反复重放的十几轮。上下文不是线性变贵，它带着复利属性：文件多读一个，之后每一轮都得再带一份。会话拖到第三个小时，单轮成本可能已经是最初的好几倍。这也解释了为什么"更多上下文"既是能力卖点，也是成本隐患。
便宜不会让人少花钱
价格下来，用户的第一反应从来不是省着用，而是把原本不敢做的事做起来：让 Agent 自己跑完整套重构、把失败的测试日志整段丢进去、开着会话一整天不关。单价下去，总用量上来，月末账单未必变薄。对 Anthropic 而言这反而是好事——门槛降低，使用深度增加，模型在真实工程流程里的粘性跟着涨。
折扣能不能吃到，取决于工具链
官方特意把降价结构和缓存机制放在一起讲，这句话值得琢磨。缓存命中要求前缀高度稳定：系统提示不能每轮都变，工具定义不能随手改顺序，中途插入的临时信息不能打乱前面的内容。不少团队抱怨"缓存好像没生效"，问题往往不在模型，而在自己拼 prompt 的方式。定价变了，工程习惯得跟着变。
谁会立刻省钱，谁暂时无感
重度 Agent 用户先拿到红利
跑长周期任务、维护常驻会话、让多个子 Agent 共享同一套系统提示的团队，缓存读取量本来就大。这批人这次拿到的折扣最实在，甚至可能重新计算自家产品的毛利模型。做编码助手、代码审查机器人、自动化修 bug 流水线的公司，40% 不是小数目，它直接决定某些功能是亏钱还是赚钱。
轻量调用者不必急着迁
每天只有几百次短请求的场景，缓存读取本来就不是成本大头，20% 的输入输出降幅落到总支出上几乎看不见。为了这点降幅去重构调用链路，投入产出比并不划算。更实际的做法是先把自己的 token 账本拆开看：缓存写入占多少、读取占多少、输出占多少。看不懂账本，就谈不上优化。
迁移成本也得算进去
换个模型不只是改一个接口地址。提示词要重调，工具调用格式要适配，团队对模型脾气的熟悉度要从零攒起。这些隐形成本常常比省下来的那点调用费更贵。价格是决策变量之一，但它不是唯一的那个。
下一场较量不在单价上
从每百万 token 多少钱，到每个任务多少钱
模型定价的叙事正在换轨。过去各家比的是每百万 token 的报价，现在这个数字越来越没有参考价值——同一个模型，命中率高的团队和命中率低的团队，实际单价能差出好几倍。真正的比较单位正在变成"完成一次代码重构花多少钱""跑通一个 issue 花多少钱"。厂商能优化的只有价目表，效率那部分，得用户自己挣。
便宜是入场券，不是结论
把 Opus 5.5 放进实际项目里，还牵扯另一个问题：省下来的钱，会不会被更长的会话、更多的重试吃掉。一个模型如果因为上下文理解更准而少跑两轮，比单价降 20% 更值钱。反过来，便宜但需要反复纠正的模型，账单会很难看。降价是好事，它把竞争拉回到单位任务成本这条更诚实的赛道上，但答案还得靠自己的日志来写。
