2026 年初，Claude Pro 的用户开始感受到限额收紧。Anthropic 悄悄调整了用量天花板。其他厂商也在做类似的事，因为 GPU 算力是物理资源，复制一份成本就归零这种事只发生在软件身上。

"随便用，反正便宜"的时代过去了。理解 token 怎么消耗、怎么优化，从可选项变成了必修课。

Claude 的对话机制和人类记忆完全不同。人类聊到第 30 句时会记得前面 29 句的大意。Claude 每次收到新消息都要从第 1 句重新读到第 29 句，才开始处理你的新问题。

对话越长，每一轮越贵。消息 30 为消息 1 到 29 全部买单，消息 60 为消息 1 到 59 全部买单。每轮的 token 消耗 = 当轮新内容 + 之前所有轮的累积，所以成本是递增的。

长对话里早期已经不相关的内容，属于"持续收费的死重"。 Claude Code 的 /compact 命令就是干这个的：把对话历史压缩成摘要，删掉旧的细节，后续回合不再为过时信息付费。

打开 Claude Code 的 /usage 面板，你能看到自己发了多少消息。但消息数只是冰山一角。

Anthropic 的数据：用户输入的 token 只占所有 input token 的 46.1%。剩下的 53.9% 来自三样东西：

1. 系统提示词 ：Claude Code 的内置行为指令、工具定义、安全规则
2. CLAUDE.md 内容 ：项目级和用户级的行为指令，全部塞进上下文
3. 工具输出 ：文件内容、grep 结果、git diff、shell 命令的输出

原文举了个例子：上传一份 51 页的 PDF，消耗了 119,000 个 token。这些 token 在上下文窗口里，每一轮都被重新读取。

对 Claude Code 用户来说，工具输出是大头。每次 Read 一个文件，每次 Grep 搜索代码，每次 Bash 跑命令，输出都追加到对话历史里，后续每一轮都要重新"付钱"读一遍。

几个值得养成的习惯：

• 能用 Grep 搜到具体行时，不要用 Read 读整个文件
• CLAUDE.md 保持精简，把不常用的规则挪到按需加载的 skill 文件里
• 大文件上传前先想清楚：你真的需要它在整个对话期间都占着窗口吗？

这个原理我之前写过一篇 详细的 Prompt Caching 解读，这里只说结论：上下文前缀（系统提示词 + CLAUDE.md + 工具定义）在对话期间不变的话，推理服务器会把它缓存起来，后续回合读取缓存的价格是正常计算的十分之一。

Claude Code 的缓存命中率能达到 92%，靠的是一条纪律： 会话期间不修改前缀 。需要补充指令时，不编辑系统提示词，作为新消息追加就行，前缀保持稳定。

反过来，频繁修改 CLAUDE.md 或在会话中途切换模型，缓存会失效，每一轮都按全价重新计算。

Wolpers 判断：模型不会像过去两年那样大幅降价了。原因有两条。

一是 output token 定价是 input token 的 5 倍 。生成一个 token 比读取一个 token 贵得多，这是 Transformer 架构的物理特性（解码阶段逐 token 串行计算），跟厂商的定价策略无关。

二是 上下文窗口是硬约束 。Claude 的 200K token 窗口听起来很大，但系统提示词、CLAUDE.md、对话历史、工具输出全塞进去，空间消耗得比你想象的快。Wolpers 提到了一个"死亡之谷"概念：Project 的上下文接近 200K 阈值时，Claude Code 需要为 Project-level RAG（检索增强生成）分配索引空间，留给实际工作的窗口就被压缩了。

两条加在一起：token 是需要精打细算的稀缺资源，别指望它像流量一样越来越便宜。

四条原理说完了，下面是具体能做的事。