Claude Code 账单优化指南
最近关于 Claude Code 的账单吐槽已经随处可见：社区里、Reddit 上、我的私信中。人们分享的数字并非极端个案。如果你想了解更宏观的视角，我写了一篇关于经济高效的 AI 构建的独立指南，但本文专门聚焦于 Claude Code 和 Desktop 内部的 token 机制。
两个月前，我的账单达到了 $1,600。
在那之前的几周里，我大幅增加了 Claude Code 的使用量（构建、写作、实验）。我自以为已经很谨慎了。但当那张发票到账时，我真的震惊了。细想一下，这其实说得通。
确实，我每次会话都是从干净的状态开始的。但我让 Claude 读取的每一个文件，都会把其全部内容永久地添加到该会话的上下文窗口中。每个 MCP 工具的响应都是完整的 JSON，而非摘要。Claude 扫描的每一份日志。所有这些都在不知不觉中层层叠加。
而且因为 Claude 在每一条消息中都会重新读取完整的上下文，会话中的第 40 条消息要为之前所有内容买单。
我并不是因为糟糕的 prompt 在浪费 token。我是因为看不见的架构在浪费 token。
1、Claude Code和Desktop的token机制
解决方案不是一堆零散的技巧。而是先理解机制，然后围绕它构建一套系统。
1.1 工具调用输出
让我们先看看工具调用输出如何在不知不觉中消耗你的 Claude Code 预算。
每次 Claude 读取文件、运行 shell 命令或调用 MCP 服务器时，完整的输出都会被追加到上下文中。不是摘要，是全部内容。
一个 10,000 行的日志文件在该会话的后续每条消息中都会保留在上下文中。MCP 服务器返回的大型 JSON 响应也是如此。工具输出的体量几乎总是比对话消息本身大得多——而且以同样的方式累积。这是最大的隐形消耗。
Claude Code 最大的成本驱动因素不是你的消息，而是每次工具调用的完整、未经过滤的输出在会话剩余时间内持续累积在上下文中。
1.2 为什么长会话成本更高
接下来我们介绍上下文累积的工作原理。
Claude 在每条消息中都会从头重新读取整个对话。第 50 条消息比第 5 条消息成本更高，不是因为你问了更难的问题，而是因为 Claude 要先重新读取前 49 条消息。长会话变成了 token 熔炉。
长会话不仅成本更高，还会让 Claude 变得更差。随着较早的上下文权重降低、先前的指令被降低优先级，质量会逐渐下降。这就是上下文腐化——一个独立的问题，但修复方法有重叠之处。
1.3 关于CLAUDE.md
还有，你的 CLAUDE.md 文件会在每条消息之前就消耗 Token。
你的 CLAUDE.md 在 Claude 读取你的代码之前加载，在它读取你的任务之前加载，在一切之前加载。一个 5,000 token 的 CLAUDE.md 在你打一个字之前就已经消耗了 5,000 token。每一轮、每次会话都是如此。这是一个你始终背负的固定基线。
Extended thinking 也是真实的消耗——它消耗输出 token，默认预算每次请求可能达到数万 token。但它排在第四位。先解决上面三个问题。
2026 年 3 月的缓存事件值得了解：Anthropic 的 prompt 缓存中的两个 bug 导致了 10-20 倍的 token 膨胀，且没有任何预警。用户不得不逆向工程 Claude Code 二进制文件才能发现它们（GitHub issue #40524）。计费层的不透明程度远超大多数构建者的想象。
应对这三个问题的有效方法：分层策略。控制什么进入上下文。控制会话如何累积。控制工具向上下文倾倒什么。每一层都是独立的，但每层都会与其他层叠加影响。
2、一次性Claude Code 设置
这些都是一次性修改。做一次，之后每次会话都能受益。
2.1 设置 .claudeignore 阻止 Claude 读取高成本文件
Claude Code 支持 .claudeignore 文件，其工作方式与 .gitignore 完全相同。如果某个内容在忽略列表中，Claude 就无法读取它，也不会在工具搜索时意外加载它。
起始模板：
node_modules/
.next/
dist/
build/
*.log
*.lock
coverage/
.env*
__pycache__/
*.pyc
根据你的技术栈进行调整。原则相同：Claude 完成工作所不需要看到的任何内容，都不应该对它可见。
不要忽略什么：Claude 实际需要的文件。过度裁剪会导致 Claude 缺失相关上下文，做出更差的决策。目标是精准裁剪，而不是焦土政策。
2.2 断开未使用的 MCP 服务器以消除每次请求的开销
说实话：我对 MCP 非常着迷，已经积攒了各种各样的 MCP。这也是为什么这个问题也困扰了我。如果你还在为 Claude Code 设置 MCP 服务器，那篇指南涵盖了类型和安装方法。
每个已连接的 MCP 服务器都会增加 Claude 在会话启动时需要推理的内容，即使你在该会话中从未调用过它。每个已连接的服务器在每次请求中都有一个不大但确实存在的开销。
检查你的 MCP 列表。如果一个服务器你已经一周没用过了，就断开它。需要时再重新连接。这是一个 10 秒钟的操作，却能带来持续累积的节省。
这同样适用于 Claude Desktop：从 claude_desktop_config.json 中移除未使用的服务器。同样的开销，同样的解决方法。
2.3 禁用未使用的 Claude Code 插件以降低基线 Token 负载
插件也是同样的情况。我运行的插件比实际需要的更多。Claude Code 中的活跃插件无论你是否调用都会增加开销。只保留当前项目或工作流中正在使用的插件。
这同样适用于 Claude Desktop：你可以在设置中禁用集成。同样的原则——如果当前工作流用不到，就关掉它。
2.4 安装 context-mode 将 MCP Token 输出降低 50–90%
context-mode 是一个开源 MCP 插件，它将工具输出路由到一个沙盒知识库中，而不是直接倾倒到你的对话里。
当 MCP 服务器返回 10,000 token 的原始 JSON 时，context-mode 会对其进行索引。Claude 获得一份摘要，需要具体细节时可以搜索已索引的内容。你的主上下文保持干净。
我每天都在使用它。在工具活跃的会话中，它能将 MCP 相关的 token 用量降低 50% 到 90%。如果你经常使用多个 MCP 服务器，这是本指南中杠杆效应最高的单一改动。
2.5 将 CLAUDE.md 控制在 500 Token 以内以降低固定基线
CLAUDE.md 应该给 Claude 提供项目的轮廓，而不是完整的文档。
五条规则加三个文件路径指引是合适的尺寸。将项目特定的工作流和参考资料放在单独的文件中，通过路径引用。Claude 只在处理相关内容时才读取那些文件，而不是每一轮都读取。
目标：500 token 以内。
# CLAUDE.md
## Rules
- Use TypeScript strict mode
- Write tests for every new function
- Follow existing patterns in the codebase
## Key Files
- API routes: see src/api/README.md
- Database schema: see docs/schema.md
- Style guide: see docs/style-guide.md
三条规则。三个路径指引。不到 200 token。Claude 只在处理相关内容时才读取链接的文件。
3、降低 Token 用量的 Claude Code 会话习惯
这些是习惯：每次打开 Claude Code 时你要做（或停止做）的事情。设置层降低了基线，这一层控制上下文从那里如何累积。
3.1 每个聊天只讨论一个主题，避免隐形上下文浪费
将之前主题的上下文带入新主题是隐形浪费。如果你之前在调试数据库问题，现在想处理 UI，就开启一个新的对话。旧的上下文对新任务没有任何帮助，只会增加每条消息的成本。
新主题 = 新聊天。没有例外。
这适用于所有 Claude 接口——Claude Desktop、Claude.ai、Claude Code 都以相同的方式累积上下文。
3.2 何时使用 /clear 与 /compact
两个不同的工具。搞清楚各自做什么。
/clear 清除整个对话。干净的状态，零上下文。在完全切换任务时使用。你不需要之前发生的任何内容。
/compact 对对话进行摘要并从摘要重新开始。在上下文变长但你仍需要保留之前线索时使用。它压缩，但不擦除。
当你想用 /compact 时却用了 /clear，意味着要重新解释本来已有的上下文。当你想用 /clear 时却用了 /compact，意味着带着主动膨胀新任务的旧上下文。
在 Claude Desktop 和 Claude.ai 上： /clear = 开启新聊天。没有 /compact 的等价功能——你唯一的选择就是全新开始。
3.3 让 Claude 针对特定文件而非整个仓库
如果你用过 Claude Code 一段时间，你可能说过类似"读一下代码库"或"看一下项目"这样的话。这很昂贵。Claude 会加载并处理它能看到的每个文件。
要具体。明确告诉 Claude 哪些文件与任务相关。大多数任务只涉及两三个文件。直接指向那些文件。
3.4 自己要读的数据用脚本获取，不要让 Claude 介入
如果目的是获取某些内容然后自己看，就写个脚本。不要让 Claude 去加载。
每次 read_file 工具调用都会将完整文件内容永久追加到该会话的上下文中。如果你打算自己看日志文件、拉取 API 响应或查看数据文件，就用 shell 脚本。Claude 不需要参与其中。
通用习惯：无论你在 Claude Code、Claude Desktop 还是 Claude.ai 中都适用。
3.5 用 CLI 工具替代 MCP 进行精准的低 Token 读取
当 CLI 可以完成 MCP 服务器的工作时，就用 CLI。CLI 工具返回精准、有范围的输出。MCP 工具无论你是否需要全部内容，都会将完整响应倾倒到你的上下文中。
一个返回 10 行的 shell 命令只消耗 10 token 的上下文。同样的请求通过 MCP 服务器可能返回一个结构化的 JSON 数据块，体量是前者的 100 倍。在整个会话中，差异会持续累积。
在默认使用 MCP 之前问问：是否已有 CLI 工具能做这件事？如果有，就用 CLI。
3.6 在 Haiku、Sonnet 和 Opus 之间切换以控制成本
Claude Code 的三个主要模型各有其适用场景。
Opus 适用于架构决策、复杂推理、多文件重构、高难度调试问题。 Sonnet 适用于实现代码、编写测试、解释代码、大多数日常工作。 Haiku 适用于机械性任务：重命名、格式化、快速查找、重复性编辑。
成本差异显著。按当前定价，Haiku 每 input token 的成本大约是 Opus 的 1/5。如果一个任务 Claude 在 30 秒内就能回答，它可能不需要 Opus。在开始前用 /model 切换。
Haiku 的短板：看起来简单但实际上需要阅读代码并做出判断的任务。它会比 Opus 更快、更便宜地给出错误答案，然后你还得花一个纠正周期的成本。拿不准时，Sonnet 是可靠的中庸之选。
同样适用于 Claude Desktop：模型选择可以在同一会话中使用。在重负载任务之前切换，而不是之后。
3.7 限制 Extended Thinking 的 Token 预算
Extended thinking 按输出 token 计费，默认预算每次请求可能在不知不觉中达到数万 token。
对于不需要深度推理的任务：
/effort low
或者设置一个硬性的环境变量上限：
MAX_THINKING_TOKENS=8000
这仍然允许有意义的推理，同时防止在不需要它的任务上产生失控的成本。
何时不要优化：复杂规划、架构决策、多步骤问题分解。当质量差异确实存在时，Opus + extended thinking 的成本是值得的。不要在重要决策上节省不该省的投入。
3.8 按需加载 Claude Code Skills，而非在会话启动时
在 Claude Code 中，skills 只在显式调用时才加载其实际内容。它们不会仅仅因为已安装就自动加载。
skill 列表在会话启动时自动加载。这是 Claude Code 的框架行为，没有内置开关可以排除它。但 skill 的内容（可能有数百行）在你用 /skill-name 调用之前一直处于休眠状态。
这意味着：不要调用当前任务不需要的 skills。不要出于习惯在会话开始时调用它们。需要时才加载你需要的。
3.9 使用子代理隔离高上下文负载的任务
当一个任务需要读取大量文件、运行长时间分析或生成大量工具输出时，将它委托给子代理。
子代理在独立的会话中运行。它们的上下文独立于你的主对话进行累积。当它们完成时，你得到结果，而它们的会话权重不会出现在你后续的成本中。
任何需要 Claude 读取超过三四个大文件的任务都是很好的子代理候选。你的主会话上下文保持干净，而子代理可以根据需要深入探索。
4、在 Claude.ai 和 $20 套餐上降低 Token 成本
本节面向 claude.ai 用户（Cowork、Chat、Web 界面）。不同的工具，同样的核心问题。
4.1 在 $20 套餐上避免用 Claude.ai Cowork 做探索性工作
Cowork 很强大，但也昂贵。每个会话在开始任何任务之前都会先读取你的项目文件夹。在你还没问任何问题之前就已经消耗了 token。
在 $20 套餐上，大部分工作请使用 Chat。在 Chat 中理清结构，敲定细节，确定方案。然后只在你确切知道要构建什么时才切换到 Cowork。在更便宜的产品中做思考，在更贵的产品中做构建——只在值得的时候才用。
4.2 只加载与当前任务相关的文件
不要把整个文件夹倾倒到 Cowork 会话中。只选择与特定任务相关的文件。选择零个文件夹意味着零本地文件上下文，对于根本不需要你文件的任务来说，这恰好是正确的。
4.3 自己记会话笔记而非依赖 AI 记忆
让 Claude 记住一切是对每次会话的 token 税。
自己记笔记。使用 session-notes.md 模式：在会话结束时，让 Claude 摘要关键决策和下一步。开始下次会话时加载那个文件。你只携带重要的内容，其他一概不带。
适用于 Claude Code、Claude Desktop 和 Claude.ai。接口不重要，习惯才重要。
4.4 在 Chat 中规划好再生成 Artifacts 以避免浪费 Token
Artifacts（电子表格、文档、幻灯片）比聊天消息成本更高。在 Chat 中规划好结构，然后在确切知道你想要什么之后再构建 artifact。
在 artifact 中探索想法很昂贵；在 Chat 中探索想法很便宜。
同样的逻辑适用于图片。生成一张是有用的。但要问问自己：这对当前正在做的事情真的有用吗？如果有用，就生成。如果只是实验，就跳过。
同样的原则在 Claude Code 中也适用：在启动代理或 artifact 之前先在 Chat 中规划。更便宜的思考阶段能节省更昂贵的执行阶段。
4.5 复用已有的 Skills 和工作流而非从头重新 Prompt
如果你已经构建了一个工作流，就用它。如果某个 skill 已经能完成当前任务，就调用它而不是从头重新 prompt。
同一个工作流从头运行两次，会为同样的结果消耗两倍的 token。构建一次，反复复用。
5、追踪和衡量 Token 节省效果
Token 优化中最容易被跳过的环节：在开始之前设置基线。没有基线，你无从知道是否真的有所改善。
5.1 在优化之前设置 Claude Code Token 基线
首先，了解你的工具。在 API 计费模式下，在会话结束时使用 /cost。它会显示 token 数量和预估费用。
要查看跨会话历史记录，前往 console.anthropic.com → Usage。在订阅模式（Pro、Max）下，/cost 只会确认你的套餐信息。改为前往 claude.ai → Settings → Usage，它会显示剩余配额和窗口重置时间。
无论哪种方式：选择一个有代表性的任务，记录你的数据，应用本文中的修改，运行相同的任务，再次检查。这个对比就是你的信号。没有它，你只是在猜测。
5.2 危险信号：相同的工作成本比昨天显著更高
API 用户看到的是成本飙升：同样的任务，账单是昨天的 10 倍。订阅用户看到的是配额消耗：同样的工作量比平时更快地烧完窗口时间。两者都指向同一个原因：缓存问题。
检查：你是否在会话中途切换了模型？消息之间是否有很长的间隔？对话是否以某种方式重组导致缓存连续性中断？如果没有任何解释且模式持续存在，检查你是否遇到了类似于 2026 年 3 月事件的缓存 bug，而不要想当然地认为它是常态。
5.3 危险信号：上下文过载表现为 ECONNRESET 和 500 错误
上下文过载不总是以账单的形式出现。有时它表现为错误，而错误的类型大致能告诉你问题出在哪里：
Internal server error (500)：服务器在处理你的请求时遇到了困难。如果这种情况持续出现（而非偶尔发生），通常与上下文有关。ECONNRESET/EPIPE：服务器在请求过程中断开了连接。通常意味着因为上下文过大导致处理时间过长。看起来像是网络问题，但通常不是。- "Chat has reached its limit"：上下文窗口被硬性触顶。当你启动多个子代理，而它们的输出同时返回到同一个主会话时，这种情况会很快发生。
这三种错误是一个递进的过程。如果你经常遇到其中任何一个，解决办法不是检查网络或重试，而是使用 /compact 或开始一个新会话。我在处理大型项目时三种都遇到过。
5.4 低成本的 Claude Code 会话实际是什么样的
保持专注和范围明确的会话，其消耗（无论是费用还是配额）远低于范围蔓延的会话。一整天的专注工作应该完全在你的限额之内。这种差异是可衡量的，不是理论上的。
6、优化体系总结
值得思考的问题是：不仅仅是如何更好地使用 Claude Code，而是如何设计你的会话结构，让这个机制为你所用，而不是与你作对？
答案就是这套体系：
初级：从设置层开始
安装 context-mode，添加 .claudeignore，并将你的 CLAUDE.md 控制在 500 token 以内。这些都是一次性改动，无需养成新习惯就能改善每一次会话。
中级：加入会话纪律
每次聊天只运行一个任务。使用 /compact 而不是让会话无限延长。让 Claude 针对特定文件工作，而不是"整个项目"。用 /cost 追踪几个会话，看看有什么变化。
高级：围绕子代理重新设计
对于任何需要读取大量上下文或运行多步分析的工作流，将其迁移到子代理模式。主会话用于方向把控和结果审查，让子代理累积大量上下文，而这些不会影响你正在进行的工作。
原文链接: Claude Code Token Optimization: Stop the $1,600 Bill (2026 Guide)
汇智网翻译整理，转载请标明出处