故障处理
Codex 额度没重置？先核限额窗口、重置方式与账号状态
Codex 到点仍提示额度用完、重置日期变了，或网页与 CLI 用量不同？按当前计划、实际限额窗口、账号与工作区逐项核对，区分自然恢复、一次性重置和显示延迟，提供只读检查、前后对照与求助清单。
等到提示的重置时间，Codex 仍说额度用完；刚使用一次重置，每周恢复日期却变了；网页还有剩余，CLI 看起来已经耗尽。先确认拦住任务的是哪一条限额，再比较同一账号、工作区、窗口与时区下的记录。 只看一个百分比，或套用别人账号的“五小时、每周”规则，很容易找错原因。
本文处理“Codex 额度没重置”、codex usage limit not reset、codex rate limit reset time 和用量显示不一致。先做只读核对，不用购买额度、兑换一次重置或发送付费任务来试探是否恢复。
先按现象找下一步
| 你看到的现象 | 先核对什么 |
|---|---|
| 已过预计时间，任务仍被限额拦住 | 第 2、4 步：是否看错窗口、日期或时区，是否还有另一条限制 |
| 每周重置日期比原来晚了 | 第 3 步：期间是否使用过会改变周窗口的一次性重置 |
| 网页、CLI、客户端显示不同 | 第 1、5 步：账号、工作区、数字含义与观测时间是否相同 |
| 别人有重置入口，自己的没有 | 第 3 步：本账号是否符合该次活动条件，权益是否仍有效 |
| API 余额充足，Codex 仍提示用完 | 第 1 步：当前使用的是 ChatGPT 计划还是 API 计费通道 |
| 只看到 HTTP 429，没有明确重置时间 | 第 6 步：先确认错误来自哪项服务，不能直接断言订阅额度耗尽 |
1. 把账号、工作区和计费通道对齐
适用条件： 多个客户端的结果不同，刚换过账号或工作区，或认为“有余额就一定能用”。
打开 Codex 用量设置，记录当前计划、选中的个人或组织工作区，以及提示的限制名称。在发生问题的客户端查看当前登录身份和执行环境；只需自行确认是否一致，向别人求助时不用公开邮箱、组织名称或账号标识。
如果使用 CLI，在已经登录、发生问题的同一环境里输入 /status，查看当前会话状态和可用的剩余限额信息。远程主机、WSL、容器内的 CLI 要分别检查，不能用本机另一份登录结果替代。官方用量入口说明将用量页面和 CLI /status 作为核对入口；某个界面未提供的字段应记为“未显示”，不要自行补齐。
再确认这次任务走的是 ChatGPT 登录还是 API Key。两者的额度与计费需分别核对；API 余额不是 ChatGPT 计划的剩余 Codex 用量。需要解释这一区别时，可对照 ChatGPT 订阅与 API 计费和 Plus 是否包含 API。不要为了排障直接切换到 API Key，以免把问题变成另一笔费用。
预期结果： 网页与故障客户端对应同一账号、工作区及计费通道。若不一致，先切到原本打算使用的身份，再重新读取用量；如果实际是 401 或登录失效，转到登录认证排查，无需清空凭据来“刷新额度”。
2. 按当前计划找实际窗口，不套用固定重置表
适用条件： 不清楚到底等哪一次恢复，或网上攻略与自己的用量页面不同。
先对照官方当前计划限额，再读账号自己的用量页面。截至本文核验日，官方对 Plus 与标准 Business 的本地消息估算采用五小时窗口；Pro 当前没有五小时限额，另有可能适用的每周限制。 不要由此推导 Pro 没有任何限制，也不要把这一套窗口外推到 Free、Go 或所有组织方案。Enterprise／Edu 的灵活计费、工作区额度及管理员控制需按实际方案核对。
在页面里逐条记录实际存在的限制。每条至少回答四个问题：
- 限制叫什么？ 是某个使用窗口、特定功能额度、credits 余额，还是组织设置的限制？保留原始标签。
- 数字是什么意思？ 是已用、剩余、token 活动量，还是余额？有没有百分号、单位或“remaining”字样？
- 哪条已经耗尽？ 一个窗口恢复，不证明其他限制也同时解除；本地与云端使用也不能默认互相独立。
- 何时恢复？ 抄下完整日期、时间与已知时区；只有倒计时就记录观测时间。页面没给出的时区或窗口起点，应保留为未知。
官方说明消耗还受模型、任务复杂度、上下文及工具等影响，因此不适合用“我只问了几次”推算必定还剩多少。也不要把“五小时窗口”改写成“每天零点恢复”，或把每周窗口当成所有用户统一的星期几。
预期结果： 能指出阻塞本次任务的具体限制及其恢复提示。若只有“额度已用完”而没有窗口信息，把这条提示和用量页放在一起记录，继续第 6 步；不要凭旧截图猜重置日期。
3. 分清自然恢复、一次性重置与余额变化
适用条件： 重置时间被顺延、重置入口消失，或刚参加过一次额度活动。
先回看自己已经发生的操作与原活动说明，不要点击兑换来做诊断。四种变化需要分别判断：
| 变化来源 | 如何判断 |
|---|---|
| 原有限额窗口自然恢复 | 以该账号、该条限额显示的恢复时间为准，不依赖促销按钮 |
| 活动自动发放的直接重置 | 核对活动范围及生效说明；不一定会留下一张可稍后使用的重置权益 |
| 已保存、由用户主动兑换的一次性重置 | 查是否确实兑换成功，以及该次权益覆盖哪些窗口、何时过期 |
| credits 或 API 余额变化 | 分别核对对应余额和计费通道，不据此推断订阅窗口已重新开始 |
官方 banked resets 说明指出，可保存的一次性重置有使用和到期条件；Full reset 会刷新其适用的五小时与每周窗口，并改变每周重置时间。例如，原本周五恢复，在周二兑换并重新使用后，下一次可能改为下周二。实际资格、适用窗口及有效期依活动和账号而异；不能据此给当前没有五小时限额的计划凭空添加一个窗口。
如果从未得到适用权益，或权益已过期，反复重启客户端不会产生兑换入口。若已经操作过但不确定结果，先保存前后用量与时间记录，再按第 5 步排除显示差异；不要消耗第二次重置来确认第一次是否成功。
预期结果： 能解释时间变化对应哪种恢复方式，或者明确缺少哪条兑换证据。没有适用活动说明时，不能承诺手动补发、延期或恢复过期权益。
4. 到点仍不能用：做一次前后对照
适用条件： 第 1、2 步已对齐，目标窗口显示的时间已到，仍无法开始任务。
先保留现有提示，在当前用量页面记录一次快照；到显示的恢复时刻之后，再重新打开该页面读取一次。排查期间不要启动额外的大任务，以免恢复后的新消耗干扰判断；同时核对是否有自己仍在运行的其他任务，组织账号还需确认是否存在共享用量或管理员限制。
可复制下面的只读取证模板。填写界面实际显示的内容，不必填写账号秘密或完整日志：
观测时间（含时区）：
客户端与版本／本地或远程环境：
计划／工作区类型／ChatGPT 登录或 API：
限制原始名称：
原始数字与含义（已用／剩余／余额）：
显示的恢复日期、时间、时区或倒计时：
此前是否已使用一次性重置及其时间：
刷新后的同一字段与原始错误提示：时区比较要换算到同一时刻。例如，虚构示例中的 2026-10-17 16:00 UTC 对应北京时间 2026-10-18 00:00（UTC+08:00）。如果北京时间 17 日晚间还未恢复，不能仅因日期都写着“17 日”就认定延迟。若页面没有说明时区，先记录原样，不假定它采用 UTC 或本地时间。
预期结果： 可以比较同一个窗口在前后两次的状态。若它已恢复但任务仍被拦，查另一条耗尽限制、工作区控制或当前错误；若同一窗口过时仍未更新，保留两次记录，接第 5、6 步。仅查看状态即可完成这轮检查，不需要发模型请求来证明额度存在，也没有必要持续高频刷新。
5. 显示不同：先统一含义，再判断是否滞后
适用条件： 网页有额度，CLI 看起来没有；或者用量百分比对不上。
在同一账号、工作区内，尽量相近时间重新查看用量页和 /status，逐项对照第 2 步的标签。已用 80% 与剩余 20% 在同一窗口下可能是一致的；已用 80% 与剩余 80% 则不是同一个数。 不要省略“已用／剩余”这层含义，也不要拿 token 数直接换算额度百分比。
CLI 的 /usage 命令既可查看 token 活动，也可能包含兑换可用重置的入口。/usage daily、/usage weekly、/usage cumulative 进入对应活动视图；其中 weekly 活动统计不等于每周限额还剩多少。这里只查看信息，不选择兑换操作；若命令要求登录，先处理身份问题，而不是把无数据当作额度归零。
一次性重置后，官方提示界面可能短暂滞后。重新打开页面或客户端的用量视图后，再比较相同字段；不要把清理浏览器全部数据、删除登录文件或重新安装作为默认步骤。官方没有为所有界面给出统一的同步秒数，不能自行保证“等几分钟一定好”。
预期结果： 对齐数字含义后能解释差异，或得到仍然矛盾的两份同窗口记录。后一种情况继续保留观测时间、原始标签及截图，按第 6 步求助；模型口头说“已经重置”、新建对话或客户端进程启动成功，都不构成限额恢复的证据。
6. 仍有问题：把请求失败和额度问题分开提交
适用条件： 已确认同一限额过时未恢复、记录互相矛盾，或遇到没有明确额度说明的错误。
先阅读原始错误，确认它来自 Codex 服务、API 通道，还是任务调用的外部工具。单独一个 429 不能定位是哪项限流；401、403、网络超时也不等于每周额度耗尽。若是任务访问外部服务失败，转到终端能联网而 Codex 任务连不上，不用等待订阅额度恢复来修网络。
如果证据仍指向账号用量，请按官方 ChatGPT 计划与 Codex 支持说明联系支持；组织控制相关问题先让工作区管理员核对。准备以下材料：
- 计划与工作区类型、客户端及版本、故障时使用的模型和执行环境。
- 限制的原始名称、当前数值及含义、显示的恢复时间，两次观测的日期和时区。
- 若涉及一次性重置，附适用的官方活动说明及已经操作的时间，不再次兑换。
- 脱敏后的用量页、客户端提示截图与原始错误文本；说明刷新后还有哪项矛盾。
只提供定位所需的信息，遮住邮箱、组织标识、API Key、认证头和私人对话。支持可以调查计量、资格或访问异常；不应把联系支持写成保证补额度、手动清零或退款的办法。
怎样确认这次排查已经完成？
验收时应能回答：哪个账号和工作区、哪条实际限额、什么恢复方式、哪个带时区的时间，以及前后记录如何变化。 如果问题来自显示含义或重置后的日期变化，应能用同一窗口的记录解释；如果仍未恢复，应能指出未解决的具体矛盾，并交给支持核查。
额度恢复后可在下一次原本就需要的任务中观察是否仍遇到同一阻塞；不要为验收连续发送付费请求，也不要把所有任务失败都归到额度。本文按 2026-10-17 官方资料核验入口、命令和规则，并核算文中的时间及百分比示例；未替读者兑换重置、购买额度或验证其个人账户的真实计量。计划与活动规则变化时，以当前官方说明和账号实际显示为准。