Opus 5.5 与 Sonnet 5.5

Claude Opus 5.5 和 Sonnet 5.5 怎么选，关键是完成任务的质量与总成本。 范围明确、能用测试验收、需要频繁迭代的编程工作，可以先用 Sonnet 建立基线。问题需要持续调查、跨模块判断，或者错误实现的返工代价很高，再评估 Opus 是否值得多付钱。这是按任务制定的建议，不是所有场景的模型排名。

Sonnet 的标准输入、输出单价是 Opus 的一半，缓存读取却同价。官方编程基准中也没有统一赢家：Sonnet 在一项评测领先，Opus 在另外几项领先。只看“旗舰”名称，或者把一个跑分写成“半价平替”，都不足以支持选型。

Opus 5.5 和 Sonnet 5.5 有什么区别

Anthropic 分别于 2026 年 9 月 22 日和 28 日发布 Opus 5.5 与 Sonnet 5.5。本文明确比较这两款 5.5；旧 Sonnet 用户可以查看 Opus 5.5 对 Sonnet 5，不要混用版本结论。

来源为官方模型总览。两者的容量相同，不代表长文检索准确率或推理质量相同。输入和输出仍须满足上下文预算，128K 不是额外赠送的使用额度。另有 300K 输出的 Batch API beta 选项，不能写成同步接口的常规上限。

编程哪个好：为什么官方基准没有统一赢家

下面统一采用 Sonnet 5.5 发布公告中的对照表。这些是发布方列出的结果，不是 OmniaKey 自行复测。

Sonnet 系统卡 §8.5 说明，Terminal-Bench 包含 66 个任务，两款模型各运行五次，共各 330 次试验。在假定试验独立的计算下，Sonnet 标准误为 ±2.5 个百分点，Opus 为 ±2.6 个百分点。测试启用了安全机制，部分请求由 fallback 模型完成，影响到的试验比例也不同；客户端是 Claude Code 的 --bare 模式。

所以 4.2 个百分点的差距不能直接写成“Sonnet 编程全面更强”，也不能在没有成对原始数据时自行宣称统计显著。它是值得在相关任务上验证的信号。

FrontierCode 更能说明“思考越多越好”的局限。公告脚注指出，Sonnet 在 max 时更常调用代码审查流程；被分析的部分案例因此超时或做出超出任务范围的修改。应同时保留 max 和 xhigh 分数，不挑选对某一结论最有利的一项。

GDPval 的两分差也不能证明模型可互换。公告还披露，用于 GDPval-AA 和 AA-Briefcase 的 Sonnet 预发布部署曾有结构化输出 bug，后来已经修复。需要保留这个条件。单款模型的发布和升级细节分别见 Sonnet 5.5 评测与 Opus 5.5 评测。

价格对比：Sonnet 单价减半，任务账单呢

下表来自 Anthropic 定价文档，单位为 USD / 百万 token，标准全球直连 API。工具费、税、区域附加费用以及其他平台的收费另计。

计费输出包含适用的思考 token，不只是屏幕上显示的答案。两者最小可缓存 prompt 都是 512 token，但达到长度要求不等于命中缓存，须查看供应商的 usage 字段。

下面固定数量只比较费率；数量可以是多次请求累计值，每次请求仍须满足容量限制。

第三行的 Sonnet 计算为 0.1 × 2 + 0.8 × 0.20 + 0.02 × 10 = $0.56；Opus 为 0.1 × 4 + 0.8 × 0.20 + 0.02 × 20 = $0.96。读取阶段约相差 1.71 倍。此前建立缓存的费用另付，第二行就是相应写入成本示例；也不要把已计入写入的 token 再算一次未缓存输入。

真实任务的 token 数、工具调用和重试次数可能不同。更有用的指标是“包含失败尝试的全部费用 ÷ 验收通过数”。人工修正时间另行记录，只有实际测量后，才能按明确的时薪情景折算总成本。

速度与思考强度：比较完整任务

Sonnet 5.5 官方“输出快 30% 以上”和“单任务最高省 30%”的比较对象是 Sonnet 5，不是 Opus 5.5，也不是 API 单价下降 30%。Opus 5.5 的典型任务约省 40%则是对 Opus 5 的比较。

Sonnet 在 Claude API 中默认 high，在 Claude Code 和 Claude apps 中默认 medium；Opus API 默认 medium。评测必须说明客户端和 effort。即使名称相同，也不代表消耗相同的计算预算。

交互任务要同时记录“首次有用输出”和“完成任务”的时间。第一段回复更快，如果之后需要反复修补，整体未必更快。官方 Fast / Moderate 分类也不是你所在地区或网关的实测延迟倍数。

哪些任务值得为 Opus 多付钱

先评估 Sonnet 的场景：已复现的 bug、有验收测试的小功能、范围清楚的代码审查、结构化资料提取。容易检查的任务，适合观察较低单价是否已经能稳定达到要求。

值得评估 Opus 的场景：跨服务的模糊故障、兼容条件复杂的迁移、需要长时间调查的问题。保持两边输入材料与验收规则一致，看 Opus 是否减少返工，而不是先假定价格高就更正确或安全。

长文与视觉任务：上下文都是 1M，比较应转向引用是否可追溯、是否漏掉关键条件、截图或图表理解是否正确。两者能看图片，不等于原生生成图片。

这是本文以成本为约束的评估策略。Anthropic 的通用模型指南则建议多数工作从 Opus 5.5 开始；质量优先、token 预算较宽松的团队可以采用这个起点。关键是先说明目标，再用真实验收检验。更完整的 CLI 选型见 Claude Code 模型选择指南。

切换模型之前检查什么

请分别阅读 Sonnet 迁移指南与 Opus 迁移指南。

• Sonnet 的 between_tools 可在 high 或以下关闭前置思考，不表示所有思考都关闭。Opus 5.5 始终开启 adaptive thinking。
• 两者都拒绝 tool_choice 的 any 和 tool 强制模式。严格校验工具入参不等于强制调用工具；平台支持范围还要单独核对。
• Thinking blocks 有模型、账号和对话保留规则。独立对测应新建会话，不要假设修改历史或跨模型重放都有效。
• 工具调用之间的进度可能以 thinking blocks 返回，默认显示策略可能省略内容。客户端应按 block 类型解析并核对流式行为，不能把无文字进度直接判为 agent 卡死。

因此，改一个 model ID 不能代替兼容性验证。本文也没有据文档推断所有 SDK 或网关都支持同样的行为。

用自己的任务复现比较

在看到模型结果前固定任务集。可以从四组各取六个任务：明确编程、复杂调试与重构、工具工作流、文档与视觉任务。24 个任务、两个模型、每项三次独立重复，共 144 次任务运行，API 请求数可能更多。这是建议的方法，不是我们已经执行的实验。

保持仓库 commit、prompt、工具、地区、权限、步数与时间上限、验收测试一致。每次重置工作区并新建会话，交替模型运行顺序。两边显式 medium 可以作为一组；默认配置或更高 effort 的结果另列，不能混成一个“最佳成绩”。

记录验收结果、失败、重试、工具错误、拒绝、可观察的 fallback、计费 token、耗时及实际人工修正。失败消耗也计入成本；代码用隐藏测试，文档核对出处，不以模型说“完成”为准。每任务三次重复不足以精确估计该任务的 P95；如果没有一次成功，写“无通过结果”，不要记成成功成本为零。

常见问题

Sonnet 5.5 编程比 Opus 5.5 更强吗

官方 Terminal-Bench 4.0 表中 Sonnet 分数更高，列出的 FrontierCode、CursorBench 则是 Opus 更高。设置与不确定性都要保留，不能由一项跑分推导通用排名。

Sonnet 5.5 的实际费用一定是一半吗

标准未缓存输入、输出单价是一半，缓存读取同价。实际 token 用量、重试、工具和修正工作会改变完整账单。

Claude Code 默认该选谁

可以先用 Sonnet 验证明确任务，用 Opus 验证复杂调查；质量优先也可以从 Opus 起步。记录 effort，并区分订阅与 API 按量收费，详见 Claude Code 价格说明。

Opus 5.5 的上下文更大吗

这两款都列明 1M 上下文、128K 标准最大输出。真正要验证的是它们如何利用上下文，而不是容量数字。

当前路线与官方来源

OmniaKey 当前显示的路线与报价见 Sonnet 5.5、Opus 5.5和 模型目录。上面的直连算例不是网关报价，也不表示本文验证过真实 API 调用。

本文引用的 Anthropic 发布公告、规格、价格、迁移指南与系统卡均为英语官方资料。修改生产接入前应再次核对价格和请求行为。