Anthropic的Claude选型指南，核心建议是先别急着换模型

Anthropic的开发者账号发了一份Claude模型选型指南，作者是Addy Osmani。开篇就给结论：大多数工作从Opus 5.5的默认medium effort开始。Claude Code默认用它不是没道理，输入输出价格是Fable 5.2的一半。

但这份指南真正值得看的部分，是关于effort档位和模型搭配的讨论。

四个模型，价格差八倍

当前Claude产品线有四个正式可用模型：Haiku 5.5、Sonnet 5.5、Opus 5.5和Fable 5.2。Mythos 5.2是网络安全和生命科学方向的专用模型，走验证项目申请。

价格差距很大。按API标价，每百万token输入输出：

四个模型的上下文窗口都是1M token，最大输出128K。Haiku 5.5是唯一按prompt长度分档计价的，超过100K token的prompt单价翻五倍。所以它最划算的场景是短prompt、高频调用。

FIG A展示的是同一张小巷照片，由四个模型分别写Python代码调用绘图引擎渲染出来。从第一层到完成，细节差异肉眼可见。但Addy没在文章里给这组图下优劣判断，只是放在那里。

effort档位比换模型更精细

指南里反复强调的一点：在换模型之前，先试试调整effort。

effort是比模型选择更细的旋钮，同时影响成本和能力。超过high之后，再升一档的成本可能赶上换更大的模型。反过来，降一档也可能拿到你需要的效果，价格还更低。

这里有个具体数字：在SWE-bench Pro上，Opus 5.5的medium比high低约2.5分，成本只要约70%。low比high低约8分，成本约三分之一。xhigh比high高约1.4分，成本却是2.5倍。

所以路线大致是这样：先确认模型能自己验证工作，有测试、构建脚本或接口调用；不行就升一档effort；还不行再换更大的模型，但从更低的effort开始。

如果任务结果可以自动检查，官方建议可以全部跑在低effort，只把失败的重新跑高effort。SWE-bench Pro子集上的数字：Opus 5.5 low加重跑失败项，通过率约97%，每任务$0.17；全部high是95.3%，每任务$0.29。

FIG B是四个模型各建一个作品集网站并排展示，FIG C是Fable 5.2渲染游戏引擎世界，从线框到光线追踪共十六种风格。这些图放在文章里，比单看benchmark百分比直观。

一个容易忽略的成本项：缓存和上下文

每一轮对话都会重新发送上下文，但长跑任务里大部分输入按缓存读取计费。Opus 5.5缓存读取每百万token $0.20，Sonnet 5.5是$0.10，Fable 5.2和Opus一样是$0.20。

这说明一件事：主模型越大，主上下文越要瘦。把决策留给贵模型，让便宜子代理去读日志、搜文件、做摘要。

Haiku 5.5在这件事上有天然优势。短prompt下它的输入价格是Sonnet 5.5的二十分之一。但如果每次调用都带长prompt，就得按完成任务的成本来比，不能只看标价。

FIG D展示了一个项目里四个模型分工：Fable 5.2把网店从JavaScript迁到TypeScript，Opus 5.5搭月度订阅，Sonnet 5.5写产品页，Haiku 5.5分类客户消息。

子代理该塞小模型，但有个坑

指南建议把子代理放在Haiku 5.5或Sonnet 5.5上，只做那种错了也容易发现的工作：找文件、跑测试、读日志。代码编辑和判断留给主模型。

在Claude Code里，可以在子代理定义里写model: haiku，或者用CLAUDE_CODE_SUBAGENT_MODEL环境变量设默认值。

但有个变化值得注意。有网友在回复里指出，当前版本的Claude Code内置Explore子代理跑在会话模型上，不再固定用Haiku。想省钱的话，可以自己定义一个叫Explore的子代理，锁定model: haiku。

FIG E是个地图demo：Opus 5.5做规划，多个Haiku 5.5子代理并行画图层，包括海拔、自行车道、雾和温度。温度是示意值，雾是印象不是预报。

切换模型前要检查兼容性

模型选择不总是改个名字就完事。指南列了几个迁移时要测的点。

Fable 5.2把preserved thinking扩展到所有API账户。thinking块之前的任何内容变了，包括system prompt、工具或更早的消息，API会返回400错误，除非你选择丢弃受影响的thinking。

强制工具调用也有变化。tool_choice设为any或tool，在Sonnet 5.5、Opus 5.5和Fable 5.2上会返回400。得改成auto，把工具标为strict: true，在prompt里写清楚什么时候用。

还有thinking块兼容性的问题。不同模型能读的thinking块不一样。Opus 5.5能读Sonnet和Haiku的，Fable 5.2能读Opus、Sonnet和Haiku的。往下一级换模型，之前的推理块会丢。

如果一套系统跑多个模型，指南建议每个请求都按最严格的模型来构造：历史保持append-only，tool_choice用auto配strict工具，按type读content block。这样上下换模型不需要改代码。

在自己的任务上测，别只看benchmark

指南最后给了一套测量流程：从真实任务里抽样，给每个任务写结果检查，每个候选模型跑两三个effort档位，每个跑在独立session里避免共享缓存，记录每个完成任务的成本，画分数对花费的图。多模型方案只有在图上赢过所有单模型点时才值得保留。

Claude Code里有个快速办法：用/model把同一个任务跑两个模型，对比/usage的数字。

评论区里有几条吐槽值得放在这里。有网友说，模型能力一直在变，这份指南能不能撑过一个月不好说。也有人提到，effort那节最该先读，很多成本抱怨来自日常任务开了Max effort。还有人开玩笑说，要用Fable 5.2改按钮颜色。

指南原文在claude.dev，作者Addy Osmani。里面还链到Sonnet 5.5和Opus 5.5的单独指南，以及effort和子代理的文档。