Claude Opus 5 正式发布：每个运营商必须了解的模型 ID 变更、基于 effort 的成本曲线与路由决策

Anthropic 于 2026 年 7 月 24 日发布了 Claude Opus 5。模型 ID 为 claude-opus-5，定价与 Opus 4.8 持平——$5 / MTok 输入，$25 / MTok 输出——但性能大幅提升。如果你一直在 Opus 4.8 和 Fable 5 之间权衡，Opus 5 会改变大多数生产工作负载的路由计算逻辑。

但在切换配置之前，每个路由到 Opus 的运营商需要了解三件事——这些在发布博客中并未置于首位。

API 层面实际发生了哪些变化

各平台模型 ID：

Bedrock 命名规范发生了变化——anthropic.claude-opus-53 与上一版本的 4-8 版本号模式不同。如果你在路由配置中 pin 了 Bedrock 模型 ID，这需要手动更新，而非自动 alias 映射。

Adaptive thinking 默认开启——且会计费。

Opus 5 的 thinking 始终处于活跃状态。你不需要在请求中加入 "thinking": {"type": "enabled"}——那是 Haiku 4.5 的语法。Opus 5（与 Fable 5、Sonnet 5 一样）默认开启 adaptive thinking。对运营商而言，这里有一个关键影响：即使 thinking 内容从未返回给你的应用，thinking token 也会按 output token 计费。 默认的 display 设置为 "omitted"，所以你的响应体中不会包含 thinking 块——但计算已经发生，你需要为此付费。

如果你对 Opus 4.8 的成本做了基准测试，并仅凭定价来推算 Opus 5 的成本，在 thinking 密集型任务上你的估算会有偏差。对于复杂推理和多步骤 agent 工作，模型消耗的 output token 数量会超出你的单请求平均预估。

Effort 参数控制成本与智能的权衡：

Opus 5 提供了 effort 调节能力。根据 Anthropic 的发布数据，在 CursorBench 3.2 上，max effort 下 Opus 5 的得分与 Fable 5 峰值相差不超过 0.5%，但每任务成本仅为后者的一半；在较低 effort 设置下，速度更快、成本更低。这是首款 Opus 层级模型，路由决策不再仅是"选哪个模型"，而是"选哪个模型、设置哪个 effort"。

对于路由团队来说，Claude 层级调用的路由策略现在有三个调节维度：模型选择（Opus 5 vs Fable 5）、effort 级别，以及是否需要将 thinking 内容返回给应用层。

Fable 5 vs Opus 5 路由决策

Fable 5 定价为 $10 / MTok 输入，$50 / MTok 输出——恰好是 Opus 5 的 2 倍。发布声明明确指出：在 CursorBench 3.2 的 max effort 下，Opus 5 与 Fable 5 的峰值得分相差仅 0.5%，每任务成本仅为后者一半。

对于编程 agent 和 agentic 软件工程任务：max effort 下的 Opus 5 在大多数任务上可作为 Fable 5 的近似替代，成本降低一半。Fable 5 仍是正确选择的场景包括：网络安全任务（Mythos 5 是上限）、Fable 5 的 extended thinking 与 Opus 5 的 adaptive thinking 存在本质差异的工作，以及你已经对 Fable 5 输出进行过调优且不想重新验证的场景。

对于知识工作、业务自动化和多步骤 agent 任务——Zapier AutomationBench、ARC-AGI 3、OSWorld 2.0——发布数据显示 Opus 5 在每单位成本完成任务数上超越了所有其他模型，包括 Fable 5。在给定计算预算下，Opus 5 能完成更多任务。

大多数团队的路由策略更新建议：如果你正在将 Fable 5 用于编程或 agent 工作，max effort 下的 Opus 5 值得进行 A/B 测试。如果你正在将 Opus 4.8 用于通用企业工作，高 effort 或 max effort 的 Opus 5 是价格不变的直接升级。

从 Opus 4.8 迁移前需要检查的事项

Token 预算假设已经过时。 由于 adaptive thinking 默认开启且按 output 计费，复杂任务的每请求平均 output token 数量会增加。在更新成本预测前，请重新做基准测试。

Bedrock 路由配置需要手动更新 ID。 anthropic.claude-opus-53 无法通过对历史 Bedrock Opus ID 进行通配符模式匹配来发现。请显式更新路由表，而不是依赖基于模式的版本检测。

Thinking display 默认值已更改。 在 Opus 5 上，display 默认为 "omitted"。如果你的应用之前依赖于 thinking 内容块缺失（这对 Opus 4.8 来说是合理假设，因为它没有 thinking），行为是一致的——但如果你希望将 thinking 内容展示给终端用户或记录用于调试，现在需要在 thinking 配置中显式设置 "display": "summarized"。

Effort 不是免费变量。 较低的 effort 设置会降低成本，但也会降低性能。如果你从没有 effort 参数的 Opus 4.8 切换到低 effort 的 Opus 5，即使是更新的模型，在复杂任务上也可能出现性能退步。请先以 high 或 max effort 测试，再逐步向下优化。

TheRouter 用户应关注什么

对于通过 AI gateway 路由 Claude 调用的团队，具体更新是两条路由表条目：

# Claude API
claude-opus-4-8  →  claude-opus-5

# Amazon Bedrock
anthropic.claude-opus-4-8-v1:0  →  anthropic.claude-opus-53

Vertex AI 和 Microsoft Foundry 使用与 Claude API 相同的 claude-opus-5 字符串。文档涵盖了如何为多云 Claude 部署配置模型 ID 和各 provider 的路由策略。

Effort 参数是请求级别的字段，而非路由级别的字段——你的 gateway 会原样透传。在应用请求中设置它，或在 Opus 5 路由的默认请求模板中指定。

关于此前 Fable 5 vs Opus 4.8 的权衡分析，请参考 Claude Fable 5 上线：新模型 ID、拒绝语义和 token 计费对你路由层的影响。Opus 5 大幅改变了在成本敏感的编程工作负载中倾向于路由到 Opus 的理由。