一项任务的成本，以及一次重试的成本
你并不是一开始就打算购买数百万个 token。你是为了构建一个功能、完成一次迁移，或者运行一项任务。token 数量只是模型为达成目标所需要的量。
两个每 token 成本相同的模型，在同一项任务上的花费可能相差很大。一个只读一遍代码。另一个读了代码，尝试修复，然后又读一遍。其中每一步都是一轮，而每一轮都会重新发送到目前为止的对话。因此，需要更多轮的模型花费更高，即使单价相同也是如此。
读完这篇文章后，你应该能够回答关于自己工作的三个问题：
- 我的典型任务在 Opus 5.5 上要花多少钱？
- 哪些设置会改变这一点，改变多少？
- 我该如何查看自己的会话用量？
我想事先说明的权衡是：每一种减少 token 消耗的方式，也可能让你付出任务无法完成的代价。降低 effort、使用更小的模型，或者减少上下文，这些当然都能节省 token。但一次重试的成本会超过这些节省。本文试图为每一种权衡标出价格。
这里的一些数字是标价，另一些则是基于标价构建的示例。这些数字是可交互的，所以你可以在阅读时更改输入。这些都是尽力而为的示例，所以请务必查阅我们的文档，并自行核算。
一个任务要花多少钱？
Claude Code 中的一个任务就是一个循环。模型读取对话，调用工具，读取结果，然后再次循环，直到完成。循环中的每一轮就是一次请求。有四件事决定了这个循环的成本。
轮次。每一轮都会重新发送到目前为止的对话。轮次越少，处理的输入就越少。
缓存读取。一轮中重新发送的大部分内容都是模型在上一轮已经看过的文本。这部分按缓存读取计费，价格仅为输入价格的一小部分。
输出 token 类型。这是最贵的 token，价格是输入的五倍。思考按输出计费，因此一个在得出答案的过程中推理更少的模型，成本更低。
模型。每个模型都有自己的价格，列在定价页面上，因此你选择的模型决定了每一个 token 的价格。
我们的示例使用 Opus 5.5 的 API 标价：每百万输入 token 4 美元，每百万输出 token 20 美元，每百万缓存读取 0.20 美元。与下方的计算器一样，这些示例将缓存输入按读取价格计费，其他所有内容按输入价格计费，并且不计缓存写入。token 数量仅为示例说明。
轮次
假设一个任务开始时上下文为 20K tokens，随着模型读取文件和工具结果，增长到 120K。在第 40 轮时，平均每轮发送约 70K tokens。这个任务大约消耗 2.8M 输入 tokens，尽管对话从未超过 120K。如果 90% 从缓存读取，输入成本约为 $1.62。同样的任务在 25 轮内处理约 1.75M tokens，输入成本约为 $1.02。
一轮的成本高于它新增的 tokens，因为它会重新发送之前的所有内容。所以最便宜的一轮就是你不需要的那一轮。
一个能减少轮次的习惯是给模型一种检查自己工作的方式。例如，一个可运行的测试、一次构建，或一个调用该端点的脚本。能够检查自己工作的模型会更早发现自己的错误。
一个能在一次遍历中收集所需内容、并批量执行工具调用的模型，也能减少重新发送的次数。
缓存读取
同样的 2.8M 输入 tokens，如果没有任何来自缓存，成本为 $11.20。在 90% 命中率下成本为 $1.62，在 96% 时约为 $0.99。没有其他设置能如此大幅地影响输入成本。一个稳定的会话本身就能保持高命中率。我在本文后面会介绍一些避免破坏缓存的注意事项。
输出 tokens
在 Opus 5.5 上，一个输出 token 的成本是一次缓存读取的 100 倍。一个典型任务的 60K 输出 token 花费 $1.20，与从缓存中读取 6M token 相同。输出包含思考过程。即使 Claude Code 只向你展示摘要，你也要为全部内容付费。这就是为什么 effort（主要改变模型思考量）会让账单变化如此之大。
模型
缓存读取更便宜的模型主要有利于长会话。输出更便宜的模型主要有利于需要大量推理的任务。
Opus 5.5 有哪些变化
有两处变化：价格，以及模型完成的工作量。
每一条价格线都更低了。输入和输出 token 比 Opus 5 便宜 20%。缓存读取便宜 60%。输入价格下降，读取费率也随之下降，从输入价格的十分之一降至二十分之一。图 A 比较了两个模型每百万 token 的价格。这些是 API 标价。在 Pro、Max 或 Team 套餐上，Opus 5.5 更低的价格会传递到你的限额上，包括缓存上下文，因此它们比 Opus 5 大约多出 25% 的可用量。缓存读取的额外降价属于 API 价格变动。
在使用 API key 的情况下，缓存读取降价对 Claude Code 影响最大。一个长时间运行的智能体会话将大部分输入花在缓存读取上。在下方图 B 所定价的会话中，缓存这一行从 $1.00 降至 $0.40，是账单上降幅最大的一项。
你能节省多少取决于你工作的形态。一个以缓存读取为主的会话，在输入上最多可节省 60%。一个没有缓存、答案很长的简短提问，最多可节省 20%，因为输出占了大头。大多数 Claude Code 任务介于两者之间。下面的计算器会显示你的任务处于哪个位置。
Opus 5.5 可以在一个回答上使用更多 token，因为它在回复前总会先思考。我们预计人们用 Opus 5.5 能完成更多工作，但这因任务而异，所以要在你自己的工作上衡量。图 C 比较了两个模型上每个任务的成本。这一部分取决于你的工作，远甚于取决于价格。
在一个范围明确的任务上，两个模型完成的轮数大致相同，价格下调就是你得到的全部好处。差距应该在开放式任务上最大，因为模型可能在一个错误的想法上耗费很多轮。没有哪个单一数字适用于所有代码库，所以要实际衡量（见最后一节）。
长时间运行以一份报告收尾。 Opus 5.5 在长时间运行结束时，会说明它改动了什么、发现了什么，以及需要你提供什么。这也能省钱，因为当你能看清发生了什么时，你重跑会话的次数就会更少。
相同任务并排对比
图 B 对同一个会话在两个模型上按相同的 token 数量计价。所以差异只来自价格变化，别无其他。切换模型即可对比。token 数量仅为示意。
$3.50
按 Opus 5 的标价
图 B。
两个模型使用相同 token 的示例会话，因此这仅反映价格变化。
图 B。两个模型使用相同 token 的示例会话，因此这仅反映价格变化。
这张账单包含 /usage 为一次会话显示的三行。按 token 计，缓存读取是最大的一行，达 2M。按 token 计，输出是最小的一行，但按成本计却是最大的一行。全新输入介于两者之间。它涵盖每个文件的首次读取以及每个新的工具结果。
图 B 给两个模型相同的 token 数量，因此它仅反映价格变化。你自己的会话在 Opus 5.5 上可能使用更多或更少的 token。按这种方式计价，该会话的成本大约低 31%。
一次实际记录的运行还会叠加第二个效应，即模型工作量多少的变化。在一个出现起步失误的任务上，差距应该会拉大。试试你自己的数字
设定你某个任务的使用量，或从预设值开始。这些预设值颇具示意性，但我仍然建议你自己算一算。缓存输入按缓存读取价格计费，全新输入按输入价格计费，因此缓存滑块展示了差距中有多少来自缓存读取。
要从真实会话中填充这些滑块，请在任务结束时运行 /usage。Session 区块会给出输入、输出和缓存的数据。最后一个滑块是你对 Opus 5.5 在你的任务上能减少多少工作量的假设。如果只想看价格变化，就把它留在 0%。
要根据你自己的工作实际来设定它，方法如下：在 Opus 5 和 Opus 5.5 上运行同一个任务，并比较轮次和输出 token。Measure it yourself 会带你走一遍流程，Reading a session 则展示了在 /usage 中该检查什么。
所有轮次中发送给模型的内容，无论是否缓存。
包含思考内容，它按输出计费。
只看价格的话就留在 0%。Opus 5.5 用更少的 token 做更多的事，但这要在你自己的任务上实测。
Opus 5 每任务
–
–
Opus 5.5 每任务
–
–
每任务变化
–
–
一个月按工作日计算。标价。不含批量或批量折扣，且缓存写入不计入（见下方缓存部分）。
最大化会话价值的技巧
Opus 5.5 更低的价格让每个 token 的成本更低。你如何运行一个会话决定了你使用多少 token，以下步骤会有所帮助。
在更换模型之前先提高 effort
Effort 为模型每一轮消耗多少 token 设定了一个总体倾向：它的思考、它写出的文本以及它的工具调用。在较低的 effort 下，它会进行更少的工具调用，并让这些调用更简短。Opus 5.5 有四个级别（low、medium、high 和 xhigh），外加用于单次会话的 max。选择一个级别，查看何时使用它以及设置它的命令。
级别从每轮最少思考到最多思考排列。
Claude Code 会为每个模型设置一个默认级别，/effort status 会显示你的级别。对于范围明确、日常性的工作，可以试试 medium。当 medium 卡住时，试试 high。它每轮的花费比 medium 多，但比换用更大的模型少。对于机械性的工作，比如重命名或在多个文件中应用已知模式，可以使用 low。
一个粗略理解 effort 定价的思路：假设 high 在整个任务中增加 20K 个思考 token。在 Opus 5.5 上，这相当于 $0.40。一个十轮的 retry 循环，使用 100K 的缓存上下文，总共输出 10K token，成本大致相同。所以，如果 high 能在某个任务上省下一次 retry，它就已经回本了。而在一个 medium 本来一次就能完成的任务上，这些开销就白费了。
当 medium 只修复了一层时
你需要更高 effort 的最明显信号，就是修复只停留在某一层。
假设某个字段在 API handler 中被重命名了。在 medium 下，模型更新了 handler，handler 的测试通过了，但客户端仍然发送旧字段。它做了被要求做的事，只是没有读得足够远，去找到第二个调用方。在 high 下，它会在写入之前花更多轮次阅读调用点，并在一次操作中同时修改两层。
检查也能捕获同样的 bug。如果模型能运行一个经过客户端的测试，那么在 medium 下，旧字段在写入的那一轮就会让该测试失败。所以，在提高 effort 之前，先检查模型是否有办法验证自己的工作。一次测试运行只花费一轮及其输出。而更高的 effort 会给每一轮都增加思考开销。
如果升级 effort 等级并增加检查都不奏效，那就换一个更大的模型。
在会话中途更改 effort
在 Claude Code 中，运行 /effort 并带上一个级别，例如 /effort high。/effort status 会打印当前级别。你可以在任务进行中更改它，新级别会应用于下一个请求。
更改 effort 或 thinking 设置会清空缓存的对话，因为这些设置是缓存所匹配的提示词的一部分。下一个请求将按整段对话支付缓存写入的费用。
为你的工作选择合适的模型
模型选择决定了一次会话中每个 token 的价格，因此它对账单的影响比 effort 更大。它的影响范围也更广。每一个继承主模型的子智能体也会继承它的价格。大多数日子需要三种模型：一个用于查询的小模型，Opus 5.5 用于你密切监督的工作，以及一个更大的模型用于最难的任务。
将 Opus 5.5 作为日常主力
将 Opus 5.5 用于你监督的工作：跨几个文件的功能开发、调试，以及带有后续修改的代码审查。你阅读它的所作所为，并在它偏离时介入，从而让循环保持简短。升级到 Fable 5.1
当结果比 token 价格更重要时，就升级到 Fable 5.1。例如你不会全程监督的长时运行、代码库中没有现成模式可循的问题，以及需要协调多个子智能体的大型改动。不要等到第三次失败才行动。如果 Opus 5.5 在 high 档位下两次遇到同一个问题，就切换过去，等问题解决后再切回来。对于交互式工作，Opus 5.5 更合适，因为它延迟更低、成本更少。
Fable 5.1 的标价是每百万输入 token 10 美元、每百万输出 token 50 美元，是 Opus 5.5 价格的 2.5 倍。其缓存读取费用为每百万 0.25 美元，仅为 Opus 5.5 费率的 1.25 倍，因为缓存读取按其输入价格的 0.025 倍计费。因此，这一差距在长时间、缓存密集的运行中最小，而在大量写入的任务中最大。
在自然的断点处切换。缓存属于上一个模型，因此预计在新模型上的第一轮会按写入价格对整段对话计费。先运行 /compact，或者用一个简短的书面计划开启新会话，以缩小那一轮的开销。运行 /model 并带上别名或模型名称即可切换。/model 还会把你的选择保存为新会话的默认值，所以当困难的部分完成后就切回来。
为查询类任务降级
为查询类任务降级到 Sonnet 或 Haiku，而不是为写代码降级：用于搜索和总结的子智能体、读取日志和测试输出，以及"这个定义在哪里"之类的问题。对于跨多个文件的机械式编辑，保留 Opus 5.5 并将 effort 设为 low。这样编辑仍由为你编写其余代码的模型完成，同时每轮成本更低。
要把子智能体放到更小的模型上，可以在其定义中设置 model: haiku 或 model: sonnet。要把所有子智能体都放到同一个模型上，可以设置 CLAUDE_CODE_SUBAGENT_MODEL 环境变量。子智能体定义中指定的模型会覆盖该变量。没有设置模型的子智能体会运行在你的主模型上，除非设置了该变量。
每个子智能体都在自己的上下文窗口中运行，并返回一份摘要，因此它读取的文件不会进入你的主对话。它仍然要消耗自己的 token，所以模型设置决定了这笔开销的成本。
代价是：一个小模型如果误读了搜索结果，就会让主模型去追错误的文件，而主模型要为这段弯路付出代价。把小模型用在出错容易发现的工作上，比如查找文件、运行测试和读取日志。
把需要判断的决策留给主模型。opusplan 别名以另一种方式拆分工作：Opus 在计划模式下做规划，Sonnet 执行计划。这就把代码编辑交给了 Sonnet，与上面的建议正好相反。在把它设为默认之前，先在你自己的任务上实测一下。
迁移时检查你的提示词
为旧模型编写的指令可能会让 Opus 5.5 写更多内容并重复调用工具。在 Claude Code 中运行 /claude-api prompt-audit，检查你的 Claude Code 配置（例如你的技能和 CLAUDE.md 文件）是否存在这些提示词反模式。它还会检查你在 Claude Platform 上构建的应用的代码。
我们在一次从 Opus 4.8 迁移到 Opus 5.5 的过程中测试了这一点，使用了一个内部客户支持基准，包含 44 张工单，其提示词中包含若干这类模式。迁移到 Opus 5.5，在低 effort 下，将该基准的成本削减了约 18%。
运行 prompt-audit 又进一步削减了 9%，降至比 Opus 4.8 起点低约 25%。该审计移除了那些让模型写更多内容并重复工具调用的仪式性指令：一个强制性的六步流程、一条草稿本规则、一条验证两次规则，以及相互矛盾的指令。
该结果来自单一基准，因此请将其视为一个示例，而非一个可以预期的数字。运行审计，然后在真实任务上对比审计前后的 /usage（参见自行测量）。
缓存与压缩
Claude Code 会为你处理缓存与压缩。你如何运行一个会话，决定了它们能节省多少。
缓存如何工作
Claude Code 会缓存请求中重复的部分，例如系统提示词、工具定义以及到目前为止的对话。
在 Opus 5.5 上，一次缓存读取的成本是全新输入 token 的 5%。写入缓存的成本比全新读取更高，按当前定价，五分钟缓存为输入价格的 1.25 倍，一小时缓存为输入价格的两倍。每次命中都会免费重置生命周期。
在 Claude Code 中，生命周期取决于你的付费方式。使用 Claude 订阅时为一小时。使用 API key 或云服务商时默认是五分钟，而订阅一旦开始消耗用量额度，也会降为五分钟。
在 120K token 的上下文下，Opus 5.5 上一次五分钟写入的成本约为 $0.60，一次读取约为 $0.02。一次写入的成本相当于 25 次读取。使用 API key 时，一次六分钟的咖啡休息会把下一次 $0.02 的读取变成 $0.60 的写入。同样规模下一小时写入的成本约为 $0.96，而在 API 上你可以支付这笔溢价来覆盖一天中的空档。
会话形态与命中率
缓存存储的是一个前缀，因此它只能复用请求中从开头起与上一次请求相匹配的那部分。
一个稳定的会话会在每一轮把内容追加到对话末尾，从而保持较高的命中率。任何改动请求较早部分的操作都会降低命中率。更改工具定义会清空整个缓存，而更改系统提示词会从该点起清空缓存，这几乎就是全部内容。
在实践中，以下情况预计会发生缓存写入：
- 你暂停的时间超过了缓存生命周期；
- 你更改 effort 或 thinking 设置（参见 effort 部分），这可能会清空缓存的对话；
- 你连接或断开某个 MCP server，这会改变每次请求开始时加载的内容；
- 你切换模型，因为新模型会从空缓存开始；以及
- 对话被压缩，这会重写缓存所匹配的历史记录。
因此，在会话开始时就把这些设置好，并在会话运行期间不要改动它们。
为什么长会话每一轮的成本更高
每一轮都会重新发送整个上下文，因此随着上下文增长，每一轮的成本也会增加，即使缓存是热的也不例外。在上下文为 20K tokens 时，一轮的缓存读取在 Opus 5.5 上花费约 $0.004。在 150K 时花费约 $0.03，而在这个规模下进行 30 轮，仅读取一项就要花费 $0.90。
同样的 30 轮在 20K 时花费约 $0.12。在 Claude 4.6 及之后的模型上，更大的上下文窗口不会改变每 token 的价格，因此成本完全来自重新发送对话。
这些上下文中有很大一部分是早先工作遗留下来的：一小时前的堆栈跟踪、你已经处理完的文件、你后来已经修复的某次测试运行的输出。每一轮仍然会把它们全部发送出去。
压缩、/compact 与 /clear
当会话接近其上下文上限时，Claude Code 会总结较早的历史记录，以便后续轮次发送更少的内容。运行 /autocompact 并附带一个 token 数量，可以更改在触发该操作之前上下文达到多满。
有两个命令可以让你自己完成这件事。/clear 会清空对话且不产生任何费用，因此当你转向无关的工作时使用它。/compact 会保持连续性，并消耗一次请求。它会读取它所总结的对话，你可以说明要保留什么，例如 /compact keep the failing test names and the schema change。
在 150K tokens 时进行压缩的大致价格约为 $0.25。这包括读取、几千个输出 token 的摘要，以及在更短上下文上的一次新的缓存写入。之后每一轮在读取上大约节省 $0.025，因此压缩大约在十轮之内就能收回成本。在你即将完成之前才进行压缩，花费会超过它节省的。
摘要还会丢失细节。在调试会话中途进行压缩，可能会丢掉那一条至关重要的日志行。在自然的停顿处进行压缩，而当下一步取决于某个具体内容时，在 /compact 指令中说明它。
在你输入之前加载了什么
你的 CLAUDE.md 文件会在每次会话开始时加载到上下文中，因此其中的每一行都会成为每一轮重新发送内容的一部分。成本文档建议将其控制在 200 行以内。MCP 工具定义是延迟加载的。会话开始时只加载工具名称和服务器指令，完整定义会在其工具被使用时才加载。运行 /mcp 可以查看已连接哪些服务器，并关闭你未使用的那些。
账单的其余部分
该表格列出了影响 Claude Code 会话的其他计费规则，并在有文档可查时附上文档链接。
自己动手测量
本文中的数字仅为示例。你的代码库、提示词和习惯各不相同，因此请在你自己的任务上测量成本。以下是检查方法。
- 在会话中，运行 /usage。 /cost 的作用相同。Session 区块会显示 token 使用量和按标价估算的美元成本。prompt-cache 一行会显示你的输入中有多少来自缓存。在 Pro、Max、Team 或 Enterprise 套餐下，同一屏幕会显示你的套餐用量条。美元数字是在你的机器上按标价计算得出的，因此在订阅套餐下，它只是你做了多少工作的参考，而非账单。
- 把同一个任务跑两遍。 从你的待办清单里挑一件事，别用玩具示例。用 /model 在 Opus 5 和 Opus 5.5 之间切换。记录每次运行的轮数、输出 token 和成本。做三到四个任务之后再下结论。
- 对于团队，使用用量和成本报告。 Claude Code Analytics API 给出每个用户的预估成本。Usage and Cost API 按模型以及缓存与未缓存 token 拆分支出。
- 试试努力程度阶梯。 把一个困难任务分别用 medium 和 high 跑一遍。把一个机械性任务用 low 跑一遍。
解读一次会话
在任务结束时，检查 /usage 里的三件事。
- 缓存占比。 对于长时间会话，它应该很高。如果很低，找找是否有长时间停顿、努力程度或模型发生切换，或者中途连接了某个 MCP 服务器。
- 输出与输入之比。 一个小小的改动却产生大量输出，通常意味着努力程度对该任务来说过高，或者模型在反复重试。
- 总输入与对话规模之比。 如果总量是对话规模的许多倍，说明这次会话经历了很多轮，值得读一读这段对话，找出循环重复的地方。
作为基准参考，Claude Code 的成本文档给出了企业部署的平均值：每位开发者每个活跃日约 $13，而 90% 的用户每个活跃日低于 $30。如果某次会话的成本远高于你自己的正常水平，那就值得复盘一下。
请记住
- 对于范围明确的日常工作，使用中等投入强度。
- 给模型一种检查自己工作的方法，并在计划模式下开始跨文件的更改。
- 当中等档位停滞不前时，把投入程度提升到高。在休息时更改，因为这一更改可能会产生一次缓存写入的开销。
- 如果高投入档位两次遇到同一个问题，就切换到 Fable 5.1。问题解决后再切换回来。
- 把搜索和日志读取子智能体放在 Sonnet 或 Haiku 上。代码编辑保留在 Opus 5.5 上。
- 让长会话持续进行，这样它的缓存就能保持热态。
- 在不相关的任务之间使用 /clear，在休息时使用 /compact，并注明要保留什么。
- 最重要的一点：在每个模型上运行一个真实任务，并比较 /usage 报告的内容。你自己的数字才是值得信赖的。
希望这篇文章对你有帮助。如果你的额度在 Opus 5.5 上没有比 Opus 5 走得更远，请通过 /feedback 告诉我们。
延伸阅读：有效管理成本 · 模型配置 · 在 Claude Code 中选择 Claude 模型和 effort 级别 · Effort · 提示词缓存 · 最大化你的 Claude Code 会话价值
感谢 Michael Segner、Kacie Jenkins 和 Molly Vorwerck 的审阅。
The cost of a task, and the cost of a retry
You don't set out to buy millions of tokens. You set out to build a feature, finish a migration, or run a task. The token count is whatever the model needed to get there.
Two models with the same cost per token can cost very different amounts on the same task. One reads the code once. The other reads it, tries a fix, and reads it again. Each of those steps is a turn, and each turn resends the conversation so far. So the model that needs more turns costs more, even at the same price.
By the end of this post you should be able to answer three questions about your own work:
- What do my typical tasks cost me on Opus 5.5?
- Which settings change that, and by how much?
- How do I check my own session usage?
The tradeoff I want to share upfront is that every way to spend fewer tokens can also cost you a finished task. Lower effort, a smaller model, or less context can all certainly save tokens. A retry costs more than those savings. This post attempts to put a price on each tradeoff.
Some numbers here are list prices, and some are illustrations built from them. The figures are interactive, so change the inputs as you read. These are best effort illustrations, so be sure to check our docs and your own math.
What does a task cost?
A task in Claude Code is a loop. The model reads the conversation, calls a tool, reads the result, and goes round again until it's done. Each trip round the loop is one request. Four things set what the loop costs.
Turns. Every turn resends the conversation so far. Fewer turns means less input processed.
Cache reads. Most of what a turn resends is text the model saw on the previous turn. It's billed as a cache read, at a small fraction of the input price.
Output token type. The most expensive tokens, at five times the input price. Thinking is billed as output, so a model that reasons less on the way to the answer costs less.
Model. Each model has its own prices, listed on the pricing page, so the model you pick sets the price of every token.
Our examples use Opus 5.5 API list prices: $4 per million input tokens, $20 per million output tokens and $0.20 per million cache reads. Like the calculator further down, the examples bill cached input at the read price and everything else at the input price, and leave out cache writes. The token counts are illustrations.
Turns
Let’s say a task starts with 20K tokens of context and grows to 120K as the model reads files and tool results. At 40 turns, the average turn sends about 70K tokens. That's about 2.8M input tokens for the task, though the conversation never grew past 120K. With 90% read from cache, the input costs about $1.62. The same task in 25 turns processes about 1.75M tokens and costs about $1.02 in input.
A turn costs more than the tokens it adds, because it resends everything before it. So the cheapest turn is the one you don't need.
One habit that can cut turns is giving the model a way to check its work. For example, a test to run, a build, or a script that calls the endpoint. A model that can check its own work finds its mistakes earlier.
A model that gathers what it needs in one pass, and batches its tool calls, pays the resend fewer times too.
Cache reads
The same 2.8M input tokens cost $11.20 if none come from cache. At a 90% hit rate they cost $1.62, and at 96% about $0.99. No other setting moves input cost this much. A steady session keeps a high hit rate on its own. I cover some actions to avoid breaking your cache later in this post.
Output tokens
On Opus 5.5, an output token costs 100 times a cache read. The 60K output tokens of a typical task cost $1.20, the same as reading 6M tokens from cache. Output includes thinking. You pay for all of it, even when Claude Code only shows you a summary. That's why effort, which mostly changes how much the model thinks, moves the bill so much.
Model
A model with cheaper cache reads mostly helps long sessions. One with cheaper output mostly helps tasks that need a lot of reasoning.
What changed in Opus 5.5
Two things changed: the price, and how much work the model does.
Every price line is lower. Input and output tokens are 20% cheaper than on Opus 5. Cache reads are 60% cheaper. The input price falls, and the read rate falls with it, from a tenth of the input price to a twentieth. Fig A compares the two models per million tokens. These are API list prices. On a Pro, Max or Team plan, the lower Opus 5.5 price is passed on to your limits, including cached context, so they go about 25% further than on Opus 5. The extra cut on cache reads is an API price change.
On an API key, the cache-read price cut matters most for Claude Code. A long agentic session spends most of its input on cache reads. In the session priced in Fig B below, the cache line falls from $1.00 to $0.40, the largest drop on the receipt.
How much you save depends on the shape of your work. A session that is mostly cache reads can save up to 60% on input. A short question with no cache and a long answer can save up to 20%, because output dominates it. Most Claude Code tasks sit between the two. The calculator below shows where yours sits.
Opus 5.5 can use more tokens on an answer, because it always thinks before it replies. We expect people to get more done on Opus 5.5, but it varies by task, so measure it on your own work. Fig C compares cost per task on the two models. This part depends on your work far more than the price does.
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 (see the last section).
Long runs end with a report. Opus 5.5 closes a long run with what it changed, what it found, and what it needs from you. That can save money too, because you rerun a session less often when you can see what happened.
The same tasks side-by-side
Fig B prices one session on both models with the same token counts. So the difference is the price change and nothing else. Switch models to compare. The token counts are illustrative.
$3.50
at Opus 5 list prices
Fig B.
Illustrative session with the same tokens on both models, so this is the price change alone.
Fig B. Illustrative session with the same tokens on both models, so this is the price change alone.
The receipt has the three lines /usage shows for a session. Cache reads are the biggest line by tokens, at 2M. Output is the smallest by tokens and the biggest by cost. Fresh input sits between them. It covers the first read of each file and each new tool result.
Fig B gives both models the same token counts, so it shows the price change alone. Your own sessions can use more or fewer tokens on Opus 5.5. Priced that way, the session costs about 31% less.
A recorded run adds the second effect, the change in how much work the model does. On a task with a false start, the gap should widen. Try your own numbers
Set what one of your tasks uses, or start from a preset. The presets are pretty illustrative but I’d still recommend doing your own math. Cached input bills at the cache-read price and fresh input at the input price, so the cache slider shows how much of the gap comes from cache reads.
To fill the sliders from a real session, run /usage at the end of a task. The Session block gives input, output and cache figures. The last slider is your assumption about how much less work Opus 5.5 does on your tasks. Leave it at 0% for the price change alone. To set it from your own work, here's how: run the same task on Opus 5 and on Opus 5.5, and compare turns and output tokens. Measure it yourself walks through it, and Reading a session shows what to check in /usage.
Everything sent to the model across all turns, cached or not.
Includes thinking, which is billed as output.
Leave at 0% for price alone. Opus 5.5 does more with fewer tokens, but measure that on your own tasks.
Opus 5 per task
–
–
Opus 5.5 per task
–
–
Change per task
–
–
A month is working days. List prices. No batch or volume discounts, and cache writes are not counted (see the caching section below).
Tips for maximizing the value of your session
Opus 5.5’s lower price makes each token cost less. How you run a session decides how many tokens you use, and these steps help.
Raise effort before you change models
Effort sets a general disposition for how many tokens the model spends on each turn: its thinking, the text it writes, and its tool calls. At lower effort it makes fewer tool calls and keeps them shorter. Opus 5.5 has four levels (low, medium, high and xhigh), plus max for a single session. Pick a level below to see when to use it and the command that sets it.
Levels run from least to most thinking per turn.
Claude Code sets a default level for each model, and /effort status shows yours. Try medium for well-scoped, day-to-day work. When medium stalls, try high. It spends more per turn than medium, but less than moving to a bigger model. Use low for mechanical work, like renames or applying a known pattern across files.
A rough way to think about effort pricing: say high adds 20K thinking tokens across a task. On Opus 5.5 that's $0.40. A retry loop of ten turns at 100K of cached context, with 10K output tokens in total, costs about the same. So high pays for itself on a task where it saves one retry. On a task medium would have finished the first time, it's wasted.
When medium fixes one layer
The clearest sign you need more effort is a fix that stops at one layer.
Say a field is renamed in an API handler. At medium, the model updates the handler, the handler's tests pass, and the client still sends the old field. It did what it was asked. It just didn't read far enough to find the second caller. At high, it spends more turns reading call sites before it writes, and it changes both layers in one pass.
A check can catch the same bug. If the model can run a test that goes through the client, the old field fails that test on the turn it was written, at medium. So before you raise effort, check whether the model has a way to check its work. A test run costs one turn and its output. More effort adds thinking to every turn.
If upgrading effort levels and adding checks doesn’t work, then switch to a bigger model.
Changing effort mid-session
In Claude Code, run /effort with a level, for example /effort high. /effort status prints the current level. You can change it mid-task, and the new level applies to the next request.
Changing effort or thinking settings clears the cached conversation, because those settings are part of the prompt the cache matches. The next request pays the cache-write price on the whole conversation.
Choose the right model for your work
Model choice sets the price of every token in a session, so it moves the bill more than effort does. It also reaches further. Every subagent that inherits the main model inherits its price too. Most days need three models: a small one for lookups, Opus 5.5 for work you supervise closely, and a bigger one for the hardest tasks.
Opus 5.5 as the daily driver
Use Opus 5.5 for work you supervise: feature work across a few files, debugging, and code review with follow-up edits. You read what it does and step in when it drifts, so the loop stays short. Moving up to Fable 5.1
Move up to Fable 5.1 when the result matters more than the token price. For example long runs you won't supervise, problems with no existing pattern in the codebase, and large changes that coordinate many subagents. Don't wait for a third failure. If Opus 5.5 on high hits the same problem twice, switch, and switch back once it's solved. For interactive work, Opus 5.5 is a better fit as it has lower latency and costs less.
Fable 5.1 lists at $10 per million input tokens and $50 per million output, two and a half times the Opus 5.5 price. Its cache reads cost $0.25 per million, only 1.25 times the Opus 5.5 rate, because they bill at 0.025 times its input price. So the gap is smallest on a long, cache-heavy run, and largest on a task that writes a lot.
Switch at a natural break. The cache belongs to the previous model, so expect the first turn on the new model to pay the write price on the whole conversation. Run /compact first, or start a fresh session with a short written plan, to make that turn smaller. Run /model with an alias or a model name to switch. /model also saves your choice as the default for new sessions, so switch back when the hard part is done.
Moving down for lookups
Move down to Sonnet or Haiku for lookups, not for writing code: subagents that search and summarize, reading logs and test output, and "where is this defined" questions. For a mechanical edit across many files, keep Opus 5.5 and set effort to low. The edit stays on the model that writes the rest of your code, at a lower cost per turn.
To put a subagent on a smaller model, set model: haiku or model: sonnet in its definition. To put every subagent on one model, set the CLAUDE_CODE_SUBAGENT_MODEL environment variable. A model named in a subagent's definition overrides the variable. A subagent with no model setting runs on your main model, unless the variable is set.
Each subagent runs in its own context window and hands back a summary, so its file reads stay out of your main conversation. It still pays for its own tokens, so the model setting decides what that spend costs.
The tradeoff: a small model that misreads a search result sends the main model after the wrong file, and the main model pays for the detour. Keep the small model on work where a mistake is cheap to spot, like finding files, running tests and reading logs.
Keep judgment calls on the main model. The opusplan alias splits the work a different way: Opus plans in plan mode, and Sonnet carries out the plan. That puts the code edits on Sonnet, the opposite of the advice above. Measure it on your own tasks before you make it a default.
Check your prompts when you migrate
Instructions written for an older model can make Opus 5.5 write more and repeat tool calls. Run /claude-api prompt-audit in Claude Code to check your Claude Code setup, such as your skills and CLAUDE.md file, for these prompting anti-patterns. It also checks the code of an app you build on the Claude Platform.
We tested this on a migration from Opus 4.8 to Opus 5.5, using an internal customer support benchmark of 44 tickets whose prompt had several of these patterns. The move to Opus 5.5, at low effort, cut the benchmark's cost by about 18%. Running prompt-audit cut it by a further 9%, to about 25% below the Opus 4.8 starting point. The audit removed ritual instructions that made the model write more and repeat tool calls: a mandatory six-step procedure, a scratchpad rule, a verify-twice rule, and instructions that contradicted each other.
That result comes from one benchmark, so treat it as an example rather than a number to expect. Run the audit, then compare /usage on a real task before and after (see Measure it yourself).
Caching and compaction
Claude Code handles caching and compaction for you. How you run a session decides how much they save.
How the cache works
Claude Code caches the parts of a request that repeat, such as the system prompt, tool definitions, and the conversation so far.
On Opus 5.5 a cached read costs 5% of a fresh input token. Writing to the cache costs more than a fresh read, at 1.25 times the input price for a five-minute cache and twice the input price for a one-hour cache, on today's pricing. Each hit resets the lifetime at no charge.
In Claude Code the lifetime depends on how you pay. On a Claude subscription it's an hour. On an API key or a cloud provider it's five minutes by default, and a subscription drops to five minutes once it's drawing on usage credits.
At 120K tokens of context, a five-minute write on Opus 5.5 costs about $0.60 and a read about $0.02. One write costs as much as 25 reads. On an API key, a six-minute coffee break turns the next $0.02 read into a $0.60 write. A one-hour write at the same size costs about $0.96, and on the API you can pay that premium to cover the gaps in your day.
Session shape and hit rate
The cache stores a prefix, so it can reuse only the part of a request that matches the previous one from the start.
A steady session appends to the end of the conversation on every turn and keeps its hit rate high. Anything that changes an earlier part of the request lowers it. Changing the tool definitions clears the whole cache, and a change to the system prompt clears it from that point on, which is almost everything.
In practice, expect a cache write when:
- You pause longer than the cache lifetime;
- You change effort or thinking settings (see the effort section), which can clear the cached conversation;
- You connect or disconnect an MCP server, which can change what loads at the start of each request;
- You switch models, since the new model starts from an empty cache; and
- The conversation is compacted, which rewrites the history the cache matched.
So set these up when the session starts, and leave them alone while it works.
Why long sessions cost more per turn
Every turn resends the whole context, so a turn costs more as the context grows, even with a warm cache. At 20K tokens of context a turn's cache read costs about $0.004 on Opus 5.5. At 150K it costs about $0.03, and 30 turns at that size spend $0.90 on reads alone. The same 30 turns at 20K cost about $0.12. On Claude 4.6 and later models a bigger context window doesn't change the price per token, so the cost comes entirely from resending the conversation.
Much of that context is left over from earlier work: a stack trace from an hour ago, a file you've finished with, the output of a test run you've since fixed. It's all still sent on every turn.
Compaction, /compact and /clear
When a session gets close to its context limit, Claude Code summarizes older history so later turns send less. Run /autocompact with a token count to change how full the context gets before that happens.
Two commands let you do this yourself. /clear empties the conversation and costs nothing, so use it when you move to unrelated work. /compact keeps continuity and costs one request. It reads the conversation it summarizes, and you can say what to keep, for example /compact keep the failing test names and the schema change.
A rough price for compacting at 150K tokens is about $0.25. That's the read, a summary of a few thousand output tokens, and a new cache write on the shorter context. Each later turn saves about $0.025 in reads, so the compaction pays for itself within about ten turns. A compaction just before you finish costs more than it saves.
The summary also loses detail. A compaction in the middle of a debugging session can drop the one log line that mattered. Compact at a natural break, and when the next step depends on something specific, say so in the /compact instruction.
What loads before you type
Your CLAUDE.md file loads into the context at the start of every session, so each line in it is part of what every turn resends. The costs docs suggest keeping it under 200 lines. MCP tool definitions are deferred. Only tool names and server instructions load at the start, and a full definition loads when its tool is used. Run /mcp to see which servers are connected, and turn off the ones you aren't using.
The rest of the bill
The table lists the other billing rules that affect a Claude Code session, with a link to the docs where one exists.
Measure it yourself
The figures in this post are illustrations. Your codebase, prompts and habits are different, so measure cost on your own tasks. Here's how to check.
- In a session, run /usage. /cost does the same thing. The Session block shows token use and an estimated dollar cost at list price. A prompt-cache line shows how much of your input came from cache. On a Pro, Max, Team or Enterprise plan, the same screen shows your plan usage bars. The dollar figure is computed on your machine at list price, so on a subscription it is a guide to how much work you did, not a bill.
- Run the same task twice. Pick something from your backlog, not a toy example. Use /model to switch between Opus 5 and Opus 5.5. Note turns, output tokens and cost for each run. Do three or four tasks before you draw a conclusion.
- For a team, use the usage and cost reports. The Claude Code Analytics API gives estimated cost per user. The Usage and Cost API breaks spend down by model and by cached versus uncached tokens.
- Try the effort ladder. Run one hard task at medium and then at high. Run one mechanical task at low.
Reading a session
Check three things in /usage at the end of a task.
- Cache share. For a long session it should be high. If it's low, look for a long pause, a change of effort or model, or an MCP server connected partway through.
- Output against input. A lot of output on a small change usually means the effort level is too high for the task, or the model is retrying.
- Total input against the size of the conversation. If the total is many times the size of the conversation, the session took many turns, and the conversation is worth reading to find where the loop repeated.
For a baseline, the Claude Code costs docs give an average across enterprise deployments of about $13 per developer per active day, and under $30 per active day for 90% of users. A session that costs well above your own normal level is worth reviewing.
Keep in mind
- Use medium effort for well-scoped daily work.
- Give the model a way to check its work, and start changes that span files in plan mode.
- When medium stalls, raise effort to high. Change it at a break, since the change can cost a cache write.
- If high hits the same problem twice, switch to Fable 5.1. Switch back once it's solved.
- Put search and log-reading subagents on Sonnet or Haiku. Keep code edits on Opus 5.5.
- Keep a long session moving, so its cache stays warm.
- Use /clear between unrelated tasks, and /compact at a break with a note on what to keep.
- The one that matters most: run one real task on each model and compare what /usage reports. Your own numbers are the ones to trust.
I hope this post was helpful. If your limits don’t go further on Opus 5.5 than on Opus 5, tell us with /feedback.
Further reading: Manage costs effectively · Model configuration · Choosing a Claude model and effort level in Claude Code · Effort · Prompt caching · Maximizing the value of your Claude Code sessions
With thanks to Michael Segner, Kacie Jenkins and Molly Vorwerck for their reviews.