Claude 与 Codex 的使用限制：什么时候重置？

Codex 提示「已达上限」，Claude Code 显示一个重置时间，浏览器里看到的又像是另一个数字。这看着自相矛盾，但多半不是故障：「重置」这个词把好几种不同的边界混在了一起。把它们分开，就能很快判断是等一等就行，还是花钱的下一步真有必要。

本文描述的是 2026 年 7 月 19 日的公开文档状态。用量模型、套餐和推广活动都会变。因此你账号里的显示，比截图、论坛帖或旧文章里的某个时间更可信。

「重置」指的是四种不同边界

五小时窗口限制的是短时间内包含的用量。每周限制则在多个这样的窗口之上再加一层上限。两者可能接连生效：如果本周额度已经用完，一个刚刷新的短窗口也帮不上忙。

上下文或长度限制说的是单个会话能处理多少内容，它不是时间额度。上下文满了时开新会话有用，但不会恢复已经消耗掉的订阅额度。这一点在长时间写代码时尤其重要，因为大文件、聊天记录和工具调用会同时推高上下文和用量。

API 的速率与消费限制属于第四类。它们归属 API 账号及其计费。ChatGPT 或 Claude 订阅并不是通用的 API 余额。把这些边界混为一谈，要么白等，要么在不知情的情况下启动了付费用量。

Codex：五小时窗口与可能的每周限制

OpenAI 当前的 Codex 价格页说明，本地消息与云端会话共用一个五小时窗口。视套餐不同，还可能存在每周限制。因此不存在「Codex 每周一 00:00 就恢复」这种可靠说法。

消耗量也不是固定的提问次数。 模型、上下文大小、推理、工具、检索、缓存以及任务复杂度，都会影响一条消息的消耗。一个小函数可能只用掉额度的一小部分；一次涉及大量工具调用的仓库长分析则会用掉多得多。

OpenAI 还把受支持的智能体功能打包在一起。Codex、ChatGPT Work、ChatGPT for Excel 和 Workspace Agents——在你的套餐中可用时——可能从同一个用量与额度池中扣减。ChatGPT 的其他限制，比如语音或文件上传，并不自动等于 Codex 的限制。因此要看提示里写的具体名称。

Claude Pro：会话额度与固定的每周重置

Anthropic 为 Claude Pro 记录了一个每五小时刷新的会话用量限制。此外还有跨模型的每周限制，其星期与时刻由系统分配给你的账号，不会因为你何时开新会话或何时订阅而改变。

Claude 的用量在多个界面之间共享：claude.ai、Claude Code 和 Claude Desktop 使用同一份订阅额度。从终端切到浏览器，并不会产生新的配额。 即便这些界面展示消耗的方式不同，或者你在其中某个界面并没有开着长会话，结论也一样。

Anthropic 明确区分用量限制和长度限制。如果只是某个会话的上下文满了，新开会话或自动上下文管理就能解决。但如果是时间额度或每周额度用尽，以显示出来的重置时间为准。

到哪里查真正的重置时间

Codex 这边打开 Usage Dashboard。在活动中的 CLI 会话里，/status 会显示当前可用状态。读一读提示说的是五小时窗口、每周限制、额度，还是别的边界。不要按你上一次提问的时间去推算：共享窗口可能已经被其他 Codex 界面或智能体功能消耗掉了。

Claude 这边，Settings > Usage 显示五小时窗口的进度、剩余时间，以及每周限制和下次重置时刻。把这个面板和 Claude Code 里的提示对照一下。如果两者对不上，先确认你登录的是同一个组织、同一个账号。

一次好的排查请求遵循和写好提示词一样的纪律：把观察到的现象、涉及的界面、提示的确切文案和你想要的下一步分开写清楚。这样「Codex 不能用了」就变成了一个可以验证的问题。

拿到这两个数之后，可以把它们填进限额重置计算器：它会用倒计时显示窗口还剩多久，并按当前速度推算额度能否撑到重置。那里还有一份有据可查的 Codex 全局重置清单，并说明了为什么无法据此推出下一次的时间。

额度、banked reset 和 API 不是一回事

在包含用量用完之后，OpenAI 会向符合条件的 Plus 和 Pro 账号提供额度。这些额度属于付费的额外使用。自动充值可能会自己补上余额；因此只在设定了明确金额和消费上限后再开启它。

banked Codex rate-limit reset 则是另一回事。它可能作为推荐活动的推广权益出现，既不是现金也不是 API 余额，而且只对活动中写明的那个 Codex 限制生效。通用条款通常要求这类保存下来的重置在 30 天内使用，除非你的活动另有说明。所以以你收到的活动文案为准。

Claude 也为受支持的付费套餐提供 usage credits。包含额度用完后，后续使用按量计费。Anthropic 明确说明，这些额度不会改变常规的五小时重置。它们买的是等待时间，不是把时钟拨回去。

而通过 API 连接又是另一条计费路径。它能让紧急的本地工作继续，但会产生标准的 API 费用，并且需要自己的密钥、预算和安全边界。它不是绕开订阅的免费办法。

被限流之后可以怎么做

在合理使用范围内，OpenAI 会让已经开始的 Codex 回合跑完，好让进行中的工作有个交代。但不要指望之后还能再开一个回合。尽早把一个小而可追溯的中间状态保存下来：测试、diff、待办事项和明确的下一步。

如果任务可以等，显示出来的重置时间就是最省钱的选项。若只是短期额度吃紧，换个更小的模型、收窄任务范围、去掉无关上下文，都能省下剩余配额。一个边界清楚的智能体任务还能减少工具调用，避免没有验收标准的大范围试探。

当省下的时间值回额外花费、并且设了消费上限时，买额度是合理的。升级套餐更适合持续性的高负载，而不是一次性的高峰。把决定和成本记录下来，别让一次紧急例外悄悄变成长期开销。

下次看到限流提示时的检查清单

• 我记下了提示的确切文案、界面、账号和套餐。
• 我能区分五小时、每周、上下文和 API 四种限制。
• 我打开了 Codex Usage 或 Claude 的 Settings > Usage。
• 我把重置时间和已用比例填进了限额重置计算器。
• 我确认了还有哪些界面在消耗同一个额度池。
• 我在会话结束前保存了 diff、测试和下一步。
• 我按成本和紧迫度比较了等待、小模型、额度和 API。
• 我在启用付费用量前设定了消费上限，并检查了自动充值。
• 我把 banked reset 当作推广权益，而不是余额。

边界与常见误解

别人账号里的消息条数没法套用到你的工作上。即便任务看起来相似，也会因为上下文、模型和工具的差别而消耗不同的额度。一张带重置时间的截图，也只能证明那个账号在那一刻的显示。

如果面板出现明显跳变，或者过了提示时间仍然被拦截，先检查服务商状态、当前所在组织、时区和最新的产品文档。之后再带着截图和时间点提交工单才有意义。社区里的单条反馈既不能证明系统性故障，也说明不了原因。

真正可靠的流程始终很简单：先确定边界，再读官方账号面板，看懂共享额度池，最后才决定怎么继续。这样，模糊的「什么时候重置」就变成了关于时间、范围和成本的具体决定。