一位开发者通过修复编程智能体中7个具体的Token浪费问题，将每日Claude Code开销从37美元降至13美元。
AI translation, not an official translation. Refer to the original for technical details.
Adapted from @sairahul1# 永远不再触碰Claude使用限额 我每天花37美元运行Claude Code。 一个月超过1,000美元。 我以为我在为智能买单。 其实是在为噪音买单。 以下是7个原因，解释为何大多数编程智能体消耗的Token是实际所需的2到3倍，以及我做了哪些改变，在不影响输出质量的情况下将每日花费从37美元降到13美元（某些天甚至更低）。 收藏这篇文章。这里的每一条，此刻都在让你白白烧钱。 ## 1. 智能体为了找一个文件而读取整个代码库 你说："修复这个身份验证Bug。" 智能体不知道身份验证模块在哪里。 于是它把所有东西都读了一遍。 → 打开完整的支付模块 → 读取相邻文件以理解代码规范 → 上下文偏移后又重新读取相同的文件 → 最终找到正确的文件 → 完成修改 到这一步，它已经为一个300个Token的改动消耗了40,000个Token。 解决方案：为智能体提供结构化上下文，而不是让它盲目搜索代码库。 像semble这样的本地工具可以通过基于向量的语义搜索减少浪费。但若要更深入地理解代码，Sonar Vortex更进一步：它使用基于AST的静态分析和图导航来映射真实的代码关系，例如调用栈和类层级结构。(https://www.sonarsource.com/products/sonar-vortex/) 智能体获得的不仅仅是看起来相关的文本，而是关于代码实际连接方式的架构上下文。 ## 2. Opus被用于Haiku在200毫秒内就能处理的任务 大多数编程智能体默认对所有任务使用能力最强的模型。 这意味着你最强大、最昂贵的模型在回答"这个函数是做什么的"这类问题。 模型的成本差异是真实存在且巨大的： → Haiku：定位代码、grep搜索、理解函数、审查差异 → Sonnet：所有迭代性和对话性任务的默认选择 → Opus：仅用于架构决策和跨模块重构策略 用Opus来回答"这个变量是做什么的"，就像花500美元时薪雇一位高级架构师来告诉你洗手间在哪里。 解决方案：在你的CLAUDE.md中写入硬性路由规则，在智能体自行决定之前强制指定模型选择。(http://claude.md/) 仅此一项改变，在实施后就能带来40%以上的成本降低。 ## 3. CLI输出用没人需要的噪音淹没上下文 运行 `npm install` ，智能体会读取每一行。 运行 `git status` ，它会处理完整的差异。 运行 `kubectl describe pod` ，3,000行YAML进入你的上下文窗口。 这些都不是你需要的内容。 智能体仍然全部处理，因为这些内容在智能体决定忽略之前就已经进入了上下文。 解决方案：使用一个pre-tool钩子，在已知的冗长命令淹没上下文之前将其拦截。 可节省60%到90%的bash输出Token消耗。行为零改变。智能体只是不再读取那些它从来不需要的大段文本。 ## 4. 每次新会话都从零开始 上周二你完成了一个功能。 今天你打开一个新的Claude Code会话来继续它。 智能体对上周二发生的事一无所知。 你要花头5到10分钟重新解释： → 你在构建什么 → 你已经尝试过什么 → 什么失败了，为什么 → 当前状态是什么 这些重新解释不是免费的。 这是数千个Token的上下文，本应早已存在。 解决方案：跨会话的语义记忆，从你过去的对话和项目历史中挖掘信息。 不再重新解释你上周构建的内容。 智能体以真正的连续性接续工作，而不是每次都失忆重来。 ## 5. 抓取 URL 会将原始 HTML 直接倾倒进你的上下文 你让代理去查一个 GitHub issue。 它抓取了该 URL。 60KB 的原始 HTML 进入了你的上下文窗口。 导航栏。页眉。页脚。侧边栏。Cookie 提示横幅。真正的 issue 内容被埋在某个角落里。 代理处理了所有这些内容。 你的账单也反映了所有这些内容。 解决方案：在外部内容进入上下文之前先进行压缩。 上下文模式（Context-mode）会在 URL 和文档进入你的窗口之前将其压缩 94–100%。 一个 60KB 的 GitHub issue 变成了真正有价值的 400 个 token。 ## 6. 代理在同一会话中重复读取同一文件三次 你询问文件 A 的内容。 代理读取了文件 A。 稍后你又问了一个相关问题。 代理再次读取了文件 A。 然后又读了一次。 每次读取都消耗完整的 token。没有缓存。没有"我已经读过这个了"的机制。 解决方案：在 CLAUDE.md 中写一条强制规则。(http://claude.md/) 一行规则。消除你在每次多步骤会话中默默支付的隐性成本。 ## 7. 代理自身的输出比实际需要的更冗长 这一点最让我感到意外。 代理默认会生成冗长、繁复的回复。 对每个步骤进行详细解释。 附带大量内联注释的完整代码。 在给出答案之前先来一大段铺垫。 输出 token 同样需要花钱。 穴居人模式（Caveman Mode）会压缩 Claude 自身的输出——更简短、更精炼、信息量不变——将输出 token 的花费削减约 65%。 有效模式：`off`、`lite`、`full`、`ultra` 你得到同样的答案，但输出 token 大幅减少。 ## 修复全部 7 个问题后的数据 修复前：$37/天 —— 92% Opus，无路由，无压缩，无记忆 修复后：$13/天 —— 5% Opus，95% Sonnet，全部 7 层机制运行 成本降低 65%。输出质量零下滑。 按降本幅度排序，前三大单项收益依次为： → 模型路由规则 —— 单项贡献总降幅的 40% 以上 → 结构化代码导航 —— 减少盲目搜索和不必要的文件读取 → CLI 噪声过滤 —— 零行为变化，立竿见影地节省开支 你不需要一次性全部实施这 7 项。 如果你只做一件事：将模型路由规则添加到你的 CLAUDE.md，并在代理开始搜索之前给它提供结构化的代码上下文。(http://claude.md/) 仅此一项，在不做任何其他改动的情况下，就能削减相当可观的花费。 这 7 个问题背后的共同规律 每一个问题，不过是同一个核心问题换了一副面孔。 代理不知道自己需要什么。 于是它读取所有内容，处理所有内容，以最大篇幅生成所有内容——然后把账单全部转给你。 解决方案始终如一：在它开始编写之前给它提供更好的上下文，而不是事后补救。 编写前提供更好的上下文 → 用于查找所需内容的 token 更少。 将验证纳入循环 → 需要修复的错误更少。 减少返工 → 代理在每次会话中运行效率更高。 自从我开始大规模运行代理以来，我一直在思考这个问题——"代理开始前已知的内容"与"它必须在会话中途自行摸索的内容"之间的差距，正是几乎所有浪费的根源所在。 Sonar 一直在用 Sonar Vortex 攻克这个问题，在代理开始编写之前注入精确的架构上下文，然后在编码循环内部实时验证输出。如果你认真考虑让大规模的智能体开发从经济上可行，这篇文章值得一读：https://fandf.co/4hKO1Fe（https://www.sonarsource.com/） ## 想进一步削减成本？以下 10 个 GitHub 仓库可以带你深入研究： → RTK —— 一个 CLI 代理，在终端输出进入上下文之前对其进行过滤。在常见开发命令上实现 60–90% 的降幅。github.com/rtk-ai/rtk → Context Mode — 将原始工具输出沙箱化到 SQLite，而非直接转储到上下文中。在 Playwright、GitHub、日志方面减少 98%。github.com/mksglu/context-mode → code-review-graph — 使用 Tree-sitter 构建本地代码库知识图谱。在大型单体仓库上减少 49 倍。github.com/tirth8205/code-review-graph → Token Savior — 通过符号而非完整文件来导航代码的 MCP 服务器。在代码导航上减少 97%。github.com/Mibayy/token-savior → Caveman Claude — 让 Claude 像穴居人一样说话以削减输出 token。输出减少 65–75%，准确率不变。github.com/JuliusBrussee/caveman → claude-token-efficient — 一个让响应保持简洁的 CLAUDE.md 文件。即插即用，无需修改代码。github.com/drona23/claude-token-efficient (http://claude.md/) → token-optimizer-mcp — 具备缓存、压缩和智能工具的 MCP 服务器。通过智能缓存减少 95% 以上。github.com/ooples/token-optimizer-mcp → claude-token-optimizer — 适用于任何项目的可复用设置提示词。将文档 token 用量从 11K 降至 1.3K。github.com/nadimtuhin/claude-token-optimizer → token-optimizer — 找出悄悄消耗上下文的幽灵 token。在压缩后仍能保持质量不损失。github.com/alexgreensh/token-optimizer → claude-context（Zilliz）— 使用混合 BM25 + 稠密向量搜索的代码搜索 MCP。在检索质量相当的情况下减少约 40%。github.com/zilliztech/claude-context 如何选择： → 终端输出量大？选 RTK → 代码库庞大？选 code-review-graph + Token Savior → MCP 服务器较多？选 Context Mode → 想要快速见效？选 Caveman + claude-token-efficient 在新会话中运行 `/context`，看看在你敲下第一个字之前已经消耗了多少。 如果觉得有用： → 转发给每一位使用 Claude Code 的开发者 → 关注 @sairahul1，获取更多此类系统内容 → 收藏本帖 — 这 7 个修复方案均可独立使用，从第 1 和第 2 个开始 由 Sonar 赞助。(https://www.sonarsource.com/)
