13.1 先厘清四本账

大多数「Claude 到底怎么算 token」的困惑，源于把四件不同的事当成了一件。

读完你能做什么：区分上下文窗口、计费 token、订阅配额、注意力预算这四本账，知道每一本的单位、上限、是否累加，以及各自对应的优化手段。

一、四本账的对照表

	窗口占用	计费 token	订阅配额	注意力预算
它衡量什么	单次请求的输入长度	累计处理的 token 流量	5 小时 / 每周窗口内的用量	模型实际能可靠使用的信息量
单位	token（瞬时）	token（累加）	计划内部单位	无客观单位
上限	1M 或 200k，取决于模型	无上限，只有钱包	按席位等级	远小于窗口上限
是否跨轮累加	否，每轮重新计一次	是，每轮都加一笔	是	否，但会随长度劣化
超限后果	400 `prompt is too long` 或自动压缩	账单变大	触发限流，等窗口重置	静默降质，不报错
怎么看	`/context`	`/usage`、Console Usage 页	`/usage` 的用量条	看不到，只能从输出质量反推
主要优化手段	压缩、外置、延迟加载	缓存命中、缩短历史、换模型	同左	缩短并提纯上下文

这张表里最容易被忽略的是第四行：窗口占用不累加，计费 token 累加。

同一段 50k 的历史，在窗口里始终只占 50k；但你每发一条新消息，它就被重新计费一次。聊 30 轮，这 50k 被计费了 30 次。

二、窗口占用：一个瞬时量

每次请求发给模型的东西是完整的：

text

[系统提示词][工具定义][CLAUDE.md][历史第1轮]...[历史第N轮][你的新消息]
└──────────────────── 全部计入本次窗口占用 ────────────────────┘

模型本身是无状态的。它不「记得」上一轮，是客户端每次把全部内容重新发过去。

关于窗口容量，2026 年 7 月的官方状态：

模型	上下文窗口	单次最大输出
Claude Fable 5	1M	128k
Claude Opus 5	1M	128k
Claude Sonnet 5	1M	128k
Claude Haiku 4.5	200k	按模型规格

对拥有 1M 窗口的模型，1M 是默认值，不需要 beta 头，长上下文请求按标准价计费，没有长上下文加价档。

价格与窗口都是版本敏感信息。以 platform.claude.com/docs/en/about-claude/pricing 与模型对比表为准。

窗口里装了什么，/context 会按类别列出来。它是本手册所有上下文讨论的起点。

三、计费 token：一个流量

这是本章最需要建立的直觉：

每一次 API 请求，输入部分都要整体重新计费一次。

所以「上下文已用 500k，我再问一个 1k token 的问题，算 501k 还是 1k？」的答案是：算约 501k 输入 token，外加输出 token。

不过这 501k 里，绝大部分会以缓存读取价结算（约为基础输入价的 10%），所以实付远低于 501k × 基础价。完整算法见 13.2 一次请求的计费数学。

计费 token 分三笔，官方在响应的 usage 字段里分开报：

json

{
  "usage": {
    "cache_read_input_tokens": 500000,
    "cache_creation_input_tokens": 2000,
    "input_tokens": 50,
    "output_tokens": 1200
  }
}

input_tokens 只代表最后一个缓存断点之后的 token，不是全部输入。真实总输入是：

text

总输入 = cache_read_input_tokens + cache_creation_input_tokens + input_tokens

许多人第一次看 usage 时以为自己只花了 50 个输入 token，这是最常见的误读。

四、订阅配额：另一套计量

用 Pro / Max / Team / Enterprise 计划时，你不按美元结算，但同样的 token 量会消耗席位额度，额度按滚动的 5 小时窗口和每周窗口重置。

[Usage] (用量) 面板（在 Claude Code 里是 /usage）会显示：

计划用量条：距离限流还有多远
用量归因：按 skill、subagent、plugin、单个 MCP server 拆分的占比
行为提示：当 long context 或 cache misses 单项占近期用量 10% 以上时会被标出

按 d / w 在近 24 小时与近 7 天之间切换。

/usage 里的美元数字是 Claude Code 在本地按标价估算的，不含促销价与合同折扣，也不是账单依据。以 Console 的 [Usage] (用量) 页为准。

一条对普通用户最有用的官方结论：一个开了一整天的会话，即使你只问了一句话，也会按整段对话的长度计入用量。

五、注意力预算：唯一没有仪表盘的那本账

前三本账都能量化，这一本不能。

官方文档把长上下文导致的召回率下降称为 context rot（上下文腐化）：随着上下文 token 数增加，模型准确召回其中信息的能力下降。这不是硬悬崖，是一条性能梯度 —— 模型在长上下文下依然可用，但信息检索精度和长程推理会变差。

机制层面的原因：Transformer 让每个 token 都能注意到其他所有 token，n 个 token 产生 n² 个两两关系。上下文越长，注意力被摊得越薄。同时训练数据里短序列远多于长序列，模型对超长依赖的专用参数更少。

推论有三条：

窗口余量 ≠ 质量余量。 窗口还剩 60%，不代表模型的可靠度还剩 60%。
加一段"可能有用"的上下文不是免费的。 它既花钱，又稀释注意力。
好的上下文工程目标是：找到能达成目标的最小高信号 token 集合。

第三条是整章的总纲。

六、四本账的联动与冲突

多数时候四本账同向：上下文变短，则窗口占用降、计费降、配额省、质量升。这是上下文工程如此高杠杆的原因。

但有三处它们会打架：

冲突点	省了哪本账	亏了哪本账
`/compact` 压缩	窗口、后续计费	压缩本身要花一次钱；摘要必然丢信息
工具延迟加载（tool search）	窗口、常驻计费	多一次往返，延迟变高
换更便宜的模型	计费	复杂任务上的质量

遇到这三处时，需要显式权衡，不能无脑「省」。决策矩阵见 13.7 省 Token 与提质量的统一决策框架。

七、两个立刻能用的反直觉结论

结论 1：/clear 不花钱，/compact 花钱。

/clear 只是丢弃客户端持有的历史，不产生任何 API 请求。/compact 需要把待压缩的对话发给模型让它写摘要，本身就是一次完整请求。所以在不需要连续性时，/clear 严格优于 /compact。

结论 2：让模型少输出，收益是复利的。

一段输出 token 被计费两次以上：生成时按输出价计一次，之后每一轮作为历史输入再计一次。一段 2000 token 的冗长回答，在后续 20 轮里会被重新计费 20 次。

13.1 先厘清四本账 ​

一、四本账的对照表 ​

二、窗口占用：一个瞬时量 ​

三、计费 token：一个流量 ​

四、订阅配额：另一套计量 ​

五、注意力预算：唯一没有仪表盘的那本账 ​

六、四本账的联动与冲突 ​

七、两个立刻能用的反直觉结论 ​

延伸阅读 ​