实测 Claude Opus 5 与 Opus 4.8：标价相同，成本相差 3 倍

Claude Opus 5 和 Claude Opus 4.8 的输入、输出价格相同，分别为每百万 token $5 和 $25。但面对相同 prompt，采用默认配置的 Opus 5 成本高出 3.1 倍。原因在于 adaptive thinking：Opus 5 默认会进行思考，这部分 token 按输出计费，却不会展示给用户。只需调整一项请求参数，就能把成本降至与 4.8 完全相同；但更大的 Fable 5 不接受这个参数。Opus 5 于 2026-07-24 正式 GA，定位是在 token 单价减半的前提下提供 Fable 5 级别的智能。实际账单能否减半，几乎完全取决于这个配置。

TL;DR

• 在五项任务矩阵中，默认 Opus 5 的账单是同价 Opus 4.8 的 3.1 倍；其输出 token 中有 42-95% 属于隐藏思考。
• 设置 thinking: {"type": "disabled"} 后，Opus 5 与 4.8 的成本完全相同（输出 token 均为 384），准确率不变；Fable 5 会拒绝该参数。
• 在 agent 流量中，额外成本缩小至 +33%，工具和批处理场景接近持平：adaptive thinking 在工具循环中很少触发。
• 1M 上下文窗口确实可用（在 969,950 token 处成功召回 needle），缓存下限为 512 token，只有 4.8 的 1,024 的一半。

作为平台，Opus 5、Opus 4.8 和 Fable 5 有何不同？

深入分析成本之前，先看整体差异。这三个当前的 Claude 层级主要在价格和请求形态两个维度上有所区别。下面是并排对比（标注实测的项目来自我们的测试，其余来自模型文档）：

其中三行需要额外说明。thinking: disabled 是迁移时容易踩的坑：根据文档，Opus 5 只在 effort 为 high 或更低时接受该设置；4.8 则将两个配置视为相互独立。迁移脚本应按版本处理。Fast mode 也带来了一个后文很重要的对比：追求速度的 Opus 5 与默认 Fable 5 的价目表完全相同，因此“fast Opus 5 与默认 Fable 5”是在 token 单价相等的前提下，单纯权衡速度与能力。数据保留方面则有一项不显眼但重要的合规优势：Opus 5 能提供 Fable 级别的智能，却不受 Fable 5 必须保留数据 30 天的要求约束。

另有两点不适合放进表格。Anthropic 记录了关闭 thinking 后的一些边界情况，例如工具调用偶尔会被写入可见文本，以及内部标签泄漏。我们在下文 agent 测试套件的 84 次 thinking-off 调用中都没有遇到，但官方说明进一步印证了这条路由原则：工具密集型路由应保留 thinking，毕竟这类请求的额外成本本来就很小。另外，Opus 5 的会话中途工具变更功能（beta）允许在不同轮次之间增删工具，而不会破坏 prompt cache。对于长时间运行的 agent 会话，这能保护我们在 prompt 缓存指南中讨论的缓存前缀成本优势。

默认配置下，Opus 5 比 Opus 4.8 贵多少？

处理相同工作、采用相同价目表时，成本高出 3.1 倍。我们通过原生 Messages API，让当前三个 Claude 层级分别完成五项任务（每个单元 n=3，prompt 加盐），并加入 Fable 5 作为参照：

答案相同，费率也与 4.8 相同，账单却是后者的三倍。Opus 4.8 不会主动思考，除非请求中明确要求；Opus 5 默认开启 adaptive thinking，并以完整的 $25/M 输出费率对思考 token 计费。

Fable 5 一列给出了一个反直觉的结果：尽管其费率是两倍（$10/$50），绝对成本却比默认 Opus 5 低 35%。原因是完成相同任务时，Fable 5 只用了 383 个输出 token，而 Opus 5 用了 1,305 个。三个模型的文档默认 effort 都是 high，因此差距来自思考策略的校准，而不是配置。数据符合两种机制。第一，更强的模型在面对简单答案时，无需投入同样多的推理就能确认结果。文字题上，Fable 5 使用了 52 个 token，Opus 5 使用了 152 个；段落任务则分别为 264 和 1,031。第二，Opus 5 的核心能力之一是 test-time compute scaling，即在困难问题上用更多思考换取更高质量。它的默认校准会为每个请求购买这层保障，哪怕请求根本不需要。对于简单流量，你付费购买了从未使用的保障；Fable 5 大多选择不为它付费。

额外成本花在哪里？

花在你看不到的推理上。将计费输出 token 与可见答案文本进行对比后发现，默认 Opus 5 的输出开销中有 42-95% 属于隐藏思考，而且即使问题完全不需要推理也会触发。例如，17*23 的答案只有 1 个 token，背后却产生了 11 个思考 token；撰写 120 词段落的任务共消耗 1,031 个输出 token，其中约 806 个用于思考。思考内容不会以任何形式返回，既没有摘要，也没有 trace。因此，在我们的 token 用量结构研究中，Opus 5 与 Fable 5 一样，处于可见性最低的一端。你可以在 usage 明细中看到数量，却无法知道这些 token 具体换来了什么。

Thinking 开关究竟有什么作用？

它能让 Opus 5 的账单降到 Opus 4.8 的水平。发送 thinking: {"type": "disabled"} 后，所有任务的思考 token 都归零，总输出 token 与 4.8 完全相同，均为 384；每组成本分别为 $0.01130 和 $0.01120：

先说明一下标签。这里每个模型的 API 文档都将 effort high 定义为默认值，Anthropic 也明确指出，显式指定 high 与省略该参数完全相同。我们的隐式默认组与显式 high 组仍有 16% 的差异，这是写作任务的运行间波动造成的。该任务在我们执行的每批测试中都是噪声最大的单元，不代表两者确有区别。应将这两行视为同一测试组的两次测量。三个模型默认配置的差异不在 effort 级别，而在该级别下 thinking 的行为：4.8 不进行思考，Fable 5 会节制地自适应思考，Opus 5 则会更积极地自适应思考。

有两点很突出。第一，effort 旋钮用于控制质量，不是控制成本。这个档位范围（从 low 到 max）并非新功能，4.8 也支持相同范围。但对于如此简单的任务，low 以上的每个档位只会增加思考量，准确率却完全相同。xhigh 的成本最高，达到 4.8 的 3.8 倍。最高档位是为真正困难的问题提供 test-time compute scaling 的，五项基础检查任务无法验证它的能力收益，但可以展示成本。数据表明，无论如何调整 effort，都无法把成本降至与 4.8 持平。只有关闭 thinking 才能做到，相比默认配置可降低 67%。第二，这个开关本身就是差异化能力。Fable 5 会对 thinking: {"type": "disabled"} 返回 400，因此它是 Opus 5 特有的能力，而不是该模型系列的共同属性。同一个 thinking 对象适用于两个 gateway 接口：/v1/messages 和兼容 OpenAI 的 /v1/chat/completions。在后者中，关闭 thinking 后，completion_tokens_details 内的 reasoning_tokens 会报告为零：

{"model": "claude-opus-5", "thinking": {"type": "disabled"}}

这里必须明确测试的局限性：我们的可核验任务以检索和单步处理为主。关闭 thinking 后，包括多步文字题在内，准确率仍为 9/9。Adaptive thinking 本来就是为更困难的 agent 工作而设计的，因此应按路由决定是否关闭，规则与我们测试 Kimi K3 和 Gemini 3.6 Flash 后得出的结论相同：抽取、格式转换和单步调用应关闭；如果 eval 表明 thinking 的收益足以覆盖成本，则保留默认设置。

Agent 工作负载也会产生 3 倍成本吗？

不会，而这个差异正是关键。在我们的 agent 场景测试套件中，包括工具循环、RAG、工具使用、批处理和长对话，每个测试组运行 50 个 episode。默认 Opus 5 的成本只比 Opus 4.8 高 33%，而不是 210%；工具类场景接近持平，为 1.01-1.22x。在这些场景中，adaptive thinking 确实做到了自适应：agent 循环内每次调用平均约产生 88 个思考 token，而单独的写作 prompt 会产生 806 个。长对话是例外，成本达到 1.58x，此时关闭 thinking 仍能降低开销（关闭后为 1.22x）。函数调用则完全没有思考成本：默认配置下，一次工具调用请求返回 52 个输出 token，没有附带任何思考 token，与非思考模型的 token 预算相同。

因此，实际的划分依据是流量形态，而不是模型。单次补全和对话类调用会承担默认 3 倍成本，适合关闭 thinking；工具密集型 agent 流量大多不需要关闭。

Opus 5 真的只有 Fable 5 一半的价格吗？

只有关闭 thinking 后才是如此。按 token 单价看，确实是 $5/$25 对 $10/$50。但在我们的基础任务矩阵中，默认 Opus 5 每组成本为 $0.03427，Fable 5 为 $0.02233，前者的绝对成本高出 53%。这是因为相同任务下，Fable 5 使用了 383 个输出 token，Opus 5 则使用了 1,305 个。关闭 thinking 后，Opus 5 的成本降至 $0.01130，几乎恰好是 Fable 5 的一半。这样才能兑现发布时的价格承诺，而实现它所需的参数恰恰是 Fable 5 自己不接受的。

上下文、缓存和 tokenizer：我们还验证了哪些内容？

1M 上下文窗口确实可用，超限时也会明确报错。在一个 969,950 token 的 prompt 中，我们将 needle 放在开头，模型在 39 秒内正确召回。对于 1,010,221 token 的 prompt，API 返回清晰的 prompt is too long: … > 1000000 maximum，而不是静默截断。

缓存下限减半。Anthropic 文档说明，Opus 5 和 Fable 5 可缓存前缀的最小长度为 512 token；Opus 4.8 和 Sonnet 5 则为 1,024。我们的扫描结果与文档一致：接近 511 token 的前缀始终无法缓存，547 token 则能稳定缓存。缓存读取价格为 $0.50/M（0.1x），写入价格为 1.25x，TTL 为 5 分钟。现在，更短的 system prompt 也可以缓存，这对高 QPS 路由有实际影响。

Opus 5、Opus 4.8、Fable 5 和 Sonnet 5 使用的 tokenizer 没有变化。在多语言和代码样本中，它们的 token 数完全相同，因此各语言的预算和 prompt 大小估算都可以直接沿用，无需重新建立基线。

常见问题

Claude Opus 5 可以关闭 thinking 吗？

可以，但 effort 必须为 high 或更低；文档说明，与 xhigh 或 max 组合会返回 400。在我们的测试中，关闭 thinking 后思考 token 降至零，成本与 Opus 4.8 持平（任务矩阵中的输出 token 均为 384）。这是 Opus 5 特有的行为：无论 effort 为何，Fable 5 都会对相同参数返回 400。Effort 旋钮（从 low 到 max）同样有效，但无法让成本持平。在我们的矩阵中，相对默认配置，low 可降低 21%，xhigh 则增加 24%。

为什么 Opus 5 与 Opus 4.8 标价相同，我的账单却更高？

因为 Opus 5 默认会进行思考，而且思考 token 按 $25/M 的输出价格计费。在我们的基础 prompt 测试中，计费输出里有 42-95% 属于隐藏推理；一道两位数乘法题的答案只有 1 个 token，背后却产生了 11 个思考 token。可以从 usage 明细中读取 reasoning_tokens，查看它在实际流量中的占比，并在不需要思考的路由上关闭该功能。

Agent 工作负载应该关闭 Opus 5 的 thinking 吗？

通常不应该。在我们的 agent 测试套件中，默认配置的成本只比 Opus 4.8 高 +33%；工具和批处理场景接近持平，因为 adaptive thinking 在工具循环中很少触发。长对话类会话是例外，成本达到 1.58x，此时关闭 thinking 仍然划算。应根据自己的流量组合进行测量；额外成本主要出现在单次补全，而不是工具调用。

测试时间为 2026-07-25 至 2026-07-27，通过 Synthorai gateway 对 claude-opus-5、claude-opus-4-8 和 claude-fable-5 进行测量：五项任务矩阵及 effort/开关消融测试来自同一标准批次（每个单元 n=3，prompt 加盐，使用原生 Messages API）；agent 数据来自包含 150 个 episode 的场景测试套件；上下文和缓存数据来自 needle recall 与前缀扫描；API 形态相关项目（prefill、开关接受情况）来自直接请求测试。准确率仅统计答案唯一且可核验的任务。价格和行为可能发生变化，请以自己的 usage 记录为准。

← 返回博客