成本与模型选择：把 token 花在刀刃上

团队里常见这样的情形：有人一天用掉的额度抵得上别人一周。问他做了什么，没什么特别的：开了一个会话，从早上干到晚上，中间换过两次模型，挂着七八个 MCP 服务器。

智能体的成本有几个反直觉的特点：它不是按「你说了多少话」计费，而是按每一次请求里发送的全部内容计费，而一次任务里有几十上百次请求。理解这一点，就理解了绝大部分节省手段。

token 怎么计费

按 token 计费的基本单位是「每百万 token 多少钱」，分成几类：

• 输入：你发给模型的全部内容，包含系统提示词、说明文件、整个历史、所有工具结果。
• 输出：模型生成的内容。思考（thinking）token 也按输出计费，输出单价通常是输入的数倍。
• 缓存写入与缓存读取：见下一节。

为什么说账单增长快？智能体每调用一次工具，就是一次新请求，请求里要带上到那一刻为止的完整历史。官方文档把这个现象讲得很清楚：在一个开了一整天的会话里问一句话，也要为整段对话付一次费，只是读缓存的价格更低。

价格会变，下面是我在核实日（2026-10-25）从 Anthropic 官方定价页读到的部分数字，只用来建立数量级的感觉，使用前请自己再确认：

模型	输入（每百万）	输出（每百万）
Claude Haiku 5.5（提示 10 万 token 以内）	$0.10	$0.50
Claude Sonnet 5.5	$2	$10
Claude Opus 5.5	$4	$20
Claude Fable 5.1	$10	$50

缓存的倍率更稳定：5 分钟缓存写入是基础输入价的 1.25 倍，1 小时写入是 2 倍；缓存命中读取一般是 0.1 倍，Opus 5.5 与 Sonnet 5.5 是 0.05 倍。批处理接口输入输出各打五折，但智能体的交互式会话用不上。

提示缓存：最大的一笔节省，也最容易被你打破

做个简化的估算（忽略上下文增长和输出）：用 Sonnet 5.5，上下文固定 10 万 token，一次任务里发起 40 次请求。

• 没有缓存：40 × 10 万 = 400 万输入 token，约 8 美元。
• 有缓存：首次写入 10 万 token 约 0.25 美元，之后 39 次读取共 390 万 token 约 0.39 美元，合计约 0.64 美元。

差了一个数量级。Claude Code 自动使用缓存，但官方文档说明，缓存是对请求前缀的精确匹配，前面任何地方变了，后面全部重算。所以这些操作会让下一轮又慢又贵：

操作	为什么破坏缓存	怎么避免
会话中途 /model 切换模型	每个模型有自己的缓存，切换后整段历史按未命中重算	会话开头定好模型；需要大模型时开新会话
多数模型上中途改 effort	同样会重算（用 API 密钥或订阅登录时，Opus 5.5、Sonnet 5.5、Haiku 5.5 例外）	开头定好
中途增删 MCP 服务器（未启用工具搜索时）	工具定义在系统提示层，变了就全废	开会话前配好
/compact、自动压缩	对话层被摘要替换，重建缓存	放在任务间隙，别在任务中途
离开太久再回来	缓存过期（API 密钥默认 5 分钟，订阅的主对话默认 1 小时）	长时间离开前先 /clear 或收尾
使用 opusplan 切换计划/执行	计划用 Opus，执行用 Sonnet，每次切换都是换模型	知道它有这个代价

不会破坏缓存的操作也值得记：在会话中途编辑 CLAUDE.md 不会让缓存失效，但也不会生效，要等到 /clear、/compact 或重启；/rewind 还会回到一个已缓存的前缀。运行 /usage 可以看到一行 Prompt cache (main)，写着命中的输入占比、未命中次数，在能识别时还会点出最近一次未命中的可能原因。

大模型、中等模型、小快模型怎么分工

选模型不是「越大越好」，也不是「越便宜越好」。我的做法是按出错的代价和任务的难度分三档：

档位	任务	说明
小快（Haiku 级）	搜索定位、读日志找报错、批量格式转换、整理提交信息、简单摘要	判断少，量大，贵模型纯属浪费
中等（Sonnet 级）	日常功能开发、按已有计划实现、写测试、常规 bug	官方文档的建议是 Sonnet 能处理大部分编码任务
大（Opus / Fable 级）	方案设计、疑难 bug 的根因分析、跨模块重构规划、安全评审	错一步返工成本高的地方

实操建议：

• 默认用中等模型，需要时升级，而不是默认最大。官方也提醒，API 或云厂商用量异常高，常见原因是会话没清理，以及默认模型一直是 Opus。
• 用别名而不是写死版本：sonnet、opus、haiku 会跟随供应商推荐的版本，但不同平台上别名指向的版本不同（例如 Bedrock 上的 sonnet 指向的并不是 Sonnet 5.5），需要稳定行为时用完整模型名或 ANTHROPIC_DEFAULT_*_MODEL 固定。
• effort 是第二个旋钮：/effort 可设 low、medium、high、xhigh、max。Opus 5.5、Sonnet 5.5、Haiku 5.5 默认 medium。简单任务调低能省思考 token。
• 别按轮次来回换模型。每次切换都要付一次未命中的代价。「计划用大模型、实现用中等」的做法有效，但应当是整个阶段切换一次，而不是每轮都换。
• 用你自己的数据决策。挑十个有代表性的任务，每个档位各跑一遍，记录「token 数 + 返工次数 + 是否通过评审」。便宜的模型返工三次，未必比贵的模型一次做对更便宜。

另外要摆正比例。官方给出的企业平均开销是每位开发者每个活跃日约 13 美元，每月 150 到 250 美元，90% 的用户每日低于 30 美元。对工程团队来说，一次返工浪费的半小时、一份难以评审的千行 diff，通常比 token 账单更贵。所以优先顺序是：先让任务第一次做对（规格、验证），再管缓存，最后才是模型分档。

其他工具（Codex、Cursor 等）的计费方式各不相同，有订阅额度，也有按量付费，本课的价格数据只核实了 Claude。但「每步重发上下文」「缓存」「大小模型分工」的原理是通用的，具体以各自官方文档为准。

子智能体：隔离上下文，不是白嫖省钱

子智能体最常被误解的一点是它能省钱。更准确的说法是：它省的是主会话的上下文，不是总 token。每个子智能体有自己的请求，要重新建立自己的缓存（它的前缀与父会话不同，第一次请求读不到父会话的缓存），而且官方说明子智能体默认只有 5 分钟缓存。Anthropic 在多智能体研究系统的文章里给出的量级是：智能体约是普通对话的 4 倍 token，多智能体约 15 倍。Claude Code 的 Agent Teams 在官方成本页面里也有说明：队友处于计划模式时，约是普通会话的 7 倍。

子智能体真正划算的情形是把读得多、判断少的活交给便宜模型。给它设置 model: haiku：

---
name: repo-scout
description: 只读调研。需要在代码库里定位相关文件、梳理调用关系、阅读大量日志时使用，只返回结论和文件路径。
tools: Read, Grep, Glob
model: haiku
---
你是只读调研员。根据任务描述，在代码库中查找相关文件和调用关系。
输出：1) 三句话以内的结论；2) 相关文件路径及各自作用；3) 你不确定的地方。
不要贴大段代码，不要提出修改方案。

放在 .claude/agents/repo-scout.md，团队提交即可共享。模型的解析顺序是：调用时指定 > 子智能体的 model 字段 > 环境变量 CLAUDE_CODE_SUBAGENT_MODEL > 主对话的模型。如果想让所有子智能体统一用某个模型，设置这个环境变量并加上 CLAUDE_CODE_SUBAGENT_MODEL_FORCE=1；想让内置的 Explore 用 Haiku，定义一个名为 Explore、model: haiku 的子智能体即可覆盖它。

请在 .claude/agents/ 下创建一个名为 repo-scout 的子智能体，要求：

1. 只读：tools 只给 Read、Grep、Glob；
2. 模型使用 haiku；
3. description 写清楚触发场景（需要读很多文件才能回答的调研），并强调「只返回结论和文件路径」；
4. 正文约定固定输出格式：结论不超过三句，文件清单带用途，最后列出不确定的点。

创建后，用它做一次真实调研：「梳理本项目中订单退款的完整调用链」。完成后告诉我：主会话上下文增加了多少，调研结果是否足以支撑下一步的实现。

看得见，才控制得住

• 会话内：/usage 的 Session 块显示本次会话的 token 与成本，数字由 Claude Code 在本地按公开价计算，是估算，权威数据以 Console 的用量页为准。订阅用户在同一界面还能看到用量归因（Skill、子智能体、插件、各个 MCP 服务器各占多少）和优化建议。状态栏可以持续显示上下文占用和成本。
• 个人复盘：/insights 生成一份报告，分析近期会话里的摩擦点。
• 团队：Teams 与 Enterprise 在管理后台看支出，并设置组织、分组或个人级别的上限；API 用户在 Console 为工作区设置支出上限；用云厂商的团队用云账单和 OpenTelemetry。官方给出的 Console 速率限制建议是：规模越大，人均 TPM 越低，例如 1 到 5 人约 20 万到 30 万 TPM，500 人以上约 1 万到 1.5 万。
• 无人值守的任务：在 GitHub Actions 里用 --max-turns 限制轮数，设置工作流超时和并发控制；claude -p 另有 --max-budget-usd 之类的预算参数，用法以 CLI 参考为准。

最后是一份「立刻见效」的习惯清单，全部来自官方成本页面：任务之间 /clear；CLAUDE.md 控制在 200 行内，偏门流程挪到 Skill；优先用 gh 这类 CLI 而不是挂满 MCP，因为 CLI 不增加按工具的列表；用 Hook 把测试输出先过滤再交给模型，把几万行日志压到几百行；写具体的提示，别让它「改进这个代码库」。

小测

一个已经进行了 2 小时、上下文约 15 万 token 的会话里，你遇到一个难题，直接用 /model 切到更大的模型继续问。关于成本，下列哪种说法最准确？

A 只有新问题的几百个 token 按新模型计费 B 新模型的缓存是空的，下一次请求要把整段历史当作未命中重新处理，成本显著高于一次普通请求 C 切换模型会清空上下文，所以反而省钱 D 缓存是跨模型共享的，所以没有额外成本

每个模型有自己的提示缓存，切换后整段历史都要重新写入。更省的做法是：开新会话，只带上必要的上下文（比如规格和计划文件）去问大模型，或者把难题交给指定了大模型的子智能体。

重新作答

小测

下面哪个子智能体配置最能在不损失质量的前提下降低成本？

A 让所有子智能体都继承主会话的大模型，保证质量一致 B 只读调研类子智能体设置 model: haiku，只允许 Read、Grep、Glob，只返回结论与路径 C 给每个子智能体都开启最高 effort D 用子智能体并行写同一模块的不同函数

调研、检索这类读多判断少的任务，小快模型已经够用，并且只返回摘要能保护主上下文。并行写代码的子智能体需要共享上下文，多智能体消耗的 token 远高于单智能体，也不适合强耦合的编码任务。

重新作答

动手清单

0/5

• 运行 /usage，找出你最近一次会话里输入、输出与缓存读取各占多少，以及 Prompt cache (main) 的命中比例
• 给你的团队写一条约定：会话开头确定模型与 effort，任务之间 /clear，压缩只在自然间隙做
• 创建一个 model: haiku 的只读调研子智能体，并用它做一次真实调研
• 挑 5 个任务，分别在两档模型上跑，记录 token、返工次数和评审结论，形成你团队自己的选型表
• 为自动化任务（CI、定时任务）设置轮数或预算上限，并在 Console 或管理后台设置支出上限

延伸阅读：上下文管理、子智能体与并行、Headless 与 CI。下一课回到代码库本身：让代码库对智能体友好。