Claude Sonnet 5.5深度评测：剑指OpenAI的隐藏杀招

Anthropic最近的势头让人无法忽视。从Fable 5.1成为许多开发者最爱的代码模型，到Opus 5.5几乎接管了整个工作流，如今又推出了Sonnet 5.5——这个发布看起来战略意图明确：尽可能地针对OpenAI。

Sonnet回归：一个被低估的发布

坦白说，Sonnet 5.5原本是我打算直接跳过、不想浪费时间讨论的模型。原因很简单：Opus 5.5的价格和价值已经足够惊艳，我已经一周多没有为任何任务选择过Fable了。而上一代的Sonnet 5，更是我记忆中最不喜欢的模型发布之一——它更像是一堆试图在特定场景里机械运作的机器人，而非真正理解任务的助手。

但这次我错了。Sonnet 5.5确实是一个令人印象深刻的模型，只是它的出彩之处可能和你想的不太一样。

Anthropic官方将其定位为Sonnet 5的明显升级：速度提升30%，大多数工作成本降低最多30%。它被定位为Opus 5.5的轻量化补充——Opus负责需要审慎判断的复杂工作，而Sonnet 5.5最擅长范围明确的日常任务，比如修bug、生成文档、幻灯片和表格。官方还预告Haiku 5.5将在未来几周加入该家族，面向高并发、成本敏感的场景。

基准测试：数字背后的真相

Sonnet 5.5在Terminal Bench上拿到了迄今最高分70.6%，而前代仅为10.3%——这是七倍的跃升。一个Sonnet级别的模型拿下Terminal Bench历史最高分，一方面让人惊讶，另一方面也让人对这个基准本身产生怀疑。

它在GDPVal上略低于Opus 5.5，在长周期任务和图像理解上表现强劲，还成为首个仅凭截图就能通关Pokemon Red的Sonnet模型。感觉Anthropic在强化学习层面有了某些内部突破——现在这些较小的模型不再像以前那样"笨拙执行"，而更像是略微变笨、速度更快的Fable版本。

但真正的问题出现在Artificial Analysis智能指数上：在每一个层级，Sonnet 5.5都比Opus 5.5更贵也更"笨"。在真实世界任务中，Sonnet 5.5的成本几乎与Fable 5.1持平——而Fable是他们跑过最贵的一档。这本该直接宣判这个模型的死刑。

定价的玄机：缓存读取是关键

Sonnet 5.5定价与Sonnet 5相同：输入每百万token 2美元，输出10美元，缓存读取20美分。问题恰恰出在缓存读取上。

对于如今的日常agent代码工作，缓存读取和缓存写入往往占据成本的大头。Fable 5.1把缓存读取成本砍掉了90%，Opus也降了约60%，但Sonnet 5.5却没有享受到这种折扣。

从定价结构看：Sonnet到Opus，输入输出成本翻倍；Opus到Fable再翻倍。但缓存读取成本在Sonnet和Opus之间几乎没变，到Fable也只涨了25%。这意味着当你往低端模型走时，缓存读取占总成本的比例会越来越高——Fable里不到5%，Opus里接近20%，而Sonnet 5.5里可能超过50%。

结果就是：在做同等的真实代码任务时，Sonnet的实际成本常常不低于、甚至高于Opus。因为常规输入token在agentic工作中几乎用不上（大多从缓存读取），而输出token只占很小一部分。

**提示词缓存（Prompt Caching）**是现代大语言模型API中的一项重要机制。在agentic工作流中，系统提示词、代码库上下文、工具定义等内容往往在多轮对话中反复传入模型，若每次都按完整输入token计费，成本会极高。缓存机制允许模型服务商将这些重复内容在服务器端保留一段时间，后续请求命中缓存时只收取远低于正常输入价格的"缓存读取费"。以Anthropic的定价结构为例，普通输入token和缓存读取token之间的价格差可达5到10倍，因此在长上下文或多步骤agent任务中，缓存命中率的高低直接决定实际账单。Fable（即Claude 3系列中的Haiku）对缓存读取给予了极大折扣，而Sonnet 5.5未能延续这一优惠，使得其在重度缓存使用场景下的实际成本优势大幅缩水，这是理解本文核心定价论点的关键背景。

远离Max模式：一个必须说清的陷阱

如果说有一件事必须强调，那就是：别用Max模式。

推理等级其实不是"等级"，而是"预算"。设置low、medium、high、x-high，是在允许模型使用到某个上限的推理token，但不必然增加实际用量。在简单任务上，low和x-high之间token差距可能只有5%到8%。

Max的问题在于，它不是抬高推理token的"天花板"，而是抬高"地板"——它在告诉模型"不达到一定推理量就不算完成"。我测过的基准里，从x-high到Max，token使用量暴涨1500%，整整15倍。更糟的是，强迫模型过度思考常常反而损害性能，让它开始自我怀疑、给出错误答案。

实测中，Sonnet 5.5在Max下跑一个基准花了7.6美元，是同档Astra的两倍多。但换成High或Medium，价格骤降到1.08美元和0.59美元。甚至在Frontier Code基准上，x-high的得分反而比Max更高、超过了GPT-6 Sol，而Max却掉到Sol之下。把这种"Max反超Opus"的图表放在博客第一张展示，实在是个奇怪的选择。

**推理模型（Reasoning Model）**是指在给出最终答案前，会先生成一段内部"思考过程"（thinking tokens）的大语言模型，代表产品包括OpenAI的o系列和Anthropic的Claude扩展思考模式。这些思考token通常也会被计入计费，但其产生的价值因任务复杂度而异。推理预算（reasoning budget）是控制思考深度的参数：设置低预算时，模型只在必要时展开推理；设置高预算时，模型可使用更多token进行推敲。文章指出的关键问题在于，"Max"模式并非简单地允许更多推理，而是强制要求模型至少达到某一推理量，相当于把"地板"抬高而非"天花板"。这对简单任务尤其有害——模型被迫过度分析反而引入噪音和自我怀疑，导致准确率下降，同时成本却急剧攀升。

Token效率短板与速度错觉

Sonnet 5.5并不是一个token高效的模型。在Cursor Bench上，它每个任务消耗271,920个token，超过Opus的218k，几乎是Gemini 3 Flash的两倍，更是GPT-6 Sol和Astra的五倍以上。

速度方面，根据OpenRouter，通过Anthropic调用Sonnet 5.5约为94 tokens/秒，Opus 5.5约70。作者在官方订阅下实测Sonnet约150 tps、Opus约100 tps。虽然更快，但因为token消耗太大，实际完成时间反而更长——在"fish slop"演示中，Sonnet花了43分钟，Opus只用36分钟；纯生成时间的差距更大，39分钟对27分钟。

设计能力同样是弱项。在Witch AI设计展示中，Sonnet的生成有滚动错乱、背景线条影响可读性、卡片设计丑陋等问题，比Opus差，比Fable差得更多。Fable 5.1依然是整体最佳的前端设计模型。

真正的价值：作为被编排的工具

说到这里你可能困惑了：一个前端差、token多、不比Opus更聪明也不更便宜的模型，作者到底喜欢它什么？

答案是：你和我都不该直接选用Sonnet 5.5，但它作为其他模型可调用的工具，价值巨大。它不该被直接调用，而应作为Opus或Fable在拆解复杂工作时编排的众多组件之一。

作者用一个"深度审计"基准验证了这点：让各模型对数十万行代码的巨型PR做深入分析、提出落地策略。这不是传统编码测试，而是偏分析和架构决策的任务。结果Sonnet的表现令人惊讶——成本约为Opus的一半，得分却略高于Opus，单位得分成本是该基准里见过的最佳。更重要的是耗时：它只用约5分钟，Opus几乎两倍时间，Astra近三倍。

换句话说，当Opus或Fable接到大任务、需要在动手前分析代码库时，它们现在可以调用Sonnet去做这类研究，并对结果满意。如果正确配置让Opus在恰当时机调用Sonnet做子agent，最终效果会是Opus感觉更快、以略低成本完成真实工作。

**多Agent编排（Multi-Agent Orchestration）**是一种将复杂任务分解、由多个AI模型协作完成的架构模式。在这种框架中，通常有一个"编排者"（orchestrator）负责任务规划与分配，而多个"子agent"（sub-agent）负责执行具体的原子化步骤。编排者往往使用能力最强的旗舰模型（如Opus），而子agent则可使用更快、更便宜的模型处理特定子任务，例如代码搜索、文档生成或格式转换。这种架构的优势在于整体效果接近全程使用旗舰模型，但成本和延迟可以显著降低。Sonnet 5.5在代码库深度分析任务中展现出的性价比，使其成为此类架构中理想的子agent候选——它足够快、足够准，且在分析类任务上成本约为Opus的一半，从而让整个编排系统在保持质量的同时降低总体开销。

OpenAI该害怕了

作者直言不会在日常中大量使用Sonnet 5.5，但它是这个新模型家族里极出色的补充。它在真实代码库中确认假设、深度挖掘特定行为的能力，以及对office文档类任务的潜力，都蕴含着巨大价值。

真正值得OpenAI警惕的是整体格局：Anthropic在它最擅长的所有领域都占了上风——没有最聪明的模型、没有最高效的模型、没有最便宜的模型、也没有最适合调用其他模型的模型。作者坦言，200美元的Codex订阅能换到的真实代码产出，远不及200美元的Claude订阅。

GPT-6 Sol在作者看来几乎是"到店即死"，没什么让他想讨论的理由。随着OpenAI Dev Day临近，这家公司势必要反击。而从目前的节奏看，竞争只会加速，不会放缓。