AI Radar — 每天的 AI 热点、模型与教程

我们估计 Claude Opus 5.5的运行成本大约低 40%在按 token 计费的典型工作负载下，相比 Opus 5。对于开发者而言，确切地了解这些节省如何累积起来很重要。

如果你按 token 付费，你会在运行时间更长、上下文更高的会话中看到最大的成本差异——正是过去六个月里变得越来越普遍的这类 Claude Code 会话。

本文将深入探讨 Opus 5.5 为何对开发者如今的编码方式（很可能也是未来的方式）具有成本效益的机制。

Claude Code 趋势

我们提取了 2026 年 3 月至 9 月期间开发者使用 Claude Code 的汇总数据。随着模型能力的提升，开发者一直在以越来越复杂的方式部署智能体。每个会话的提示数量保持稳定，但我们发现了一些有趣的行为：

所有这些都表明，开发者正将更勤奋、信息更充分的 Claude 指向更大、更开放式的任务。对于这类会话，上下文工程的经济影响会被放大。

有三项变化让长时间运行、上下文繁重的会话更具成本效益：定价、模型行为和 Claude Code 框架的变化。让我们逐一来看。

对于按 token 计费的使用量，我们将输入和输出 token 的成本降低了 20%，并且我们将读取缓存 token 的价格降低了 60%。后一项降价意义重大，因为缓存读取占智能体和编码工作成本的大部分。

正如我们刚才讨论的，每个请求的上下文在六个月内增加了大约 2.6 倍，这意味着节省的趋势正朝着正确的方向发展。对于按 token 计费的用户来说，同样的价格变化在今天的 Claude Code 流量上比六个月前节省更多，因为现在账单中更大一部分是重新读取的上下文。

截至发布日期，Opus 5.5 上的缓存 token 成本是竞争模型的五分之一，同时性能还优于它们。

这一点与 Opus 5.5 关系不大，更多是我们在过去六个月里添加的许多 Claude Code 功能的结果。鉴于我们刚才讨论的编码会话趋势，你可能会预期缓存未命中的比例更高，但事实恰恰相反。未命中缓存的输入减少了超过 50%。

例如，我们让一些较小的琐碎操作更难意外破坏你的缓存，比如刷新登录。我们也让一些较大的操作更难破坏缓存，比如在对话中途添加指令或按需加载工具。对于像 Opus 5.5 和 Fable 5.1 这样的较新模型，你现在可以在会话期间更改努力级别而不会重置缓存。

我们还让缓存对长时间运行和委派的会话更有用。使用 API 密钥和云提供商的开发者现在可以设置一小时的缓存生命周期（订阅用户早已拥有此功能），并且分叉的子智能体从父级的缓存开始，而不是为相同的上下文再次付费。

Opus 5.5 完成相同任务所需的轮次可能比其他模型更少。Zeta Labs 发现每个任务的轮次和工具调用比 Opus 5 更少，但成本几乎只有一半，并且他们最难的任务完成数量翻了一倍。

这并不适用于每一个任务。在Opus 5.5 上完成一个任务的成本，Addy 写道：“在一个范围明确的任务上，两个模型完成的轮次大致相同，价格下调就是你得到的全部好处。差距应该在开放式任务上最大，因为模型可能会在错误的想法上花费很多轮次。没有单一数字适用于每个代码库，所以要实际测量。”

换句话说，简单、简短且机械的任务会消耗相同的轮数，而更长、更难的任务则更有潜力让 Opus 5.5 避免在错误的方法上浪费 token。减少的轮数甚至比缓存 token 更具成本效益。

同样值得注意的是，尤其是当 Claude 在无人值守或不间断的情况下运行更长时间时，Opus 5.5 的输出生成速度比 Opus 5 快 30% 以上。虽然这不会提高缓存命中率或减少 token 使用量，但这意味着在长时间运行中等待更少。

随着智能体编程的成熟，组织已从要求开发者不惜一切代价扩展，转变为要求开发者高效扩展。在 Claude Code 中运行 /usage 以查看你的使用量中有多少是缓存读取。然后保护这个数字：

将 Opus 5.5 用于那些开放式、上下文繁重的工作，在这些工作中这些习惯会产生复利效应，并查看Opus 5.5 上某项任务的成本以获取具体数字。