别无脑上最强模型：我的 Claude 月费从 $63 砍到 $19
Anthropic 官方讲 Fable、Opus、Sonnet、Haiku 怎么选：Opus + medium 起步，先调 effort 再换模型。我按这个思路把知识库 7 个自动任务重新分配模型，粗算月费省七成，附子 agent 和定时任务配置。
很多人用 Claude 有个习惯：遇到问题，第一反应是切到最强的模型。Fable 不行就开 max，再不行就骂模型。
钱烧了，结果还不一定更好。
昨天 Anthropic 官方博客发了一篇 Addy Osmani 写的长文《Which Claude model should you build with?》，专门讲 Fable、Opus、Sonnet、Haiku 四个模型怎么选。我读完最大的感受是：官方自己都在劝你别无脑上最强模型。
这篇我先把官方的结论讲清楚，然后拿我自己的知识库系统开刀——每天有七八个自动任务在跑，我把它们按官方思路重新分配了一遍模型。
先看价格：最便宜和最贵差 80 倍
当前四个正式可用的模型（每百万 token，输入 / 输出）：
| 模型 | 定位 | 输入 / 输出 | 缓存读取 |
|---|---|---|---|
| Haiku 5.5 | 大批量、成本敏感 | $0.10 / $0.50（≤100K） $0.50 / $2.50（>100K） | $0.01 |
| Sonnet 5.5 | 范围清晰的日常任务 | $2 / $10 | $0.10 |
| Opus 5.5 | 复杂编码和知识工作的主力 | $4 / $20 | $0.20 |
| Fable 5.2 | 最难、最开放的技术工作 | $8 / $40 | $0.20 |
四个模型上下文都是 1M，最大输出都是 128K。
Haiku 的输入价是 Fable 的 1/80。同样一个"给文章打标签"的活，用错模型就是 80 倍的差价。
注意 Haiku 有个特殊点：prompt 超过 100K token，价格直接涨 5 倍。所以 Haiku 适合短 prompt 的高频活，喂一大堆上下文给它，就没那么划算了。
官方结论：Opus + medium 起步，然后上下调
官方给的 TL;DR 就一句话：大多数工作从 Opus 5.5、effort medium 开始。
这也是 Claude Code 现在的默认配置。然后：
- 往下换 Sonnet：范围清晰的日常活，比如修 bug、按 spec 写功能、反复跑的 agent 任务
- 再往下换 Haiku：分类、路由、抽取这种最简单的大批量活，以及给大模型打下手的子 agent
- 往上换 Fable：大重构、大迁移、架构规划、带一堆子 agent 干活，或者 Opus 开到
high还搞不定的
有一句很容易被忽略：spec 写得清楚，不代表就该用 Sonnet。 迁移、性能优化这类活 spec 可以写得很清楚，难度照样够得上 Opus。
反直觉的一点：先调 effort，再换模型
这部分我觉得全文最值钱。effort 是比换模型更细的旋钮。官方给了一组 SWE-bench Pro 上的数据（Opus 5.5，以 high 为基准）：
| effort | 得分变化 | 成本 |
|---|---|---|
low | 约 -8 分 | 约 1/3 |
medium | 约 -2.5 分 | 约 70% |
high | 基准 | 基准 |
xhigh | 约 +1.4 分 | 2.5 倍 |
从 high 到 xhigh，多花 1.5 倍的钱，换 1.4 分。
还有一组对比：Terminal-Bench 3.0 上，上一代 Fable 5.1 开 max 得分 58.0%，Opus 5.5 开 high 得分 58.9%，token 只用了一半。
所以官方的建议是：effort 一旦要开到 high 以上，先别往上加了，试试上一档模型配低一点的 effort。很多时候降一档 effort 也够用，还更便宜。
effort 管不了所有事。它能让模型想得更久、多调几次工具、多检查几遍，可模型本来就不会的东西，开多高也没用，这时候只能换模型。
模型不够用时，按这个顺序排查
官方给了一个三步顺序，我觉得可以直接贴在墙上：
- 先检查模型能不能自己验证结果：有没有测试、有没有 build、有没有能调接口的脚本
- effort 往上调一档
- 换上一档模型，而且从比原来更低的 effort 开始
第一步最容易被跳过。没测试、没 build，模型改完自己也确认不了对不对，只能猜。
一个省钱的组合拳：低档全跑，失败的再高档重跑
如果结果能自动检查，可以全部任务先用低 effort 跑，只把失败的用高 effort 重跑。
官方数据：Opus 5.5 先 low 跑、失败的用 high 重跑，通过率约 97%，每个任务约 $0.17；全部直接用 high，通过率 95.3%，每个任务 $0.29。
更便宜，通过率反而更高。
实操：我把知识库的自动任务重新分了一遍
光看官方的表没意思，我拿自己的系统试了一遍。
我有一个用 Claude Code 搭的个人知识库（之前写过），每天有一堆任务定时自动跑：
- 06:03 生成每日洞见简报
- 扫收件箱，按我的兴趣过滤素材
- 给当天新增文章分类，判断适合做视频、公众号还是推特
- 22:00 生成第二天的内容发布计划
- 08:30 读当天计划推送提醒
- 自动发推
- 定时提醒我去 X 上互动
- 把原始素材编译成 wiki 条目
以前这些全跑在默认模型上。按官方的思路过一遍，好几个明显是大材小用。
重新分配后的方案
| 任务 | 原来 | 现在 | 理由 |
|---|---|---|---|
| 定时提醒去 X 互动 | 默认模型 | 不用模型 | 固定文案，脚本直接推送 |
| 自动发推 | 默认模型 | Haiku | 读计划、找当天条目、发出去，纯执行 |
| 新文章分类 | 默认模型 | Haiku | 典型的分类任务，分错一眼就能看出来 |
| 收件箱过滤 | 默认模型 | Haiku + 兜底规则 | 分类任务，但误归档不容易发现，所以拿不准的留在收件箱 |
| 生成内容计划 / 推送提醒 | 默认模型 | Sonnet medium | 反复跑的起草任务，官方原话："Well-defined, repeated tasks rarely need a bigger model" |
| 每日洞见简报 | 默认模型 | Sonnet medium | 有"连接点""观点碰撞"这种判断，但格式固定，每天跑 |
| 编译 wiki（涟漪更新） | 默认模型 | Opus medium + Haiku 子 agent | 要判断哪些旧条目受影响，是真正的判断活；读原文交给 Haiku |
| 仓库大重构 | — | Fable | 一年也就一两次，用就用最好的 |
收件箱过滤那一行多说两句。官方的原则是：小模型只放在"出错了很容易发现"的地方。 文章分类分错了，我看计划的时候一眼就知道；但收件箱过滤要是把一篇好文章归档了，我可能永远不会再看到它。所以给 Haiku 加一条规则：拿不准的不归档，留在收件箱等我看。
粗算一笔账
我手上没有每个任务精确的 token 用量，下面按一个假设粗算：每个任务平均读 5 万 token、写 5 千 token，不考虑缓存。
单次成本：
- Opus：5 万 × $4/M + 5 千 × $20/M = $0.30
- Sonnet：5 万 × $2/M + 5 千 × $10/M = $0.15
- Haiku：5 万 × $0.10/M + 5 千 × $0.50/M ≈ $0.0075
原来 7 个任务全用 Opus：每天约 $2.10，一个月约 $63。
现在：1 个不用模型 + 3 个 Haiku + 2 个 Sonnet + 1 个 Opus，每天约 $0.62，一个月约 $19。
省了七成左右。数字是粗算，真实情况用 /usage 看，但量级摆在那。
具体怎么配：能直接抄的配置
1. 交互式会话里切换
/model # 切换模型
/effort # 调 effort，/effort status 查看当前值
/usage # 看用量
官方推荐的快速对比方法：从待办里挑一个真实任务，用 /model 在两个模型上各跑一遍，比较 /usage 的数字。
2. 给子 agent 指定小模型
存成 .claude/agents/log-reader.md：
---
name: log-reader
description: Reads test output and logs, and reports each failing case. Use after a test run.
tools: Read, Grep, Glob, Bash
model: haiku
---
Read the logs you're given. For each failure, report the file, the test name and the first error line. Don't edit any files.
没单独指定模型的子 agent，可以用环境变量统一设默认值：
export CLAUDE_CODE_SUBAGENT_MODEL=haiku
3. 一个容易踩的坑：Explore 子 agent 不再默认用 Haiku
新版 Claude Code 里，内置的 Explore 子 agent 用的是你当前会话的模型，不再固定用 Haiku。你主会话开着 Fable，它翻文件也按 Fable 计费。
想让探索便宜下来，自己定义一个同名子 agent 覆盖掉：
---
name: Explore
description: Read-only search agent for finding files and code.
tools: Read, Grep, Glob
model: haiku
---
Search the codebase and report locations and short excerpts. Don't edit any files.
4. 定时任务用命令行指定模型
定时跑的 headless 任务，直接在命令里写死模型：
claude -p "执行 /triage" --model haiku
claude -p "执行 /briefing" --model sonnet
切模型的时机：别在对话中间乱切
prompt 缓存是跟着模型走的。长对话中间切模型，新模型的第一轮要把整段对话按缓存写入价重新付一遍。
thinking block 也有跨模型的限制：往下切一档，之前的推理过程就丢了，小模型读不了大模型的思考块。
所以官方建议在"自然断点"切换：
- Claude Code 里先
/compact再切，或者干脆开新会话，带一份简短的书面计划 - API 里用一段摘要开启新模型的对话，别带完整历史
关于 opusplan，官方自己也留了个心眼
Claude Code 有个 opusplan 别名：plan 模式用 Opus 做规划，执行用 Sonnet 改代码。
但官方在这篇文章里明确说了，这跟他们的建议正好相反：官方建议代码修改留在主模型上，小模型只干出错容易发现的活。所以如果你想把 opusplan 设成默认，先在自己的任务上测一测。
官方最后一节：在自己的任务上测
原文最后一节叫"Measure on your own work"，四步：
- 挑一批真实任务，每个都写好结果检查（测试通过、工单关闭、行数对得上）
- 每个候选模型跑两三档 effort，各开独立会话，别共享缓存
- 把得分和花费画成图，组合方案只有在打败所有单模型方案时才值得保留
- 赢家先在一部分真实流量上影子运行，再正式切换
有个数据我记下了：在一个 20 道题的测试集上，最难的 2 道题占了 43% 的花费。比较模型时只拿典型任务去测，会把账算错一大截。
回头看我自己那张表也是这样。每天 $0.62 里，编译 wiki 一个任务就占了 $0.30，差不多一半。那三个换成 Haiku 的任务加起来才两分钱。下一步要省钱，该盯的是 wiki 编译。