Claude Code 日成本从 37 美元降至 13 美元:7 个 Token 浪费原因及修复方案

我每天运行 Claude Code 要花 37 美元。
每月超过 1,000 美元。
我以为我付钱买的是智能。
实际上我付钱买的是噪音。
以下是大多数 coding agent 多消耗 2–3 倍 Token 的 7 个原因,以及我做了哪些改动,把每天的开销从 37 美元降到 13 美元(有些天甚至降得更多),同时完全不牺牲输出质量。
收藏这篇文章。其中每一条现在都在让你花钱。
1. Agent 为了找一个文件而读遍整个代码库

你说:“修复 auth bug。”
Agent 不知道 auth 模块在哪里。
于是它读取所有内容。
→ 打开完整的 payments 模块
→ 读取相邻文件来理解代码模式
→ 当上下文漂移时重新读取相同的文件
→ 最终找到正确的文件
→ 进行修改
到那时,它已经为一个 300 Token 的修改消耗了 40,000 个 Token。
解决方法:给 Agent 提供结构化的上下文,而不是让它盲目地在代码库中搜索。
像 semble 这样的本地工具可以通过基于向量的语义搜索减少浪费。但要获得更深入的代码理解,Sonar Vortex 走得更远:它使用基于 AST 的静态分析和图导航来映射实际的代码关系,比如调用栈和类层次结构。
Agent 不只是找到看起来相关的文本,而是获得关于代码实际如何连接的架构级上下文。
2. Haiku 能在 200ms 内处理的任务却动用了 Opus
大多数 coding agent 默认对所有任务都使用最强大的模型。
这意味着你最好、最贵的模型在回答诸如“这个函数是做什么的”这类问题。
模型成本分层真实存在且差距巨大:
→ Haiku:定位代码、grep、理解函数、diff 审查
→ Sonnet:所有迭代性和对话性任务的默认选择
→ Opus:仅用于架构决策和多模块重构策略
用 Opus 回答“这个变量是做什么的”这种问题,就像花每小时 500 美元请一位资深架构师告诉你洗手间在哪。
解决方法:在你的 CLAUDE.md 中设置硬性路由规则,强制在 Agent 自行决定之前先完成模型选择。
## 三层模型路由
Haiku 4.5 → 定位代码、grep、理解、diff 审查
Sonnet 4.6 → 所有迭代性任务的默认选择
Opus 4.7 → 仅用于架构决策
绝不要用 Opus 做:
- 代码查找或文件读取
- 单函数相关问题
- Diff 审查
仅这一项改动,实施后就能带来 40% 以上的成本降低。
3. CLI 输出用没人需要的噪音淹没上下文

运行 npm install,Agent 会逐行读取。
运行 git status,它会处理完整的 diff。
运行 kubectl describe pod,3000 行 YAML 进入你的上下文窗口。
这些都不是你需要的内容。
但 Agent 还是会全部处理,因为在它来得及决定忽略之前,这些内容已经进入上下文了。
解决方法:用一个 pre-tool hook 在已知的冗长命令淹没上下文之前将其拦截。
## 在冗余输出进入上下文之前将其拦截
if echo "$command" | grep -qE '(pytest|EXPLAIN ANALYZE)'; then
echo "Use ctx_batch_execute instead." >&2
exit 2
fi
if echo "$command" | grep -qE '(kubectl logs|kubectl describe|gcloud|gh api)'; then
echo "Blocked: verbose output. Redirect to sandbox." >&2
exit 2
fi
在 bash 输出上节省 60–90%。行为零改变。Agent 只是不再阅读那些它从来不需要的大段文字。
4. 每个新会话都从零开始
你上周二完成了一个功能。
今天你打开一个新的 Claude Code 会话想继续做下去。
Agent 对上周二发生的事情一无所知。
你要花最初的 5–10 分钟重新解释:
→ 你当时在构建什么
→ 你已经尝试过什么
→ 什么失败了以及为什么
→ 目前的状态是什么
这种重新解释不是免费的。
它是本应早已存在的数千 Token 的上下文。
解决方法:跨会话语义记忆,挖掘你过去的对话和项目历史。
## 索引你过去的会话
mempalace mine ~/.claude/projects/ --mode convos
## 未来的会话会自动浮现相关上下文
## “上周的 auth 工作”无需重新解释就会出现
不再需要重新解释你上周构建了什么。
Agent 带着真正的连续性继续工作,而不是失忆。
5. 抓取一个 URL 会把原始 HTML 倾倒进你的上下文
你让 Agent 查看一个 GitHub issue。
它抓取该 URL。
60KB 的原始 HTML 进入你的上下文窗口。
导航栏。页眉。页脚。侧边栏。Cookie 提示条。真正的内容被埋在其中的某个地方。
Agent 全部处理一遍。
你的账单也全部反映出来。
解决方法:在外部内容进入上下文之前进行压缩。
## 在 CLAUDE.md 中 —— 添加这条规则:
公开 URL → 先 ctx_fetch_and_index(url),再用 ctx_search
绝不直接内联 WebFetch。
Notion 页面 → 每个会话只抓取一次,写入后绝不重复抓取。
Context-mode 在 URL 和文档进入你的窗口之前将其压缩 94–100%。
一个 60KB 的 GitHub issue 变成真正重要的那 400 个 Token。
6. Agent 在同一个会话中把同一个文件读三遍
你询问文件 A。
Agent 读取文件 A。
之后你问了一个相关的问题。
Agent 又读取了一遍文件 A。
然后又读了一遍。
每次读取都是全额 Token。没有缓存。没有“我已经读过这个了”。
解决方法:在 CLAUDE.md 中加一条硬性规则。
## 防止重复读取规则 —— 添加这条规则并严格执行:
绝不在同一会话中重复读取已经读过的文件。
如果需要再次引用,就使用上下文中已有的内容。
一行规则。消除你在每个多步骤会话中都在缴纳的一笔隐形税。
7. Agent 自己的输出比实际需要更长

这一条最让我意外。
Agent 默认生成冗长的回复。
对每一步的详细解释。
附带大量行内注释的完整代码。
在给出答案之前的长篇铺垫。
输出 Token 同样要花钱。
Caveman Mode 压缩 Claude 自己的输出——更短、更密集、信息量相同——将输出 Token 开销削减约 65%。
## 安装并设置强度
mkdir -p ~/.config/caveman
cat > ~/.config/caveman/config.json << 'JSON'
{
"defaultMode": "full"
}
JSON
有效模式:off、lite、full、ultra
你得到同样的答案。输出 Token 显著减少。
修复全部 7 条之后的数字
之前:每天 37 美元 —— 92% 使用 Opus,无路由、无压缩、无记忆
之后:每天 13 美元 —— 5% 使用 Opus,95% 使用 Sonnet,全部 7 层措施运行中
成本降低 65%。输出质量零下降。
按顺序排列,三个最大的单项收益:
→ 模型路由规则 —— 仅此一项就占总降幅的 40% 以上
→ 结构化代码导航 —— 减少盲目搜索和不必要的文件读取
→ CLI 噪音过滤 —— 行为零改变,立竿见影的节省
你不需要一次性做到全部 7 条。
如果你只做一件事:在 CLAUDE.md 中添加模型路由规则,并在 Agent 开始搜索之前给它结构化的代码上下文。
仅这一项就能在不做其他任何改动的情况下砍掉你开销中的很大一块。
所有 7 条背后的共同模式
每一条都是同一个问题换了个伪装。
Agent 不知道自己需要什么。
于是它读取一切、处理一切、以完整篇幅生成一切——然后为所有这些向你收费。
解决方法始终相同:在它动手写之前给它更好的上下文,而不是之后。
更好的前置上下文 → 找到所需内容消耗的 Token 更少。
把验证纳入流程 → 需要修复的错误更少。
更少的返工 → Agent 每次会话运行得更高效。
这就是我从大规模运行 Agent 开始一直在思考的问题:“Agent 开始前已知的东西”和“它必须在会话中途摸索出来的东西”之间的差距,几乎所有的浪费都存在于这里。
想进一步削减吗?
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 构建代码库的本地知识图谱。大型 monorepo 可减少 49 倍。github.com/tirth8205/code-review-graph
- Token Savior —— 通过符号而非整个文件来导航代码的 MCP server。代码导航可减少 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
- token-optimizer-mcp —— 具备缓存、压缩和智能工具判断能力的 MCP server。通过智能缓存可减少 95% 以上。github.com/ooples/token-optimizer-mcp
- claude-token-optimizer —— 可复用于任何项目的配置提示词。将文档 Token 用量从 11K 降至 1.3K。github.com/nadimtuhin/claude-token-optimizer
- token-optimizer —— 找出悄悄吞噬你上下文的幽灵 Token。经受得住 compaction 而不损失质量。github.com/alexgreensh/token-optimizer
- claude-context(Zilliz) —— 使用 BM25 + 稠密向量混合搜索的代码搜索 MCP。检索质量相当的情况下减少约 40%。github.com/zilliztech/claude-context
如何选择:
- 终端输出很重?RTK
- 代码库很大?code-review-graph + Token Savior
- MCP server 很多?Context Mode
- 想快速见效?Caveman + claude-token-efficient
在一个全新会话中运行 /context,看看在你还没输入一个字之前就已经消耗了多少。
- 原文链接: x.com/sairahul1/status/2...
- 鸿途知科网 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
版权声明
本文仅代表作者观点,不代表区块链技术网立场。
本文系作者授权本站发表,未经许可,不得转载。
鸿途知科网
发表评论:
◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。