TL;DR5 小时窗口是滚动回满的，不是整点清零。把大重构、批量迁移这类重活放在窗口刚回满的时候，改文档、写测试这类轻活放在窗口尾部，同样额度能多干不少活。这篇给一份能直接照做的排活节奏。
来源信号 SOURCES
以下内容整理自社区公开讨论，本页只做拆解与核实，不搬运原帖；观点归属原作者。
OpenAI 社区 · Tips and Tricks for Codex & Rate Limits（2026-02 精华帖）查看原帖 ↗Apidog · Codex 配额与限流机制概述（2026-01）查看原帖 ↗
事实性知识 FACTS
这些是讨论中被多方印证、或可对照官方文档核实的事实。
- Codex 的 5 小时窗口是滚动窗口：额度随旧用量逐步移出窗口而回满，不存在「整点清零」的时刻。
- 本地 CLI 消息与云端任务共享这 5 小时窗口的额度，两种用法会互相挤占。
- 5 小时窗口与每周窗口是两层独立的节流，你可能只撞其中一层。
概念性知识 CONCEPTS
社区讨论里的概念不全是事实——每条都标注了它的性质，读之前先看标签。
滚动窗口已验证事实
额度不是定时刷新，而是按你自己的使用时间线滚动计算：五小时前用掉的部分现在开始陆续回来。所以「几点重置」是个错问题，「我几点用过多少」才是答案。
错峰排活个人观点
社区精华帖里反复出现的做法：把 token 消耗大的任务集中放在窗口头部（刚回满时），把几乎不耗额度的人工检查、轻量修改放在尾部。它不增加总额度，但减少了「窗口中途撞墙」的次数。
头部加载待验证假设
有人更进一步主张窗口开头先跑最重的任务，理由是窗口初期的可用余量最大、任务中断风险最小。这个策略在多任务并行的日子里是否始终更优，社区没有一致性结论。
场景 SOP STEP BY STEP
目标场景：工作日要推进一个大重构，同时还有零散小需求，不想在窗口中途被限流打断。目标：按 5 小时窗口把一天的活排出来。
前提付费订阅的 Codex 账号；明确今天要做的一件重活与若干轻活。
- 01开工先查余量
在 CLI 里跑
/usage，确认当前 5 小时窗口与每周窗口的剩余百分比，两个数字都记住。 - 02重活放最前
余量充足时立刻开大任务（重构、批量迁移、长生成）。窗口头部的余量最大，中途撞墙概率最低。
- 03轻活垫窗口尾
重活跑完或接近限流时，切换到改文档、写注释、小修小补这类低消耗任务，等窗口滚动回血。
- 04撞墙先看是哪层
被限流时看提示指向 5 小时窗口还是每周窗口：前者等几十分钟就回血，后者可能要等到次日，应对完全不同。
- 05云任务当重活算
云端任务与本地消息共享额度，提交云任务前把它按「重活」计入窗口预算，不要在窗口尾部才提交。
- 06睡前留回血窗
如果晚上还要再跑一轮，安排一个 40 分钟以上的间隔做别的事，让窗口自然回血，而不是硬等。
结果一天结束时：重活在两次窗口回满之间完成，中途没有被限流硬打断，每周窗口余量仍够后天使用。
看完之后 NEXT
想知道今天的重置判定？回到 首页实时雷达。