Claude Code的计费单位是输入token、输出token加思考token，一轮对话聊到第50条时前面49条作为上下文每次都重发，到底哪些操作在偷偷烧钱，/usage、/usage-credits、/clear这几个命令该怎么配合才能把账盯住？

一、导语：一条被忽视的账单曲线

很多开发者第一次对 Claude Code 的用量产生“不对劲”的感觉，往往发生在一次长会话之后：明明只是让模型改了几个文件、跑了几次测试，账单却比预期高出一个数量级。直觉上，人们会把成本归因于“模型回答太长”或“思考太多”，但真正的主因通常藏在另一个地方——每一轮请求都会把此前全部对话历史重新发送一遍。

这不是 Claude Code 独有的设计，而是当前主流大模型对话式接口的通用范式：模型本身无状态，服务端不保存你的会话，所谓“记忆”完全依赖客户端在每次请求中把历史消息拼接进 prompt。于是第 50 轮对话的输入 token 里，包含了前 49 轮的几乎全部内容。成本不是线性叠加，而是随轮次累积放大。

本文的分析主线是：把 Claude Code 的每一次请求都视为一次“上下文快照的重新计价”。理解这条主线，就能把“为什么账单涨得这么快”转化为“哪些 token 被重复计费、哪些被缓存折扣、哪些可以提前截断”三个可操作的问题。

需要先说明边界：Anthropic 的定价、缓存策略与 Claude Code 的具体实现会随版本更新而变化，本文引用的价格与机制以官方文档公开口径为准，并在涉及具体数值处标注来源与时间点。读者在实际核算时，应以自己账户的实时计费页与官方文档为准。本文不构成任何商业或采购建议。

二、计费口径：三类 token 的定义与边界

2.1 输入 token：不只是你敲的那句话

输入 token（input tokens）指一次 API 请求中被送入模型的全部 token，包括系统提示、工具定义、历史消息、当前用户消息、以及被读取进上下文的文件内容。一个常见误解是“我这一轮只问了一句话，输入就很小”——实际上，在 Claude Code 这类 agent 场景中，系统提示与工具 schema 本身就占据可观的固定开销，历史消息则是随轮次增长的变量开销。

Anthropic 在官方文档中区分了普通输入 token 与缓存写入（cache write）、缓存读取（cache read）两类特殊计费项。缓存写入的价格通常高于普通输入，缓存读取则显著低于普通输入。这一设计的经济学含义是：服务端鼓励你把稳定前缀缓存起来反复复用，而不是每轮重新付费。

2.2 输出 token：可见回答与不可见推理的分野

输出 token（output tokens）指模型生成的 token，通常单价最高。在支持扩展思考（extended thinking）的模型上，需要区分两类输出：一类是最终呈现给用户的回答文本，另一类是模型在思考阶段产生的推理内容。不同厂商对思考 token 的计费处理并不一致，有的将其计入输出 token 计费，有的单独列出。Anthropic 在其定价文档中将思考内容视为输出的一部分进行计费，这一点在核算时必须纳入。

2.3 计费口径对照表

注：相对单价为示意性比例，用于说明数量级关系，具体数值以 Anthropic 官方定价页为准（docs.anthropic.com/en/docs/about-claude/pricing）。

三、上下文重发：成本放大的数学结构

3.1 一个简化的成本模型

设每轮用户消息平均长度为 u，每轮模型输出平均长度为 a，系统提示与工具定义为固定前缀 s。在不考虑缓存的情况下，第 n 轮请求的输入 token 约为：

I(n) = s + (n-1)·(u + a) + u
     = s + n·u + (n-1)·a

前 N 轮的累计输入 token 为：

ΣI = N·s + u·N(N+1)/2 + a·N(N-1)/2

这个式子给出了本文最关键的一个结论：累计输入成本对轮次 N 是二次的。当 N 从 10 增长到 50，累计输入 token 不是增长 5 倍，而是约 25 倍量级（忽略固定前缀项）。这就是“聊到第 50 条时账单突然刺眼”的数学根源。

3.2 为什么“第 50 条”是心理阈值而非物理阈值

从上面的模型看，成本增长是连续的，并不存在第 50 条突然跳变的物理机制。但工程实践中确实存在若干“阈值效应”：一是上下文窗口接近上限时，客户端可能触发压缩或截断策略，导致行为变化；二是缓存前缀在内容变化后失效，使原本享受折扣的部分回落到全价；三是长会话中工具调用与文件读取累积，使单轮输入的实际增量远超用户消息本身。这些因素叠加，会让开发者在某个轮次附近产生“账单陡增”的体感。

3.3 上下文重发的三种典型放大源

第一类是文件内容进入上下文。Claude Code 读取文件后，文件内容会成为历史的一部分，在后续每一轮被重发。一个 2000 行的源文件，一旦被读入，就相当于给此后每一轮都加上了一笔固定输入成本。第二类是工具调用结果。命令输出、测试日志、搜索结果都会留在历史里。第三类是模型自身的冗长输出。模型每轮回答越长，后续每轮的重发负担越重，形成正反馈。

这三类放大源的共同特征是：它们都是“一次性产生、长期计费”的资产。理解这一点，就能理解为什么“清理上下文”不是可选项，而是成本控制的必要动作。

四、缓存机制：折扣从哪里来，又在哪里失效

4.1 前缀缓存的工程原理

提示缓存（prompt caching）的基本思想是：把请求中稳定不变的前缀部分（如系统提示、工具定义、长文档）在服务端缓存，后续请求若前缀完全一致，则直接复用缓存的计算结果，按较低的缓存读取价计费。Anthropic 的缓存机制要求前缀精确匹配，且缓存有生存时间（TTL），过期后需重新写入。

这一机制对 Claude Code 尤其重要，因为系统提示与工具 schema 在会话中通常保持不变，天然适合缓存。但缓存是“前缀匹配”，意味着一旦前缀中任何位置的内容发生变化，其后的所有缓存都会失效。这是理解“为什么有时候折扣突然没了”的关键。

4.2 缓存失效的常见触发条件

4.3 缓存命中率的可观测性

Anthropic 的 API 响应中会返回缓存创建与缓存读取的 token 计数（如 cache_creation_input_tokens 与 cache_read_input_tokens），这是核算缓存效益的直接依据。在 Claude Code 的交互界面中，/usage 提供了面向使用者的用量视图。把这两个口径对齐，才能判断“折扣到底吃到了没有”。

关于 API 响应字段的准确含义，建议直接查阅官方文档的 prompt caching 章节（docs.anthropic.com/en/docs/build-with-claude/prompt-caching），不要依赖二手转述。

五、隐性烧钱路径逐项排查

5.1 文件读取：一次读入，长期计费

在 agent 工作流中，模型为了理解代码库会主动读取文件。读取动作本身消耗输入 token，而读取结果进入历史后，会在后续每一轮被重发。一个常见的浪费模式是：模型读取了一个大文件，但只用到其中几行，剩余内容长期占据上下文。更糟的是，如果模型反复读取同一文件的不同片段，历史中会累积多份近似内容。

可行的缓解手段包括：在提示中明确要求“只读取相关函数所在区间”；使用搜索工具先定位再读取；在任务切换时用 /clear 释放不再需要的文件上下文。这些手段的本质都是减少“一次性产生、长期计费”的资产规模。

5.2 工具调用与命令输出

运行测试、执行构建、搜索日志，都会产生大量文本输出。这些输出被回填进上下文后，同样长期计费。一个典型的失控场景是：测试失败输出几百行堆栈，模型据此分析，但堆栈本身在后续多轮中持续被重发。工程上的做法是让命令输出先经过过滤（如只保留错误摘要、截断到关键行），再交给模型。

# 示意：把冗长输出截断后再喂给模型，降低长期上下文负担
npm test 2>&1 | tail -n 40
# 或只提取失败用例摘要
npm test 2>&1 | grep -E "FAIL|Error" | head -n 20

注：以上为工程示意，具体过滤策略应结合项目实际输出格式调整。

5.3 系统提示与工具 schema 的固定开销

Claude Code 作为 agent 工具，其系统提示与工具定义规模不小。这部分是每轮请求的固定成本。好消息是它适合缓存；坏消息是如果缓存未命中，固定成本会按全价重复计入。因此“保持会话连续性以维持缓存”与“及时清理以截断历史”之间存在张力，这正是需要三命令协同的原因。

5.4 思考 token 的不可预测性

扩展思考让模型在复杂任务上表现更好，但也让输出成本变得难以预估。同一句提示，模型可能思考几十个 token，也可能思考几千个。对于成本敏感的场景，可以在提示中约束“先给结论再展开”，或对简单任务关闭扩展思考（若客户端提供该选项）。需要强调的是，关闭思考可能降低复杂任务的正确率，这是一个需要按任务类型权衡的取舍，而非无脑省钱。

5.5 重复提问与无效往返

还有一类成本来自交互习惯：同一问题反复追问、模型理解偏差导致的来回澄清、把本可以一次说清的需求拆成多轮。每一轮都在为历史重发付费。改善提示的完整性（一次性给出目标、约束、验收标准）往往比任何工具技巧都更省钱。

六、三命令协同：/usage、/usage-credits、/clear

6.1 三个命令各自的职责边界

在 Claude Code 的交互中，斜杠命令用于控制会话与查看状态。/usage 用于查看当前会话或账户的用量情况；/usage-credits 用于查看额度与计费相关信息；/clear 用于清空当前会话上下文。三者分别对应“观测”“对账”“干预”三个环节。

需要提醒的是，斜杠命令的具体名称、输出字段与可用性会随 Claude Code 版本变化。使用前建议在客户端内输入 /help 确认当前版本支持的命令列表，并以官方文档为准（docs.anthropic.com/en/docs/claude-code）。本文侧重方法论，不绑定某一具体版本的字段名。

6.2 协同工作流：观测—判断—干预

把三个命令串成一条闭环，是本文建议的核心操作路径：

6.3 什么时候该 /clear，什么时候不该

判断标准可以归结为一个问题：接下来的任务是否还需要当前历史中的具体内容？如果任务切换到新模块、新问题域，历史中的文件内容和调试日志已无复用价值，此时 /clear 能立即截断二次增长的输入曲线。反之，如果任务是在同一文件上继续迭代，清空会导致模型重新读取文件、重新建立理解，反而增加总成本。

6.4 一个可复用的成本核算模板

把观测数据记成表，比凭感觉判断更可靠。下面是一个简化的记录模板，字段可根据 /usage 实际输出调整：

轮次 | 输入 | 缓存读取 | 输出 | 思考 | 备注
-----|------|----------|------|------|----------------
 10  | ...  |   ...    | ...  | ...  | 读取 user.py
 20  | ...  |   ...    | ...  | ...  | 运行测试
 30  | ...  |   ...    | ...  | ...  | 缓存失效?
 40  | ...  |   ...    | ...  | ...  | 切换模块前
-----|------|----------|------|------|----------------
增量分析：若单轮输入增量 > 2×均值，检查是否有大文件或长日志进入上下文。

注：模板为示意结构，非真实数据。

七、工程化成本管控：从个人习惯到团队规范

7.1 任务切分：把长会话拆成短会话

既然成本对轮次是二次的，那么把一个大任务拆成若干短会话，就能把二次曲线切成多段更平缓的曲线。关键在于切分点要落在“上下文可丢弃”的边界上：完成一个函数、修完一个 bug、跑通一个测试用例，都是天然的切分点。切分后，新会话需要重新建立对代码库的理解，这部分成本要用“读取必要文件”来补，而不是把整个历史带过去。

7.2 提示工程层面的成本控制

几条可落地的习惯：其一，一次性给出完整需求与验收标准，减少澄清往返；其二，明确要求模型“只读取必要区间”“输出结论优先”；其三，对机械性任务显式要求简洁输出，避免长篇解释进入历史；其四，把稳定的项目约定写进项目级配置文件（如 CLAUDE.md 一类机制，若当前版本支持），让固定信息以可缓存的形式存在，而不是每轮口头重复。

关于 Claude Code 的项目配置与最佳实践，官方文档与社区教程都有较多讨论，可参考 Claude Code 记忆与配置文档 以及 Anthropic 工程博客 中的相关文章。

7.3 团队层面的用量治理

对团队而言，个体习惯的差异会放大为账单差异。可行的治理动作包括：统一项目级配置以减少重复提示；为不同类型的任务约定推理预算；定期导出用量数据做趋势分析；把“每阶段 /usage 快照”写入团队工作流。需要强调的是，治理的目标是让成本可解释，而不是简单地压缩用量——不可解释的成本波动比高成本本身更危险。

八、对比与局限：这套方法不解决什么

8.1 与其他成本控制思路的对比

常见的替代思路有三类：一是换用更小的模型，直接降低单价；二是自建检索增强，把长文档放到外部检索而非上下文；三是对输出做后处理压缩。三者各有边界：换小模型可能牺牲复杂任务质量；检索增强需要额外工程投入且引入检索误差；输出压缩无法解决输入重发问题。本文主张的“上下文生命周期管理”与这三者并不互斥，而是可以叠加。

8.2 方法的局限与不确定性

必须诚实说明局限：其一，计费规则与缓存策略由服务方定义且可能调整，本文的数量级结论稳定，但具体倍数需以实时文档为准；其二，/usage 等命令的输出字段随版本变化，模板需按实际调整；其三，成本与质量的权衡缺乏普适最优解，需要按任务类型实测；其四，本文的模拟算例仅用于说明趋势，不能替代真实账单核算。

九、结论与展望

回到主线：Claude Code 的账单本质上是“上下文快照的重复计价”。输入、输出、思考三类 token 构成计费口径，多轮对话的上下文重发构成二次增长，缓存机制提供折扣但也引入失效风险，而 /usage、/usage-credits、/clear 分别承担观测、对账、干预的职责。把三者串成“观测—判断—对账—干预”的闭环，就能把不可解释的账单波动转化为可管理的工程变量。

展望来看，随着 agent 工具链成熟，上下文管理有望从“手动清空”走向“自动摘要与分层记忆”：把长期稳定的项目知识放入可缓存前缀，把短期任务上下文放入可丢弃区，把工具输出做结构化压缩。这一方向既能降低成本，也能缓解长上下文带来的注意力稀释问题。对从业者而言，尽早建立成本可观测性与上下文生命周期意识，比追逐某一个具体命令的用法更有长期价值。

十、参考文献与拓展资源

10.1 主要参考文献（8 篇）

1. Anthropic. Pricing. Anthropic 官方文档, 2024–2025 持续更新. 链接
2. Anthropic. Prompt caching. Anthropic 官方文档, 2024–2025. 链接
3. Anthropic. Claude Code 文档. 2024–2025. 链接
4. Anthropic. Extended thinking. 官方文档, 2024–2025. 链接
5. Vaswani A., et al. Attention Is All You Need. NeurIPS, 2017.（Transformer 与上下文长度的基础文献）
6. Liu N. F., et al. Lost in the Middle: How Language Models Use Long Contexts. TACL, 2024.（长上下文利用的实证研究）
7. Pope R., et al. Efficiently Scaling Transformer Inference. MLSys, 2023.（推理成本与 KV 缓存相关）
8. Anthropic Engineering. Claude Code 相关工程文章. 2024–2025. 链接

10.2 拓展资源（教程与视频）

• Anthropic 官方 YouTube 频道（Claude Code 演示与更新）：youtube.com/@anthropic-ai
• Anthropic Cookbook（含缓存与工具调用示例）：github.com/anthropics/anthropic-cookbook
• Claude Code 官方仓库与 issue 讨论：github.com/anthropics/claude-code
• 提示缓存实践教程（社区）：官方 prompt caching 指南

10.3 关于数据与预处理说明

本文未使用任何自建数据集或作者团队实验数据。文中出现的 token 数量级为模拟参数（s=8000、u=200、a=600），用于演示二次增长趋势，已在正文标注为模拟数据。计费比例与缓存折扣为示意性数量级，实际数值以 Anthropic 官方定价页为准。若读者需做真实核算，建议以 API 响应中的 usage 字段与账户计费页为准，并注明采集时间。