Claude Code 的额度是怎么算的：双滚动窗口与加权 token

Claude Code 的额度不是一个数字，而是由两套机制共同决定的：5 小时滚动窗口 + 7 天滚动窗口的双重限额，以及按模型加权计量的 token。

这两件事都容易被误解，误解之后会做出错误的应对——最常见的是撞到限额就去补额度，其实等一会儿就能继续跑。

本文把这两套机制讲清楚，并说明「档位名上的倍数」和「实际 token 量」为什么是两个口径。命令都可复制运行。

一、额度不是一个数字，是两个滚动窗口

限流机制是 5 小时滚动窗口 + 7 天滚动窗口双重限额，两个窗口同时生效，任意一个打满都会被限。

最容易误解的是「滚动」两个字：

滚动窗口的含义是：14:00 花掉的额度，会在 19:00 前后自然退出 5 小时窗口的统计，而不是等某个整点一次性重置。

这决定了正确的应对方式：撞到 5 小时窗口上限时，通常等一两个小时，早先那批消耗滚出去就能继续跑。

而 7 天窗口撞上限是另一回事——那说明这一周的整体强度超出了当前档位的设计容量，等是等不回来的。

所以第一步永远是分清自己撞的是哪个窗口。

二、不是所有 token 等价：加权计量

第二套机制：额度按加权 token 计量，不是按原始 token 数。

不同模型的权重不同（由高到低）：

同样一段对话，用 Sonnet 比用 Opus 明显更省额度。

这条的实际影响比大多数人以为的大。如果从早到晚全程用高权重模型处理「改个变量名」「补个注释」「格式化一下」这类任务，额度消耗速度会远高于预期，而这些任务用基准权重的模型完全够用。

会话里随时可以切：

/model          # 查看并切换当前模型
/cost           # 查看当前会话消耗
/context        # 查看上下文占用情况

一个实用习惯：开新任务前先判断这个任务需要多强的模型。

三、档位名与额度口径：两套计量方式

这一节解释一个容易造成换算错误的地方。

订阅档位名里的「5x」「20x」这类倍数，描述的是消息条数口径；而实际扣减额度用的是加权 token 口径。两者不是同一套计量方式，因此倍数关系不能直接套用。

实测对照下来，20x 档的实际 token 额度约为 5x 档的 2.66 倍，与名称字面的 4 倍并不一致。

这个差异会在两个场景里造成误判：

1. 按名字做除法。例如认为「20x ÷ 4 = 每份 5x」，据此规划多人分摊，实际每份拿到的量明显低于预期。
2. 估算升档收益。按字面倍数规划工作量，实际容量会短缺三分之一左右。

结论：看到「数字 + x」这类命名，先确认它描述的是哪套口径。 判断额度够不够，应该看实际加权 token 消耗——控制台里「已用 / 剩余」那组数才是结算口径，拿它跟自己一周的真实用量对照，比对着名称做算术可靠得多。

四、知道机制之后，三个可执行的动作

1. 撞限时先分清是哪个窗口。 5 小时窗口等一两个小时；7 天窗口反复打满说明整体强度与档位容量不匹配。

2. 按任务难度选模型。 常规任务用基准权重模型，复杂任务再切高权重模型，/model 随时切换。

3. 用 token 口径判断容量，不用名称倍数。 两者不是一套计量方式。

另外还有一条影响更大、但跟配额机制无关的因素值得单独提一句——prompt caching 是 0.1 倍计价。

重复读同一批文件时，命中缓存的部分只按十分之一计价。它的特点是「用错了不会报错」——缓存命中要求前缀完全一致，会话里任何一次上下文变动都可能让后续请求全部落空。判断方法是看命中率：正常实现应稳定在较高水平；长期偏低说明每轮都在重新传输整个上下文，慢、贵，而且更容易触发限流。

五、控制上下文，比补额度更有效

上下文长度直接决定单次请求的消耗。长会话里上下文会持续膨胀，很多额度其实花在反复重传历史上。

/compact        # 压缩历史，保留结论丢掉过程
/clear          # 任务切换时直接清空，比 compact 更彻底

换任务时清一次，是性价比很高的习惯。一个会话从早开到晚、中间换了五六个不相关的任务，上下文里会堆满无关内容。

另外两条：

• 别让它读不该读的目录。 项目根目录如果有 node_modules、dist、大量日志或数据文件，探索时可能被卷进上下文。用 .gitignore 和 CLAUDE.md 明确排除。
• 用 /init 生成 CLAUDE.md。 让它一次性记住项目结构，比每次重新探索省得多。

六、一个前提：用量必须可查

上面这些方法都有同一个前提——你能看到自己的用量。

看不到的话，你没法知道自己撞的是哪个窗口、哪个模型烧得最多、上周消耗趋势如何，本文前五节的判断一条都执行不了。

所以选接入方式时，「用量是否逐条可查」是个应该提前确认的技术指标：至少要能看到 5 小时 / 7 天两个窗口的已用与剩余、以及逐条请求日志。

FAQ

Q：5 小时窗口和 7 天窗口，哪个更容易先撞到？

短时间高强度开发（连续重构、大规模代码生成）通常先撞 5 小时窗口；长期稳定高强度使用则是 7 天窗口先到。前者等待即可恢复，后者需要调整使用强度或容量。

Q：额度用完了会怎样？

会有明确提示，不是静默失败。这一点值得确认——如果额度用尽时表现为超时或报错但不说原因，排查成本会很高。常见错误码的含义可以参考错误码指南。

Q：切到基准权重模型会不会明显变差？

日常开发任务基本感觉不出来。真正拉开差距的是复杂推理、跨文件大规模重构、疑难 bug 定位——这些场景再切回高权重模型。把强模型留给真正需要的地方，是最划算的用法。

Q：/compact 和 /clear 有什么区别？

/compact 压缩历史但保留结论，适合同一任务的长会话；/clear 完全清空，适合切换到不相关的新任务。换任务用 /clear 更彻底。

Q：共享账号会不会互相影响额度？

会共用同一个额度池，所以共享形态更适合轻中度使用。重度使用建议选独享形态，额度完全归自己。

以上机制说明基于 Anthropic 公开的限流设计与实际使用观察，具体数值可能随官方策略调整，实际额度以你所用服务的控制台实时数据为准。

本文由 Code2AI（code2ai.codes）团队整理，基于实际使用记录。