# 别无脑上最强模型：我的 Claude 月费从 $63 砍到 $19

> Anthropic 官方讲 Fable、Opus、Sonnet、Haiku 怎么选：Opus + medium 起步，先调 effort 再换模型。我按这个思路把知识库 7 个自动任务重新分配模型，粗算月费省七成，附子 agent 和定时任务配置。

- 原文链接: https://laojin.blog/blog/20261110_claude_model_selection
- 作者: 老金
- 发布日期: 2026-11-10
- 标签: Claude, Claude Code, 模型选择, AI 编程, 成本

---

![别无脑上最强模型：我的 Claude 月费从 $63 砍到 $19](https://pic-1258874139.cos.ap-hongkong.myqcloud.com/laojinblog/posts/20261110/00_cover.png)

很多人用 Claude 有个习惯：遇到问题，第一反应是切到最强的模型。Fable 不行就开 `max`，再不行就骂模型。

钱烧了，结果还不一定更好。

昨天 Anthropic 官方博客发了一篇 Addy Osmani 写的长文[《Which Claude model should you build with?》](https://claude.dev/blog/which-claude-model-should-you-build-with/)，专门讲 Fable、Opus、Sonnet、Haiku 四个模型怎么选。我读完最大的感受是：官方自己都在劝你别无脑上最强模型。

这篇我先把官方的结论讲清楚，然后拿我自己的知识库系统开刀——每天有七八个自动任务在跑，我把它们按官方思路重新分配了一遍模型。

---

## 先看价格：最便宜和最贵差 80 倍

当前四个正式可用的模型（每百万 token，输入 / 输出）：

| 模型 | 定位 | 输入 / 输出 | 缓存读取 |
|---|---|---|---|
| Haiku 5.5 | 大批量、成本敏感 | $0.10 / $0.50（≤100K）<br />$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 管不了所有事。它能让模型想得更久、多调几次工具、多检查几遍，可模型本来就不会的东西，开多高也没用，这时候只能换模型。

### 模型不够用时，按这个顺序排查

官方给了一个三步顺序，我觉得可以直接贴在墙上：

1. 先检查模型能不能自己验证结果：有没有测试、有没有 build、有没有能调接口的脚本
2. effort 往上调一档
3. 换上一档模型，而且从比原来更低的 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`：

```markdown
---
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，可以用环境变量统一设默认值：

```bash
export CLAUDE_CODE_SUBAGENT_MODEL=haiku
```

### 3. 一个容易踩的坑：Explore 子 agent 不再默认用 Haiku

新版 Claude Code 里，内置的 Explore 子 agent 用的是你当前会话的模型，不再固定用 Haiku。你主会话开着 Fable，它翻文件也按 Fable 计费。

想让探索便宜下来，自己定义一个同名子 agent 覆盖掉：

```markdown
---
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 任务，直接在命令里写死模型：

```bash
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"，四步：

1. 挑一批真实任务，每个都写好结果检查（测试通过、工单关闭、行数对得上）
2. 每个候选模型跑两三档 effort，各开独立会话，别共享缓存
3. 把得分和花费画成图，组合方案只有在打败所有单模型方案时才值得保留
4. 赢家先在一部分真实流量上影子运行，再正式切换

有个数据我记下了：在一个 20 道题的测试集上，最难的 2 道题占了 43% 的花费。比较模型时只拿典型任务去测，会把账算错一大截。

回头看我自己那张表也是这样。每天 $0.62 里，编译 wiki 一个任务就占了 $0.30，差不多一半。那三个换成 Haiku 的任务加起来才两分钱。下一步要省钱，该盯的是 wiki 编译。