Opus 5.5 调价测算：代理费用降 35%，大头是缓存写入

30 秒看完主要结论

9 月 22 日，Anthropic 发布了 Claude Opus 5.5。这次各项单价的降幅并不一样：输入、输出和缓存写入降了 20%，缓存读取降了 60%。下表单价均为每百万 token 的美元价格。

官方的说法是：默认设置下，典型任务的费用下降 40%。这个数字既包括单价下降，也包括模型完成每项任务时使用的 token 变少。我们想单独看调价的影响，于是统计了六个长期运行的代理会话，共 7,850 次助手轮次、29 亿输入侧 token，再把同一批用量分别套入两张价目表。本文回答的问题比官方的 40% 更窄，不能用来验证那个数字。

结果可以归为三点：

1. 未缓存 input 只占 0.015%。 输入标价适用的用量少得几乎可以忽略。缓存读取占 93.4%，缓存写入占 6.6%。
2. 按价目表建模的 token 费用下降 35.3%。 同一批用量从 $3,534 降到 $2,286，降幅超过 20%。原因是读取量极大，而读取单价降了 60%。
3. 费用最高的是缓存写入。 按 Opus 5 价目表计算，写入占 54.3%；换成 Opus 5.5，占比变为 67.1%。写入单价也降了 20%，只是总费用降得更多，所以写入占比反而上升。

要优化费用，第三点尤其关键。缓存命中多，不代表钱就主要花在读取上。

样本与统计方法

这六个会话处理的都是真实任务，包括编程、研究和运维，连续运行时间从数天到数周不等。Claude Code 会为每次助手轮次记录一个 usage 对象。其中有四个计数：input_tokens 是未缓存 input，cache_creation_input_tokens 是缓存写入，cache_read_input_tokens 是缓存读取，output_tokens 是输出。我们逐项汇总了这些计数。

六个会话另有 10,467,579 个输出 token，约为输入侧用量的三百分之一。

不同会话的缓存读取占比介于 88.2% 至 96.8%。最低的也有约八分之七的输入侧 token 来自缓存读取。未缓存 input 的占比，即便在最高的会话中，也只有 0.051%。

自己统计时，先去重再求和。 Claude Code 的会话文件可能多次写入同一条助手消息。我们最大的会话有 3,291 条 usage 记录，却只有 1,570 个不同的消息 ID。直接累加所有记录，会多算 51% 的 token。上表已经按 message.id 去重。

这种用量结构有其原因，但六个会话还不足以证明它有多普遍。长时间运行的代理通常带着一大段稳定前缀，里面有系统提示词、工具定义、技能和累积的对话。这些内容写入缓存后，每一轮都会再读一遍。轮次越多，重复读取越多；未缓存 input 则不会因此成倍增加。

同一批用量，费用降了多少

把同样的 29 亿输入侧 token 和对应输出，分别按两张价目表计算。以下是按价目表建模的 token 费用，不是核对过的账单。 这里只计四类 token，采用标准 API 标价，不含服务端工具费，也不考虑协议价。

我们把所有缓存写入都按一小时单价计算，因为实测有 99.5% 的写入 token 使用这一档。若把剩余 0.5% 也精确按各自单价计算，总额只会变化约 0.1%。

算下来，总费用下降了 35.3%。如果预算只按整体降价 20% 来估，会得到 $2,827，比这里的建模结果多出 $541。这 $541 全部来自缓存读取：它的降幅超过了其他费用项。

因此，对这批用量来说，只看输入和输出的标称降幅，会低估这次调价带来的节省。不过，总额下降之后，还要看剩下的钱主要花在哪里。

缓存写入，为什么更贵

在 Opus 5.5 这一列，缓存读取占 token 用量的 93.4%，却只占总费用的 23.7%；缓存写入仅占用量的 6.6%，费用占比却达到 67.1%。读取在 Opus 5 下的费用占比为 38.3%，降价后进一步缩小。

原因在单价。我们的读取 token 数是写入的 14.1 倍。但 Opus 5 的一小时缓存写入，每百万 token 要 $10，读取只要 $0.50，单价相差 20x。20 倍的单价足以抵消 14.1 倍的用量差距，最终写入费用仍是读取的约 1.4x。

到了 Opus 5.5，读取比写入降价更多，两项费用之间的差距也随之拉大：

这会影响优化的先后顺序。很多人会先压缩上下文，减少每轮读回的 token。但在这张价目表下，读取已经很便宜，缓存失效后重写前缀才贵：一小时缓存写入按基础输入单价的 2x 收费。如果提示词缩短了 10%，代价却是每轮都多重写一次缓存，总费用反而会上升。

官方的说法，和样本矛盾吗

Opus 5.5 的发布公告称，缓存读取占代理和编程任务成本的大部分；读取价格降至每百万 token $0.20，比 Opus 5 低 60%。原文写道：

Cache reads (which make up the majority of agentic and coding work costs) are $0.20 per million tokens, 60% less than Opus 5.

我们的样本没有呈现这种情况：按 Opus 5.5 价目表计算，读取占 23.7%，写入占 67.1%。要理解两种结果为何不同，可以先算一个边界：读取量要比写入量大多少，才能抵消写入与读取的单价差？

设写入单价为 write_price，读取单价为 read_price。读取费用超过写入费用，当且仅当：

read tokens ÷ write tokens > write_price ÷ read_price

也就是：读取 token 数 ÷ 写入 token 数 > 写入单价 ÷ 读取单价。

这里比较的只是缓存读取和缓存写入两个费用项。即使读取比写入贵，也不能据此认定读取占了总费用的多数，因为输出和未缓存 input 还没有算进去。这个盈亏平衡点能告诉我们，在两类缓存费用中，哪一类更值得优先关注。

公式右边由价目表决定。以下单价均为每百万 token 的美元价格：

公式左边则取决于实际用量。六个会话的读写 token 比分别是：

六个会话都低于 40:1，因此按 Opus 5.5 价目表计算，全部都是写入费用更高。而旧版 Opus 5 的门槛是 20:1，当时 A、B、E 三个会话确实是读取费用更高。官方的说法与我们的观察，可以分别适用于不同用量结构，关键是读写 token 比落在哪一边。

同时，有两点需要说清楚。

Anthropic 掌握的用量数据远比我们多。 我们只有一台机器上的六个会话，官方看到的则是客户总体用量。我们不知道公告中那句话具体依据什么数据。我们的测量只能证明：确实存在一类长期自主运行的会话，其读写 token 比明显低于这条线。至于其他会话，可以用同一个公式自行判断。

这次降价，让“读取费用更高”更难成立。 读取降价 60%，写入只降价 20%，一小时缓存的盈亏平衡点便从 20:1 提高到了 40:1。用量完全不变，也可能从读取更贵变成写入更贵，我们的六个会话中就有三个如此。读取越便宜，剩余费用就越集中在写入上。

一小时 TTL 怎样才划算

Anthropic 提供两档缓存时长：五分钟写入按基础输入单价的 1.25x 收费，一小时按 2x 收费。我们的会话几乎全用一小时缓存，占缓存写入 token 的 99.5%。

如果保持观测到的写入量不变，所有写入都按一小时计价，建模总费用会比全部按五分钟计价高 33.6%：$2,286 对 $1,711。单看写入一项，价差是 60%；总费用的差距更小，是因为读取和输出费用没有变化。

这不代表切换 TTL 就能省下这笔钱。 缓存时长变短，会更频繁地过期；每次过期，都可能迫使后续请求重新写入。换 TTL 也会改变写入量。我们的记录只包含实际发生的写入，无法测出同样的会话如果改用五分钟缓存，会多写多少 token。因此，33.6% 不能当成可直接实现的节省。

不过，价目表足以算出一小时方案划算的门槛。这里还要考虑读取费用：TTL 缩短后，多出来的写入会替代原本的读取，因为一个前缀既然需要重新写入，就不会在这次请求中从缓存读回。扣除这部分读取费用后，一小时方案更便宜的条件是：

W₅ₘ ÷ W₁ₕ > (price₁ₕ − price_read) ÷ (price₅ₘ − price_read)

其中，W₅ₘ 和 W₁ₕ 分别是五分钟、一小时方案的写入 token 数；公式右边的各项分别为一小时写入单价、读取单价和五分钟写入单价。

代入 Opus 5.5 的价格，右边是 (8 − 0.20) ÷ (5 − 0.20) = 1.625。换句话说：

只有改成五分钟缓存后，写入量会增加超过 62.5%，一小时 TTL 才更划算。 Opus 5 价目表下的门槛是 65.2%。

若只比较两档写入单价，会算出 60%，低估了门槛，因为没有扣掉新增写入所替代的读取费用。

如果会话每隔一两分钟就运行一轮，通常不容易达到这个门槛。五分钟缓存很少会在两轮之间过期，选一小时却要为每次写入多付钱，而更长的有效期很少派得上用场。

如果会话经常停二十分钟再继续，一小时方案可能划算，但也不能直接下结论。要统计的是这些间隔会迫使多少 token 重新写入，还要考虑各段前缀的大小，不能只数停顿次数。另外，TTL 从请求发出时就开始计时，模型生成内容的时间也算在内。该选哪一档，可以根据自己的复用间隔测算，无须直接接受默认设置。

每百万 token 的混合单价

将输入侧三类费用相加，再按全部输入侧 token 平摊，可以得到混合单价。下表按我们的用量结构计算，单位仍为美元／百万 token：

对这批代理用量，输入标价约为混合单价的四到六倍，而且各模型的倍数并不相同。这组数据中，价格从低到高的顺序恰好没有变化：Sonnet 5、Opus 5.5、Opus 5、Fable 5.1。但模型之间的价差变了。只看标价，Opus 5.5 是 Sonnet 的两倍；按样本用量计算，则是 1.6x。做预算或评估是否更换模型时，应当用自己的混合单价来比较。

Anthropic 的定价也反映了这一点。缓存读取通常按基础输入单价的 0.1x 收费，Opus 5.5 是明确列出的例外，只有 0.05x；Fable 5.1 更低，为 0.025x。所以，尽管 Fable 的输入标价是 $10，按我们的用量结构计算，缓存读取也只占其总费用的 13.4%。这类单独给缓存读取的折扣，说明厂商清楚代理用量主要集中在哪一类 token 上。

结论的适用范围

样本都是长期运行的会话。 它们连续运行数天到数周，似乎也是上述缓存折扣面向的使用方式。但一台机器上的六个会话不能代表更广泛的用户。短对话如果前缀很小，混合单价就会更接近输入标价。

订阅费用要分开看。 Pro、Max 和 Team 收取固定月费，API 价目表变化不会让这笔月费降低。超出套餐所含额度的用量则不同：这部分以用量额度按标准 API 价格计费，因此能享受到降价。不论是否额外付费，用量结构都值得关注，因为它会影响会话消耗当前用量窗口额度的速度。

我们只测算调价，没有预测模型行为。 固定 token 数、分别套入两张价目表，可以单独看价格变化的影响。但这不等于预测你的账单会下降 31%。据称 Opus 5.5 运行速度也更快，同一项工作实际产生的 token 数未必相同。

全文统一按一小时写入价格建模。 各会话观测到的写入中，有 98-100% 使用这一档。五分钟缓存的总费用会不同，前面的 TTL 一节已经说明了差异和比较方法。

优化成本，从这几步入手

1. 先算自己的混合单价。 从会话记录提取 usage，按消息 ID 去重，再计算 (uncached_cost + write_cost + read_cost) ÷ (uncached + write + read tokens)，换算成每百万 token 的美元费用。这里有意排除了输出；若计入输出，Opus 5.5 的数字是 $1.108，而非 $0.717。我们测得的输入侧混合单价不到输入标价的五分之一，用它做预算比直接套标价更合适。
2. 压缩上下文之前，先查写入从何而来。 读取占 token 用量的 93.4%，却只占建模费用的 23.7%，单纯减少读回的内容，对总费用影响有限。但缓存写入也并非全是浪费：追加消息或工具结果，本来就需要写入。应当先区分首次写入、正常增长，以及本可避免的缓存失效。系统提示词里的时间戳、顺序不断变化的工具列表、插入后又移除的文件，都可能让前缀失效。分清原因，再决定改哪里。
3. 结合实际间隔选 TTL，别停在 60% 这个粗略门槛上。 扣除被替代的读取费用后，Opus 5.5 的门槛是写入量增加超过 62.5%。检查轮次间隔会导致多少重写；如果会话一直忙碌，一小时缓存的额外费用可能买来了很少用到的有效期。
4. 比较模型时，给四类 token 分别计价。 缓存读取通常是基础输入价的 0.1x，Opus 5.5 为 0.05x，Fable 5.1 为 0.025x。但倍率低，还要看基础单价：Fable 的 0.025x 仍是每百万 token $0.25，高于 Opus 5.5 的 $0.20，而且它的写入单价是这四个模型中最高的。最终应当按自己的各类用量加权计算。

延伸阅读

• Claude Code 的 33,000 token 启动开销——缓存里那段反复读回的前缀，到底装了什么。
• Claude Code 定价——从订阅角度理解费用和额度。
• 企业使用 AI 编程代理，到底花多少钱——把单个会话的费用放到组织规模下看。
• 复现 Spotify 的 token 节省方案：用量减少 90%——实测减少进入上下文的内容，能带来多大收益。
• Claude 模型档位与推理强度——影响 token 用量的另一个设置。

来源

1. Anthropic：提示词缓存。价目表和计费倍率的官方依据：五分钟缓存写入为基础输入价的 1.25x，一小时为 2x，缓存读取通常为 0.1x；文档另列出 Claude Opus 5.5 的 0.05x 和 Claude Fable 5.1 的 0.025x。
2. Anthropic：Claude Opus 5.5。2026 年 9 月 22 日的发布公告。
3. Anthropic：定价。文中各模型单价的出处。

本文测量来自 macOS 上处理真实任务的六个 Claude Code 会话，共 7,850 次去重后的助手轮次。每轮的 token 数取自会话文件记录的 usage 对象，包括 input_tokens、cache_creation_input_tokens、cache_read_input_tokens、output_tokens。统计采用全量记录，没有抽样，并按 message.id 去重。会话文件会重复序列化同一条助手消息，若直接累加原始记录，会把我们最大会话的 token 数多算 51%。这些记录中没有出现子代理分支的轮次。会话名称均以字母代替。费用通过已公布的价目表与上述计数计算得出；各会话 98-100% 的缓存写入使用一小时 TTL，因此统一按一小时缓存写入单价建模。

FAQ

Opus 5.5 用于代理任务，费用能降多少？

只换价目表、保持 token 数不变，我们这批用量按价目表建模的 token 费用下降 35.3%，从 $3,534 降到 $2,286。这不是核对过的账单。超过输入和输出 20% 降幅的部分，全部来自缓存读取单价下降 60%。官方另称，默认设置下的典型任务费用下降 40%，还计入了每项任务使用更少 token 的收益；本文的固定用量测算，既不能证实，也不能否定这个更宽泛的说法。

这些代理会话的 token 都用在了哪里？

共计 7,850 次助手轮次中，输入侧 token 有 0.015% 是未缓存 input，6.62% 是缓存写入，93.37% 是缓存读取。各会话的缓存读取占比为 88.2% 至 96.8%。统计前必须按消息 ID 去重，否则我们最大会话的用量会多算 51%。这些数字描述的是本次测得的长期运行会话，不能据此推断所有代理任务。

缓存写入量更少，为什么费用反而更高？

因为单价差距更大。读取量是写入的 14.1x，但 Opus 5 的写入单价是读取的 20x，所以写入费用仍达到读取的 1.4x。Opus 5.5 的读取单价降了 60%，写入只降了 20%，两项费用之比便扩大到 2.8x。

一小时缓存 TTL 值得选吗？

要看它能避免多少重复写入。TTL 缩短后，多出的写入会替代一部分读取，因此不能只拿写入单价比较。扣除读取费用后，Opus 5.5 的条件是：改用五分钟缓存会让写入量增加超过 62.5%，一小时方案才划算；Opus 5 为 65.2%。门槛高于单看写入价差得到的 60%，需要按实际复用间隔判断，不能直接套用默认设置。

每百万 token 的费用，与输入标价差多少？

按我们的用量结构建模，Opus 5.5 的输入侧混合单价为每百万 token $0.717，输入标价是 $4，前者不到后者的五分之一。不同模型的差距并不一样，标价是混合单价的 4.4x 至 6.4x。这组数据中的价格排序虽然没变，但只看输入标价，会误判模型之间的实际价差。

Anthropic 说缓存读取占大头，是说错了吗？

不能这样判断。读写 token 比只有超过“写入单价 ÷ 读取单价”，读取费用才会超过写入费用；这只比较两个费用项，不代表读取占了总费用的多数。一小时缓存下，Opus 5 的门槛为 20:1，Opus 5.5 为 40:1。我们的六个会话介于 7.5:1 至 30.4:1，新价目表下全是写入更贵，其中三个在旧价目表下却是读取更贵。Anthropic 看到的用量远比我们多，我们也不知道其说法的具体依据；这些样本提供的是一种确实存在的情况，以及自行判断的方法。

这次降价会减少 Claude Code 的订阅费用吗？

固定月费不会降低。超出套餐所含额度的部分，以用量额度按标准 API 价格计费，因此这部分能享受到降价。不论采用哪种付费方式，都值得关注 token 的构成，因为它会影响会话消耗当前用量窗口额度的速度。