Claude Code 的用量上限，以及怎样不再撞上它

Claude 的订阅按用量计量，而不是按消息条数。两个人一周内发出同样多的提示，处境可能完全不同，因为其中一个人每问一次就捎上整个仓库，另一个没有。

上限在计什么

粗略地说，计数器跑在按模型加权的已处理 token 上。这意味着三件事，其中第三件常让人意外：

• →长会话每轮的开销高于短会话，因为整段记录每次都会重发。
• →同样的工作，大模型每 token 的开销高于小模型。
• →读文件不是免费的。为了回答一个一行的问题而打开六个文件的代理，等于把这一行问题的代价花了六遍。

所以上限往往出现在高产那天的下午，而不是清闲一周的末尾。这里的高产意味着长会话，而长会话是平方级的：每一轮都在为它之前的每一轮付费。

为什么它总在任务中途落下

因为昂贵的是中间那些轮次。会话的第一轮很便宜，第二十轮却背着十九轮记录，加上一路读过的每个文件，加上每一次测试输出。你不会在规划时被截断，你总在收尾时被截断。

真正有用的四个习惯

按一周下来的价值排序：

• →每项任务开一个新会话。这是最关键的一条，清单上其余各条都不接近。
• →点名文件，而不是描述它。探索是代理做的最贵的事。
• →机械性工作交给小模型：重命名、格式化、单文件修改。
• →把吵闹的命令输出挡在对话之外，先过滤再让它进来。

不改变工作方式也能做到

上面这些习惯确实有效，但要求你在每一轮都保持自律，而这恰恰是人到周三就会放弃的那类事。另一条路是给上下文设一个上限，让它自动生效。

$npm i -g @penra/capsul

$capsul ask '修好失败的鉴权测试' --budget 3000

已经撞上之后

在时间窗内没有办法花钱脱离会话上限，也没有任何选项能把它重置。你能做的是让下一个窗口比上一个撑得更久，而这取决于每一轮携带了什么，不取决于你进行了多少轮。