Anthropic 又发新模型了。距离 Claude Opus 5.5 发布还不到一周，Anthropic 于 9 月 28 日推出 Claude Sonnet 5.5。
这是 Claude 5.5 家族的第二款模型，Haiku 5.5 也将在未来几周内登场。 Anthropic 宣称，新模型的输出速度提升超过 30%，完成多数任务所需的 Token 更少，因此单任务成本最高可降低 30%。
Claude Code 创建者 Boris Cherny 还发布了一段演示，展示 Sonnet 5.5 通过 Claude Code 修复一个 Bug，并配文称：“速度提升 30%，使用量减少 30%。不过，Sonnet 5.5 虽然把 Sonnet 这个“中档模型”推到了接近 Opus 的位置，但当推理强度拉到最高，它对 Token 的消耗也达到了一个惊人的水平。
Sonnet 5.5 最明显的升级，就是编程 从 Anthropic 公布的数据看，Sonnet 5.5 的核心提升发生在 Coding Agent 场景。其中变化最明显的是 Terminal-Bench 4.0。
Sonnet 5.5 从上一代的 10.3% 跃升到 70.6%，还超过了 Opus 5.5 公布的最佳成绩。这项测试要求模型在命令行环境中自主使用工具，完成复杂的多步骤任务，考察的是完整的 Agentic Coding 能力。
CursorBench 更接近日常开发。它使用来自 Cursor 编辑器真实编程会话的任务，包含需求模糊、跨文件修改和理解现有代码库等情况。
Sonnet 5.5 在这项测试中得到 55.5%，与 Opus 5.5 的 57.8%只差约两个百分点。 Anthropic 称，早期测试者最明显的感受，是 Sonnet 5.5 理解代码库的速度更快。
它也更倾向于把多个工具调用批量执行，减少模型与终端之间来回交互的次数。对于 Claude Code 这类需要反复搜索、读取、修改、测试和验证的 Coding Agent，减少一步往往意味着同时减少等待时间、Token 消耗和中途出错的机会。
Lovable 的测试提供了一个更具体的观察：Sonnet 5.5 完成编程任务所需的工具调用减少约三分之一，Shell 执行次数大约减半。 Base44 在 118 次真实应用构建中发现，Sonnet 5.5 平均经过 3.6 轮迭代完成一个应用，Opus 5 则需要 7.7 轮；新模型的工具调用失败次数也是所有参测模型中最少的。
这些数据表明，Sonnet 5.5 的变化不只体现在输出速度上。至少在 Anthropic 引用的早期测试中，它用更少的工具调用、Shell 运行和迭代完成了任务，减少了模型与工具之间的往返。
“单任务最高省 30%”，但有前提 Sonnet 5.5 延续了 Sonnet 5 的价格：每百万输入 Token 2 美元、输出 Token 10 美元、缓存读取 0.2 美元、缓存写入 2.5 美元。与 Opus 5.5 相比，Sonnet 5.5 的输入、输出和缓存写入价格均低一半，缓存读取价格相同。
但 Artificial Analysis 的测试显示，当推理强度调到 Max 时，Sonnet 5.5 每项 Intelligence Index 任务平均生成约 19.3 万个输出 Token，是该机构测试过的模型中最高的。这个数字比 Opus 5.5 Max 和 Sonnet 5 Max 高约 60%，约为 GPT-6 Astra Max 的 7 倍。
Sonnet 5.5 Max 的单任务成本达到 7.60 美元，比 Sonnet 5 高约 50%。作为交换，Sonnet 5.5 Max 在 Artificial Analysis Intelligence Index 中得到 56 分，只比 Opus 5.5 Max 低两分。
也就是说，Anthropic 所说的“单任务成本最高降低 30%”针对的是多数任务，并不代表把推理强度调到 Max 后仍然更省。值得注意的是，Sonnet 5.5 在 FrontierCode 1.1 中使用 Max 设置时得到 46.2%，反而低于 Xhigh 的 52.1%。
Anthropic 在脚注中称，Sonnet 5.5 在 Max 设置下更容易触发由多个子 Agent 执行的代码审查。 Cognition 检查的两个案例中，出现了超时或任务范围外的额外修改，最终被 FrontierCode 扣分。
谁需要 Sonnet 5.5？ Sonnet 5.5 发布后，一名 Hacker News 用户提出了一个很现实的问题：Opus 5.5 的效率已经很高，即使同时运行两三个会话，Max 5x 套餐的额度也完全足够日常工作。
“所以，我想知道自己什么时候才会使用 Sonnet 5.5”。 “至少目前，我自己的工作需求似乎已经快被模型能力完全满足了。
当然，我可以把所有请求都调到 Max Effort，单纯为了消耗 Token，但这显然没有意义。他的评论点出了 Sonnet 5.5 一个略显尴尬的位置。
Claude Max 目前分为每月 100 美元的 5x 套餐和每月 200 美元的 20x 套餐。对已经订阅 Max、日常额度又足够的人来说，Opus 5.5 能处理最难的任务，未必有场景需要我们切换到 Sonnet 5.5。
还有一名 Hacker News 用户问得也很直接：“Opus 5.5 使用 Low 设置时，看起来比 Sonnet Medium 更聪明、更便宜、速度也更快，那 Sonnet 存在的意义是什么？另一名用户勉强找出了一个场景：Claude Code 的子 Agent 会继承主 Agent 的 Thinking Level。
如果想让不同子 Agent 使用不同强度的推理，就需要换用不同模型，因此他偶尔会选择 Sonnet。但他自己也承认：“这算不上一个特别好的理由，只是我目前唯一会使用 Sonnet 的场景。
这种困惑也与付费方式有关。 Max 用户支付的是固定月费，只要套餐额度还够用，继续使用 Opus 5.5 并不会立刻增加支出，Sonnet 5.5 的低单价自然缺少吸引力。
API 用户面对的情况不同。模型在多轮对话和工具调用过程中产生的输入、输出 Token 都会计入账单，Sonnet 5.5 的输入和输出单价只有 Opus 5.5 的一半。
对于需要批量修复 Bug、补充测试、处理 CI 问题或者并行运行多个 Agent 的团队，只要任务边界清晰，Sonnet 5.5 使用 Medium 或 High 设置就能把价格优势真正体现出来。但把推理强度调到 Max 后，这项优势又很快消失。
Artificial Analysis 测得，Sonnet 5.5 Max 的单任务成本达到 7.60 美元，跑 10 个任务就是 76 美元，跑 100 个就是 760 美元。它虽然获得了接近 Opus 的性能，成本也随之进入了另一个区间。
因此，Sonnet 5.5 最清晰的使用场景集中在高频、明确、可验证的 API 任务上。对于 Max 订阅用户，如果 Opus 5.5 已经能在现有额度内完成工作，确实很难找到切换的迫切理由。
更复杂的是，即使开发者选择了 Sonnet 5.5，最终处理请求的也可能是 Sonnet 5。 Sonnet 5.5 是首款加入网络安全分类器和模型回退机制的 Sonnet，其网络安全能力已经接近 Opus 5，因此 Anthropic 为它采用了相同级别的防护措施。
这套检测分为三个阶段：系统首先通过探针读取模型的内部激活状态，随后由运行在 Sonnet 5.5 上的轻量级分类器检查，最后再由一个单独训练的 LLM 分类器决定是否拦截对话。如果请求被判定为高风险网络安全任务，系统可能停止使用 Sonnet 5.5，将请求交给能力较弱的 Sonnet 5。
在 Claude 应用中，用户会看到模型切换提示。 API 开发者则需要主动启用服务器端 fallback；启用后，部分因网络安全或前沿模型限制而被拒绝的请求会自动交给 Sonnet 5，没有启用时，请求将直接返回拒绝。
Artificial Analysis 在测试 Sonnet 5.5 的五档推理强度时，均启用了 Anthropic 的默认回退机制。约 0.1% 的 Intelligence Index 任务触发了回退，主要集中在 Terminal-Bench 4.0，所有触发回退的请求最终都由 Sonnet 5 处理。
因此，“选择 Sonnet 5.5”包含了两个问题：它是否比 Opus 更适合当前任务，以及这项请求最终是否真的由 Sonnet 5.5 完成。 Artificial Analysis 观察到的回退比例只有约 0.1%，但这个数字仅来自其基准测试，不能代表真实生产环境中的整体回退率。
参考链接： /ai-market-guide/ /ai-market-guide/ /ai-market-guide/ id=49881850