> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# Claude Code 账单优化指南
- URL: https://www.hubwiz.com/blog/claude-code-billing-optimization-guide/
- Published: 2026-05-13T14:58:47.000Z
- Updated: 2026-05-13T14:58:47.000Z
- Description: 通过调整配置、会话习惯和 Desktop 技巧，防止费用持续累积
- Author: admin
- Tags: AGENT, CLAUDE CODE, #Import 2026-10-14 14:41

最近关于 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 响应也是如此。工具输出的体量几乎总是比对话消息本身大得多——而且以同样的方式累积。这是最大的隐形消耗。

![](https://substackcdn.com/image/fetch/$s_!J9_8!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F2b505069-1885-4a2f-b3ef-5d0b18bc3b50_762x524.png)

Claude Code（上）和 Claude Desktop（下）的工具调用输出

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*](https://github.com/anthropics/claude-code/issues/40524?ref=hubwiz.com)*）。计费层的不透明程度远超大多数构建者的想象。*

应对这三个问题的有效方法：分层策略。控制什么进入上下文。控制会话如何累积。控制工具向上下文倾倒什么。每一层都是独立的，但每层都会与其他层叠加影响。

## 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 插件](https://github.com/mksglu/context-mode?ref=hubwiz.com)，它将工具输出路由到一个沙盒知识库中，而不是直接倾倒到你的对话里。

当 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** 适用于机械性任务：重命名、格式化、快速查找、重复性编辑。

成本差异显著。按[当前定价](https://www.anthropic.com/pricing?ref=hubwiz.com)，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)](https://buildtolaunch.substack.com/p/claude-code-token-optimization)

汇智网翻译整理，转载请标明出处