Codex 额度又重置了？五小时限额、掉额度与卡顿排查
围绕 Codex 额度显示突然变满、新增五小时窗口限制、用一会儿就见底，以及响应卡顿、模型说"继续"后停住等现象，梳理额度计量维度、掉额度快的常见原因和可操作的排查步骤，并给出省额度与放开用两种思路的取舍建议。
额度面板昨天刚见底，今天打开又满了；高兴没两分钟，发现多出一条「5 小时窗口」的限制，用不了多久就被限住，任务还卡得厉害——这是最近不少 Codex 用户遇到的组合问题。它其实包含两条独立线索：一条是额度规则本身在变，另一条是服务响应和网络链路的稳定性。混在一起看，很容易误判成「官方又在乱改」。
下面把这两件事拆开讲：额度面板上的数字到底在计量什么，为什么掉得比你预期快，卡顿和「模型说继续然后不动了」又该怎么定位。
额度面板上的三层限制
Codex 的用量通常不是单一额度，而是几个维度叠加计量，面板上会同时出现多行：
| 计量维度 | 特点 | 典型表现 |
|---|---|---|
| 短周期窗口（如 5 小时） | 窗口内用量封顶，到点刷新 | 用一阵就提示受限，等一段时间恢复 |
| 周级额度 | 按周累计，重置时间通常固定 | 前松后紧，周末容易见底 |
| 模型/通道专属额度 | 特定模型单独计量，与主模型不共享 | 主模型还有余量，换个模型却不能用 |
几个容易踩的认知点：
- 「变满了」不等于真的重置。 运营侧调整套餐限额、灰度新规则、修正计量错误，都可能让数字跳变；同一账号在网页、CLI、IDE 插件里看到的额度也可能不同步。
- 专属额度不共享。 面板里某一行显示 100%，只说明那一项没被消耗，不代表主模型额度充裕。
- 规则变动频繁属于常态。 限额、窗口长度、可用模型都可能在调整中，具体数值与重置时间请以官方最新说明和账号实际面板为准，不要照搬别人截图里的数字。
额度掉得比预期快的常见原因
在限额没变的前提下，消耗速度主要由「上下文规模 × 轮次」决定，而不是你感觉干了多少活。
- 全仓库读取。 让 agent 自己找文件，它会不断列目录、读文件、再读一遍，每一步都进上下文。
- agent 循环。 测试失败→改→再跑，或者工具调用报错后反复重试，轮次迅速累积。
- 推理档位过高。 高强度推理模式适合难题，用来改一行配置就是纯浪费。
- 并行开多个会话或后台任务。 同时跑三四个任务，额度按总量扣，感知上就是「一会儿就没了」。
- 超长会话不换。 一个会话从需求讨论干到重构再到写文档，历史消息不断被重复送入。
对应的收敛办法：只把相关目录加入工作区、用忽略规则排除构建产物和依赖目录、把「先探索再改」改成「指定文件后直接改」、简单任务降档、重任务结束就新开会话。
卡顿与「说继续然后停住」怎么定位
这类现象至少要分三种来源，处理方式完全不同：
- 额度或限流拦截。 通常会伴随错误提示或直接中断，先去面板确认对应窗口是否已耗尽。
- 流式长连接断开。 跨境链路抖动、代理切换、休眠唤醒都会切断长连接，表现就是输出到一半没了，或者模型回了句「好的，我会继续」就再无下文。
- 本地资源与客户端问题。 大仓库索引、CPU 占满、插件版本过旧，同样会造成长时间无响应。
一条务实的排查顺序：
1. 新开一个空会话，只给一个文件、一句话，确认基础请求是否正常
2. 查看额度面板与错误信息，排除限流
3. 换一条网络（手机热点 / 有线）做对比，判断是否链路问题
4. 缩小工作目录，加忽略规则，关闭并行任务后重试
5. 更新客户端 / 插件到最新版本
还有一个细节值得注意：模型停住时，先检查它是否已经改了文件，再决定要不要重发指令。直接复制原 prompt 重试，很可能把已经完成的改动再做一遍，既浪费额度也可能把代码改乱。
省着用还是放开用：两种做法的取舍
围绕额度的使用策略，实际存在两种相反的做法：
- 省着用：把强模型、高推理档位留给关键改动，日常小改动用低档或快模型。代价是复杂任务容易半途而废，反而要开更多轮次去补，最后未必省。
- 放开用：一次把需求写清楚、让模型一口气做完。前提是你的任务边界足够清晰，否则跑偏后重来的成本更高。
更稳的中间路线是把「省」落在减少无效轮次上，而不是降低任务完成度：
- 一次交代清楚目标、涉及文件范围、验收标准（比如「只改 a.ts，跑通单测即止」）。
- 要求先给改动计划再执行，避免大范围试探。
- 跨多个项目的任务单独开一个会话，别和日常小修混在一起。
- 长任务中途插入新需求时，宁可新开会话重述上下文，也不要在一个超长会话里继续叠。
网络环境与长时运行的补充
如果本地链路本身不稳，或者需要 Codex 挂着跑长时间任务，把执行环境放到机房侧的 Mac 上是可选方案之一：整机独享、长期在线、出口网络相对稳定，能减少本地断网、休眠、切换 Wi-Fi 导致的流式中断。它解决的是链路与在线时长问题，不解决额度规则问题——额度该怎么算还是怎么算。是否值得，取决于你的任务量和本地网络质量，建议先用最小任务对比验证再决定。
小结
把这次的现象归成两句话：额度规则在调整，面板数字会跳，专属额度与主额度不共享，看到「满格」先确认是哪一行；卡顿与中途停住，多半是限流、长连接断开或本地资源三类原因之一，按「最小复现→看面板→换网络→缩上下文」的顺序排查，比反复重发指令有效。规则仍在变化，具体限额与重置时间以官方最新说明为准，剩下的就靠把任务拆小、把上下文收窄来自己掌控。
