AI 编程会话一旦跑起来，额度消耗经常比直觉快得多：上午才开两个任务，下午就见底了。Claude Code 的用量体系有几个关键机制——5 小时滚动窗口、终端与聊天共享的额度池、从首次使用起算的窗口起点——不理解这些，就看不懂额度为什么耗尽、什么时候恢复。这篇把机制拆开讲：/usage 面板怎么读，窗口怎么滚，共享池意味着什么，耗尽之后怎么办，以及哪些用法在悄悄加速消耗；省钱的具体做法另有一篇专讲，见省额度的六个习惯一篇。
/usage 面板怎么读
会话里敲 /usage，当前用量一目了然：本窗口已用多少、还剩多少、什么时候重置，都以面板实时显示为准。这个命令要养成随手敲的习惯——尤其在大任务开跑之前看一眼余量，避免跑到一半被掐断；任务跑完再看一眼，建立「这类任务大概耗多少」的手感。额度数字背后的窗口机制，正是接下来要拆的几层。
窗口从哪一刻起算
额度按 5 小时滚动窗口补给，起点是当天首次使用的那一刻，并不按整点清零。你早上九点开工，窗口到下午两点；同事十点开工，窗口到下午三点——每个人的「额度什么时候回来」答案都不同，别拿别人的恢复时间推自己的。窗口到期额度恢复，下一次使用又开启新窗口，滚动向前。这个设计对轻量用户友好，对高强度使用者则意味着：一个窗口里把额度打光，就得等这个窗口走完。Codex 那边有一篇同构的窗口机制拆解，两相对照更透，见额度窗口机制一篇。
| 情形 | 窗口起点 | 窗口结束 | 说明 |
|---|---|---|---|
| 早上九点开工 | 当天 9:00 | 14:00 | 从首次使用起算，不按整点清零 |
| 同事十点开工 | 当天 10:00 | 15:00 | 恢复时间各人不同，别照别人的推 |
| 窗口走完后再用 | 再次使用那一刻 | 顺延 5 小时 | 额度恢复，窗口滚动向前 |
共享池：终端与聊天同一本账
最容易被忽略的一条：Claude Code 的终端用量与聊天端的用量共享同一个订阅额度池，没有各自的小灶。白天在网页聊天里长对话，下午回终端跑编码任务，扣的是同一份额度；反过来，终端里跑的重任务也会吃掉聊天端的余量。多端并用的人查用量时，别只看单一入口的局部数字，以 /usage 的池子口径为准。这带来一个直接结论：任何一端猛跑，处处吃紧，任务重的时候更要省着分配。
额度耗尽后的重置等待
额度用尽，Claude Code 会给出本窗口用量到顶的提示与恢复时间，此时正确动作是等，狂重试没有意义——重试不产生额度，只会白耗。等待期间可以做的事不少：把已完成的任务验收落地、整理下个窗口的任务清单、处理不依赖 Claude Code 的杂活。有紧急任务要继续，也可以临时切 API key 按量跑，两条认证的切换见档位与解法一篇；按量计费有成本，切之前想清楚。
为什么消耗比直觉快
三个因素在加速消耗。一是 agentic 的多轮执行：一次编码任务里模型反复读文件、改代码、跑命令，每一轮都带着完整上下文，折成额度的开销远超一次普通问答。二是上下文累积：长会话里历史消息越滚越大，每一步都在为旧内容付费，上下文窗口的机制见上下文窗口一篇。三是并行任务：同时开多个任务，额度成倍走。理解了加速器，省法就顺理成章——轻模型干轻活、及时压缩上下文、控制并行数量。想建立自己的消耗画像，可以让 DeepSeek 把 /usage 的数据整理成按天对照表，豆包和 Kimi 则适合解释 token 与额度的折算关系，账看得越明白，用得越稳。
用量窗口速查
- /usage 随手看：余量、重置时间以面板为准
- 5 小时滚动窗口从当天首次使用起算，起点因人而异
- 终端与聊天共享一个额度池，一处猛跑处处吃紧
- 耗尽后等窗口刷新，狂重试不产生额度
- 多轮执行、上下文累积、并行任务三大加速器
关于用量窗口的三问三答
- 窗口到点额度立刻全额恢复吗？：以官方面板显示为准，恢复后下一次使用开启新窗口；长期高强度使用的话，窗口之间的余量可能一直偏紧，节奏要自己调。
- 关掉终端会暂停窗口吗？：不会。窗口从首次使用起算，计时与终端开不开无关；想省窗口内的额度，办法是少耗，而非暂停。
- 查用量为什么和聊天端数字对不上？：两端共享一个池子，任何一端的消耗都影响总数；以 /usage 的池子口径为准，别拿单一入口的局部数字对账。
