我们估计，对于按 token 计费的典型工作负载，Claude Opus 5.5 的运行成本比 Opus 5 低约 40%。对开发者而言，这些节省究竟如何累积起来才是关键。
如果你按 token 付费，那么在运行时间更长、上下文更高的会话中，成本差异最为明显——而这正是过去六个月里愈发普遍的 Claude Code 会话类型。
本文将深入探讨 Opus 5.5 为何能在开发者当下（以及未来很可能）的编码方式下实现成本效益的机制。
Claude Code 趋势
我们汇总了 2026 年 3 月至 9 月期间开发者使用 Claude Code 的聚合数据。随着模型能力提升，开发者部署智能体的方式日益精妙。每个会话的提示词数量保持稳定，但我们发现了一些有趣的行为：
- Claude 在每个提示词上的工作时长增加了 3.3 倍，每个提示词的模型调用次数增加了 40% 以上。中断次数减少了 68%。
- 开发者连接工具服务器的可能性约为原来的两倍，使用技能的可能性也约为两倍，而将文本粘贴到提示词中的可能性则减少了三分之一。
- 每次请求的上下文增长了 2.6 倍。输入与输出 token 的比例从 189:1 变为 324:1。
所有这些都表明，开发者正把更勤奋、信息更充分的 Claude 用于更大、更开放式的任务。对于这类会话，上下文工程的经济影响会被进一步放大。
简而言之，Claude 读取的 token 更多了。你需要确保你提供的所有上下文都是必要的，并且尽可能多的上下文是从缓存中读取的。
是什么让 Opus 5.5 在长时间、上下文密集的会话中具备成本效益
有三项变化让长时间运行、上下文密集的会话更具成本效益：定价的变化、模型行为的变化，以及 Claude Code harness 的变化。让我们逐一来看。
缓存很便宜
对于按 token 计费的使用，我们将输入和输出 token 的成本降低了 20%，并且将读取缓存 token 的价格降低了 60%。后一项降价意义重大，因为缓存读取构成了智能体和编程工作成本的大部分。
正如我们刚刚讨论的，每次请求的上下文在六个月内增加了约 2.6 倍，这意味着节省正朝着正确的方向发展。对于按 token 计费的用户来说，同样的价格调整在如今的 Claude Code 流量上比六个月前节省更多，因为现在账单中更大一部分来自重新读取的上下文。
截至本文发布之日，Opus 5.5 上缓存 token 的成本仅为竞争模型的五分之一，同时性能还优于它们。
Claude Code 更擅长利用缓存
这一点与 Opus 5.5 的关系没那么大，更多是我们在过去六个月里为 Claude Code 添加的许多功能所带来的结果。考虑到我们刚才讨论的编码会话趋势，你可能会预期缓存未命中的比例更高，但事实恰恰相反。未命中缓存的输入减少了 50% 以上。
例如，我们让一些较小的操作更难意外破坏你的缓存，比如刷新登录。我们也让一些较大的操作更难破坏缓存，比如在对话中途添加指令或按需加载工具。对于 Opus 5.5 和 Fable 5.1 这类较新的模型，你现在可以在会话过程中更改 effort 级别，而不会重置缓存。
我们还让缓存对长时间运行和委派的会话更有用。使用 API key 和云服务商的开发者现在可以设置一小时的缓存生命周期（订阅用户此前已享有此功能），而分叉出的子智能体会从父级的缓存开始，而不必为相同的上下文再次付费。
同样的任务，但轮次更少
完成同样的任务，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，查看你的用量中有多少是缓存读取。然后保护这个数字：
- 在会话开始时选好你的模型，而不是中途切换，
- 在离开之前进行压缩，而不是之后，以及
- 如果你使用的是 API key 或云服务商，请为长时间会话设置一小时缓存生命周期。
把 Opus 5.5 用于开放式、上下文繁重的工作，在这些工作中这些习惯会不断累积产生复利效应，并查看在 Opus 5.5 上运行一项任务的成本了解具体的计算数字。
We estimate Claude Opus 5.5 costs about 40% less to run than Opus 5 for typical workloads billed by token. For developers, exactly how those savings stack up matters.
If you pay by the token, you will see the greatest cost difference for longer-running, higher context sessions–the exact type of Claude Code sessions that have become more prevalent in the last six months.
This post will dive into the mechanics of what makes Opus 5.5 cost effective for how developers are coding today (and likely tomorrow).
Claude Code trends
We've pulled aggregate data on how developers have been using Claude Code from March to September 2026. As model capabilities improve, developers have been deploying agents in increasingly sophisticated ways. The number of prompts per session has been steady, but we found some interesting behaviors:
- Claude works 3.3x longer on each prompt with more than 40% more model calls per prompt. There are 68% fewer interruptions.
- Developers are about twice as likely to have a tool server connected or use a skill and a third less likely to paste text into a prompt.
- Context per request has grown 2.6x. The input to output token ratio moved from 189:1 to 324:1.
All of this points to developers aiming a harder working, better informed Claude toward bigger, more open-ended tasks. For these types of sessions, the economic impact of context engineering is compounded.
Simply put, Claude reads more tokens. You need to make sure all the context you are providing is necessary, and that as much of that context as possible is reading from cache.
What makes Opus 5.5 cost effective for long, context heavy sessions
There are three changes that make long-running, context-heavy sessions more cost effective: changes to pricing, model behavior, and the Claude Code harness. Let’s look at each.
Cache is cheap
For usage billed by the token, we reduced the cost of input and output tokens 20%, and we dropped the price of reading a cached token 60%. The latter reduction is significant because cache reads make up the majority of agentic and coding work costs.
And as we just discussed, context per request has increased roughly 2.6x in six months, which means savings are trending in the right direction. The same price change for those billed by token saves more on today's Claude Code traffic than it would have six months ago, because more of the bill is now re-read context.
As of the publication date, a cached token on Opus 5.5 costs a fifth of what it does compared to competing models while outperforming them.
Claude Code is better at using the cache
This is less specific to Opus 5.5, and more the result of many of the Claude Code features we’ve added in the last six months. Given the coding session trends we just discussed, you would expect a higher rate of cache misses, but the opposite is true. Input that misses the cache decreased by more than 50%.
For example, we made it harder to unintentionally break your cache with smaller papercuts like refreshing a login. We also made it harder to break with larger actions, like adding instructions mid-conversation or loading tools on demand. For newer models like Opus 5.5 and Fable 5.1, you can now change effort levels during your sessions without resetting your cache.
We also made the cache more useful for longer-running and delegated sessions. Developers on API keys and cloud providers can now set a one-hour cache lifetime (which subscribers already had) and forked subagents start from the parent's cache instead of paying for the same context again.
The same task, but with fewer turns
Opus 5.5 can need fewer turns than other models to accomplish the same task. Zeta Labs saw fewer turns and tool calls per task than Opus 5, but at nearly half the cost and twice as many of their hardest tasks completed.
This won't hold for every task. In The cost of a task on Opus 5.5, Addy wrote, "On a well-scoped task, both models finish in about the same number of turns, and the price cut is all you get. The gap should be biggest on open-ended tasks, where a model can spend many turns on the wrong idea. No single number holds for every codebase, so measure it."
In other words, simple, short, and mechanical tasks will take the same amount of turns while longer, harder tasks have more potential for Opus 5.5 to avoid burning tokens on the wrong approach. A reduced turn is even more cost efficient than a cached token.
Also worth noting, especially as Claude works longer unattended or uninterrupted, is that Opus 5.5 generates output more than 30% faster than Opus 5. While this doesn’t increase cache hit rate or use less tokens, it means waiting less on long runs.
Protect your cached reads
As agentic coding has matured, organizations have shifted from asking developers to scale at all costs to asking developers to scale efficiently. Run /usage in Claude Code to see how much of your usage is cached reads. Then protect that number:
- Pick your model at the start of a session rather than switching midway,
- Compact before you step away rather than after, and
- If you're on an API key or cloud provider, set the one-hour cache lifetime for long sessions.
Point Opus 5.5 at the open-ended, context-heavy work where those habits compound, and see What a task costs on Opus 5.5 for the worked numbers.