DeepSeek V4 Flash 上线 · 我们的 GLM-5.2 价格本次下调至 5折
OmniaKey
登录
博客
成本控制

降低 Claude Code Token 消耗

最大的节省通常来自减少反复携带的上下文和避免返工，而不是单纯要求 Claude 把最终回答写短。

12 分钟阅读OmniaKey
Claude Codetoken usagecontextcost control

要降低 Claude Code Token 消耗，首先要控制模型每一轮必须重新处理的内容。即使最终回答很短，只要请求里带着很长的历史对话、多个文件、命令输出、项目规则、工具定义和 extended thinking，这一轮仍可能很贵。

真正值得优化的指标，不是某一次回答用了最少 Token，而是一个改动从调研、编辑、测试、纠偏到人工验收的总成本。

优化每个已验收改动的成本，而不是每次回答的 Token。 删掉必要上下文，可能让当前一轮更便宜，却因为 Claude 猜错、改错文件或连续返工三轮，让整个任务更贵。

本文使用 Claude Code 当前提供的 /usage、/context、/clear、/compact、/model、/effort 和 /mcp。这些方法最直接适用于 API 按量计费会话；订阅套餐虽然按额度窗口管理，但减少无效上下文同样可以让额度更耐用。

为什么回答不长，Claude Code 仍会消耗很多 Token

Claude Code 是编程 Agent，不是一次提问、一次回答的普通聊天。一个工作会话可能包含：

  • 当前提示词以及仍然相关的历史对话；
  • Claude 探索仓库时读取的文件；
  • 命令、测试、编译器和其它工具输出；
  • CLAUDE.md、匹配当前路径的项目规则和已调用 Skill；
  • MCP server 的工具定义与返回结果；
  • 规划、extended thinking、生成的代码和解释；
  • subagent 摘要以及后续每一轮纠偏。

上下文会不断累积。一段已经无关的日志，或上一个功能的设计讨论，只要还留在会话里，后面的请求就可能继续处理它。Prompt caching 可以降低重复内容的价格，Claude Code 也会在接近上下文上限时自动 compact，但这都不代表无关材料可以无限保留。

比较有效的优化顺序是：

  1. 先测一个有代表性的真实任务；
  2. 移除与当前任务无关的上下文；
  3. 缩小常驻规则和工具开销；
  4. 避免无边界探索和大段噪声输出；
  5. 按任务选择模型与 effort；
  6. 再测一次完整可验收结果的成本。

先建立基线，不要凭感觉判断

优化前先运行 /usage。对 API 用户，它的 Session 区域会按模型显示 Token 使用量，并按照标准目录价格在本地计算成本估算。这个估算可能不包含网关优惠或合同价，所以财务结算仍要以实际供应商账单为准。

再运行 /context，查看当前上下文究竟被什么占用。过长的 CLAUDE.md、已经调用的 Skill 或工具开销，会从猜测变成可以检查的数据。

如果会话通过 OmniaKey 计费，可以把本地诊断与用量 Dashboard对照。Dashboard 会记录请求模型、输入/输出 Token、缓存信息、延迟和逐次实际费用。余额与用量文档说明了账户余额、API Key 上限和调用明细。

选择一个可以重复的任务，前后都记录：

指标为什么要看
输入、cache read、cache write、输出 Token判断使用量主要堆在哪里
模型轮次和工具调用次数发现循环与重复探索
重试和人工纠偏次数找出看似便宜、实际制造返工的请求
测试和验收条件是否通过防止为了省 Token 牺牲正确性
最终实际扣费衡量真正支付的结果成本

不要拿两个完全不同的会话比较。修一个拼写错误和处理陌生数据库迁移，本来就不应该有相同的 Token 基线。

1. 无关任务之间使用 /clear

回报最高的习惯也最简单：下一个任务不需要当前对话时，用 /clear 开一个干净会话。

如果以后可能需要回来，先命名当前会话：

text
/rename auth-refresh-investigation
/clear

旧会话仍可通过 /resume 找回。当前 Claude Code 在 /clear 后也会重置 /usage 里的 Session 累计值，方便把下一个任务单独测量。

适合清理的情况包括：

  • 从后端故障切换到完全无关的营销文案；
  • 一个功能已完成，接下来进入另一个仓库区域；
  • 已确认当前方案的前提错误，准备换一条路线；
  • 会话里保留了多份已经不影响判断的大日志。

不要只因为上下文进度条上涨就清空。如果任务仍在继续，应先保留已经验证的事实和决策，或者用明确指令主动 compact。

2. 长任务中主动控制 /compact

/compact 会把较早的历史压成摘要，让后续请求使用更小的表示。执行时告诉 Claude 哪些内容必须保留：

text
/compact 保留验收条件、已修改文件、失败测试输出和尚未解决的决策。

对长实现任务来说，这比没有要求的通用摘要更稳。如果同一套保留规则适用于整个项目，也可以在 CLAUDE.md 里加入简短的 compact 说明。

Compact 不等于重置订阅额度，上下文警告也不等于计费额度警告。Compact 只管理会话继续携带什么内容，不会增加套餐额度，也不会给 API 余额充值。

任务仍然一致、只是抵达当前状态的过程太嘈杂时，用 /compact；工作主题本身已经改变时，用 /clear。

3. 缩小每次会话启动就加载的内容

Claude Code 会在会话开始时读取项目规则。有效规则可以防止错误；但把一本手册塞进每个会话，无论当前任务是否需要，都会占用上下文。

Anthropic 当前建议保持 CLAUDE.md 简洁，并把专用流程移到按需加载的 Skill。一个好的根目录规则文件应主要包含：

  • 能验证改动的命令；
  • 仓库特有的架构边界；
  • 不容易从代码推断的环境约束；
  • 与常规语言默认不同的项目规范。

长篇 API 教程、一次性迁移 runbook 和领域资料不应常驻。可以链接到独立文档，或整理成只在需要时加载的 Skill。

MCP server 也有类似取舍。运行 /mcp，关闭当前不用的 server。Claude Code 默认会延迟加载完整工具定义，但工具名称和真正调用后的 schema 仍会占上下文。简单操作如果已有 gh、aws、sentry-cli 等专用 CLI，通常比加载一整套工具面更节省上下文。

清理后再运行 /context。如果启动占用没有变化，应继续找真正的大项，而不是盲目修改更多配置。

4. 把任务限定到不需要全仓探索

“优化这个仓库”必然诱发大范围扫描。一个有边界的提示可以直接奔向证据：

text
修复 src/api/auth.ts 中 token 刷新后的 401。
保持公开响应结构不变。
为 access token 过期但 refresh token 有效的情况增加回归测试。
运行 auth 定向测试和 typecheck。

这里给出了症状、可能文件、不能破坏的 contract 和验收方式。Claude 仍可在需要时追踪依赖，但没有理由先读完整个仓库。

复杂任务应先研究和规划。一个短的 plan 阶段可以避免在错误架构上完成一整套昂贵实现。位置和改法都明确的一行修复，则不必为计划额外付出开销。是否规划取决于不确定性，而不是任务名字听起来大不大。

发现方向不对时尽早停止。不要等 Claude 生成大补丁，再花几轮解释为什么全部推翻。/rewind 可以把对话和代码恢复到较早 checkpoint。

还可以给输出设定明确 contract：

  • 先写结论；
  • 只列修改文件和验证结果；
  • 不复述原问题；
  • 信息不足时先提问，不直接实现；
  • 只有在不会截断证据时才限制产物长度。

少写解释确实能省一些输出 Token，但避免探索错误和返工通常省得更多。

5. 精简工具与测试输出

大段命令输出会进入工作上下文。优先运行能够证明改动的最窄命令：

bash
pnpm vitest run tests/unit/auth.test.ts
rg -n "FAIL|ERROR" test-output.log
git diff --check

不要为了省 Token 隐藏失败。失败断言、相关 stack frame、退出状态以及足够定位根因的上下文必须保留；重复进度条、所有成功测试名称和数千行无关日志则可以去掉。

稳定的预处理应写成脚本或 hook。Anthropic 成本指南举了一个例子：在 Claude 读取超大测试日志前先筛出错误。经过 review 的小过滤器，比每次都让模型重新从噪声里找规律更可靠。

需要读取大量文件的调研，可以交给范围明确的 subagent，让主会话只接收短摘要。这是在隔离上下文，不保证总 Token 一定更少，因为 subagent 自己也有独立上下文。只有当摘要能避免主任务反复读取时，委派才真正划算。

6. 按决策难度匹配模型与 effort

模型会同时影响单价和完成任务所需的尝试次数。Claude Sonnet 5适合作为日常起点，Claude Haiku 4.5适合范围窄、可重复的工作，Claude Opus 5更适合架构、歧义或错误代价较高的任务。

使用 /model 主动切换。更完整的任务路由方法见 Claude Code 模型选择指南。

在 API 路径中，extended thinking Token 按输出 Token 计费。任务简单且规格明确时，可以用 /effort 降低 effort，再检查结果是否仍通过验收。陌生调试或困难规划如果 effort 太低，增加的重试会抵消节省。

不要把所有任务都扔给最便宜的模型，然后称之为优化。要比较包含纠偏和 review debt 在内的每个已验收结果成本。

7. 优化使用量之后，再增加财务护栏

消费上限不会减少 Token 使用量。它限制的是循环、Key 泄漏或异常 workload 持续发请求时的财务损失。

使用 OmniaKey 时，在 API Key Dashboard为本地开发、自动化和共享任务创建独立 Key，并设置与用途匹配的上限。先检查用量，再决定是否提高。独立 Key 比所有环境共用一个无限 Key 更容易归因和撤销。

正确顺序是：

  1. 先移除无用上下文和重复请求；
  2. 测出正常任务成本；
  3. 把上限设在合理波动之上；
  4. workload 超过边界时告警或停止。

上限太低，只会把成本问题变成任务中途失败；只有上限、没有用量复盘，也只能知道某次碰到了天花板。

10 分钟 Claude Code Token 审计

选择一个真实会话，按下面顺序检查：

  1. 运行 /usage，记录各模型用量。
  2. 运行 /context，找出最大的可避免占用。
  3. 当前任务与旧对话无关时，使用 /clear。
  4. 缩短 CLAUDE.md，把专用说明移到按需 Skill。
  5. 用 /mcp 关闭没在用的 server。
  6. 把宽泛需求改成文件、症状、边界和验收条件。
  7. 运行定向测试，过滤重复输出但保留失败证据。
  8. 按任务难度选择 /model 与 /effort。
  9. 重复同类任务，比较完整可验收结果的成本。
  10. 知道正常范围后，再设置单 Key 上限。

一次只改一两个变量。如果同时清会话、换模型、降 effort、重写任务，就无法判断究竟是哪项有效。

常见误区

只要求回答短一点

这能减少可见输出，却不会消除文件读取、历史对话、工具和 thinking。它有用，但通常不是最大杠杆。

删除任务仍需要的上下文

缺失约束会让模型猜测并返工。清理或 compact 前，应保留已经验证的决策。

把 cache hit 当成零使用量

Prompt caching 可以降低重复输入的价格，但缓存 Token 仍会出现在用量记录中。重复上下文仍应有用，并以实际账单核对。

每个小问题都调用 subagent

每个 subagent 都有自己的启动和工作上下文。把范围明确、输出量大的调研交出去；很小的本地问题留在当前会话解决。

把消费上限当成 Token 优化

Key 上限只会在边界停止支出，不会让边界以内的请求更高效。

常见问题

为什么 Claude Code 回答很短，Token 使用量仍然很高？

请求可能携带历史对话、项目规则、文件、命令输出、工具和 thinking，它们远大于最终文本。应查看 /context 和 /usage，不要只看回答长度。

/clear 会删除以前的 Claude Code 会话吗？

它会开始一个新会话。重要工作先用 /rename 命名，之后可以通过 /resume 回到保留的会话。

/compact 一定会降低账单吗？

它会减少未来请求携带的历史，因此可能降低后续输入用量。净效果取决于会话还会继续多久、摘要保留了什么，应使用 /usage 和实际账单验证。

为了省 Token，是否应该永远使用 Haiku？

不应该。Haiku 适合范围窄的工作，但多次失败可能比一次成功的 Sonnet 或 Opus 更贵。应按任务路由，并比较已验收结果。

API Key 消费上限能降低 Token 使用量吗？

不能。它只在请求已经消耗用量后限制支出。要同时缩小上下文、收窄提示、选择合适 effort，并复查逐次调用。

资料来源

事实核对日期：2026 年 8 月 8 日。Claude Code 命令、模型行为和计费界面可能变化；设置生产预算前，请重新核对上述官方文档和自己的真实用量记录。

控制 Claude Code API 支出阅读余额与用量指南