claude code 的 token 消耗与成本控制方法

六月中旬的一天早上，我打开 Anthropic Console，习惯性地扫了一眼本月账单。页面加载出来那一刻，我下意识刷新了两遍，数字没变，确实是 $247.38。而此时距离账单周期结束还有整整 12 天。我上一次在开发工具上花出这种感觉，还是 2017 年误触了某云厂商的 GPU 按需实例。

这笔钱花在了 Claude Code 上。不是 ChatGPT，不是 Copilot，而是那个黑底白字的终端工具。我用它来写一个 Next.js 全栈项目的核心模块，前后大约两周半。期间没有滥用，没有让 AI 写莎士比亚十四行诗，干的都是正经的开发活儿。

这件事倒逼我开始系统性地研究 Claude Code 的 token 消耗机制，不是读文档泛泛了解，而是抓数据、做对比、改配置、测极限。下面这些内容，是我花了大约 $400 学费换来的成本认知框架。它不会让你把账单压到零，但能帮你避免那种“我用得起 AI，但我不配”的无奈时刻。

先给结论：Claude Code 的账单泄漏点不在模型单价，而在你的“对话结构”

很多开发者看 Anthropic 的 API 定价，Claude 3.5 Sonnet 每百万输入 token 3 美元、输出 token 15 美元，再对比一下 GPT-4o，感觉价格还好。于是认为自己在 Claude Code 里随便聊几句代码，也就消耗个一两毛钱。

实际上，Claude Code 的终端交互模式决定了，它在单次任务中消耗的 token 量通常是同规模 API 调用的 3 到 8 倍。 而造成这个倍数的，不是模型变贵了，而是 Claude Code 在后台给你加了一套“看不见的系统提示词”、维持着不断膨胀的对话上下文、并且在每一次工具调用中都重新发送大量历史信息。

我的核心结论很简单：控制 Claude Code 成本的主战场，从来不是“换更便宜的模型”或“限制输出长度”，而是管理你的对话上下文规模与拆分你的任务粒度。 如果你只记一个原则，记住这句：对话越长，浪费的 token 越隐蔽；任务越整，重复发送的内容越多。

下面我会把这句原则拆开，用数据、截图规划和真实踩坑记录还原整个逻辑。

先搞懂 Claude Code 到底是什么，它的 token 流向和普通 API 调用完全不同

Claude Code 是 Anthropic 官方推出的命令行 AI 编程助手，运行在你的终端里，可以直接读写文件、执行 shell 命令、搜索代码库、调用 Git。你可以把它想象成一个住在你项目里的 Claude 代理。它底层调用的是 Claude 的 API，但交互模式决定了它的 token 消耗结构和你直接调 /v1/messages 是两套世界。

一个典型的 Claude Code 任务，背后的 token 流向大致如下：

1. 系统提示词固定消耗：每次对话启动时，Claude Code 会注入一套复杂的系统指令，告诉模型它是个编程助手、遵守什么规则、怎样调用工具、怎样格式化回复。这套系统提示词大约 3500-5000 token，具体数我没反编译出来，但用了几种间接推断方法得出的估值在这个范围。
2. 用户输入：你自然语言写的需求本身。
3. 上下文文件：当你执行 claude 命令时，如果开启了自动上下文（默认行为），Claude Code 会把当前打开的文件、光标附近的代码作为上下文附加进去。如果你指定了 –add-dir 或配置文件里设了 include，整个项目结构或部分文件内容也会被吞进去。
4. 工具调用往返：Claude 每调用一次工具（Read、Write、Edit、Bash、Glob、Grep），都需要把整个对话历史加上新的工具结果重新发送回模型，才能让它决定下一步。
5. 助手回复：包含代码块、解释、以及工具调用指令。

你把这几项加在一起就会发现，一个看似简单的“帮我修一下这个 bug”请求，在 Claude Code 里触发的首轮对话就能消耗 2000-8000 输入 token，再经过两三轮工具调用，总消耗轻松过万。 而如果同样的任务你直接去 API Playground 里贴代码，可能 1500 token 就出结果了。

为什么差这么大？因为 Claude Code 的设计目标不是“最省 token”，而是“最懂你的项目，并且能自己动手”。这本身不是缺陷，但如果你不了解它的成本结构，就很容易在“无感”中把预算用完。

我的数据观察：同一个任务，三种使用方式的 token 消耗相差 5.7 倍

我用一个真实任务做了对比测试：在一个中等规模的 Next.js 项目中，修改 API 路由的权限校验逻辑，涉及一个中间件文件和一个路由处理文件，改动量大约 40 行代码。

测试了三种方式：

• 方式A：Claude Code 普通对话模式。在项目根目录直接运行 claude，然后用自然语言描述需求，让 Claude Code 自己读文件、改代码、运行检查。
• 方式B：Claude Code 的 /compact 压缩模式。在执行过程中手动使用内置命令压缩上下文。
• 方式C：直接调用 Anthropic API。我自己拼装消息，把相关文件内容贴进去，请求生成修改方案，然后我手动应用。

我把每次交互的 token 用量通过 API 后台日志和 Claude Code 的 --verbose 输出汇总，结果如下表（数值为四舍五入后的近似整数）：

直接 API 方式成本仅 4 美分，而 Claude Code 默认模式花了 23 美分，差距 5.75 倍。这就是我前面说的 3 到 8 倍区间的真实来源。

更值得关注的是，这还只是一个单文件、单轮对话内完成的小任务。如果你的任务需要跨越 5 个文件、来回修改 8 轮，对话历史会急剧膨胀。我记录过一次跨越 30 分钟的多轮调试，最终输入 token 累积到 18.7 万，单次对话成本突破 1 美元。这在天天使用的场景下，一个月花掉一两百刀完全不是玩笑。

容易被忽视的四个 token 消耗黑洞

在为成本头疼的那几周，我把 Claude Code 的 --verbose 日志开了整整七天，逐条分析每一次 API 请求体大小。然后我发现了四个让我“原来钱都烧在这儿了”的瞬间。

黑洞一：自动附加项目上下文，但你不一定需要那么多

Claude Code 在启动时会根据你的配置和当前工作目录，自动搜集相关文件内容作为初始上下文。如果你在主目录或者一个 monorepo 的根目录跑 claude，它可能会把一大堆无关的文件信息吞进去。我测试过在 monorepo 根目录启动，首轮请求的输入 token 直接突破 1.2 万，而我实际要改的只是其中一个子包里的配置文件。

很多人以为“上下文给得多，AI 理解得更好”，这在 Claude Code 里不完全成立。Claude 3.5 Sonnet 在处理超长上下文时，对中间段信息的注意力会衰减，你多给的无关内容不仅浪费 token，还可能干扰模型判断。 我的做法是：在项目子目录里用 .claude.yaml 显式限定 include 范围，或者干脆在专门给 Claude Code 用的终端窗口里 cd 到最近的工作目录再启动。

黑洞二：遗留对话历史造成的“复利型浪费”

这是最隐蔽的一个。Claude Code 默认保持对话连续性，也就是说，你早上问了一句“帮我看看这个组件”，下午问了一句“刚才那个组件再加个 loading 状态”，晚上又问“把 loading 换成骨架屏”，虽然每次都是简短一句话，但每次请求都会把整个对话历史重新发送一遍。

如果一个对话持续了一天，积累了 3 万 token 的历史，那你晚上那个 20 token 的“换个骨架屏”请求，实际输入成本是 3.002 万 token。你的有效利用率只有 0.07%，剩下 99.93% 都在为历史买单。我把这种浪费叫做“复利型浪费”，因为它会随着对话长度非线性增长。

黑洞三：工具调用产生的隐式往返

Claude Code 每次调用 Bash 执行测试命令、Read 读取文件内容、Glob 搜索文件，都会新发一次 API 请求，并且附带此前所有上下文。如果你的任务需要 Claude Code 先搜文件、再读内容、再改代码、再跑测试、再根据错误修改，恭喜你，光是“读文件”这一步，可能就发出了 4 到 5 次请求，每次都含全量历史。一个典型的 TDD 流程（让 AI 写测试→跑测试→修代码→再跑测试）消耗的 token 可能是直接给出现成代码段的 10 倍。

黑洞四：最大输出 token 设得太大

Claude Code 允许你通过 max_tokens 参数限制单次回复的最大输出 token。但很多人不设这个值，或者为了“防止回答截断”设到 8000 以上。问题是 Claude 模型在输出代码时，即使实际有效内容只有 600 token，它也可能因为各种格式对齐、注释、冗余说明而把输出撑满设定值。我把 max_tokens 从默认 4096 压到 2000 后，输出 token 平均减少了约 18%，但代码可用性没下降。 因为对大部分代码修改任务来说，2000 token 的输出已经能容纳 150-200 行有效代码，足以覆盖单次修改量。

控制成本的七个实战方案（附我的调优数据）

下面是我在实际项目中逐步打磨出来的成本控制方案，按效果从大到小排列。每个方案都带着我的实测数据和取舍考量，你可以根据自己的项目情况组合使用。

方案1：用“任务单元拆分”替代“连续长对话”

这是降本最猛的一招。我现在的铁律是：一次对话只干一件事，干完立刻结束，新任务开新对话。 具体操作是每次发起对话前先在脑中过一下：这个任务能分成几个独立的子任务？如果能分成三个，就开三次 claude 会话。

效果：我对比过两次相似规模的特性开发。第一次用一条长对话从头搞到尾，消耗约 21.2 万 token（成本 ~$0.95）。第二次拆成 4 段独立对话，总消耗 9.4 万 token（成本 ~$0.40），降幅 58%。而且拆分后的代码质量并没有下降，因为每次对话的上下文更聚焦，模型准确度反而更高。

方案2：善用 /compact 命令，但要知道它到底做了什么

Claude Code 内置了 /compact 命令，它会把对话历史压缩成一段摘要，释放上下文窗口空间。很多人知道这个命令，但不敢用，怕丢失关键信息。我详细解释一下它的工作原理：它不是简单截断历史，而是调用一次模型，让模型把之前的对话内容总结成一段精炼的摘要，然后用这个摘要替换掉原始历史。

我强烈建议：在你的对话超过 20 轮交互、或者输入 token 累计超过 1.5 万时，主动执行一次 /compact。执行时机也有讲究，最好在一个子任务刚完成、信息还没“冷却”前做，这样摘要质量最高。不要在模型刚报完错、需要根据错误信息继续排查的时候执行压缩，那样可能丢失关键细节。

方案3：设置项目级 .claude.yaml 精确控制上下文

Claude Code 从项目根目录读取 .claude.yaml 配置文件。这里面你可以做很多省 token 的设置：

• include / exclude：明确告诉 Claude Code 哪些文件/目录要作为上下文，哪些必须忽略。我通常会把 node_modules、.next、dist、.git、测试覆盖率报告目录、日志文件全部排掉。
• max_tokens：限定单次输出上限，推荐 2000-3000。
• model：可以根据任务复杂度切换模型。常规的代码修改用 claude-3-5-sonnet-20240620 足够，不需要上 Opus。只有涉及复杂架构设计或需要深度推理时，我才临时切 Opus。

我的 .claude.yaml 典型配置大概长这样（这不是代码块，我描述一下结构）：在配置里关掉自动检测 gitignore 外的无关目录，只把 src/、config/ 和 package.json 纳入上下文；输出 token 硬封在 2500；把 *.test.* 文件从自动上下文中排除，因为我在让 AI 改业务逻辑时不需要测试代码干扰。

这个设置帮我把首轮请求的平均输入 token 从 6000-8000 压到了 2500-3500，首轮成本直接减半。

方案4：利用“系统指令复用”减少重复的系统提示词损耗

我们知道每次对话 Claude Code 都会注入系统提示词。这部分我们改不了，但我们可以把自己的需求写成“固定的引导词”，放进项目规则文件，让模型提前内化，而不是在每次请求里反复描述。

Claude Code 支持项目级指令文件，放在 .claude/settings.local.md 或通过 CLAUDE.md。我把项目的技术栈偏好、命名规范、常见库的使用约定写了进去。这样，我在每次发起请求时就不用再说“请用 TypeScript 严格模式、函数组件用箭头函数、使用 Zod 做校验”之类的套话了。这些信息变成了模型的内置知识，而不是每次都要消耗 200-300 token 去复述。

估算下来，这个习惯在日均 20 次交互的情况下，每月大约帮我省了 2-3 美元的输入成本。不算大钱，但关键是思维负担也轻了。

方案5：手动管理对话历史的“滑动窗口”

这一招偏硬核，但效果比 /compact 更精细。当我对精度要求极高、又不想被旧历史污染的场合，我会在对话到达某个节点后，手动把前面已解决的问题摘要一下，然后用 Ctrl+C 结束当前会话，新建一个对话，把摘要作为第一句话贴进去，告诉模型“这是之前完成的背景”。

说白了就是人工做压缩，牺牲一点便利性，换取极致的 token 利用率和上下文清洁度。我的体验是，人工压缩的信息保真度比模型自动压缩要高，因为在代码开发中，我知道哪些细节是后面还要用的，哪些可以丢掉。模型压缩有时候会过度泛化，把重要的函数签名给抽象没了。

我在一个 React 组件重构任务中对比过：一段经历 35 轮交互的长对话，用 /compact 压缩后，后续开发中模型出现了 3 次签名错误；而人工整理摘要再开新对话，零次签名错误，且总 token 消耗还低了 12%。

方案6：用 --output-format 控制回复中冗余内容的占比

Claude Code 支持 --output-format 参数，可以设成 text 或 stream-json。默认模式下，模型喜欢在你让它改代码之前先来一段“I'll help you modify that…”的礼貌性套话，然后再输出代码块。这段话消耗的就是实打实的输出 token。

我在非交互式脚本里调用 Claude Code 时，会加一些提示词引导，比如“只输出修改后的完整文件内容，不要任何解释”。但在交互式对话中，完全压制解释会让开发体验变差。我选择了一个折中：在任务要求里加一句“Brief explanation, then code”，通常能把解释部分从 300-500 token 压到 80-120 token。

另外，我发现开启 --verbose 模式看日志时，可以清楚地看到每次模型输出的 token 分布：有多少是真正的代码，有多少是自然语言。这个数据帮助我逐步调整提示词，把“解释/总输出”的比值从 22% 优化到了 9% 左右。

方案7：建立个人成本看板和预警阈值

光有技巧不够，人总会懈怠。我的最后一道防线是一个简陋但有效的监控脚本：每小时从 Anthropic Console 的 Usage API 拉一次数据，写入本地 JSON，然后用一个简单的 HTML 页面可视化。超过日预算 80% 时发通知。

这个看板让我发现了很多“隐形消费瞬间”。比如有一次我发现某天上午 10 点到 11 点之间 cost 陡增，翻日志一看，是我开着 Claude Code 去吃饭，同事家猫踩了我键盘，触发了十余次自动补全请求。后来我就养成了不用时立刻 exit 的习惯。

我不是推荐你复刻我的看板，但至少做两件事：

• 在 Anthropic Console 设置月度硬性预算上限，避免失控。
• 每周花五分钟扫一眼账单按 project 或 API key 的分布，看看哪类任务最耗钱。

不同规模项目下的成本取舍建议

Claude Code 不是越省越好。在错误的地方省钱，最终的代价是开发时间翻倍、代码质量下降，甚至引入更难排查的 bug。 所以成本控制必须分场景决策。

小型个人项目或学习项目：我建议以保护调试心流为主，不必过于纠结成本。设定一个 30 美元左右的月度预算上限，然后尽情用，重点是把东西做出来、把概念跑通。这个阶段，花 50 美分让 AI 帮你理清一段复杂逻辑，远比你自己翻两个小时文档值。唯一需要注意的是别把预算上限忘了，我见过有人在实验性项目上开着 Opus 跑自动化脚本，两天烧掉 $80。

中型业务项目（给自己或客户交付的）：这里要引入一个“是否值得拆分”的判断标准。我的经验法则是：如果一次对话预估 token 消耗超过 5000，或者任务跨越 3 个以上文件，就值得花一分钟拆分成独立的子对话。 这一分钟的前期规划，通常能换来 40%-60% 的 token 节约。另外，在中型项目里，强烈建议用 .claude.yaml 锁死上下文范围，不要每次动态加 --add-dir。

大型团队项目或企业级使用：这里就不能只靠个人习惯了，需要工程化管理。建立共享的 Claude Code 配置文件模板，统一上下文策略；在 CI / CD 中集成 token 消耗监控；对不同角色（前端、后端、全栈）设定差异化的模型和预算上限；定期审计哪些类型的任务消耗了最多的 token，针对性优化提示词或流程。

我用一张决策矩阵来总结不同阶段的取舍：

那些“省钱技巧”可能让你亏更多

我必须单开一节来谈这个，因为网上有些教程给出的建议，在 Claude Code 场景下是反效果。

误区纠正一：“用更便宜的模型平替”

有人建议日常用 Claude 3 Haiku，遇到难的才切 Sonnet。这在 API 直接调用的场景是好策略，但在 Claude Code 里我必须提醒你：Haiku 的工具调用准确率明显低于 Sonnet。我用 Haiku 跑过 3 天的自动化测试，发现它经常读错文件路径、误解 shell 命令的输出，导致来回多轮纠正，最终总消耗反而比直接用 Sonnet 多了 18%。每一次纠正都是在给历史浇 token。在需要密集工具调用的终端场景，模型能力的微小差距会被放大成巨大的成本差异。

误区纠正二：“关掉所有自动上下文”

Claude Code 允许你通过参数关闭自动文件读取。我试过纯手动提供所有代码，结果发现自己拼装上下文的时间成本远超 token 节省下来那几美分。而且手动贴代码经常漏掉依赖关系，导致模型给出的方案在项目里跑不通。更合理的策略是精确地半自动上下文，即保留自动上下文功能，但通过 .claude.yaml 把范围收窄到真正相关的文件子集。

误区纠正三：“无脑开缓存一定省钱”

Anthropic 对 API 缓存有特殊的定价规则，写入缓存的 token 比直接输入略贵，但命中缓存后的读取便宜很多。问题在于 Claude Code 的对话上下文是动态变化的，每次工具调用后整个上下文都变了，缓存命中率比很多人预想的低得多。我测过一周的数据，缓存命中率在 12%-19% 之间徘徊，而为了使用缓存我特意维持了长对话不拆分，结果整体账单反而高了 8%。结论：缓存是锦上添花，不是成本控制的支柱。你的首要任务永远是缩短对话、限制上下文。

我的终极经验与你的下一步行动

写到这里，我想把一件最重要的事点透：

Claude Code 这种工具的本质，是用 token 换开发者的认知负荷。 你每花 1 美分 token，买到的不是“文本输出”，而是“帮你做了几轮思考、读了几次文件、排查了几个错误、最终给出解决方案”的全过程。从这个角度看，Claude Code 并不贵，哪怕一个月花 200 美元，它创造的价值也远超这个数。

但问题在于，很多 token 不是花在了“思考”上，而是花在了“搬运历史”和“喂食无关信息”上。这就是我整篇文章试图帮你划清的界限：把 token 花在刀刃上，花在模型真正需要推理的部分，而不是重复传输已经确定的信息。

怎么做到？我把前面的内容浓缩成一个可以立刻执行的行动清单：

1. 花 10 分钟写一个 .claude.yaml，把上下文限定在你实际工作的 2-3 个目录。这是 ROI 最高的单次动作。
2. 建立“一任务一会话”的习惯。在任务边界果断结束当前对话，新任务开新会话。
3. 对话超过 20 轮或感觉“模型变慢”时，执行 /compact，不要等。
4. 把输出 max_tokens 限制在 2000-3000，除非你明确需要模型输出超大段代码。
5. 在 Anthropic Console 设一个月度预算上限，并每周扫一眼支出分布。
6. 用 Haiku 处理简单任务前，先做 3-5 次对比测试，确认不会因为纠错开销反而更贵。
7. 把项目约定写进 CLAUDE.md，省去每次对话的重复描述成本。

如果你目前正经历“账单没眼看”的阶段，不用焦虑。我认识的每个深度使用 Claude Code 的工程师，几乎都经历过一个 $200-$400 的“交学费月”。关键是从这个月里提取出自己的成本模型，然后把策略固化进工作流。

Claude Code 用得好，它就是你付过最值的开发费；用得便宜但用错了，省下的 token 会被浪费的时间加倍偿还。希望这篇用真金白银换来的记录，能帮你更快地走到“用得好，且不贵”的那个平衡点上。