成本优化策略

同样的活，花的钱可以差 10 倍。这一页按收益从高到低排。

成本从哪来

一次请求的花费：

花费 = (输入 token × 模型倍率
      + 输出 token × 模型倍率 × 补全倍率
      + 缓存命中 token × 模型倍率 × 缓存倍率) × 分组倍率 × 2 USD/1M

三个可优化的变量：输入多长、输出多长、用什么模型。

编码 Agent 的钱主要花在输入上

这和聊天场景直觉相反。Agent 每一轮都会把「系统提示 + CLAUDE.md + MCP 工具定义 + 全部历史对话 + 读过的文件」重发一遍。

一个跑了 30 轮的会话，输入 token 通常是输出的 20–50 倍。 所以省钱的第一优先级永远是控制上下文长度。

---

1. 换任务就 /clear（收益最大）

上下文是累积的。一个开了一整天的会话，第 50 轮的输入可能是第 1 轮的 40 倍。

# 做完一件事，立刻
/clear

判断标准：新的问题和刚才那件事没关系了 → 清。

同一件事但太长了 → /compact（保留结论，丢弃过程）。

在 控制台日志 里看 prompt_tokens 列，如果一路往上涨到几十万，说明你该清了。

2. Prompt Cache

Claude 系模型的缓存倍率是 0.1——命中的部分按十分之一计费。

什么会被缓存

会话里前缀稳定不变的部分：系统提示、CLAUDE.md、MCP 工具定义、早期的对话历史。

快米兔 API 原样透传 cache_control 和缓存相关的 usage 字段，命中率与直连官方一致。

怎么提高命中率

做法	效果
CLAUDE.md 写好就别天天改	改一次 → 缓存全废，要重新写入
MCP server 配置固定下来	增删 server 会让工具定义变化 → 缓存失效
同一任务连续问，别开新会话	新会话 = 冷启动
把不变的内容放前面，变化的放后面	缓存按前缀匹配

怎么验证命中了

Claude Code 里 /cost，或者看 API 返回的 usage：

{
  "usage": {
    "input_tokens": 1200,
    "cache_creation_input_tokens": 0,
    "cache_read_input_tokens": 45000,
    "output_tokens": 800
  }
}

cache_read_input_tokens 占比越高越好。理想状态下长会话里它能占到输入的 80%+。

缓存写入是要花钱的

第一次建立缓存时按 cache_creation 计价（通常高于普通输入价）。所以： 只有会被反复复用的内容才值得缓存。 一次性的东西不要打 cache_control。

3. 模型分档

不要用一个模型干所有事。

任务	模型	相对成本
搜索、定位、改 typo	claude-haiku-4-5-20251001	1×
日常写功能、写测试	claude-sonnet-4-6	3×
重构、疑难 bug、架构	claude-opus-4-8	5×

具体倍率见 模型与分组。

实操方式：

• Claude Code：/model 随时切；subagent 指定 model 把机械活派给 Haiku
• Codex：--profile 预置快/慢两套
• Cline：Plan / Act 分别设模型

别把 Haiku 档改成 Opus

Claude Code 的后台任务（会话命名、todo 摘要、文件检索）走 Haiku 档。 把 ANTHROPIC_DEFAULT_HAIKU_MODEL 指到 Opus，会话成本会翻 5–10 倍，而这些任务根本不需要那么强的模型。

4. 用 default 分组

default 分组倍率 0.7，专用分组 1.0。同样的模型，直接便宜 30%。

只有在 default 上频繁遇到 503 / 限速时才换专线分组。详见 模型与分组。

5. 控制输出长度

输出的单价是输入的 2–8 倍（补全倍率），而且推理模型的 thinking token 也算输出。

做法	说明
明确要求简洁	「只给改动的那几行，不要重复整个文件」
限制 max_tokens	API 调用时设一个合理上限
降低推理强度	Codex 的 model_reasoning_effort，简单任务用 low
控制 thinking 预算	Anthropic 协议的 thinking.budget_tokens
不要它写多余的东西	「不要写 README、不要加示例、不要总结」

6. 精简常驻上下文

每一轮都要重发的东西，长度直接乘以轮数：

常驻内容	优化
CLAUDE.md	控制在 100–300 行；细节拆成 Skill 按需加载
MCP 工具定义	只装当前需要的
@ 引用的文档	只引用每次都要的；偶尔用的写一行「需要时自己读」
粘贴的代码	改成让模型自己读文件

7. 用 Subagent 隔离"过程垃圾"

大范围搜索会产生大量中间内容。放主会话 → 永久占上下文；交给 subagent → 只回来一句结论。

用子代理去搜索所有调用了 v1 API 的地方，只告诉我文件和行号

8. 关掉不用的功能

功能	影响
Web 搜索	每次搜索都会把网页内容塞进上下文
自动 Git 集成	diff 内容进上下文
冗余的 MCP server	工具定义常驻

---

排查"钱花哪了"

客户端侧

/cost

看当前会话的累计消耗和缓存命中情况。

服务端侧（更准）

控制台日志 里：

1. 按令牌名称筛选，定位是哪台机器/哪个项目
2. 看 模型 列——是不是有大量本该走 Haiku 的请求走了 Opus
3. 看 提示 token 列——如果单次请求就几十万，说明上下文失控了
4. 展开详情看缓存命中——cache_read 为 0 说明缓存没生效

典型的三种"烧钱模式"

症状	原因	解法
每次请求输入都 20 万+ token	一个会话开太久没清	/clear
缓存命中一直是 0	CLAUDE.md 或 MCP 配置一直在变	稳定下来别改
日志里全是 Opus	没做模型分档	日常切 Sonnet，搜索交给 Haiku

---

一份可执行的清单

□ 换任务就 /clear
□ CLAUDE.md 控制在 300 行以内，写好后别频繁改
□ 日常用 claude-sonnet-4-6，不是 opus
□ 搜索/定位类任务交给 subagent + haiku
□ 令牌用 default 分组（0.7 倍率）
□ MCP 只装当前项目需要的
□ 明确告诉模型"不要写多余的东西"
□ 每周去日志页看一次 token 趋势

配套阅读

• 模型与分组
• 提示词技巧
• Subagents 子代理
• 账号 · 充值 · 令牌