Claude Sonnet 5评测：接近 Opus 4.8，但真实成本高于标价

Claude Sonnet 5评测：一句话结论

如果主要用它做 AI 代理、编程和大量调用工具的自动化任务，应该切换到 Sonnet 5；但在认定成本下降之前，先把 tokenizer 变化算进预算。

Anthropic 于 2026 年 6 月 30 日发布 Sonnet 5，将其定位为迄今代理能力最强的 Sonnet 模型：它能规划多步骤工作、操作浏览器和终端等工具，并完成以往 Sonnet 模型容易中途卡住的任务。在 API 和 Claude Code 中，它默认以 effort=high 运行；在这一设置下，部分任务的表现已接近 Opus 4.8，而标价仅为后者的一小部分。对已经深度使用 Claude Code 或正在构建 AI 代理的大多数人来说，它现在就是更合适的默认选择。

真正需要谨慎的是成本，而不是能力。首发价格看起来像是降价，但新 tokenizer 会让同一段文本的 token 数增加约 30%；同时，API 还有 3 项破坏性变更，如果不先处理，迁移后的请求会直接返回 400。下文会逐项说明。

与 Sonnet 4.6 相比，真正变了什么

Sonnet 5 可以直接替换 Sonnet 4.6：它减少了一部分手动控制，换来了明显更强的自主执行能力。

最显著的提升是代理任务的持续执行能力。Anthropic 自己也承认，近期最明显的能力跃升此前主要出现在 Opus 级模型上，而 Sonnet 5 缩小了这道差距：它以更低价格提供接近 Opus 4.8 的表现，同时比 Sonnet 4.6 覆盖更宽的成本与速度区间。它在推理、工具调用、编程和知识工作上都优于 4.6；参与早期测试的合作方称，它可以完成多步骤软件任务，并在无人提醒的情况下检查自己的输出。在 Anthropic 重点展示的代理搜索（BrowseComp）和计算机操作（OSWorld-Verified）基准中，它全面优于 4.6；提高 effort 后，部分任务还能追平 Opus 4.8。按照 Anthropic 的安全说明，它也比 4.6 更少出现不良行为，而网络安全任务能力明显弱于当前的 Opus 模型——对大多数企业用途而言，这反而是优势，而不是损失。

最实用的一项行为变化是：adaptive thinking 默认开启。 在 Sonnet 4.6 中，请求如果不带 thinking 字段，就不会进行思考；到了 Sonnet 5，同样的请求会自动采用自适应思考。默认答案因此更好，但 max_tokens 同时限制思考过程和最终回复，所以按 4.6 调好的输出上限现在可能会截断用户实际看到的答案。凡是过去不启用思考的工作负载，都应该重新检查 max_tokens。

真实价格：完整的 Claude 5 产品梯队

Sonnet 5 的 API 首发价截至 2026 年 8 月 31 日为：每百万输入 token $2、每百万输出 token $10；此后调整为输入 $3、输出 $15。按当前数据，它在整个产品梯队中的位置如下：

换算成比例后，选择会更清楚。按首发价计算，Sonnet 5 的单 token 成本是 Opus 4.8 的 40%；即使采用 8 月后的标准价，也只是 Opus 的 60%。与更便宜的型号相比，Sonnet 5 的标准价是 Haiku 4.5 的 3x，而 Haiku 的上下文窗口最高只有 200k，Sonnet 5 则达到完整的 1M。因此，Sonnet 5 本来就是产品线的中间档：比 Opus 便宜，能力显著高于 Haiku，同时拥有与旗舰型号相同的 1M 上下文和 128k 最大输出。

还有一项对长任务很重要、却容易被忽略的规格：Sonnet 5 的 1M-token 上下文既是默认值也是最大值，不提供更小上下文的版本；在 Batch API 中加入 output-300k-2026-03-24 beta header 后，最大输出可提高到 300k token。与 Opus 档位相比，它缺少的是 Priority Tier 访问权限，因为 Sonnet 5 不提供该选项。

别忽视 tokenizer 带来的 30% 隐性成本

标价降了，但单位工作量的实际成本没有同步下降那么多，因为 Sonnet 5 使用了新的 tokenizer，同一段文本生成的 token 比 Sonnet 4.6 多约 30%。

tokenizer 负责把文本切分成用于计费的 token。Sonnet 5 的 tokenizer 与 4.6 不同，Anthropic 明确表示，同样的输入文本会多产生约 30% 的 token，具体比例取决于内容。单 token 价格没有变化，但账单按 token 计算：如果某个请求在 4.6 上被切分为 10,000 token，到了 Sonnet 5 上就会变成约 13,000 token；在单价变化之外，同等任务的成本还会增加约 30%。这也意味着 1M 上下文窗口能容纳的实际文本更少，而按照 4.6 输出量设置的 max_tokens 可能会提前截断回复。

实际操作只有一条原则：不要再沿用旧模型测出的 token 数，必须针对 Sonnet 5 重新测量。 如果成本预测、单次请求预算或上下文装填逻辑建立在 4.6 的数据上，现在都会偏乐观。此前 Opus 产品线也出现过同样的情况，我在 Opus 4.7 tokenizer 变化中做过详细拆解；解决方法依旧是先重新计数，再作决定。

这些变化并不意味着 Sonnet 5 昂贵。按首发价计算，在输出质量相近时，它依然远低于 Opus。只是诚实的比较方式应该是把“$2 的标价、真实的能力提升，以及约 30% 的 token 开销”放在一起看，而不是简单地说“它变便宜了”。在假定能省钱之前，先用自己的工作负载算一遍。

切换前先处理 3 项破坏性变更

从 4.6 迁移总体并不麻烦，但有 3 类昨天还能正常工作的请求，现在会返回 400 错误。必须先处理这些问题，否则代理循环第一次调用就会中断。

# Fails on Sonnet 5 (returns 400)
resp = client.messages.create(
    model="claude-sonnet-5",
    temperature=0.7,
    thinking={"type": "enabled", "budget_tokens": 32000},
    max_tokens=4000,
    messages=[...],
)

# Works: no sampling params, adaptive thinking, roomier max_tokens
resp = client.messages.create(
    model="claude-sonnet-5",
    thinking={"type": "adaptive"},
    max_tokens=8000,
    messages=[...],
)

Claude Sonnet 5 vs Opus 4.8：什么时候该选更便宜的模型

对于代理编程和工具调用自动化，Sonnet 5 在 effort=high 下应当作为默认选择；只有任务确实需要更高能力上限时，才升级到 Opus 4.8。

Sonnet 5 的核心优势在于 effort 调节档位。它提供与 Opus 档位相同的 medium/high/extra-high 级别；Anthropic 自己的成本—性能曲线显示，它覆盖的范围远大于 4.6：medium effort 具有很高的效率，提高 effort 后，部分任务能够达到 Opus 4.8 的能力。考虑到其首发价只有 Opus 的 40%（8 月后为 60%），更合理的做法是先用 Sonnet 5，仅将少数特别困难的任务升级到 Opus，而不是所有任务都支付 Opus 的价格。

继续使用 Opus 4.8 的理由虽然有限，却很实际：有些工作只有能力曲线顶端的模型才能值回成本，例如最困难的代理编程任务、单个步骤失败就会代价高昂的长时间自主运行，或任何不能接受“部分任务追平”、因为真正重要的恰好是未追平部分的场景。如果要大规模委派无人值守的生产任务，多付的模型费用可能比一次 Sonnet 执行失败更便宜。

真实口碑：为什么有人认为它是降级

社区评价明显分化，假装没有争议并不诚实。除了有人称赞它“finishes tasks 4.6 couldn't”，本月 r/ClaudeAI 的公开讨论中也出现了标题直白的“Sonnet 5 is a downgrade”，以及一连串“is it actually worth using”和“what's the consensus”帖子。Anthropic 所说的“close to Opus 4.8”，与部分用户的实际感受之间确实存在落差，这一点值得正视。

多数分歧可以由两点解释。第一，默认启用 adaptive thinking 改变了回复形式和延迟，因此针对 4.6 更简短、无思考输出调校的工作流，即便质量提升，体验也会不同。第二，在重新测量之前，tokenizer 变化会让成本对比显得更差，人们会先把它理解为“更贵”，而不是“换了 tokenizer”。这两点都不代表模型本身不好，只说明所谓直接升级从来不会完全无缝。请先用自己的真实 prompt 测试，再决定是否相信任何人的结论——也包括我的结论。

哪些人应该切换，哪些人适合再等等

正在迁移编程或代理环境，想先把真正影响效果的配置调整到位？领取免费的 Claude Code + Codex 配置清单，在生产环境切换模型前完成值得检查的配置与成本控制步骤，并在每次新模型分析发布时及时收到更新。