Claude Opus 5 深度解析：用五档推理强度把算力花在刀刃上

Claude Opus 5 是 Anthropic 面向复杂编程、智能体和企业任务的旗舰模型。它于 2026 年 7 月 24 日发布，核心卖点很直接：以旧版 Opus 的价格，提供接近 Fable 5 的能力。

从价格看，它是 Opus 4.8 顺理成章的升级；但要投入生产，事情没那么简单。thinking 现在默认启用，effort 会改变模型在文本与工具调用上的投入，而沿用旧的输出上限，可能让任务在推理完成前就被截断。

Claude Opus 5 评测：日常高难任务的旗舰首选，而非能力天花板

每天都会遇到的高难任务，优先用 Opus 5；吞吐量和延迟更重要时，用 Sonnet 5；只有当某项任务已经未能通过 Opus 评估，且失败代价高于 2x token 溢价时，才值得上 Fable 5。

Anthropic 对当前产品线的定位也是如此。其现行模型指南建议尚未决定的开发者，先用 Opus 5 处理复杂的智能体编程与企业任务；只有需要当前最高能力时，再升级到 Fable 5。

Opus 5 提供 1 million token 的上下文窗口，以及最高 128,000 token 的同步输出。上下文窗口指模型在一次请求中可以纳入视野的材料，并不保证每个 token 都能获得同等关注。输出上限同时包含隐藏 thinking 和用户可见的答案，这一点在迁移时尤其关键。

模型 ID 是 claude-opus-5。它可通过 Claude API、Amazon Bedrock、Google Cloud 和 Microsoft Foundry 使用。在 Claude 应用中，Anthropic 将其设为 Max 套餐的默认模型，也是 Pro 套餐可用的最强模型。

这不是一份永久有效的模型排名，而是一套能跨越下一次模型发布的路由策略：每次切换都由真实工作负载的证据驱动，而不是对某个模型档位的偏好。

看基准测试，真正该算的是每个成功任务的成本

Opus 5 最有价值的基准结论，不是它赢下了所有项目，而是它往往能用成本更低的一次运行，交付同样可被接受的结果。

Anthropic 公布了 5 项足以影响选择的结果：

• 在 Frontier-Bench v0.1 上，Opus 5 的表现超过 Opus 4.8 的 2 倍，同时单任务成本更低。
• 在 CursorBench 3.2 上，以 max effort 运行的 Opus 5，与 Fable 5 峰值结果相差不到 0.5%，单任务成本却只有一半。
• 在 ARC-AGI 3 上，按照 Anthropic 的对比，其得分是次优模型的 3 倍。
• 在 Zapier AutomationBench 上，以相同单任务成本计算，其通过率约为次优模型的 1.5 倍。即便使用最低 effort，它通过的任务仍多于该对比中的其他所有模型。
• 在 OSWorld 2.0 上，它以略高于三分之一的成本，超过了 Fable 5 最好的计算机操作成绩。

这些都是厂商在发布时公布的结果，不是适用于所有代码仓库、政策文档或浏览器工作流的通用排行榜。它们只能说明一个方向：增加 effort，有机会把更多 token 转化为可被接受的成果。它们无法回答你自己的智能体需要重试几次、答案被人工驳回的频率，或对你的服务等级目标而言，更快但略弱的结果是否更合适。

“每个成功任务的成本”能把这些缺口补上。把每次尝试消耗的 token、工具调用费用、影响产品的延迟和人工审核全部计入，再除以通过验收规则的输出数量。

对编程智能体来说，成功可以定义为测试通过、diff 没有超出范围，并且审核者无需再发起修正轮次就接受结果。对运营智能体来说，成功可以是记录更新正确、在应当审批时发起了审批，并且没有执行缺乏依据的操作。比较 effort 档位之前，评分标准必须先明确最终结果。

模型看起来有多聪明不是指标；以明确成本拿到验收通过的结果，才是。

固定工作负载的成本：$9、$22.50 或 $45

在 token 结构完全相同的前提下，Opus 5 的成本正好位于 Sonnet 5 临时价格与 Fable 5 之间。

假设有 100 个任务，每个任务发送 20,000 个输入 token，并接收 5,000 个输出 token。整批任务共消耗 2 million 个输入 token 和 500,000 个输出 token：

• 按 Sonnet 5 上线初期每百万输入 $2、输出 $10 的费率，总成本为 $9。
• 按 Opus 5 每百万输入 $5、输出 $25 的费率，总成本为 $22.50。
• 按 Fable 5 每百万输入 $10、输出 $50 的费率，总成本为 $45。

这组计算采用 Anthropic 当前的 API 价格。Sonnet 5 的 $2/$10 费率持续至 2026 年 8 月 31 日，之后标准价格将变为 $3/$15。计算未包含提示词缓存、批处理折扣、网页搜索、代码执行、重试，以及模型或 effort 档位造成的 token 用量变化。

在这个小规模案例中，Opus 比 Sonnet 多花 $13.50，Fable 又比 Opus 多花 $22.50。只要 Opus 能避免一次价值超过 $13.50 的修正，整批任务升级到 Opus 的溢价就值得；Fable 则必须避免超过 $22.50 的失败或审核成本，才能证明继续升级合理。

当任务量增至 10,000 个且 token 结构不变时，总成本分别变为 $900、$2,250 和 $4,500。Opus 比 Sonnet 高出 $1,350，Fable 则再增加 $2,250。原型阶段看似无关紧要的路由选择，到了生产规模就会成为明确的预算项。

Fast mode 更能说明其中的区别。Opus 5 在该模式下的运行速度约为普通模式的 2.5 倍，价格则为 $10/$50，是普通模式的 2 倍。上面的 100 个任务会花费 $45，与 Fable 5 的基础 token 总成本相同。只有当响应时间带来的产品价值足以覆盖溢价时才购买，不要把它当成默认加速开关。

Claude Opus 5 推理强度：effort 是策略，不是 token 预算

从 high 开始。它是 Claude API 和 Claude Code 的默认值；Anthropic 也明确说明，显式设置 high 与省略 effort 参数的行为相同。

effort 控制 Claude 为整个响应投入多少工作，涵盖可见文本、thinking、工具调用和函数参数。降低 effort 可以减少 token 消耗和工具活动，提高 effort 则有助于展开更深入的探索。但它始终是行为信号，而非硬性上限，所以即使困难请求设为 low，仍可能触发 thinking。

5 个档位各有明确用途：

low 适合便宜、边界清晰的工作。 用于分类、提取、简单转换，以及输出易于检查的狭窄子智能体任务。让分流智能体判断工单应进入哪个队列，比让它直接解决工单更合适。

medium 是均衡的生产档位。 适合路径已知但输入会变化的常规工具辅助工作，例如汇总客户记录、起草标准回复，或执行定义清晰的操作流程。当 token 成本或延迟成为重点时，它是从默认档位向下调整的第一步。

high 是困难日常工作的默认档位。 适合代码修改、细致分析和多步骤智能体，因为这类任务的错误代价足以支持更审慎的推理。它也是正确的初始测量点，之后每个更高或更低档位都能以此为基准比较。

xhigh 面向长周期任务。 Anthropic 将它用于可运行超过 30 分钟、token 预算达到数百万的智能体或编程任务。当模型需要反复探索、调用大量工具，或在长时间执行中维持计划时，可以选择它。

max 是例外路径。 为追求最高能力，它会取消对 token 消耗的约束。只有在 xhigh 已经失败，或结果价值高到 token 效率退居次要位置时，任务才应进入这一档。

有两个常见误区。

第一，不要用 effort 控制写作长度。Anthropic 文档指出，调整 effort 并不能可靠缩短 Opus 5 的可见回答；想要多长，直接在提示词里说明。

第二，不要让所有看起来很难的任务一上来就用 max。这样既无法得知 high 是否足以通过，也会让后续所有成本讨论都停留在假设。真正有意义的比较，是能稳定达到目标的最低档位，而不是能买到的最高分数。

哪些人该用 Opus 5、Sonnet 5 或 Fable 5

多数采购方不该让所有请求都使用同一个模型，而应确定一个默认选项，再设计一条范围收紧的升级路径。

正在打造智能体产品、已有融资的创始人

容易验证的高吞吐交互用 Sonnet 5；需要规划、梳理冲突上下文，或从工具故障中恢复的环节用 Opus 5。

这类创始人最大的风险，是觉得 Opus 最稳妥，于是每一轮都用它。如果大多数请求都沿着可预测路径运行，溢价就花在了根本不需要旗舰模型的工作上。让低成本路径覆盖更广，把 Opus 留给后果更重的步骤。

复杂编排先从 Opus high 开始。只有当某个已知困难类别的验收率提升，足以覆盖额外 token 用量时，才升级到 xhigh。只有在 Opus 未能完成具有代表性的任务，且业务影响足以支撑 2x 单价时，才把它交给 Fable。

正在统一模型层的中型企业 CTO

把 Opus 5 设为旗舰默认模型，并在策略中明确展示模型路由。这样，工作负载负责人就能说明某项任务为何使用 Sonnet、Opus 或 Fable，以及哪一项评估结果会改变这条路由。

不要只把每个 Opus 4.8 请求的模型字符串改掉，就宣告迁移结束。默认 thinking 会改变输出行为和 token 消耗，现有的 max_tokens 设置、缓存对话设计和验证提示词都需要重新检查。

Claude Sonnet 5 分析是实用的下限参照：只要按当前价格计算，它的输出仍能通过验收，Sonnet 就胜出；Fable 则是上限。除非某个已命名工作负载证明任一边界更优，否则中间地带归 Opus。

正在自动化业务流程的资深运营负责人

当任务跨越系统或政策边界时，用 Opus。读取请求、检查账户、执行规则，再判断是否需要人工批准，比起草摘要更难，因为每一步都会改变下一步的后果。

工具边界清晰、流程稳定时用 medium；如果经常遇到例外、记录含糊或政策文本冲突，则升到 high。即使基准表现很好，不可逆操作也要保留人工审批。更强的模型可以减少例行审核，但不会让问责消失。

只有当任务既异常困难、价值又异常高时，Fable 才可能合理。如果每个结果无论如何都要由人审核，额外的模型溢价，可能还不如改进审核界面划算。

独立技术开发者

产品形态还在变化时，先用 Sonnet 5。困难调试、架构审查和跨文件实现再切到 Opus 5。真正拉开差距的场景，是一次失败会带来高昂的上下文重建成本，而不是小修小改。

跨厂商的整体选择仍是另一件事。GPT-5.6 与 Claude Sonnet 5 不只模型质量不同，执行系统也不同。Opus 5 强化了 Anthropic 的旗舰路线，却不会让编排、工具权限或可观测性变得可以互换。

对这 4 类读者而言，决策拐点完全一致：当实际测得的失败与审核成本超过模型溢价时，再升级。如果还没人测过这笔成本，稳妥的商业决策就是先评估，再升级。

从 Opus 4.8 迁移，有两个会破坏旧行为的变化

把 claude-opus-4-8 改成 claude-opus-5，仍保持相同的 $5/$25 单价，但运行时行为不会原样保留。

第一个变化是 thinking 默认开启。Opus 4.8 可以在请求未启用 thinking 时直接运行；Opus 5 则默认自行决定何时思考、思考多少。由于 max_tokens 同时限制 thinking 和可见答案，一个足以容纳 Opus 4.8 响应的上限，可能会在 Opus 5 智能体完成任务前将其截断。

第二个变化是 thinking 与 effort 的组合规则。如果请求一边关闭 thinking，一边设置 xhigh 或 max，API 会返回 HTTP 400。必须关闭 thinking 时，把 effort 保持在 high 或更低；使用更高 effort 时，则移除禁用 thinking 的字段。

Anthropic 还提醒，关闭 thinking 偶尔会让 Opus 5 把工具调用写进普通文本，或暴露内部 XML 标签，而不是正确发出 tool_use 块。应尽可能保持 thinking 开启，并通过 effort 控制开销。

下面是一段适用于长时间编程或智能体任务的有效 Python 请求：

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-5",
    max_tokens=64000,
    output_config={"effort": "xhigh"},
    messages=[
        {
            "role": "user",
            "content": (
                "Review this repository migration plan. Identify unsafe "
                "assumptions, propose the smallest sound change, and verify "
                "the final plan against the stated acceptance criteria."
            ),
        }
    ],
)

for block in response.content:
    if block.type == "text":
        print(block.text)

64,000 token 是 Anthropic 针对 xhigh 或 max 建议的起始上限，并非每个请求的硬性要求。观察实际用量和完成情况后，再向下调整。

还要预期一些质的变化。Anthropic 表示，Opus 5 往往会写出更长的交付物，在智能体会话中更频繁汇报进度，更主动地委派给子智能体，也更常在没有单独指令的情况下验证工作。这些行为可能很有价值，但围绕 Opus 4.8 较安静的行为构建的智能体界面、日志管道或编排层，或许需要调整。

决定生产账单的 3 个细节

effort、缓存与速度会相互影响。只单独优化其中一项，可能让另外两项表现更差。

在缓存对话内保持 effort 不变

在请求之间更改 output_config.effort，会改变 Anthropic 渲染后的提示词，因此后续请求无法保留已缓存的前缀。系统如果在同一段长对话中反复调高、调低 effort，可能会失去原本期望得到的缓存节省。

依赖缓存的会话，应在开始时选定 effort 并保持不变。后续工作如果需要不同 effort，就路由到新对话；否则，要把缓存未命中计入升级成本。

Opus 5 把可缓存提示词的最低长度，从 Opus 4.8 的 1,024 token 降至 512 token。更短的重复指令因此也能使用缓存，但前提是提示词前缀和 effort 都保持稳定。

为延迟购买 Fast mode，而不是为能力

Fast mode 的速度约为普通模式的 2.5 倍，每百万 token 价格为 $10/$50。它不会把 Opus 变成 Fable。按前面的固定 100 个任务计算，在不考虑缓存或重试前，它会把 Opus 总成本从 $22.50 提高到 $45。

Fast mode 在 Claude API 上处于 research preview 阶段，目前无法通过 Amazon Bedrock、Google Cloud 或 Microsoft Foundry 使用。多云架构不能假设这项速度设置会随模型出现在所有平台。

把新的 beta 控件当作 beta 功能

对话中途工具变更允许应用在轮次之间添加或移除工具，同时保留提示词缓存。该功能使用 mid-conversation-tool-changes-2026-07-01 beta header。

自动回退可以将被分类器标记的 Opus 5 或 Fable 5 请求，交给 Anthropic 推荐的回退模型，而不是直接阻断。默认和显式回退列表使用 server-side-fallback-2026-07-01 beta header。

这两项控件都解决了实际运维问题，但也会改变一次逻辑会话能做什么，以及最终由哪个模型回答。在不可逆工作流中启用前，应测试权限变化、失败处理和输出质量。

上线前完成一次 5 档 effort 扫描

375 次运行足以把对 effort 档位的争论变成路由数据：25 个代表性任务、5 个 effort 档位，每种组合重复 3 次。

之所以需要重复，是因为智能体可能靠运气通过一次，却在下一条工具路径上失败。任务集的内容比规模更重要，既要包含普通工作，也要覆盖已知边界情况，以及过去需要人工修正的失败案例。

如果生产环境依赖提示词缓存，测试期间不要在同一会话中途改变 effort。每个档位都要采用稳定的对话设计，否则缓存未命中会成为无法控制的变量。

一份有用的结果可能显示：medium 足以处理常规账户工作，异常处理需要 high，而某类狭窄的调试任务在 xhigh 下有所改善。这不代表所有任务都该用 xhigh，而是证明应建立 3 条经济性不同的路由。

同一套流程也能判断 Fable 5 是否值回票价。只把 Fable 加入那些 Opus 仍未达到门槛的任务。如果在 100 个任务的示例中，Fable 带来的验收提升不足以覆盖 $22.50 溢价，就继续用 Opus。

Claude Opus 5 的安全边界与 Fable 5 不同

对合规的安全工作而言，Opus 5 的限制比 Fable 5 少，但它并不是不受约束的网络安全模型。

Anthropic 表示，Opus 5 的网络安全分类器触发频率应比 Fable 5 低约 85%。该模型可以在源代码中发现漏洞，但安全防护会阻止基于二进制文件的漏洞扫描、渗透测试和漏洞利用代码生成。在进攻性网络安全和生物学研究方面，它也仍落后于 Mythos 5。

这条边界会直接影响调试与安全智能体。源代码审查也许能够完成，之后的漏洞利用验证却可能被拒绝或改走其他路由。工作流应把拒绝设计成可处理的状态，而不是突如其来的解析器故障。

Cyber Verification Program 为符合条件的企业和研究人员提供限制更少的版本。普通用户在确认获得访问资格之前，不应围绕这条路径规划生产工作流。

Anthropic 的内部行为审计给 Opus 5 的整体不一致行为打出 2.3 分，是其近期模型中的最低值。应把它视为 Anthropic 自有测试集上的证据，而不是取消审批、沙箱或最小权限工具访问的许可。

最终结论

对于新的旗舰工作负载，以及完成分阶段迁移后的大多数现有工作负载，Claude Opus 5 应当取代 Opus 4.8。它价格相同，能力随 effort 提升得更稳定，并在多项关键评估中接近 Fable 5。

但它不该取代所有高吞吐路由上的 Sonnet 5，也不该让 max 成为默认值。真正的经济收益来自路由：便宜且能通过验收的工作交给 Sonnet 或较低 effort，困难的日常工作交给 Opus high，经测量确认的长周期任务交给 xhigh，只有在 Opus 失败确实代价高昂时才用 Fable。

effort 档位的价值，在于把这套策略明确化。在缓存敏感的场景中保持档位稳定，把它作为评估变量，并让每次升级都对应一个有名称、可复现的失败。

想把下一次模型更新也转化成可执行的生产决策？订阅 Newsletter。