Claude Code 每次启动的 33,000 token 开销：花在哪、是不是浪费、该剪什么

新开一个 Claude Code 会话，一个字都还没敲，发给模型的第一条请求就已经有大约 33,000 token 长。这个数字来自 2026 年 7 月的一次测量：研究者把日志代理放在代理和 API 之间，直接读出用户第一个字之前到底发了什么。同样设置下，更精简的编程代理 OpenCode 在相同冷启动里大约是 7,000 token，所以 Claude Code 的基线开销约大 4.7x。当时传播最广的说法是：Claude Code 在读取提示前发送的 token 是 OpenCode 的 4.7x；这件事也冲到了 Hacker News 前排。

这个数很醒目，最容易得出的结论是：Claude Code 太臃肿。这个结论对了一半，但指错了重点。下面先把 33,000 token 拆开，看每一块花在哪里；再讲那个快结论跳过的部分：为什么原始基线不是你真正该怕的东西，真正花钱的又是什么。来源放在文末。

30 秒版

1. 基线开销是真的。 全新配置、没有 MCP、没有指令文件时，Claude Code 第一轮约 33,000 token，OpenCode 约 7,000 token。这是你输入之前就付出的冷启动开销。
2. 工具定义占大头。 33,000 token 里大约 24,000 是 27 个内置工具的 JSON 工具定义：核心编程工具，加上后台代理和编排工具组。系统提示词约 6,500；脚手架提示约 2,000。
3. 你不是每轮都按原价付。 稳定前缀会被缓存：先按 1.25x-2x 写入一次，之后按约 0.1x 读取。稳定状态下，一个大但稳定的前缀很便宜。
4. 真正漏钱的是缓存反复重写。 Claude Code 的前缀不是逐字节稳定的，所以缓存会在会话中途被重写；某次测试里，它的缓存创建 token最多是精简代理的 54x。重写按写入溢价计费，不按读取折扣计费。
5. 真实世界起步是 75,000-85,000。 加上 MCP 服务器和 CLAUDE.md 文件，也就是正常配置，你每次请求刚开始就已经用掉 200k 上下文窗口的 40% 以上。
6. 开销大不等于纯粹浪费。 它买来的是更有能力的代理，并行调用打包也能抵消一部分成本。只有当你带着从不使用的工具、服务器和文件时，它才变成浪费。

33,000 token 花在哪里

这次测量把冷启动载荷拆成三块。下面是在全新配置、没有 MCP 服务器、没有指令文件时，两边的对比：

最大的一行不是系统提示词，而是工具定义：大约 24,000 token，接近整个基线的四分之三。Claude Code 带了 27 个工具，OpenCode 带的是 10 个经典编程工具。每个工具的名字、描述和完整 JSON 输入定义，都会被序列化进每一轮请求里，好让模型知道自己能调用什么。

多出来的 17 个工具不是填充物。它们是后台代理、子代理和编排能力，目的是把 Claude Code 做成一套代理团队平台，而不是单线程编程助手。这也是这个数字里第一个必须诚实面对的张力：如果你用代理团队，24,000 token 买来的就是你需要的能力；如果你从不用，它就是一段你很难自己移除的载荷。

缓存掩盖的那部分成本

把这件事说成“每轮 33,000 token”，会误导。你并不是每次请求都按完整输入价格支付 33,000 token。Claude API 会缓存稳定前缀：tools 块和 system 块先渲染，并且顺序固定；只要字节不变，就先写入缓存一次，之后轮次按缓存读取计费，价格大约是输入价的 0.1x（约十分之一）。缓存写入会有一点溢价：5 分钟缓存按输入价的 1.25x，1 小时缓存按 2x；但这个溢价只付一次，会摊到后续每一次读取上。对一个真正稳定的 33,000 token 前缀来说，稳定状态下的成本并不高。

这是理论。测量发现，Claude Code 没能吃满这个好处。日志代理看到，同一会话里，运行框架会发出几种不同的请求形态，系统字节在请求之间会变。缓存命中要求严格的前缀匹配：前缀里任何位置只要差一个字节，后面的内容就都不能命中。于是，一个在会话中途改变形态的前缀，就会迫使缓存被重写，而不是被读取。精简代理保持前缀逐字节一致，可以走便宜的读取路径；Claude Code 则在反复变动。

账单能看出来。对比中，Claude Code 写入的缓存创建 token最多达到 OpenCode 的 54x。在一个文件摘要任务里，Claude Code 记录到 53,839 个缓存创建 token，OpenCode 是 1,003。缓存创建 token 按 1.25x-2x 的写入溢价计费。所以真正漏钱的，不是那 33,000 token 基线安静地待在缓存里，而是这份基线需要被重新缓存多少次。真正花钱的是反复重写，不是基线本身有多大。

这解释了很多开发者已经体感到的现象：同样一件事，Claude Code 比更精简的工具更快烧完按 token 计的额度。额度那部分我们在 Codex 与 Claude Code 用量限制拆解里讲过；这里的缓存重写行为，就是同样形状的墙来得更早的原因之一。

真实世界是 75,000-85,000

33,000 token 是干净环境里的数字：全新配置，没有 MCP，没有记忆文件。几乎没人这样使用 Claude Code。把普通开发者会加载的东西加上去，同一测量给出的真实起点是：第一次提示之前已经 75,000-85,000 token。放在 200k 上下文窗口里，就是每一次请求刚开始就已经用掉 40% 以上。

两个新增项把数字推了上去，而且它们的行为不一样：

• 指令文件每轮整份加载。 CLAUDE.md，包括全局、项目和本地文件，再加上自动记忆文件，都会被读进每一次请求的上下文。一份膨胀的 CLAUDE.md，就是你每轮都要付的开销；不管它和当前任务有没有关系，都会重新发送。这也是为什么 CLAUDE.md token 错误和 CLAUDE.md 大小与性能值得认真处理：这个文件看起来编辑免费，实际并不免费。
• MCP 服务器比“每个定义每轮都发”更微妙。 默认情况下，Claude Code 启动时只加载 MCP 工具的名字，完整工具定义按需再取。这是一种工具搜索延迟加载，目的就是避免服务器列表一大，基线立刻膨胀。但名字仍然会在服务器变多时累积；当工具搜索决定提前加载工具定义时（预算够时默认会这样），或者你关掉延迟加载，MCP 定义就会重新大幅进入基线。所以，MCP 确实会推高 75,000-85,000 这个数字，只是它比原始工具块处理得更聪明，而且缓解机制已经在产品里。

子代理还会把它放大。每个子代理都会带着自己的新上下文和自己的基线启动：系统提示词比主会话更瘦，但 CLAUDE.md 和工具集会重新加载一遍。所以扇出工作会乘上固定成本。测量里有一个任务，直接做本来是 121,000 token；一旦分给两个子代理，就膨胀到 513,000 token，大约是 4x，大部分都是重复基线。这个交换值不值得，是另一篇 Claude Code 代理团队值不值得烧 token的主题；本文这里讲的是成本账。

这到底算不算浪费

最痛快的答案是：算，33,000 token 都是臃肿。更诚实的答案没那么简单。

反对“纯浪费”的一边是：整项任务的 token 用量大致等于基线 × 请求数 + 对话增长。Claude Code 会把并行工具调用打包进更少的轮次，所以它发出的总请求数可能比串行代理少。大基线、少请求，有时会接近小基线、多请求；因此，每请求 4.7x 并不等于整项任务账单也是 4.7x。围绕这次测量的 Hacker News 讨论里，也有人准确指出了这一点：启动开销和整段会话成本不是同一个数字。

支持“浪费”的一边是：如果你带着自己不用的能力，上面这些抵消就救不了你。24,000 token 的工具定义假设你可能会编排子代理；一排 MCP 服务器假设你会调用它们；400 行 CLAUDE.md 假设每一行都值得出现在每一轮里。当这些假设不成立，开销就是实打实的浪费。你在为不会触发的工具和指令支付缓存写入溢价，也在消耗上下文窗口。

所以公平的结论是：基线开销买来的是一个确实有能力、脚手架提示也很多的代理；它会在你个人用不到的边际上变成浪费。 修法不是盯着 33,000 token 生气，而是别继续往上堆自己不用的重量。

真正能裁掉什么

内置系统提示词和 27 个核心工具定义是固定的，你裁不掉，也没必要把时间花在那里。真正能控制的，是那些把 33k 推到 85k 的东西：

• 保持 CLAUDE.md 精简。 这是最确定的省法，因为记忆文件每次请求都会整份加载，没有延迟加载。文件越短、信号越密，每轮 token 越少；同时，指令也更容易被遵守。我们在过度工程化规则和 token 错误指南里都算过收益。
• 按项目断开用不到的 MCP 服务器。 延迟加载会限制 MCP 对基线的膨胀，但不会把它清零：工具名字仍然会发出去，工具定义也会按需获取。断开项目不需要的服务器，才能移除这些载荷；权限 deny 规则做不到，因为它挡的是执行，不是上下文。哪些值得保留，可以看最佳 MCP 服务器。
• 用 /context 看实时占用。 Claude Code 会给出当前窗口里各部分的拆分：系统提示词、工具、MCP 工具、记忆文件和消息。会话变重时跑一下，把抽象的“开销”变成你能处理的具体行项。更完整的工作流见上下文管理。
• 有意识地派生子代理。 每个子代理都带一份完整基线，所以扇出是真成本，不是免费的并行能力。任务真的能拆时再委派，不要条件反射式地开。

真正的教训

“Claude Code 在你输入第一个字之前就发送 33,000 token”这件事是真的，测得也扎实，但它大多不是大家第一反应以为的问题。基线大，是因为这个代理能力重；提示缓存本来应该让“大但稳定”的基线变便宜。测量真正暴露的是一个更窄、也更有用的问题：Claude Code 的前缀会反复变动，所以它在本该缓存读取的地方支付缓存写入；同时，它还鼓励你把 MCP 服务器、指令文件和子代理叠上去，而这些都是确实可以裁掉的成本。该盯的数字不是 33,000，而是你又往上加了多少，以及这些内容被重新缓存了多少次。

配套阅读

• Codex 与 Claude Code 用量限制 —— 为什么更高的 token 消耗会让同样形状的墙更早到来
• Claude Code 用量限制详解 —— 5 小时窗口、周上限，以及怎样观察消耗速度
• Claude Code 上下文管理 —— /context 命令和拥挤窗口的完整处理流程
• Claude Code 代理团队值不值得 —— 24,000 token 工具定义买来的能力
• CLAUDE.md token 错误 —— 指令文件在每次请求里带来的开销

Sources

1. Claude Code Sends 4.7x More Tokens Than OpenCode Before Reading Your Prompt — systima.ai
2. Hacker News discussion of the measurement
3. Prompt caching — Anthropic (cache write/read pricing, prefix-match rules)
4. Manage Claude’s context / the /context command — Claude Code docs

FAQ

你发消息之前，Claude Code 会先用掉多少 token？ 按 2026 年 7 月一次日志代理测量，全新配置、没有 MCP 和指令文件时，大约是 33,000 token：系统提示词约 6,500，27 个工具定义约 24,000，脚手架提示约 2,000。更精简的代理 OpenCode 在同样冷启动里约 7,000 token，差距是 4.7x。加载 MCP 服务器和 CLAUDE.md 后，真实世界起点是 75,000-85,000 token，占 200k 窗口的 40% 以上。

既然开销会被缓存，为什么还要在意？ 逐字节稳定的前缀会先写入缓存一次，按输入价格的 1.25x-2x 计费；之后按约 0.1x（约十分之一）读取，所以稳定基线在稳定状态下并不贵。但 Claude Code 的前缀不是逐字节稳定的：同一会话里会出现几种请求形态，迫使缓存中途重写。它写入的缓存创建 token 最多是精简代理的 54x；某个任务里是 53,839 对 1,003。真正漏钱的不是基线多大，而是它被反复重写的频率。

33,000 token 的开销都是浪费吗？ 不是纯粹浪费。最大的一块，约 24,000 token，是 27 个工具的定义，其中包括子代理编排工具组；你用代理团队时，这是能力，不用时才是很难剥掉的重量。并行工具调用打包也会抵消一部分高基线，因为整项任务成本大致是基线 × 请求数 + 对话增长。真正浪费的是你用不到的边际：常开不用的 MCP 服务器、工具和指令文件。

怎样降低 Claude Code 的 token 开销？ 内置系统提示词和核心工具裁不掉，但你能控制叠在上面的东西。保持 CLAUDE.md 和记忆文件精简；它们每次请求都会整份加载，没有延迟加载，是最确定的省法。断开项目用不到的 MCP 服务器：Claude Code 默认会延迟加载 MCP 工具定义，启动时只加载名字、按需取完整定义，所以 MCP 对基线的膨胀比原始工具块小；但断开服务器才能移除工具名，权限 deny 只挡执行。用 /context 看实时拆分，派生子代理时也要有意识，因为每个子代理都带自己的基线。

Claude Code 真的比 OpenCode 多用 4.7x token 吗？ 这是 2026 年 7 月一次单机测量，不是定律。测试固定了模型，请求路径里有本地网关，对比的是全新配置下的冷启动基线：~33,000 对 7,000，也就是 4.7x。字符级拆分是直接测得的，所以整体形状可信；但运行框架提示词经常变，样本很小，整项任务用量还取决于请求数和打包方式，不只取决于基线。把 4.7x 当成有来源的启动开销快照，不要当成永久的每任务倍数。