Claude 1M 上下文一周烧了我 28M token，6 个我每天都在用的省钱手法

大家好，我是飞飞。

周末晚上我打开 Claude Code 的 usage 看板，被自己吓了一跳：上周累计 28M tokens。

我自己是 Claude Max 5x $100/月的订阅。Max 的好处是按 5 小时窗口给配额，不计 token 总量，听上去用不完。但我连着两天跑完整的博客 pipeline（researcher → writer → polisher → artist → distributor 一条龙），从早上 9 点到晚上 11 点几乎不停。第二天下午 3 点开始撞到 5 小时窗口的限流：每条新消息要等 90 秒才回。

这件事让我开始正经盯每个 prompt 的 token 消耗。一周下来摸出来 6 个手法，今天这篇是把它们摆出来给你看。

声明前置：我不是 Anthropic 内部员工，也没法读到他们的计费源码。下面所有的数字都是我自己 usage 看板上读出来的实测数据，能复现，但样本只有我一个人。如果你的工作流和我不一样，效果会有差异。

上周我跑了一遍账单

先把基线摆出来。

我的工作流主力是 Claude Code，模型默认 Sonnet 4.6。开了 1M 上下文的长上下文档位（按 Anthropic 现在的定价，超过 200K 的部分输入是 $6/M、输出是 $22.50/M，比标准档贵 50%）。每天大概 6 到 12 个会话，每个会话从几千 token 到几十万 token 不等。

上周这种节奏下，我看到的几个数字：

• 总输入：约 26.4M tokens，其中缓存命中（cache read）占 19.2M，约 73%。
• 总输出：约 1.8M tokens。
• 如果按 API 现价裸算（不考虑 Max 订阅打包）：26.4M 输入 × $3 + 1.8M 输出 × $15 大概是 $106。
• 走缓存的实际成本：cache read 是 $0.30/M，cache write 是 $3.75/M。所以实际可计费输入 ≈ 7.2M × $3 + 19.2M × $0.30 + 缓存写入费用，估算下来真实成本约 $33。

73% 的缓存命中率不是天上掉下来的。它是我把 6 个手法摞在一起跑出来的结果。下面挨个拆开讲。

Prompt caching 是这套手法里杠杆最大的一条

如果今天你的工作流里只能加一件事，加这个。

Claude 的 prompt caching 机制是这样：你在 system prompt 或者前置消息里标记某段内容为 cache_control: ephemeral，Anthropic 就会把这段 prefix 缓存 5 分钟。下一次请求里只要这段 prefix 一字不差，就走缓存读取，价格降到 $0.30/M（标准输入是 $3/M）。第一次写入是 $3.75/M（贵 25%），但只要 5 分钟内被命中至少一次就回本。

Claude Code 自带这套机制。它会自动把 CLAUDE.md、加载进来的 skills、对话历史的稳定部分标记为 cacheable。但前提是这些内容确实稳定。

我做的几件事：

• 把 CLAUDE.md 当 cache 优化的对象写。任何会随会话变化的字段（”今天的任务是 X”）都不写进 CLAUDE.md，写进会话开头的临时消息。CLAUDE.md 只放真正长期不变的项目结构、命令、约束。
• 常驻 skill 永远显式 load。我的 6 个 content skill 每次会话都加载，等于成了缓存的一部分。如果哪次我只用 1 个 skill，整个 prefix 哈希变了，缓存读全废。所以我现在宁可全部加载浪费一点首次写入费用，也不让缓存碎掉。
• 不要在 system prompt 里塞时间戳。”Today is 2026-04-29”这种字段一变，缓存当场失效。把时间留给 user message 处理。

我看到的实测数据：缓存命中率从我没专门优化前的 ~30% 涨到现在的 73%。按上周那个账面，光这一条就把账单从 $106 压到 $33 量级。

/compact 我不再等到上下文满了才按

Claude Code 的 /compact 命令把当前会话历史压缩成一段摘要，腾出上下文空间。很多人（包括过去的我）的习惯是看到右下角红条快满了才按。

这个时机是错的。

原因：长会话里，每次新轮次的请求都把前面所有历史回放一遍。如果你已经积累了 80K token 的对话，你接下来每条消息的输入都至少 80K。等 1M 满了再 compact，意味着你最后那段对话每条都按 1M 计费。

我现在的规则是：上下文用到 40% 就开始考虑 compact，到 60% 必 compact。

每次 /compact 本身是一次 LLM 调用，大概烧 3K 到 8K token（取决于历史长度）。但它能让接下来 30 到 50 轮对话的输入维度从 600K 压到 30K。算账上看是大赚的。

判断什么时候 compact 的实际信号：

• 当前任务和前面的话题已经不再直接相关。
• 我在同一个文件上反复修改同一段代码（说明前面的修改记录是噪声）。
• 我准备开一个新的探索（比如让 Claude 读一遍另一个目录）。

这三种情况一出现就 compact。代价是有时候 compact 会丢一些细节，需要我重新提一下背景。但比起按 1M context 烧钱，这点不便完全可以接受。

探索任务我现在全部丢给 sub-agent

这一条是我在跑 /ultraview 那篇文章的实测里学到的。

主会话的 context 是宝贵的。每多一个文件读、每多一次 grep，都把这个会话的历史变长，下一轮请求的输入就变长。如果你只是想知道”这个项目里 RPA 任务相关的代码在哪几个目录”，让主会话去跑 find + 读 5 个文件不划算。

正确做法是把这种探索任务丢给 sub-agent。Claude Code 的 Task tool 可以拉起一个新的会话（用 general-purpose 或 Explore 子代理），它有自己独立的 context window，跑完之后只把结果摘要返回给主会话。

实际数据感受：让 Explore 子代理去找”RPA 任务相关的代码”，子代理会跑 10 几个 grep 和 read 调用，自己烧掉大概 30K token，但返回给我主会话的只有 800 字左右的总结。如果同样的事让主会话亲手做，我的主 context 会多出 30K 的污染，接下来每轮请求都得带着这 30K 算钱。

我现在的判断标准：任何一个我不打算自己读全文的探索任务，都丢 sub-agent。包括”看一下 X 的相关代码”、”统计 Y 在项目里出现多少次”、”调研 Z 库的最新 API”。

副作用是 sub-agent 偶尔会理解偏，需要我再次澄清。但这件事一年我可能撞 5 次，省下来的 token 是天天在省。

CLAUDE.md 每一行都在每轮重读

这条听起来废话但很多人不在意：你 CLAUDE.md 里写了什么，每一轮请求都把它当作 prefix 重新发一遍。

我两个月前的 CLAUDE.md 是 12KB。里面塞了项目背景、各种命令、最佳实践、过往踩坑、为什么选这个架构……写得像一篇博客。我自己看着挺爽，每次告诉 Claude “去看 CLAUDE.md” 它都能秒答任何项目相关的问题。

但 12KB 是 3K token。每轮都 3K。一个 50 轮对话的会话光 CLAUDE.md 就重复发了 150K token。

我上周做的事是把 CLAUDE.md 砍到 4KB。砍掉的内容分两个去向。

一部分搬进了 skill 文件。每个 skill 有自己的 SKILL.md，按需加载。”我的博客 pipeline 怎么跑”这种内容现在在 content-director 的 SKILL.md 里，没触发就不读。

剩下的部分直接删了。”为什么选 Hexo 不选 Astro”这种历史决策记录，对当前工作没帮助，留着也是占 token。

砍完之后我观察到的副作用是 Claude 偶尔会问一些过去能直接答的问题。频率大概一周三五次。每次回答它一句话就行，比起每天省下来的 token 完全划算。

small_fast_model 我切到了 Haiku 4.5

Claude Code 的请求路由里有一个”快速辅助模型”槽位，处理一些低权重的小任务（比如生成搜索关键词、写 commit message 草稿）。默认是 Sonnet 走双角色。

我把它切成了 Haiku 4.5：

export ANTHROPIC_DEFAULT_HAIKU_MODEL=claude-haiku-4-5
export CLAUDE_CODE_SUBAGENT_MODEL=claude-sonnet-4-6

Haiku 4.5 输入是 $1/M、输出是 $5/M。Sonnet 4.6 是 $3/M、$15/M。差三倍。

这一条我没法精确测算省了多少，因为 Claude Code 的内部路由不是完全暴露的。但凭手感，做完这个切换之后，5 小时窗口的限流被撞到的次数明显少了。

注意：是切 small_fast_model，不是切主模型。主模型仍然是 Sonnet 4.6。Haiku 处理的是那种”给我一个文件名候选”、”这段错误日志的关键词是什么”这种轻量请求。

thinking_effort=high 我现在只对真问题打开

Claude Code 支持 --thinking-effort 参数（或者在会话里 /thinking high），打开后模型在回答前会先做一段”思考”。这段思考也算 token，且是按输出计费。

过去我习惯打开 thinking_effort=high 当万能开关，觉得”反正多想一会儿不亏”。但 Anthropic 的计费里，思考 token 跟普通输出一个价。一个有 thinking 的复杂回答，输出可能从 800 token 涨到 3500 token。乘以一天几十次，账上就多了。

我现在的规则：

• 默认 thinking_effort=medium。这是大部分任务的最优解。
• 只有真在做架构决策、复杂调试、跨多文件的影响分析时切 high 或 max。
• 写 commit message、改 typo、生成测试样例这种，关到 low 甚至 minimal。

这条不是 prompt caching 那种几倍杠杆的省，但它解决的是”我以为 thinking 是免费的”这个错觉。一旦你认识到 thinking 也是 token，就不会无脑全打开了。

这周省下来的钱大概够多跑两天

把六条加起来回看上周。

修改前我估算如果不优化跑同样的工作量，账单大概在 $100 量级。修改后看到的实际命中价是 $33 量级。我的 Max 5x $100/月已经覆盖了，不会真到 API 计费。但更直接的体验是：5 小时窗口的限流我撞到的次数从一周 6 次降到 2 次。换句话说，我可以在 Max 5x 的额度里多干两天活。

如果你是按 API 计费的开发者（没开 Max 订阅，直接拿 API key 跑 Claude Code），上面这套手法理论上能把账单压到原来的 1/3。但你的实际数字必然和我不一样，因为工作流里”什么内容是稳定的”这件事每个人差别很大。

唯一一条我建议无脑就开的是 prompt caching。它的杠杆远超其他，且几乎没有副作用。

MCP server 和 sub-agent 自己的开销我还没拆完账本

写到这里我想留两个真实没解决的点。

最先想搞清楚的是 MCP server 的开销。MCP 协议每次 turn 都要把工具 schema 注入到请求里，schema 大的 server 一旦多挂几个，prefix 会被撑得很大。我目前挂了 6 个 MCP server（brave-search、fetch、obsidian-cli 等），但我还没专门测过关掉某几个之后命中率和总开销的变化。下周想做一个对照。

另一个没拆开的账本是 sub-agent 自己烧的那部分。我目前的算法是按”主会话 context 干净”这个角度看的，sub-agent 内部那一段的消耗没单独算。理论上一个 30K token 的 sub-agent 调用要算 30K。我直觉上还是合算，但没拆过详细账。

评论区想问两个具体问题。

你自己跑 Claude Code 一周大概烧多少 token？是 Max 订阅还是 API 计费？

另外，你有没有什么我这篇没写到的省 token 手法？尤其是 MCP server 这块，如果你做过对照测试，特别想听你的结果。