58版Claude Code首请求开销实测

给 Claude Code 发一个字母，也可能先带上近两万 tokens 的系统提示和工具定义。作者安装了 58 个版本，测量用户输入之前的固定开销：它曾在十个月里增长 86%，也曾因一次升级下降 39%。

对经常开短会话、使用子代理的程序员，这组数据值得看。但要分清：请求带了多少 tokens、缓存命中了多少、最终花了多少钱，是三件事。

一个字母为什么会带上几万 tokens

Claude Code 向模型发送请求时，除了用户的话，还要提供系统提示和内置工具定义。工具定义就是告诉模型有哪些工具、各自能做什么、参数怎么填。

作者测量了从 1.0.60（2025 年 7 月）到 2.1.310（2026 年 10 月 23 日）的 58 个版本，每个版本从 npm 安装到独立目录。测试统一使用 Claude Haiku 5.5，在空目录和全新配置目录中，通过 claude -p 发送字母 a，没有 CLAUDE.md、插件或额外设置。

统计对象是第一次模型请求的输入 tokens，包含未缓存、缓存读取和缓存写入三部分。关闭 MCP 后，每版运行 3 次；同一版本的结果每次完全一致。

这测到的是特定条件下的请求基线，不能直接当作每次请求的全价账单。

固定开销会增长，也能被一次升级砍掉

从 2025 年 7 月到 2026 年 5 月，基线由 19,498 增至 36,309 tokens，增长 86%；同期内置工具从 15 个增加到 27 个。

不过，工具数量解释不了全部变化。2026 年 10 月 7 日发布的 2.1.293，在工具数量相同的情况下，把基线从 29,701 降到 18,055 tokens，下降 39%，回到接近 2025 年中期的水平。原文没有说明具体改了哪些提示或定义，不能据此认定某项优化是原因。

此后 15 个版本又逐步涨到 18,841 tokens，增加约 4%，单次增幅通常为 100 到 400 tokens。2.1.310 新增 Monitor，内置工具达到 25 个。

升级客户端，可能比精简自己的几句话更能减少请求开销。

但这个判断主要适用于仍在使用高开销旧版本的人，不能推导成版本越新、基线必然越低。

连接应用曾经让一个字母膨胀到约 39.5 万 tokens

作者还开启自己在 claude.ai 连接的 13 个应用，对每版追加测试 1 次。

在 2.1.83 至 2.1.140，也就是 2026 年 3 月下旬至 5 月中旬，这些应用的工具会随每次请求一起发送。它们额外带来 420 到 426 个工具，使字母 a 对应的输入达到约 395,000 tokens。

从 2.1.145 起，这些工具改为按需加载。作者本月测到的所有版本，开启或关闭连接应用的基线都相同。这里的改善来自工具何时进入请求，而非用户少写了什么。

费用还要看缓存。作者指出，首次请求之后，这块内容通常从提示缓存读取，价格为普通输入的十分之一或更低。因此，短会话、每个都要携带一份提示的子代理，以及缓存过期后的请求，更容易承受这部分开销。

这不等于所有场景都能稳定获得同样的缓存收益。

我的判断

这组测量最有用的地方，是把容易忽视的客户端开销变成了可比较的数字。空目录、全新配置、固定模型和输入，也让版本差异更容易观察。

局限同样明确：只有一台 Windows 笔记本、一个模型和一个提示。较早版本在 10 月 21 日测量，最新 12 个版本在 10 月 24 日测量，脚本和登录账号相同，但服务端按账号开启的功能仍可能影响结果。旧客户端连接的也是今天的 API，并非当年的服务端环境。

所以，它支持「版本会显著影响请求基线」，却不足以证明所有模型、系统和团队都有相同收益。真实项目里的 CLAUDE.md、MCP、插件和 skills 还会继续增加输入。

原文另附了子代理开销增加 128%、最小配置降低 64% 的相关研究，但这里没有展开对照过程，只能当作后续线索。至于节省了多少实际费用、任务质量是否变化，这篇没有给出对照数据。

能拿来做什么

• 如果还在用旧版 Claude Code，先确认版本并升级，再用相同模型和配置比较请求输入量，尤其留意连接应用较多的环境。
• 排查前端或 Node 项目的 AI 用量时，先测空目录基线，再加入项目配置，区分客户端固定开销和项目上下文开销。
• 把任务拆成多个子代理之前，考虑每个代理都要承担初始提示开销；对于很小的任务，拆分收益未必覆盖这部分成本。
• 评估节省效果时，同时看未缓存输入、缓存读取和缓存写入，不要把输入 tokens 的降幅直接写成费用降幅。