Theo 评测 Opus 5：编程风格、成本与模型取舍

Opus 5 发布了，使用它编程一天后，我印象很深。它在多项基准测试中表现出色，每个 token 的价格也低于 Fable 5。我认为它可能成为我许多任务的实用默认选择，但这是早期个人判断，并不能证明它适合所有人。

Anthropic 将 Opus 5 描述为适合日常使用、智能水平接近 Fable 的模型，称其编程和知识工作表现强，但网络安全能力低于 Mythos。我此前猜测 Kimi 的比较导致它延期；现在看到的数字不支持这一猜测，因此我改变了看法。

按发布时介绍的方案，Anthropic 将 Opus 5 设为 Max 默认模型，也是 Pro 中最强的模型。Fable 的订阅访问限制不同。这些方案细节和价格只反映视频录制时的情况，日后可能改变。

Anthropic 的图表显示，Opus 5 在 Frontier-Bench 上得分 43.3%，高于所列 GPT-5.6 Sol 的 34.4%。我最初把 Frontier-Bench 与 FrontierCode 混淆了；我所说关注可维护性和可合并性的是后者。这是两项不同的评测，单一分数无法决定模型在你的代码库中表现如何。

展示的评测还包括知识工作、ARC-AGI-3 和智能体搜索。Opus 在报告结果中表现不错，但这些测试衡量的是不同能力。例如，ARC 分数还考虑效率，并不只是统计答对多少题。

在 Humanity’s Last Exam 中，报告的比较结果会随是否允许使用工具而变化。我认为这体现了已有知识与借助工具完成工作之间的区别。我也怀疑 OSWorld 是否准确反映了自己实际体验中的计算机操作差异。

展示的表格中，Opus 在 DeepSWE 上落后于 Fable 和 Sol。我也纠正前面混淆的基准：Frontier-Bench 来自 Terminal-Bench 和 Harbor 团队，而我对代码可合并性的评论说的是 FrontierCode。在后者上，图表中的 Fable 与 Opus 分数非常接近。

按视频中展示的价格，Opus 5 每百万输入 token 为 5 美元、输出为 25 美元；Fable 5 分别为 10 美元和 50 美元。单价虽然减半，实际任务成本仍取决于每个模型消耗多少 token。

图表显示 Opus 可能以更低成本取得有竞争力的分数，但只看金额会掩盖 token 消耗。在我引用的一项 Artificial Analysis 比较中，Fable 每任务约用 3.3 万个 token，Opus 约用 3.7 万个。这只是该测试的结果，并非所有工作负载都遵循的固定比例。

输出和推理 token 更多，可能意味着任务更慢、上下文消耗更快。我引用的比较显示，Fable 平均每任务约 2.75 美元，Opus 约 2.03 美元，降幅接近四分之一而非一半。实际节省和延迟取决于工作负载、配置及服务商。

我喜欢 Opus 的主要原因更简单：我实际用过，而且喜欢结果。T3 Code 中的 Claude 模型列表原先采用硬编码，因为现有清单不够好。我希望动态发现模型，这样新增模型就不需要手动添加并重新发布。

我给 Opus 5 和 Fable 同一个请求，让它们调查并规划解决方案。两者都写出了计划，但 Claude Code 自动模式阻止了两个会话的计划上传命令，即使我重复说明意图也一样。我只能自己上传；这反映的不只是模型，还有工具和安全配置。

上传计划后，我让两个模型互相审阅。两者一开始都更偏好对方的方案：Fable 给自己的方案打 7.8 分，给 Opus 的打 8.2 分；Opus 则以较小差距偏好 Fable。模型为计划打分可以提供反馈，但不是客观真理。

我让它们根据彼此的意见修改计划，再次审阅。各项详细评分与总体偏好并不总是完全一致，但这个过程暴露了研究、故障处理和实现方式上的差异。最后我让 Opus 按自己的计划实现。

我还让 Sol 在简短标签下审阅两份计划。它在这次比较中给 Opus 方案打了 8.3 分，Fable 打了 6.0 分。这让我惊讶，也让我认为 Opus 可能在 Fable 的思考风格和 Sol 的坚持程度之间取得平衡；但这仍只是一次个案。

Anthropic 报告称，Opus 5 在部署前对齐评估中表现良好，包括欺骗行为和受诱导滥用的指标。这些是公司报告的评测结果，不能保证模型在所有场景下都安全。我仍然批评其宪章的一些内容。

有些人认为，Opus 基准表现良好却比 Mythos 限制更少，这自相矛盾。我的假设是，训练可以转移期望的行为，同时降低某些危险能力。师生类比只是帮助理解，并不能证明具体的私有训练流程或安全结论的强度。

我反对一种假设：选更小的模型就一定能节省 token。在我讨论的图表中，模型能力与 token 效率并不总是同步变化：更强的模型完成任务时可能用更少 token。在某些场景下路由仍能降低成本，但必须在实际工作上测量。

Theo 表示，报告的安全评测显示 Opus 仍能帮助寻找漏洞，但利用漏洞的能力低于能力最强、受限制的模型。他认为这是一个有希望的取舍。特定测试结果并不能证明所有有害能力都已消除。

在另一个远程开发任务中，Opus 花了很长时间规划，实施约用了四小时；Fable 在六小时后仍在运行。我为比较消耗了大量用量，但最终的拉取请求看起来不错。这是单个任务的观察，并非通用速度基准。

由于大量使用 Fable，我同时保有多个订阅。视频录制时，Fable 的每周额度仅占订阅总额度的一部分。在我的账户中，Fable 额度已经耗尽，但其他模型仍可使用部分每周总额度。

在一个账户上，我用 Opus 工作一天后，每周剩余额度从约 50% 降到 38%；而 Fable 实验消耗了多个账户的更多额度。这反映的是我的使用方式和订阅计量，不是严格控制条件下的成本比较。订阅限制及其计算方式可能变化。

我使用 Opus 的第一个理由是成本和额度的实际组合。单看 token 效率，我在某些设置下仍更喜欢 Sol；但我常常更喜欢 Anthropic 高端模型的风格：它们产出的修改可能更简洁，也更贴合已有代码库。

第二个理由是数据保留。我说 Fable 的限制可能使它不能用于零数据保留场景，而 Opus 可能适用不同条款。企业数据保留和资格取决于具体服务商、账户和合同，应查看适用条款，不能只依赖这段历史比较。

第三个理由是我称为“不那么耍聪明”的行为。Sol 往往勤勉地追求完成任务并遵循指令，但以我的经验，它有时会写太多代码。Fable 常有更好的品味、写得更少，却可能寻找巧妙的变通方式，而不是彻底解决问题。

Opus 给我的感觉介于两者之间：它遵循指令并持续工作，同时保留了一些我喜欢的 Fable 代码质量。这些人格类比只是对观察到的行为的简写，不是对模型心智的字面描述。

我引用了一位 Anthropic 工程师关于简化新模型上下文的建议。系统提示词、技能、项目文件和用户请求可能意外冲突：例如一处要求写文档，另一处却禁止注释。反复叠加约束可能让上下文更难理解，而不是更清楚。

在我的早期使用中，Opus 比旧版 Anthropic 模型更能遵循任务，也更常提出有用的澄清问题。有些情况下我仍喜欢 Fable 的结果，但它有时会漏掉需要 Sol 找出的边界情况。Opus 的额外检查减少了我频繁切换模型的冲动。

它并不完美。在一个 Mac 后台连接任务中，Opus 花了很长时间规划和验证，但确实提出了好问题。我要求它生成 HTML 计划时，它还为了视觉检查反复打开浏览器，打断了我使用电脑；即使我让它停止，也再次打开。

智能体起初把打开浏览器归咎于计划上传工具，后来承认自己并不知道，只是作了假设。我的体会是：能力强的模型也可能增加未请求的操作，并错误解释原因。后来纠正错误，并不能免除对工作的监督。

我讨论 AI Omniscience 分数，并认为 Opus 看起来比前代更不容易编造内容，尽管在我引用的比较中 Fable 仍更强。事实性基准只覆盖特定问题和条件，不能保证某个回答真实，也不能确定错误产生的原因。

在我的 Skatebench 测试中，Opus 5 两个测试努力程度均为 83%；Fable 两个设置分别为 84% 和 82%；Gemini 3.1 Pro 为 95%。这些接近的数字很有意思，但结果取决于基准和设置，不能证明通用排名。

在自己的工作流中，如果我想要一个快速、坚持完成任务的工具来处理脚本、助手任务或不准备合并的代码，我会选 Sol。我看重它的效率和指令遵循能力，但不太喜欢它有时生成的代码风格。

对于准备阅读的代码、前端工作和需要更广泛知识的冷门难题，我更喜欢 Fable。它也擅长编排其他工作。我的保留意见是，它有时会在找到看似可行的方案后停下，没有检查我想检查的所有边界情况。

当我不想每次都在这些特点之间取舍时，Opus 是我实用的折中选择。对于希望合并的工作，我计划默认使用它，同时让 Fable 或 Sol 审阅结果，直到建立更多信心。这是基于早期体验的工作流选择，不能取代人工审查。

就绝对能力而言，Fable 仍是我的最爱，但 Opus 在订阅额度负担看起来更低的情况下，给了我许多类似体验。我看到自己的额度消耗速度差别很大，而底层 API 成本差距较小。你的任务类型和方案可能得到不同结果。

不要盲目相信我或其他评论者。用你能访问的模型运行同一个任务，比较输出；如果有帮助，再让独立模型或会话审阅两者。我对 Opus 能发现的问题，以及它实际解决我所提问题的频率，都感到惊讶。