「上午才用了半小时，怎么下午就报额度用完了？」AI 编程工具 Codex 的额度体系里，最让人措手不及的就是窗口算法：额度不在整点清零重来，窗口从你当天第一次使用的那一刻起滚动 5 小时——起点因人而异，额度耗尽的时刻自然也对不上钟点。窗口之外还有一层周限，本地命令行、IDE 与云端任务又共享同一个额度池，几层机制叠在一起，消耗经常比直觉跑得快。这篇拆清滚动窗口怎么算、周限怎么管、额度池怎么共享，以及哪些用法最费额度。
滚动窗口：起点是当天首次使用
滚动窗口的关键在「滚动」二字。窗口的切分不按自然日或整点，起点是当天首次调用 Codex 的时刻，5 小时后到期；到期额度恢复，下一次使用又开启新窗口。这个设计跟着实际使用走，对轻量用户友好；副作用是窗口起点因人而异——你早上九点开工，窗口到下午两点；同事十点开工，窗口到下午三点，两个人「额度什么时候回来」的答案完全不同。别拿别人的恢复时间推自己的，想知道自己的窗口状态，在 CLI 里用 /usage 查看面板，剩余额度与刷新时间以面板实时显示为准。
周限：更长周期的第二道闸
5 小时窗口之上还有一道周限：以周为周期统计的总量上限。两层是嵌套关系——窗口管短期的节奏，防止额度被一口气打光；周限管长期的总量，防止每个窗口都省着用、一周下来仍然超额的累积。周限有自己的计数周期与重置逻辑，具体数值以官方用量面板显示为准。任何一层触顶，都会收到 You've hit your usage limit 一类的提示，先判断是真超额还是误报，排查路径见额度提示一篇。
共享额度池：三个入口一个账本
额度池是共享的：CLI 在本地跑的任务、IDE 插件里的调用、云端执行的任务，消耗同一个池子的额度。多端并用时消耗叠加——白天在 IDE 里改代码，晚上在终端跑批量任务，扣的都是同一个池。查额度时也因此不能只看单个入口的局部用量，要以统一的用量面板为准。池子的大小由订阅档位决定，档位结构见计费轨道一篇；这类「用量计量与重置」的通用机制，在对话类产品的限流体系里也有对应设计，见限流重置一篇。
| 层级 | 怎么起算 | 主要防什么 | 顶到之后 |
|---|---|---|---|
| 5 小时滚动窗口 | 从当天首次调用 Codex 的时刻起算，5 小时后到期 | 短期节奏，额度被一口气打光 | 窗口到期额度恢复，下一次使用又开新窗口 |
| 周限 | 以周为周期统计总量，有自己的计数周期与重置逻辑 | 长期总量，每个窗口省着用、一周下来仍然超额 | 收到 You've hit your usage limit 一类提示 |
| 共享额度池 | CLI、IDE 插件、云端任务消耗同一个池子 | 多端并用时消耗叠加、单看一处看不出全局 | 只能以统一的用量面板为准 |
哪些用法最费额度
agentic 的用法天然比一问一答的聊天费额度：一次编码任务里，模型要多轮思考、读写文件、执行命令，每一轮都带着完整上下文，折成额度的开销远超一次普通对话。最大的两个杠杆是换小模型与压缩上下文，量化对比见省额度杠杆一篇。另一个容易踩的点是并行：同时并行跑多个任务，额度成倍消耗，社区实测并行三个任务时消耗接近三倍——并行省的是等待时间，费的是额度池，赶工期时值得权衡。想让额度用得更明白，可以让 DeepSeek 把窗口、周限、共享池三层机制整理成一张示意图，再用豆包按你的日常任务强度列出最费额度的三个习惯，对照着改。
额度窗口速查
- 滚动窗口：从当天首次使用起算 5 小时，起点因人而异
- 周限：以周为周期的总量上限，与窗口嵌套
- 三个入口共享额度池：CLI、IDE、云端任务同一账本
- agentic 多轮任务比聊天费额度，小模型与压缩上下文是杠杆
- 并行任务成倍消耗，三个并行约三倍
- 剩余额度与刷新时间以 /usage 面板为准
额度窗口快问快答
- 窗口到点额度立刻全额恢复吗？：窗口到期额度恢复，但周限是独立的第二道闸，窗口没到、周限先顶到，额度照样受限，两层都要看。
- 为什么和同事同时开工，耗尽时间差很多？：窗口起点由各自首次使用时刻决定，任务强度、模型选择、是否并行都影响消耗速度，个体差异是机制内的正常现象。
- 额度用完会看到什么提示？：通常是 You've hit your usage limit 一类提示；先按排查路径区分真超额与误报，再决定等窗口、升档还是改用法。
