Claude 三档模型怎么选：同一套编码测试，差距全在账单上
原文：OpenRouter - 《Claude Opus vs Sonnet vs Haiku: Which Should You Use?》（https://openrouter.ai/blog/insights/claude-opus-vs-sonnet-vs-haiku/）
一、问题的起点：默认模型不是你以为的那个
OpenRouter 这篇实测报告里，最反直觉的一句话是：Claude Code 在 Pro、Max、Team、Enterprise 和 API 账号上默认用的都是 Opus 5.5。如果你从没改过模型设置，那么你一直在跑最贵的那一档。
紧接着的第二个结论更值得停下来看。在他们跑的编码测试里，Opus 5.5 并没有赢过 Sonnet 5.5，两档分数打平，但 Sonnet 每 token 便宜一半。
这篇文章的价值不在于"推荐用哪一档"，而在于它把"模型选择"这件事拆成了一张能核对的账。我们按它的顺序来读。
二、三档模型的基本盘
Opus 5.5 于 2026 年 9 月 22 日发布，Sonnet 5.5 于 9 月 28 日，Haiku 5.5 于 10 月 7 日。三者同属一个代际，上下文窗口都是 100 万 token，都接受文本、图片和 PDF。差别主要落在价格上，以及 Haiku 的基准分数。
| 指标 | Opus 5.5 | Sonnet 5.5 | Haiku 5.5 |
|---|---|---|---|
| 输入（每百万 token） | 4.00 美元 | 2.00 美元 | 0.10 美元 |
| 输出（每百万 token） | 20.00 美元 | 10.00 美元 | 0.50 美元 |
| 缓存读取（每百万 token） | 0.20 美元 | 0.10 美元 | 0.01 美元 |
| 智能指数 | 57.6 | 56.0 | 43.4 |
| GPQA Diamond（OpenRouter 实测） | 90.4% | 92.4% | 86.6% |
| τ-bench airline（OpenRouter 实测） | 75.5% | 78.7% | 76.0% |
表格里的价格是 2026 年 10 月 21 日的列表价，基准数据来自 10 月 17 日的运行。智能指数是第三方机构 Artificial Analysis 打的综合分，横跨 10 项评测。
有几个数字要单独点出来，因为它们容易被读反：
- 智能指数上 Opus 领先 Sonnet 1.6 分。这是三档里唯一 Opus 明显领先的地方，而这个指数里 agentic 任务和通用知识各占 30%，编码和科学推理各占 20%。
- 两个实测基准上 Sonnet 都反超了 Opus：GPQA Diamond 高 2 分，τ-bench airline 高 3.2 分。
- Haiku 在两个基准上比 Sonnet 分别低 5.8 分和 2.7 分，但它比 Opus 高 0.5 分。
最后一条说明什么？在这样的分数密度下，单个基准的几分差距很可能只是噪声。原文自己承认，每档只跑了 100 到 200 个任务，几个点的差距不足以定性。
三、编码测试：全员满分，只比账单
真正有意思的是两组编码测试，因为三档模型的分数完全一样。
第一组是 11 道 Python 题，每道题配一个隐藏测试文件。8 道日常题（解析时长、合并区间、LRU 缓存、不借助 eval 的算术求值器、cron 表达式下次运行时间、文本折行、SemVer 排序、JSON 路径读取），3 道难题（不用 re 模块写正则引擎、带三值 NULL 逻辑的 SQL WHERE 过滤、跨时区并在夏令时切换日的空闲时段计算）。每档模型每题都做了重复运行，合计 25 次尝试。
结果：三档都是 25 次全过。差别全是钱。
| 指标 | Opus 5.5 | Sonnet 5.5 | Haiku 5.5 |
|---|---|---|---|
| 通过次数 | 25/25 | 25/25 | 25/25 |
| 日常题单次成本 | 0.0211 美元 | 0.0112 美元 | 0.0007 美元 |
| 难题单次成本 | 0.0739 美元 | 0.0380 美元 | 0.0027 美元 |
| 难题单次耗时 | 32.1 秒 | 25.7 秒 | 22.6 秒 |
第二组更贴近真实工作：给 Claude Code 一个只有三个 bug、五个测试的小型发票库。三个 bug 分别是银行家舍入（四舍六入五取偶）、CSV 解析器在引号内的逗号处错误切分、汇总时覆盖数量而非累加。每档模型跑三次，通过设置 ANTHROPIC_MODEL 环境变量来切换模型。
结果同样整齐：三档都是 3/3 全部修好。每档的中位会话成本依次是 0.098、0.062、0.0052 美元。
这里 Haiku 的成本比 Opus 低了将近 19 倍，但它多用了轮次：Opus 是 5 轮，Haiku 是 6 到 8 轮。也就是说，便宜模型的单价优势会被"多跑几轮"吃掉一部分，但吃得不多。
还有一个细节值得记下来：难题上 Haiku 反而最快，22.6 秒，比 Opus 快近 10 秒；它的推理 token 平均用了 3202 个，Opus 是 1252 个。Haiku 想得更多，但想得更快，最后总成本还是便宜了 27 倍。这说明"低阶模型就是阉割版"这个直觉不成立，它们往往是在参数规模之外用了不同的推理配置。
四、一个会误导你的成本数字
原文专门标出了一处坑：Claude Code 自带的 total_cost_usd 字段不认 OpenRouter 的 Haiku slug，报出的会话成本是 0.16 到 0.31 美元，而按列表价算出来的中位数是 0.0052 美元，差了 30 到 60 倍。
在打印模式下运行会看到这样的告警：
[claude-code:unrecognized_model] {"model":"anthropic/claude-haiku-5.5","query_source":"sdk"}这提醒我们一件事：成本核算必须以账单或请求返回的 usage 字段为准，不能相信客户端自己算的数。第三方的成本面板之所以容易被误信，就是因为它看起来很精细。
五、怎么在自己的项目里验证
原文提供了 OpenRouter 上的调用示例，我把它改成了带成本断言的版本，方便直接拿来做决策。
# 基于原文示例改写，模型名与价格口径以官方文档为准importosimportrequests MODELS={"anthropic/claude-opus-5.5":{"in":4.00,"out":20.00},"anthropic/claude-sonnet-5.5":{"in":2.00,"out":10.00},"anthropic/claude-haiku-5.5":{"in":0.10,"out":0.50},}PROMPT="Write a Python function that merges overlapping intervals."defrun(model):r=requests.post("https://openrouter.ai/api/v1/chat/completions",headers={"Authorization":f"Bearer{os.environ['OPENROUTER_API_KEY']}"},json={"model":model,"messages":[{"role":"user","content":PROMPT}]},timeout=300,)r.raise_for_status()returnr.json()["usage"]formodelinMODELS:u=run(model)p=MODELS[model]# usage 里带 prompt_tokens / completion_tokens / cost 三个关键字段print(f"{model:32s}out={u['completion_tokens']:5d}tok "f"cost=${u['cost']:.4f}"f"in={u.get('prompt_tokens',0)}tok")这段代码对应原文 10 月 13 日的实测输出：同一个提示词，Opus 输出 1190 token 花了 0.0239 美元，Sonnet 输出 876 token 花 0.0088 美元，Haiku 输出 852 token 花 0.0004 美元。注意 token 数并不一样，输出越长的那次自然越贵，所以比较成本要在同一任务上比，不能只比单价。
要判断哪一档适合你的项目，原文给的建议是用 Ori Eval：让编码 Agent 在你的代码库里找测试素材、写出评测、跑你指定的几个模型，最后给出分数、耗时和成本。他们给的评测文件是 TypeScript 的 eval.ts 格式，把三档的 slug 分别传给 setupAgent 的 model 参数，同一套测试就都能跑一遍。
同样把口径说清：我没有复现这些测试。上面的数字全部来自 OpenRouter 的原文，我的改动只是把示例代码整理了一下并加上成本打印。
六、按角色分配模型，比选一个"最强"更划算
原文给出的选型建议很简单，也很实用：
默认用 Sonnet 5.5。它在两个基准上不低于 Opus，在全部编码测试上打平，单价便宜一半。
高频任务用 Haiku 5.5——分类、抽取、路由、子智能体、批量改代码这类。它在测试里全部通过，成本是 Sonnet 的 1/12 到 1/16，是 Opus 的 1/19 到 1/30。前提是把提示词控制在 10 万 token 以内，才能守住低档价格。
长任务、模糊任务、错一次代价高的任务留给 Opus 5.5。原文也很诚实地承认，他们测试的都是短任务，没有覆盖 Opus 被设计来做的长程 agentic 编码，所以那里的优势不能排除。
在 Claude Code 里可以直接按角色拆分模型，原文给了四个环境变量：
export ANTHROPIC_DEFAULT_OPUS_MODEL="anthropic/claude-opus-5.5" export ANTHROPIC_DEFAULT_SONNET_MODEL="anthropic/claude-sonnet-5.5" export ANTHROPIC_DEFAULT_HAIKU_MODEL="anthropic/claude-haiku-5.5" export CLAUDE_CODE_SUBAGENT_MODEL="anthropic/claude-haiku-5.5"这四个变量只决定"每个名字指向哪个模型"，不决定你实际用哪个。要让 Sonnet 成为主模型，得在会话里执行 /model sonnet，或者启动前设置 ANTHROPIC_MODEL。想让 Opus 做规划、Sonnet 写代码，用 /model opusplan。最后一行把子智能体默认指到 Haiku，任何没有自己指定模型的子任务都会跑在便宜档上。
还有一个容易漏的细节：Claude Code 2.1.307 认 Opus 和 Sonnet 的 slug，会给它们 100 万 token 上下文；但它还不认 Haiku 的 slug，默认按 20 万 token 处理。想给 Haiku 完整窗口，要在 slug 后面加[1m]后缀，OpenRouter 在路由前会把这个后缀剥掉。不加的话，Haiku 会话会被压在 20 万 token 左右。
这一条对做多档模型路由的人是个通用提醒：模型名不只是一个标识，上下文窗口这类元信息也要跟着走，客户端不认识这个名字，就会用默认值兜底，而这个默认值往往是旧版本的。
七、结论：三档差距不在能力，在成本和场景
把这篇报告读完，我自己的收获是三点。
其一，在明确的、有测试可验的任务上，同代际的三档模型差距很小，小到测试集本身的分辨能力都不够用。这种情况下先按成本选。
其二，真正区分三档的是任务长度和失败代价。短任务、结构清晰的活，便宜模型能干；长任务、需求模糊、错一次要回滚重来的活，贵模型值那个钱。这个判断标准比看榜单分数靠谱。
其三，成本核查要自己做。客户端显示的成本可能错几十倍，第三方面板的统计口径也可能和你的账单不一样。按请求返回的 usage 字段自己算一遍，是最省心的做法。
