Claude Opus 5.5 的单任务成本更低，但 Token 价格只解释了一半

Anthropic 将 Claude Opus 5.5 的 Token 费率下调了 20%，但估算的 Claude Opus 5.5 单任务成本降幅可能更大。缓存读取的成本比 Opus 5 低 60%，这改变了长时间 Claude Code 会话的成本结构。

Claude Devs 通过一份任务成本分析及互动计算器凸显了这一差异，两者于 2026 年 9 月 22 日发布。该分析建议开发者衡量已完成的工作，而不是比较孤立的 Token 费率。

这一差别构成了 Opus 5.5 与 Opus 5 之间真正的较量。Token 更便宜，并不保证某项功能开发、迁移或调试会话的成本更低。交互轮次、缓存行为、推理输出、重试次数和模型设置共同决定最终结果。

Claude Opus 5.5 单任务成本发生了什么变化

Anthropic 下调了所有主要 Token 类别的价格，但缓存读取的降幅最深。

输入和输出 Token 费率均较 Opus 5 低 20%。根据 Anthropic 的模型公告，缓存读取价格则低了 60%。

这一差异之所以重要，是因为 Claude Code 会反复将先前的对话材料发送回模型。这些复用材料通常包括指令、源文件、工具结果，以及截至当前已完成的工作。

提示词缓存可让服务识别此前已处理过的内容。缓存读取会以低于新输入处理的价格，获取这些可复用上下文。

Anthropic 表示，在许多编程和智能体工作负载中，缓存读取占据了大部分 Token 用量。该说法描述的是 Token 构成，并不意味着它必然是每张账单中收费最高的部分。

由于推理和生成文本均按输出 Token 计费，输出仍可能主导最终成本。输入量不高、但需要大量推理的会话，可能无法从更低的缓存读取价格中获得太多收益。

官方的任务成本分析将这些影响拆分开来。它先在相同 Token 数量下比较两款模型，以隔离费率变化的影响。

其示例会话包含大量缓存上下文、部分新输入，以及较少的输出。在这些固定假设下，Opus 5.5 的成本约比 Opus 5 低 31%。

这一结果介于各项 headline 降幅之间。由于会话受益于更低的缓存读取价格，降幅超过了 20%；但其他 Token 类别同样重要，因此仍低于 60%。

Anthropic 另行估算，在默认设置下，典型工作负载的成本约低 40%。这一更广泛的估算同时包含更低费率，以及该公司认为 Opus 5.5 能以更高效率完成工作的预期。

这些是不同层面的说法。20% 和 60% 的数字直接来自已公布的费率变化。31% 的示例则取决于示例性的 Token 构成。

估算的 40% 降幅还加入了对模型行为的假设。开发者不应将其自动套用于每个代码库、提示词或编码工作流。

Opus 5.5 于 9 月 22 日通过 Claude API 和多个主要云平台上线。该模型也进入了 Claude Code 与 Anthropic 的订阅产品。

其模型概览列出了一百万 Token 的上下文窗口，以及默认的中等 effort 设置。自适应思考始终处于启用状态。

这些细节会在新费率表之外影响成本。更大的可用上下文可支持更长的会话，而自适应思考会根据任务难度增加可计费的输出。

结果是单位成本下降，但总成本仍取决于工作负载。费率变化创造了节省空间，但智能体完成任务的路径决定其中有多少会真正体现出来。

为什么 Claude Code 任务的成本高于其最终上下文

Claude Code 支付的是跨轮次反复处理的成本，而不只是最终可见的对话。

Claude Code 任务以循环方式运行。模型读取上下文、选择工具、检查结果、更新推理，然后重复这些步骤。

每次循环都会产生新的请求。该请求包含此前轮次积累的大部分对话内容。

设想一个会话：它从适中的上下文开始，随着 Claude 读取文件、运行测试并接收终端输出而不断增长。其最终上下文大小并不等于总处理输入量。

如果任务经历许多轮次，模型会反复遇到先前材料。提示词缓存会让这些重复读取更便宜，但不会让它们免费。

这一机制解释了为何两个最终代码改动相似的会话，成本可能截然不同。一个模型可能立即找到相关文件，并在短暂验证循环后完成任务。

另一个模型则可能检查了错误的子系统，尝试修复后遇到失败，再回溯原来的路径。第二个会话要为更多工具调用、更多推理和更多重复上下文付费。

因此，轮次数量相当于成本乘数。每一个不必要的轮次，都携带着新内容和已积累的对话。

Anthropic 的示例从一个增长到六倍的上下文开始，并持续了 40 轮。总处理输入远大于最终上下文窗口。

将该示例缩减至 25 轮，能显著降低总输入量。节省来自避免对同一段不断增长的对话进行重复处理。

这也是为什么可靠的测试命令可以降低 Claude Code 的任务成本。模型会直接获得其改动是否有效的信号。

缺少这一信号时，它可能要检查更多文件，或围绕数种推测性解释进行推理。构建命令、单元测试或复现脚本都可缩短这段搜索过程。

工具批处理也能产生类似效果。在一轮中读取多个相关文件，可能避免额外的请求循环，尽管无差别地检索内容会膨胀上下文。

有用的目标不是尽可能少的 Token，而是通向正确且已验证结果的最短可靠路径。

在比较 Opus 5.5 与 Opus 5 时，这一区别尤为重要。较新的模型可能在单轮中生成更多推理，却能在总体上减少所需轮次。

反过来也可能发生。Opus 5.5 始终使用自适应思考，Anthropic 表示它可以在相同标称 effort 级别下进行更多思考。

若开发者只比较单次请求的输出，可能会忽略完整的任务模式。有意义的单位应包括探索、编辑、测试、修正和最终报告。

重试尤其值得关注。一次低 effort 运行若失败后必须重做，成本可能高于一次在更高设置下成功完成的运行。

模型降级也是如此。较小模型可在一次查询中节省 Token，但错误结果可能让主智能体走上一条昂贵的弯路。

Anthropic 的分析将此定义为每项已完成任务的成本。这一衡量方式会奖励准确完成，并惩罚错误起步，即便底层 Token 费率看上去很有吸引力。

对工程团队而言，结论很实际：应计算从范围明确的请求到经过验证的结果的整个循环，而不是只看一次回复或一个上下文快照。

缓存读取带来了最大的价格反转

Opus 5.5 降幅最大的 Token 类别，恰恰是长时间智能体会话最常大量使用的类别。

Opus 5 对缓存读取的收费为其标准输入费率的十分之一。Opus 5.5 将这一比例降至二十分之一。

结合更低的输入费率，这便形成了 60% 的缓存读取降幅。新输入和输出的降幅则较小，为 20%。

因此，缓存占比高的任务会更接近较大的节省幅度。重用上下文很少的短请求，仍会更接近基础 Token 费率的降幅。

Anthropic 的计算器允许读者调整总输入、缓存部分、输出、每日任务量和效率假设。最后一项控制参数代表 Opus 5.5 使用更少 Token 的程度。

将该效率假设设为零，可隔离定价因素。任何额外降幅，都代表了关于模型行为如何改变任务的假设。

这种拆分很重要。费率表可由外部验证，而模型的效率取决于代码库和所要求的工作。

缓存表现同样取决于会话行为。稳定的提示词前缀和连续工作有助于服务复用此前处理过的内容。

若干操作会破坏这一模式。切换模型会使新模型上的首次请求，在不同缓存下处理对话。

通过云服务商或网关更改某些设置，也可能降低复用率。在会话过程中连接新的工具服务器，可能改变提示词结构。

长时间暂停可能会使缓存材料过期。具体影响取决于缓存时长和请求路由方式。

缓存写入带来另一项限制。将新材料写入缓存的成本，高于之后读取它的成本。

该计算器有意在简化比较中排除了缓存写入。这使其有助于理解主要变量，但它并不是完整的账单模拟器。

因此，对大型代码库的首次处理仍可能很昂贵。当后续轮次复用模型已处理的内容时，节省才会逐步累积。

上下文压缩引入了另一项权衡。它会用更短的摘要替换较早的对话材料，从而减少后续请求中重新发送的上下文。

不过，上下文压缩也会创建新的提示词状态。紧接着的请求必须处理该摘要，部分详细上下文可能需要再次检索。

在不相关任务之间清除会话，可防止不再需要的旧上下文跟随新工作。但在同一个连贯任务中清除会话，可能丢弃有用的缓存上下文。

模型切换也会形成类似边界。Anthropic 建议在自然断点切换，此时重建上下文的成本不太可能抵消模型优势。

子智能体进一步复杂化了账单。每个子智能体拥有独立的上下文窗口，并向主对话返回摘要。

这种隔离可将庞大的文件搜索排除在主上下文之外。然而，每个子智能体仍会消耗 Token，且除非另行配置，否则会继承同一模型。

缓存降价有利于长时间、连贯的会话，但这并不意味着无限延长对话就是最优选择。旧指令和无关工具结果会增加每一次后续请求的负担。

团队应同时审视缓存占比和总输入量。较高缓存比例固然有益，但过大的对话仍可能处理过多材料。

管理良好的会话会保持可复用上下文处于可用状态，同时移除无关工作。在智能体工作流中，这种平衡比单次回复式聊天更重要。

Opus 5.5 与 Opus 5 是一项工作负载测试

在团队于自身任务中复现之前，Anthropic 估算的节省仍只是供应商预测。

该公司表示，Opus 5.5 所需的服务算力更少，输出生成速度比 Opus 5 快逾 30%。它还报告称，该模型在多项内部基准测试中表现更强。

这些发现支持了成本效率提升的论点。但它们并不能证明生产代码库会普遍实现成本下降。

基准测试提供的是受控比较，而真实代码库中存在不完整的测试、非典型依赖、内部约定和不断变化的需求。这些因素都会改变智能体的任务路径。

最不确定的变量，是完成等效工作所需的 Token 数量。Opus 5.5 可能避免错误起步，但自适应思考也可能增加某些提示词的输出。

其默认 effort 为 medium，而 Opus 5 默认是 high。若比较接受这两种默认值，改变的不止是模型版本。

迁移指南明确建议重新校准 effort。沿用旧设置可能产生误导性结果。

该模型还引入了行为和集成层面的变化。Thinking 无法关闭，且多种工具调用模式需要更新。

在 Claude API 或 Google Cloud 上使用较早 computer-use 接口的应用，必须迁移至新版工具集。某些强制工具选择配置如今会返回错误。

工具调用之间的进度文本也可能通过 thinking blocks 传送。无法处理这些 blocks 的界面，可能会在执行过程中看似毫无响应。

这些变化不只是迁移细节。请求失败、工具失效或进度显示缺失，都可能导致重试并提高采用过程中的运营成本。

因此，公平的 Opus 5.5 与 Opus 5 测试应保持任务不变，同时记录相关设置。两次运行都需要使用相同的代码仓库状态、验收标准和验证命令。

开发者应测试真实待办事项，而不是玩具式提示词。一个小型语法修改几乎无法揭示 agent 循环、缓存复用或从错误路径中恢复的能力。

合适的候选任务包括可稳定复现的 bug、跨越多个文件的功能，或拥有明确测试套件的迁移任务。

一次运行并不足够。代码仓库状态、工具延迟和模型行为的非确定性，都可能改变任务的执行路径。

三到四组配对任务能够提供更可信的初始样本。较大的团队应按任务类型归类结果，而不是报告一个混合平均值。

团队还必须一致地定义成功。一项生成了看似合理的代码、却未通过测试的运行，不应被算作更低成本的完成。

人工审查时间也应纳入运营分析，即便它不会出现在 token 收据中。难以理解的补丁会在生成结束后继续消耗工程时间。

Claude Code 的最终报告可帮助审查者理解较长的运行过程。Anthropic 将更清晰的结案报告视为另一项潜在效率来源。

这一收益是合理的，但取决于工作负载。团队应衡量审查者是否需要更少的后续提示，或是否花更少时间重建 agent 的操作过程。

独立的公开证据仍然有限，因为 Opus 5.5 在本次分析前仅四天刚刚发布。早期用户反馈尚不足以建立稳定的行业平均水平。

更稳妥的结论应更为有限。Opus 5.5 的公开费率更低，而缓存密集型任务可获得更大的结构性优势。

完成任务所需成本的下降幅度是否接近 Anthropic 的估计，取决于轮次、输出、缓存行为、重试次数以及迁移质量。

如何衡量你自己的 Claude Code 任务成本

`/usage` 命令可利用你的实际会话，将定价主张转化为可重复的测试。

在一个完整任务结束后运行 /usage。/cost 可在 Claude Code 内提供相同视图。

会话区块会报告输入、输出、缓存输入，以及基于目录价计算的估算成本。订阅用户应将该估算视为工作量指标。

它并不是额外的订阅账单。套餐限制与按 token 计费的 API 用量属于不同的计费安排。

首先记录模型和 effort 设置。没有这些细节，两份会话收据可能看似可比，实际却代表不同的运行模式。

接下来，记录任务定义和验收测试。明确的完成条件可避免一次运行比另一次更早停止。

然后检查缓存占比。较长的会话通常应复用其输入中的很大一部分。

较低的缓存占比可能意味着暂停、模型变更、effort 变更或提示词修改，也可能反映任务本身较短或较为碎片化。

将总输入量与观察到的最大上下文进行比较。如果总输入量是后者的许多倍，该会话很可能使用了大量轮次。

这种差异并不自动等于浪费。多步骤工程工作天然需要多次请求，尤其是在测试揭示新信息时。

不过，反复检查相同文件可能表明存在可避免的循环。审查这些重复操作附近的记录，以找出缺失的指令或验证工具。

输出值得单独检查，因为其中包含内部 thinking。若一个小型机械修改产生很高输出，可能说明 effort 过高或存在重复推理。

对于配对测试，应将代码仓库重置到相同的起始状态。先用 Opus 5 运行任务，再用 Opus 5.5 运行，并在后续测试中交替执行顺序。

记录轮次、新输入、缓存读取、输出、耗时、测试结果和所需人工修正。这些字段比单一总量更能解释结果。

仅在收集这些测量数据后再使用计算器。输入真实 token 数量才能得出有价值的费率比较。

第一次计算时，将其效率控制项保持为零。这样可显示公开费率变化对相同 token 工作负载的影响。

随后根据配对运行计算实际观察到的 token 差异。第二种视图将定价与模型的实际行为结合起来。

不要假设未来所有任务都会匹配该样本。应区分调试、功能开发、代码审查、代码仓库搜索和无人值守 agent 运行。

还应按任务类别测试 effort。Medium 可能适合范围明确的日常工作，而棘手故障可能值得使用 high effort。

Low effort 可适用于确定性的修改，但前提是验证能以较低成本发现错误。一次失败的低 effort 尝试会削弱任何表面上的节省。

使用网关的团队还需要额外检查。网关必须保留 prompt-caching 和用量字段，否则内部报告可能误述会话经济性。

Anthropic 的网关文档介绍了集中式用量追踪、预算和请求归因。文档也警告，过时的网关可能阻碍新功能的使用。

大型组织可以利用用量报告按开发者和模型汇总结果。若没有任务结果，仅按用户统计的总量仍然不足。

一个有用的内部指标是将已完成任务与 token 消耗配对。另一个指标则跟踪测试失败或审查者拒绝后发生的重试。

团队可以将简短的实验记录存放在工程决策旁边。可搜索的技术知识库可以保留提示词、设置、结果和迁移发现。

这类记录有助于区分模型变化与流程变化，也能避免每个团队都在缺乏共享方法论的情况下重复相同基准测试。

目标不是将每次会话都优化到最小收据，而是识别出能以可预测成本和审查工作量交付已验收代码的设置。

三个信号将揭示节省是否成立

接下来的考验是，更低的费率能否在日常工程工作中转化为稳定、经过验证的输出。

第一个信号来自真实项目中的配对 /usage 数据。若在调试、功能开发和审查中反复观察到成本下降，将增强每任务成本论点的可信度。

这些比较应公开 token 类别和成功标准。若没有缓存占比、effort 和重试次数，单一标题百分比无法解释究竟发生了什么变化。

第二个信号是长会话中的缓存稳定性。团队应关注 Opus 5.5 是否能在工具调用、上下文压缩和模型切换期间维持较高的缓存复用率。

持续偏低的缓存占比会削弱预期优势。这将表明工作流设计或基础设施阻碍用户获得有利的缓存费率。

第三个信号是迁移后的重试频率。Opus 5.5 改变了 effort 默认值、thinking 行为和多种工具接口。

更少的失败循环将支持 Anthropic 关于模型能更高效完成工作的主张。更多集成错误则可能暂时抵消公开的节省。

开发者还应避免将比较仅限于 Opus 5。较小的 Claude 模型可能依然更适合搜索、日志阅读和低成本摘要。

相关决策是工作负载分配。Opus 5.5 可作为受监督编码的主力模型，而较小模型负责边界明确的信息检索。

高难度、无人值守的任务，若能避免多次失败，使用能力更强的模型也可能合理。成本最低的成功路径，可能从成本更高的模型开始。

Anthropic 的计算器通过揭示估算背后的变量，改善了这一讨论。但它无法替某个具体团队给出最终结论。

在 token 用量相同的情况下，Claude Opus 5.5 的单任务成本更低，尤其是在缓存读取主导输入时。确切降幅仍是一个需要实证回答的问题。

选择一个真实的待办事项，定义其通过测试，并在每个模型上各运行一次。比较 /usage、轮次、输出、缓存占比和审查修正。

在更改团队范围的默认设置前，应针对多种任务类型重复这一过程。若 Opus 5.5 能以更少重试完成任务，费率下降的效果将进一步累积。

如果它消耗更多推理资源或扰乱某项集成，标题式节省将会收窄。接下来一个月的配对生产测量，比任何单一计算器预设都更重要。