Sonnet 5.5 vs Opus 5.5：更便宜的Claude为何反而更贵

Anthropic在三周内连续发布了Haiku 5.5、Sonnet 5.5和Opus 5.5，三款模型均支持百万级token上下文，定价从每百万输入token 0.1美元到4美元不等。但一个反直觉的发现是：在最高推理档位下，更便宜的Sonnet 5.5单任务成本反而超过了Opus 5.5。这背后涉及模型定价、推理力度调节和实际token消耗量之间的复杂关系。

三款模型的基本定位与定价

Opus 5.5于9月22日率先登场，Sonnet 5.5紧随其后在9月28日发布，Haiku 5.5则在10月7日收尾。三款模型都支持一次处理高达一百万token的输入，核心差异在于速度和价格。

输入定价方面，Opus每百万token收费4美元，Sonnet为2美元，Haiku仅需10美分。输出端价格统一为输入的5倍。Haiku 5.5被Anthropic称为"迄今最便宜、最快的小型模型"，比Haiku 4.5便宜约75%，专为大批量处理、分类、客服支持以及作为更大模型的子代理而设计。

一个有趣的细节是，Haiku在测试中曾被问"total里有几个R"，它回答"一个"——实际上一个都没有。这提醒我们，即便模型在价格上有巨大优势，在需要精确推理的任务上仍需谨慎。另外需要注意：当prompt超过10万token后，Haiku的价格会跳涨5倍。

什么是 token 上下文（context window）

大模型的"上下文窗口"指模型在单次推理中能够同时读取和处理的 token 总量，包括输入（prompt、文件、对话历史）和输出。一百万 token 大约是 75 万个英文单词，相当于几本长篇小说的体量，足以一次塞进中型代码库或数百页文档。上下文越大，模型越能保持长文档、长对话的一致性，不必频繁分块切割。但要注意两点：一是超长上下文会显著推高输入 token 账单，尤其是 Haiku 在超过 10 万 token 后价格跳涨 5 倍；二是"能装下"不等于"能用好"，模型在超长上下文深处的召回和推理能力通常弱于开头部分，这也是实务中仍要配合检索、摘要和子代理的原因。

Sonnet 5.5：日常工作的最佳平衡

Sonnet 5.5被Anthropic定义为"速度与智能的最佳组合"，面向日常工作者——修bug、写文档、做幻灯片和电子表格。在Anthropic自家的基准图表中，Sonnet 5.5在TerminalBench上甚至超过了Opus。

Encode Rabbit的实测数据提供了更具体的画面：在13个高难度bug测试中，Sonnet正确修复6个，Opus修复8个，而Opus在max effort档位下能修复10个。成本方面，Sonnet每次审查约花费47美分，Opus约1.16美元。他们的结论是：Sonnet非常适合审查每一个Pull Request，但不应作为高风险变更的Opus替代品。

Opus 5.5：长时间硬任务的首选

Opus 5.5定位为处理长时间、高难度工作的模型——大型迁移、深度研究、可以自主运行数小时的Agent。Anthropic的官方建议也是：如果不确定选哪个，从Opus开始。

客户Quantium分享了一个案例：一个编码任务原本需要38次prompt交互、耗时4天，使用Opus 5.5后缩短为11次prompt、3小时内完成。在Opus之上还有第四个模型Fable 5.1，输出定价10.5美元，面向最严苛的推理需求。

核心反转：便宜模型为何可能更贵

这些模型都配有"effort dial"（推理力度调节旋钮）：low、medium、high、xhigh和max五档。Artificial Analysis的测试揭示了一个关键发现——在max effort下，Sonnet的单任务成本为7.67美元，而Opus为5.98美元。

原因在于token消耗量：Sonnet在完成任务时写出了比Opus多约60%的输出token。正如Andrew Seas所指出的，token单价告诉你"一个词多少钱"，而token使用量告诉你"模型需要写多少词才能完成任务"。Anthropic自己的指南也认同这一观点：调节推理力度往往比切换模型更有效。

effort dial（推理力度调节）究竟是什么

"effort dial"是 Anthropic 在较新模型上引入的一类参数，本质是控制模型在给出答案前愿意投入多少"思考 token"——可以理解为在 low 到 max 之间调节模型花多少力气做内部推理、自我检查和纠错。档位越高，模型越可能反复推演、验证边界条件，因而越可能一次做对复杂任务，但输出 token 也随之膨胀，成本上升。它不同于简单的"回复长度"控制，更像是在"多想一会儿"和"省点钱"之间取舍。Anthropic 官方因此建议：优化时先调这个旋钮，再考虑换模型，因为同模型跨档位的表现差异，有时比跨模型的差异还大。

实战选型指南

根据不同任务类型，选型策略可以归纳为：

• 大批量支持工单分类：Haiku，快速且便宜
• 修bug并撰写发布说明：Sonnet
• 运行数小时的代码库迁移：Opus
• 审查每个Pull Request：Sonnet为主，高风险变更用Opus
• 长时间深度研究：Fable

多模型协作：Team模式

不必只选一个模型。Anthropic描述了"Teamer"模式——由强模型协调，便宜模型执行批量工作。在一次测试中，Fable领导25个Sonnet worker的总成本约为单独使用Fable的一半，耗时从15小时以上降至不到2.5小时。质量分数低了10到12分，但整体表现仍优于Sonnet单打独斗。

实际操作中，可以通过/model命令切换模型。如果需要Opus规划、Sonnet执行的分工，可以使用Opus Plan模式。子代理甚至可以设定为运行在Haiku上。

子代理（subagent）与编排模式

子代理指由一个"主模型"派生、负责执行具体子任务的独立模型实例，它可以运行在更便宜的模型上（例如 Haiku），从而把昂贵模型的算力集中用在规划、判断和质量把关上。Team 模式正是这种思路的规模化版本：一个强模型充当"协调者"，把任务拆解分发给多个廉价 worker 并行处理，最后汇总结果。这样做的好处是并行带来时间压缩、廉价模型摊薄单位成本；代价是拆分与汇总本身可能丢失上下文细节，质量会有折损（文中测试掉了 10 到 12 分）。是否值得，取决于任务对质量的敏感度以及能否容忍小幅降级。

选型方法论

两条路径可选：从Haiku起步、按需升级；或从Opus起步、逐步降级。无论哪条路，在切换模型之前，先试试调节推理力度旋钮——这往往是性价比最高的优化手段。