Sonnet总比Opus便宜一半吗？

不是。未缓存输入/输出公开单价确实为一半，但缓存、token 消耗、重试与工具费用都会影响任务总成本。上面的示例就是为了单独看清这几项差异。

代码审查一定要用Opus吗？

文档不能推出这样的普遍规则。应在代表性审查任务里比较确认的问题和误报，并统计人工核验每项发现的时间。

受支持的流程可以包含可见消息，但思考块有兼容性规则。应查迁移文档，不能假设全部隐藏状态都会转移。

边界清楚的编程任务，可以先评估 Sonnet 5.5；需要更复杂判断、问题含糊或反复失败的任务，可把 Opus 5.5 加进测试。这是一种按工作负载选候选模型的方法，不证明 Sonnet 必定能处理小任务，也不证明 Opus 一定赢得大任务。验收仍以仓库测试和审核标准为准。

Anthropic 把 Sonnet 定位为更快、成本更低的 Opus 补充，把 Opus 用于需要审慎判断的复杂工作。但计费项目和 effort 配置让选择不止于“Sonnet便宜一半”。本文依据 2026 年 9 月 29 日核对的文档，不声称做过原创模型对测。

来源：Sonnet规格和Opus规格。这是厂商价格，不是订阅额度或 Ofox 报价。反复使用仓库上下文时，尤其应看缓存读取这一行：较大的缓存前缀，并不存在未缓存输入和输出那样的两倍价差。

假设两次请求都读取 100,000 个缓存 token，并产生 2,000 个计费输出 token，不计其他项目。Sonnet 的费用为 0.04 美元，Opus 为 0.06 美元。这是算术示例，因缓存读取同价，合计费用并非两倍关系。如果某款需要额外轮次，比较结果还会变化。

任务	建议从怎样的比较开始	应保留的证据
可稳定复现的Bug	先试适中effort的Sonnet，必要时再试Opus	失败测试、补丁、完整回归测试
需求明确的小功能	Sonnet与当前可靠基线比较	验收清单、修改范围
原因不明的跨模块故障	一开始就纳入Opus	不同解释、检查过的文件、验证过的原因
仓库代码审查	两款使用相同范围	确认的问题与误报
高风险迁移	分别比较方案和验证过程	迁移清单、回滚路径、集成测试

这些是测试设计，不是实测通过率。短补丁也可能需要很难的推理，大量机械修改反而可能简单。单靠文件数量或改动行数，无法可靠衡量任务难度。

Artificial Analysis的Sonnet发布评测展示了多项较强成绩，也指出 max 档的输出消耗高得多。报告同时说明，测试用的预发布部署存在结构化输出问题，相关项目将重跑。这些结果可以支持同时评估两款模型，却不能直接确定你最省钱的配置。

拿 Opus medium 与 Sonnet max 对测，得到的是配置比较，不能称作只改变模型的对比。这样的测试仍然有价值，但要公开两边设置与实际预算。同名 effort 也不保证算力相同。

Anthropic 的发布说明也描述了不同模型的长处和评估条件。厂商主张、独立测量与自己的观察应分开记录。图表不一致，可能只是任务或设置不同，并不一定存在无法解释的矛盾。

运行前先写停止条件，例如只提出一次修复并做回归检查。检查失败后，先看失败原因再重跑。如果模型误解了任务，应先澄清输入，不要盲目提高 effort。如果方向正确却写不出有效修复，再尝试 Opus 就是一次有价值的受控升级。

新运行应带上问题说明、相关文件与测试结果。不要假设加密思考块可以跨模型通用。Sonnet 5.5 对模型和对话有特定规则，见迁移指南。应保留可见证据，不要依赖隐藏思考状态自动延续。

第一次尝试与升级后的费用要一起记录。否则路由系统可能把前一次失败算到一个模型头上，却只统计另一个模型最后成功的成本，让结果显得虚假便宜。审核时间也要保留：能编译、但仍需要大量清理的补丁，还不算完成任务。

不能把 API 价格表直接换算成 Claude Code 的精确可用提问次数。订阅额度与使用限制受账户和服务条件影响。客户端更新或供应商变化后，尤其要确认实际选择的模型，并把计费模式与模型名分开记录。

Claude Code设置指南介绍版本检查与明确选模；effort指南区分 API 与 Claude Code 默认值。考虑其他厂商时，可按 Sonnet与Sol比较指南设计受控测试。