Opus 5.5 与 Sonnet 5
按任务难度、验收结果和总成本选择模型。
Claude Opus 5.5 和 Sonnet 5 怎么选，取决于工作本身。 范围清楚的编码任务可以从费用较低的 Sonnet 5 开始；需要持续排查、复杂架构判断或减少高代价返工时，再评估 Opus 5.5。多付费用是否值得，要看最终通过验收的结果。
核验日期：2026 年 9 月 28 日。 本文依据 Anthropic 当前规格、价格和发布文档，没有独立开展两模型对照测试或延迟实测。建议是评估起点；成本示例固定 token 数，不是实测任务账单。
Opus 5.5 与 Sonnet 5 核心区别
| 对比项 | Sonnet 5 | Opus 5.5 |
|---|---|---|
| 官方 API model ID | claude-sonnet-5 | claude-opus-5-5 |
| 上下文 / 标准最大输出 | 1M / 128K tokens | 1M / 128K tokens |
| 输入 / 输出 | 文本和图片 / 文本 | 文本和图片 / 文本 |
| 默认 effort | high | medium |
| 思考模式 | Adaptive | Adaptive，始终开启 |
| 官方延迟类别 | Fast | Moderate |
| 每百万未缓存输入 / 输出 | $2 / $10 | $4 / $20 |
| 每百万缓存读取 | $0.20 | $0.20 |
| 建议起点 | 明确、高频、可验收任务 | 困难、开放、失败代价较高的任务 |
来源：官方规格和 API 价格。表格是全球标准直连 API 的美元价格，工具、区域选项和其他服务模式另计。
两个模型的标称上下文与标准输出上限相同。升级到 Opus 5.5 并不会在这里买到更大的窗口；它的潜在价值在于怎样利用已有证据，需要自己的任务来验证。
哪些编程任务先用 Sonnet 5
范围明确的功能、可复现的 Bug、已有接口的测试、常规重构和聚焦的代码审查，都适合作为 Sonnet 基线。这类任务通常有明确验收条件，能判断低成本路线是否已经足够。
高频工作更需要注意费用：每次请求的差异会经过 agent 步骤、重试和日常使用放大。先补齐上下文、限定任务并运行验证，再决定是否升级模型。这里不保证 Sonnet 一定完成，也不认为换模型能弥补缺失的需求或测试环境。
什么时候值得评估 Opus 5.5
看似合理的补丁反复修不到根因、改动跨越多个服务、迁移必须保留微妙行为，或者一次错误会带来大量修复工作时，可以试 Opus。给两个模型相同证据与验收标准。
Anthropic 将 Opus 5.5 定位于长时间 agent 编程和知识工作。发布材料报告了相对早期型号的进步，但相对 Opus 5 的提升不能直接当成相对 Sonnet 5 的提升。具体评测条件见 Opus 5.5 评测。
架构或诊断确定以后，常规实现可以回到更低成本路线。选择清晰的任务边界并传递已验证结论，不在未解决的对话中悄悄换模型。
API 费用并非所有场景都相差两倍
Opus 5.5 的未缓存输入和输出单价是 Sonnet 5 的两倍，但缓存读取单价相同。每百万 tokens 的五分钟缓存写入分别是 Sonnet $2.50、Opus $5；一小时写入分别为 $4、$8。
| 完全相同的 token 工作量 | Sonnet 5 | Opus 5.5 |
|---|---|---|
| 100K 未缓存输入＋20K 计费输出 | $0.40 | $0.80 |
| 100K 未缓存输入＋800K 缓存输入＋20K 计费输出 | $0.56 | $0.96 |
第二行 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。这不含先前的缓存写入，并假设用量中确实报告了命中。输出数量包含计费的思考 tokens，而不只是可见文本。
示例不含工具、重试和平台调整。模型或 effort 变化可能改变 token 消耗，应观察“总计费金额 ÷ 验收通过任务数”，并单独记录人工修正时间。
OmniaKey 是独立网关路线，当前可用性和报价以 Opus 5.5、Sonnet 5 模型页为准。官方表格不是网关账单，Claude 订阅也与 API 按量计费分开。
速度与思考强度要按完整任务比较
官方把 Sonnet 延迟列为 Fast、Opus 5.5 列为 Moderate。这是供应商分类，不是独立测得的 tokens/秒倍数。更快给出答案，仍可能因重试和修正而花更长时间完成任务。
先从各自默认值开始：Sonnet high、Opus 5.5 medium。这是比较通常的起始配置，不是相同算力预算。如果另测相同名称的 effort，应单独报告，同名也不保证相同 token 预算或工作量。
固定提示词、仓库状态、工具与验收测试，记录首个有用输出时间、总耗时、重试、费用和通过情况。用多个代表性任务，不把一次满意输出包装成普遍排名。
切换前核对 API 请求合同
Opus 5.5 要求 Adaptive thinking。关闭思考或手工设置思考预算会报错；强制 tool_choice 为 any、tool 也不支持。思考块还有对话保留规则，工具调用之间的进度文本可能出现在 thinking 块中。
不要只修改一个 Sonnet 请求的 model 名就认定其余设置全部有效。阅读 Opus 5.5 迁移指南，验证工具循环和实际路由行为。CLI 里的选择与切换见 Claude Code 模型指南。
常见问题
Opus 5.5 编程一定比 Sonnet 5 好吗？
文档不能推出通用结论。Opus 面向更困难的工作；Sonnet 对能够稳定通过验收的任务可能已经足够且更便宜。比较实际通过率、总成本和人工修正时间。
Sonnet 5 是一半价格吗？
官方标准未缓存输入和输出单价是一半，但缓存读取相同，完整费用还取决于 token 组合、思考、重试和工具。
Opus 5.5 的上下文更大吗？
两者都列出 1M 上下文和 128K 标准最大输出。这是容量，不是免费用量；其他 API 模式有单独条件。
旧版 Opus 5 对比还需要看吗？
比较5.5时使用本文；Opus 5 vs Sonnet 5仍服务旧版本选择。引用效果与价格时明确版本。