Claude Code成本拆解：43%花在系统提示上

一位开发者公开了自己 Claude Code 一周的 token 日志：日均调用 2,772 次，缓存读取 3.15 亿 token，输出 240 万 token。按成本权重折算后，最大的开销并非模型回复，也不是工具输出，而是每次调用都要重读的固定上下文——系统提示加工具列表，占了总成本的 43.3%。

一周数据全景：调用量大，缓存读取是主线

这份统计来自 2026-10-12 至 10-18 的本地会话日志，取 7 天日均值。三个核心数字分别是：

• 每日调用次数：2,772
• 每日缓存读取 token：315M
• 每日输出 token：2.4M

日均近 2,800 次调用意味着平均每小时上百次模型交互，属于典型的重度使用场景。你可能没注意到缓存读取 token 达到 3.15 亿，与输出 token 相差两个数量级——这符合 Claude Code 这类 Agent 工具的工作模式：每一轮对话都要把完整上下文重新送进模型，而缓存机制让这部分重复输入以较低单价计费。

作者采用的成本权重为：输入 1、缓存写入 1.25、缓存读取 0.1、输出 5。也就是说，1 个输出 token 的成本相当于 5 个输入 token，而缓存读取只按输入价的十分之一计算。这个权重体系是理解后续占比拆解的前提。

Prompt Caching（提示词缓存） 是 Anthropic API 等大模型服务商提供的一项机制：当请求的前缀部分（如系统提示、工具定义、长文档）与之前某次请求完全一致时，服务端可以复用已计算好的 KV Cache，无需重新对这些 token 做前向计算。命中缓存的部分按显著更低的单价计费（本文中为输入价的 0.1 倍），而首次写入缓存则按 1.25 倍计价。

对 Claude Code 这类 Agent 工具而言，每一次工具调用后的下一轮对话都会把「系统提示 + 工具列表 + 历史消息」整体重新发送，缓存机制让这段几乎不变的前缀得以低成本复用。这也解释了为何缓存读取 token 会达到输出 token 的两个数量级——它不是异常，而是 Agent 多轮循环的固有形态。

成本拆分：固定上下文吃掉近半预算

按内容切片统计的成本占比结果如下：

切片	成本占比
Base（系统提示 + 工具列表）	43.3%
模型回复	25.5%
用户输入 + 附件	21.6%
Shell 命令输出	6.1%
子代理	2.1%
文件读取	1.2%
搜索（grep/glob）	0.1%
MCP 及其他工具	0.1%
网页抓取	0.0%

这张表最有价值的地方，是它打破了两种常见直觉。

第一，模型回复只排第二。 25.5% 的占比说明输出确实贵（权重 5），但并不是成本主体。真正的大头是每次调用都要重新加载的系统提示与工具定义。

第二，工具输出远没有想象中那么可怕。 Shell 命令输出占 6.1%，文件读取仅 1.2%，搜索几乎可以忽略。很多开发者习惯性地担心「工具返回太多内容把上下文撑爆」，但在这份数据里，工具侧的浪费并不是主要矛盾。

系统提示（System Prompt）与工具列表（Tool Definitions） 构成了 Claude Code 每次请求的固定前缀。系统提示包含Agent 的行为准则、安全约束、输出格式要求等；工具列表则是以 JSON Schema 形式声明的全部可调用工具（读文件、执行 shell、搜索、编辑等），每个工具都带有名称、描述和参数定义。

这部分内容在单次会话中几乎不变，却会随每一轮调用被完整重发。在重度使用场景下，工具数量越多、描述越详细，固定前缀就越臃肿，被 2,772 次调用反复计费后便成为成本主项。这也正是文中建议「精简自定义系统提示和工具集」的直接依据。

为什么缩短会话比裁剪工具输出更有效

作者的结论很直接：既然最大切片是每次调用都会重读的固定上下文，那么让会话更短比修剪工具输出带来的节省更明显。

这个判断背后的机制并不复杂。固定上下文（系统提示 + 工具列表）的体量与单次会话长度无关，但会被每一次调用重复计费。会话越长、调用次数越多，这笔固定开销就被乘得越大。日均 2,772 次调用意味着这 43.3% 的成本被重复了 2,772 次。

相比之下，工具输出只影响单次或少数几次调用的上下文增量，而且 shell 输出、文件读取、搜索三项加起来不到 8%。把精力花在压缩这些内容上，投入产出比并不高。

对重度使用 Agent 编程工具的开发者来说，可操作的优化方向由此变得清晰：

• 把长任务拆成多个短会话，及时结束已完成目标的会话
• 精简自定义系统提示和工具集，减少每次调用都要重读的固定部分
• 优先关注调用次数这个乘数，而不是单次工具返回的字节数

会话长度与调用次数的乘数关系是理解该结论的关键。固定上下文的成本公式可近似写为：固定前缀 token 数 × 调用次数 × 缓存读取单价。缩短会话并不改变单次前缀的体量，但直接削减了调用次数这个乘数；而裁剪工具输出只作用于个别轮次的增量部分，对乘数没有影响。

换言之，前者是「减少乘法次数」，后者是「减小某一项的加数」。在工具输出合计不足 8% 的前提下，优化杠杆自然落在会话管理上。

这份数据的边界

需要说明的是，这是单一用户的个人日志，2,772 次日均调用属于相当高的使用强度，未必代表普通用户的使用分布。成本权重也是作者自行设定的近似值，不同模型和计费档位下，各切片的绝对占比会发生变化。

但它揭示的结构性事实仍有参考价值：在 Agent 式编程工具里，固定上下文的重复计费是一个容易被忽视的成本项，而它恰恰是占比最大的那一块。对于想要控制 Claude Code 使用成本的团队，这个视角值得纳入考量。