Claude Opus 5 vs Opus 4.8：切换后到底会出什么问题

同一批四个小型编程与推理任务，提示词完全一致，每个模型各跑一次，两个模型全都答对了。但 Opus 5 分别消耗了 81、94、407 和 600 个输出 token；Opus 4.8 则是 36、35、103 和 206 个。输出价格同为每百万 token $25。Claude Opus 5 vs Opus 4.8 的迁移就是这样：改模型字符串只要一行，账单和实际行为却远不止一行代码。

文档给出的原因并不是能力差异。Opus 5 默认运行 thinking，而 Opus 4.8 默认关闭，因此同一请求现在会为过去无需付费的推理过程买单。真正左右成本的也不是模型选择，而是 effort。如果你的生产环境已经在跑 claude-opus-4-8，先记住下面几点：

• 有一处明确的 API 破坏性变更。 在 Opus 5 上，thinking: {"type": "disabled"} 与 xhigh 或 max effort 同时使用会返回 400；Opus 4.8 接受这种组合。
• 价格不是变量。 两者输入均为每百万 token $5、输出均为 $25，支出变化只取决于 token 用量。
• thinking 默认开启，max_tokens 依然同时限制 thinking 和可见回复，所以按 4.8 调出的上限，现在可能会截断回答。
• 提示词的风险可能高于代码。 原本要求 4.8 反复核查的指令，会让 Opus 5 过度验证。
• 两个模型都没有被弃用。 它们都处于 Active 状态，因此至少在下一个发布周期内继续使用 4.8 是合理选择。

只改模型 ID，生产环境里会变什么

Anthropic 在迁移指南中称 Opus 5 是“与 Claude Opus 4.8 同价的直接升级版本”。API 表面确实几乎没变：claude-opus-5 是没有日期后缀的固定模型 ID，命名方式与 claude-opus-4-8 一致。但在切换生产流量前，仍有五项必须审计。

1. 在 xhigh 或 max effort 下使用 thinking: {"type": "disabled"} 会返回 400。官方行为变更说明将其列为相对 4.8 的破坏性变更：4.8 中，关闭 thinking 与 effort 无关。验证是按请求执行的，因此即使对话前几轮正常通过，中途提高 effort 也会被拒绝。2. max_tokens 现在必须为 thinking 预留空间。它仍是总输出的硬上限，覆盖 thinking 与最终回复。因此，一个在 4.8 上关闭 thinking、设置 max_tokens: 4096 的任务，切到新模型后上限不变，但推理会占用其中一部分。Anthropic 建议，在 xhigh 或 max 下从 64k 开始设置。3. 要求验证的提示词可能适得其反。Opus 5 会主动检查自己的工作。提示工程指南指出，“加入最终验证步骤”之类的指令会导致过度验证；删掉它们能够“减少浪费的 token，且不损失质量”。一位早期访问用户 Allie K. Miller 也从 effort 设置上遇到了这个问题：“我经常默认使用 high 推理 effort……后来不得不降到 medium。”4. Skill 和 Agent 脚手架可能悄悄漂移，API 却不会报错。Anthropic 表示，Opus 5“无需改动即可很好地适配现有 Claude Opus 4.8 提示词”。但也有团队得到相反结论：Every 的 Dan Shipper 在发布日发文称，“它破坏了向后兼容性……经常会过早停止，或漏掉你的指令”，他们因此从头重建了 skills。这只是一个团队的经验，但也正是你必须重跑评测的原因：日志中没有任何一行会提示你这里出了问题。5. Anthropic 标注的 Opus 5 知识截止日期是 2026 年 5 月，而 4.8 是 2026 年 1 月。系统提示词若硬编码“你的知识截止于 2026 年 1 月，请以检索上下文为准”，现在描述的已经不是正确模型；任何基于这个字符串的日期计算也会随之偏移。

第一项背后还有一个容易踩的坑。关闭 thinking 时，Opus 5 偶尔会把工具调用写进可见文本，而不是输出 tool_use 块；也可能泄露内部 XML 标签。对于 Agent 循环，这些文本会保留在历史记录中，污染后续轮次。Anthropic 给出的缓解方式是：保持 thinking 开启，用更低的 effort 控制成本。

这个请求会返回 400：两种修复方式

下面这份 diff 可以直接对照你的请求体查看问题组合：

# 在 claude-opus-5 上被 HTTP 400 拒绝；claude-opus-4-8 接受。
  {
    "model": "claude-opus-5",
    "max_tokens": 16000,
    "thinking": { "type": "disabled" },
    "output_config": { "effort": "xhigh" }
  }

# 修复方案 A：保留 xhigh effort，让 thinking 运行。提高 max_tokens，因为 thinking 计入该上限。
  {
    "model": "claude-opus-5",
-   "max_tokens": 16000,
+   "max_tokens": 65536,
-   "thinking": { "type": "disabled" },
    "output_config": { "effort": "xhigh" }
  }

# 修复方案 B：继续关闭 thinking，但将 effort 限制在 high 或以下。
  {
    "model": "claude-opus-5",
    "max_tokens": 16000,
    "thinking": { "type": "disabled" },
-   "output_config": { "effort": "xhigh" }
+   "output_config": { "effort": "high" }
  }

涉及 Agent、多文件修改或密集工具调用的任务，建议选方案 A，因为工具调用泄露才是代价更高的失败模式。延迟敏感接口和严格格式抽取则适合方案 B：从 xhigh 降到 high，通常不会损失太多。

切到 Opus 5，实际多了什么

Opus 5 于 2026-07-24 发布。在 Claude Opus 5 vs Opus 4.8 对比中，大家最先看的两项没有变化：价格仍为 $5/$25，上下文窗口仍为 1M token。完整的Claude Opus 5 发布与定价详情已另文说明；真正影响迁移的变化更集中。

规格核验日期：2026 年 7 月 25 日：

除了表格中的变化，还有两点值得关注，但其中只有一点来自基准测试：

• 短提示词现在也能缓存。最小长度从 1,024 token 降至 512 token。因此，在 4.8 上不能缓存的 600-token 系统前缀，在 Opus 5 上命中缓存时每百万 token 的费用为 $0.50，而标准输入是 $5。写入一个 5 分钟缓存条目的价格为每百万 token $6.25，所以这个前缀必须被复用，缓存才划算。
• 能力提升目前只有厂商口径。Anthropic 的公告提供了相对数据，但没有独立复现：Frontier-Bench v0.1 的单任务成本据称“不到” Opus 4.8 的一半，CursorBench 3.2 的成绩距 Fable 5 峰值不到 0.5%，成本则为其一半。公开披露的短板反而更有参考价值：在网络安全和生物学上落后于 Mythos 5。

我们的四项任务无法说明能力上限，因为两个模型全都通过了。在这种小任务上，能力升级看不出来，token 增长却非常明显。

成本怎么算：单价一样，关键是输出量

两个模型的输出价格都是每百万 token $25。因此，在同一渠道、按标价计算时，Claude Opus 5 vs Opus 4.8 的成本问题只剩一个：完成相同任务时各自输出多少 token。我们的四项任务中，Opus 5 总计为 1,182 token，Opus 4.8 为 380 token，比例为 3.1 倍；约为 3.0 美分对 0.95 美分。

这组数字有三个限制：

• 每项任务每个模型只运行一次，时间是 2026-07-24。这只是冒烟测试，不是基准测试。
• 两边都使用默认设置：没有指定 effort，没有 thinking 字段，也没有系统提示词。
• 只统计输出 token，因为网关对某些模型系列报告的提示 token 数量极不一致。绝对金额很小，只有比例具备扩展意义。

而且方向并不完全一致。我们另外通过 Claude Code 第一方渠道，而非网关，重跑了其中两个任务：

这三次里，Opus 5 有一次 token 更低。Anthropic 在最高档位上给出了相反方向的说法：一家法律行业合作伙伴在 max reasoning 下平均少用了 26% token，但没有公开方法论。

这两种现象可以同时成立。默认开启 thinking，加上 Opus 5 的回复更长，会在推理纯属额外开销的场景中增加输出；但在多文件任务中，同一段推理也可能替代反复重试，因此每个完成任务的 token 数可能下降，即便每次调用的 token 数上升。两份数据都没有直接测量这一点，所以应根据你自己的“每个被接受任务的成本”做预算，并把 effort 而不是模型本身当成主要调节杆：

• 先降低 effort。Anthropic 的建议是：Opus 5 的 low 和 medium 设置，以一小部分 token 就能胜过此前 Opus 模型的相同设置；而编程和 Agent 任务仍建议从 xhigh 开始。
• 审计继承下来的默认值。分类接口沿用 xhigh，很可能是你账单上最贵、却没有任何质量收益的一行配置。
• 成本还是高？该考虑换层级。同一预算下比较 Opus 5 与 Sonnet 5，后者是更便宜的分支。

哪些情况下，继续用 Opus 4.8 更合理

本季度以下四种情况，4.8 更值得保留：

• 你持有 Priority Tier 承诺。迁移指南明确指出，Priority Tier 不支持 Claude Opus 5，但 Opus 4.8 仍支持。如果你购买了为延迟保证而预留的容量，迁移就意味着放弃它。这是采购决策，不只是工程决策。
• 某项集成必须在关闭 thinking 的同时使用高于 high 的 effort。如果你的评测需要 xhigh 推理，同时又要求无 thinking 输出，那么目前只有 4.8 能同时满足。
• 你有深度调优的 skills，但本周期无法重新测试。保留一条冻结的 4.8 路径，优于半迁移状态、仍在使用为其他模型编写提示词的 Opus 5 路径。
• 成本压力很大，而且通过中继访问。第三方 OpenAI 兼容网关对旧模型会给出大幅折扣：AIReiter 的 Anthropic 模型列表中，Opus 4.8 价格为每百万 token $1.56/$7.76，比标价低约 69%，而且尚未加入 claude-opus-5。跨访问渠道后，价格对等不再成立；只要 4.8 已经能通过任务，正确且最便宜的模型就是更好的选择。最适合编程的 Claude 模型一文则按任务比较了完整阵容。

不该把“担心即将退役”列进理由。Anthropic 的模型弃用页面在 2026 年 7 月 25 日将两者都标为 Active，而非 Deprecated，意味着均未安排退役。暂定最早退役日期分别为：4.8 是 2027 年 5 月 28 日，Opus 5 是 2027 年 7 月 24 日。

一套便于回滚的上线顺序

1. 先冻结 4.8 基线。在 20 到 50 个真实请求上记录输出 token、延迟和通过率，作为最低基线；对高波动的 Agent 任务则应增加样本，其中也要包含 4.8 当前会失败的请求。没有这些记录，回归和正常差异看起来没有区别。2. 部署前先 grep。搜索 "disabled" 与 effort 的相邻使用、低于 16k 的 max_tokens 值，以及系统提示词中的“verify”“double-check”和“January 2026”。四次搜索可覆盖一项破坏性变更和三项静默变更。3. 只开一条流量通道，不要全量切换。将部分流量路由到 claude-opus-5，模型 ID 应放在配置中，而不是散落在代码里。这样回滚只需改配置，无需重新部署。4. 通道上线前，先定义量化晋级门槛。通过率不得低于 4.8 基线；schema 有效性和工具调用合规率也不能低于基线；每个被接受任务的成本不得超过预先设定的上限；p95 延迟必须满足 SLO；400 错误率必须为零。任意一项未达标，就将配置切回 claude-opus-4-8。5. 分别记录请求模型与实际返回模型。在启用服务端回退后，Opus 5 的网络安全分类器可将被拒绝的请求路由回 Opus 4.8。因此，仪表盘上看似由 Opus 5 处理的一次运行，实际可能由 4.8 提供服务。

对大多数团队来说，Claude Opus 5 vs Opus 4.8 的结论是：在一个发布周期内，按这个顺序迁移；只有通过第 4 步门槛、且优于自身 4.8 基线的流量才晋级。第一天就该删除继承下来的验证型提示词，Anthropic 自己的指南也这样建议：这正是 token 增长会变成真实账单的地方。

常见问题

Claude Opus 5 是 Opus 4.8 的直接替代品吗？

Anthropic 的迁移指南称它是在同等价格下的直接升级，从 API 层面看确实如此：上下文窗口相同、128k 输出上限相同，只有一项需要审计的破坏性变更。但在提示词层面并非如此。为 4.8 调过的验证指令、effort 默认值、max_tokens 上限和 skill 定义都需要复查，而且它们不会主动报错。

为什么我的 Opus 5 请求返回 400 错误？

最可能的原因是：你同时发送了 thinking: {"type": "disabled"} 与 xhigh 或 max effort。Opus 5 会对每个此类请求予以拒绝。你可以移除 thinking 字段并保留当前 effort，或者继续关闭 thinking，同时将 effort 降至 high 或以下。所有 4.7 及之后的 Claude 模型，在使用非默认的 temperature、top_p 或 top_k 值时同样会返回 400。

Claude Opus 4.8 会停止服务吗？

不会。Anthropic 的弃用页面将 claude-opus-4-8 列为 Active，暂定最早退役时间为 2027 年 5 月 28 日；其针对公开发布模型的政策是至少提前 60 天通知。它仍是 Opus 5 网络安全类别拒绝请求的回退目标，也继续支持 Opus 5 不具备的 Priority Tier。

现在最好的 Claude Opus 模型是哪一个？

按照 Anthropic 的厂商数据和早期开发者反馈，Claude Opus 5 是当前最强选择，尤其适合 Agent 编程和长周期任务。对于 Priority Tier 工作负载、需要在高于 high effort 下关闭 thinking 的集成，以及暂时无法重新建立提示词基线的场景，Opus 4.8 仍是更好的选择。

如何在 Claude Code 和 Claude 应用中切换到 Opus 5？

Opus 5 是 Claude Max 的新默认模型，也是 Claude Pro 中能力最强的模型；你还可以在 Claude Code、Claude Cowork、claude.ai、Amazon Bedrock（模型名为 anthropic.claude-opus-5）、Google Cloud 和 Microsoft Foundry 中选择它。

Claude Code 默认 effort 为 high，推理深度现在通过 effort 设置，而不再使用手动 extended-thinking 开关。上述平台也仍可选择 Opus 4.8，因此无需改 API 代码即可回滚。

Claude Opus 5 会比 Opus 4.8 更贵吗？

按 token 单价不会：两者均为每百万 token 输入 $5、输出 $25；Batch API 中均为 $2.50/$12.50；缓存命中均为每百万 token $0.50。但按任务计算，我们的单次测试中 Opus 5 输出了约 3 倍 token，因此即便标价相同，最终账单仍可能更高。Fast mode 的价格为 $10/$50，速度约为 2.5 倍，但仅适用于 Claude API。