OpenAI疑似从8月25日起恢复ChatGPT Plus及Business Standard用户在Codex、ChatGPT Work中的5小时滚动使用上限。短期窗口与每周额度并行，Pro用户暂未受到影响。

ChatGPT Plus五小时限制恢复：开发者的“短暂解放”结束了

OpenAI疑似已从2026年8月25日起，恢复ChatGPT Plus及Business Standard用户在Codex与ChatGPT Work中的5小时滚动使用上限。这个变化目前主要通过用户实测、产品负责人公开表态和社区反馈被确认，部分账号的具体显示可能仍存在延迟或差异。

这意味着，过去六周里曾经暂时取消的短周期限额重新回到付费用户面前：即使账号的每周额度尚未用完，只要在连续5小时窗口内消耗过多，用户仍可能需要等待窗口自动恢复，或者使用额外额度继续工作。

对于把Codex当作日常开发助手的人来说，这不是一次小修小补。它直接改变了连续编码、代码重构和长任务代理的使用节奏。

ChatGPT Plus、Business Standard、Pro方案与5小时滚动限额关系示意图

发生了什么：5小时滚动窗口重新出现

**5小时滚动使用上限是指，用户在任意连续5小时内只能消耗一定数量的Codex和ChatGPT Work额度，额度会随着最早一批使用记录过期而逐步恢复。**它不是每天零点重置的固定日限额，也不是简单的“每天只能用几次”。

根据目前公开信息，OpenAI Codex与ChatGPT Work负责人Thibault Sottiaux在8月24日宣布，Plus用户从8月25日起重新启用这一限制。社区讨论中还出现了Business Standard用户同步受到影响的反馈，因此目前更准确的说法是：Plus和Business Standard的部分账号已经恢复或正在恢复5小时限制，但不同地区、工作区和账户的生效时间可能不完全一致。

这项限制主要影响两个场景：

Codex：用于分析代码仓库、修改文件、运行测试、修复报错和生成提交说明等代理式开发任务。
ChatGPT Work：用于更长上下文、更复杂任务或面向工作流的持续使用场景。

普通的短问短答并不一定会以同样方式消耗额度。真正容易触发限制的，是需要模型多轮思考、读取大量文件、调用工具、执行命令并根据结果反复修改的任务。

目前的额度机制可以理解为两层水闸：

| 额度层级 | 作用 | 典型触发场景 | 恢复方式 | |---|---|---|---| | 5小时滚动限制 | 防止短时间内集中消耗计算资源 | 连续运行Codex、长时间代理开发、密集调用Work | 等待滚动窗口释放额度 | | 每周额度 | 控制套餐周期内的总消耗 | 一周内持续进行大型项目开发 | 等待周额度重置，或使用额外额度 |

**5小时限制与每周额度是两套并行机制，短周期限制恢复并不代表每周额度也会同步恢复。**如果用户同时触及两个上限，只等待5小时窗口结束可能仍然无法继续高强度工作。

为什么OpenAI又把限制加回来

**恢复5小时上限的核心原因，是让计算负载更平滑，同时避免用户在一次长任务中耗尽整周额度。**这是一种资源调度策略，也是一种套餐体验设计，而不只是简单削减权益。

今年7月，OpenAI曾暂时取消Plus、Pro和Business方案的5小时滚动限制，并重置了相关用户的用量计数。当时GPT-5.6 Sol上线后不久，Codex和ChatGPT Work的需求快速增加。两项服务共用一部分用量池，用户集中运行长任务后，容易出现短时间内额度快速消耗、另一项服务可用性下降的问题。

临时取消限制的目的，是在模型和基础设施承压期间先降低使用摩擦。换句话说，OpenAI当时选择了“先让用户用起来”，而不是继续用短窗口限制精细控制流量。

但这种方式也带来两个明显问题。

第一，固定月费套餐的计算成本变得更难预测。一次看似简单的“帮我修改登录逻辑”，可能涉及读取整个仓库、定位依赖、修改多个文件、执行测试、分析报错，再进行数轮修复。用户只发出了一句话，后台却可能执行了十几轮工具调用。

第二，部分用户可能在一次集中工作中消耗掉大量周额度。随后几天里，即使只是处理小问题，也会因为周额度不足而无法使用。短周期限制虽然会在当下制造阻碍，却能把消耗分摊到更长时间内，降低“周初用光、周末停摆”的概率。

从OpenAI的角度看，5小时限制类似电网的峰谷调度：它并不一定减少一周允许消耗的总电量，但会限制用户在某个时段同时打开所有大功率设备。对模型公司而言，这有助于降低GPU集群的瞬时峰值；对用户而言，则意味着长任务不能无限连续运行。

对开发者影响最大：不是总额度，而是连续性

5小时限制对开发者最直接的影响，不是套餐总额度必然减少，而是它会打断连续的工程任务。

普通聊天被限额时，用户可以换个问题、稍后再问，损失通常比较有限。但Codex类代理任务往往具有明显的上下文连续性：模型刚读完项目结构，刚建立修改计划，刚完成数据库层调整，下一步就可能需要继续处理接口、补测试和修复回归问题。

假设一个开发者上午开始重构一个Python项目，工作流可能是：

让Codex扫描仓库并梳理模块依赖；
修改数据库模型和迁移文件；
更新后端接口与前端调用；
执行单元测试和类型检查；
根据错误日志继续修复；
生成变更摘要并检查潜在回归。

这种任务并不是六次独立问答，而是一条不断累积上下文的工作链。若在第4步或第5步触及5小时窗口，用户面对的就不只是“暂时不能发送消息”，而是整个任务被迫暂停。

尤其是大型仓库、高推理模式、长上下文和频繁工具调用同时出现时，额度消耗很难凭肉眼估算。修改一个函数可能消耗很少；让代理在一个数十万行代码库中完成跨模块重构，消耗则可能快速上升。

这也是社区对恢复限额反应强烈的原因：用户真正不满的并非“付费服务存在限制”，而是缺少足够准确的消耗预估。产品页面如果只展示一个抽象的“剩余额度”，却不说明当前任务大致会消耗多少，用户就很难安排开发节奏。

Plus、Business Standard和Pro有什么区别

**目前公开信息显示，Pro 100美元和Pro 200美元方案暂时不受这次5小时限制影响，Plus与Business Standard则是主要受影响的套餐。**不过，Pro用户也并非没有其他用量约束，具体模型、功能和周期额度仍应以账户页面显示为准。

| 方案 | 5小时滚动限制 | 主要受影响功能 | 当前判断 | |---|---:|---|---| | ChatGPT Plus | 已恢复或正在恢复 | Codex、ChatGPT Work | 需要关注账户实际提示 | | Business Standard | 社区反馈显示已恢复或正在恢复 | Codex、ChatGPT Work | 企业工作区可能分批生效 | | ChatGPT Pro 100美元 | 暂未受影响 | Codex、ChatGPT Work | OpenAI表示未来数月继续豁免 | | ChatGPT Pro 200美元 | 暂未受影响 | Codex、ChatGPT Work | OpenAI表示未来数月继续豁免 | | Enterprise / Edu | 信息不完整 | 取决于工作区额度制度 | 不能直接套用Plus规则 |

这里需要特别注意“Business Standard”这个名称对应的是标准企业方案，而不是所有Business工作区。企业账号往往还涉及管理员策略、组织级额度和独立的计费规则，因此单个用户看到的提示，未必能代表整个组织的实际政策。

用户现在应该怎么用

面对恢复的5小时窗口，最有效的应对方式不是盲目减少提问，而是把长任务拆成可恢复、可验证的阶段。

1. 先确认到底触及了哪一层限制

当Codex或ChatGPT Work无法继续时，先看产品页面给出的恢复时间和提示。如果页面明确显示5小时窗口将在某个时间恢复，通常说明是短周期限制；如果提示周额度已经用尽，等待几个小时未必有效。

两者的处理方式不同：

只触及5小时窗口：等待最早一批用量释放；
触及每周额度：需要等待周周期重置，或使用账户支持的额外额度；
工作区管理员设置了限制：个人等待并不能解决问题，需要由管理员调整策略。

2. 把一次大型任务切成多个检查点

不要让代理从“扫描仓库”一路运行到“完成全部重构”。更稳妥的方式是先让它分析并输出计划，再单独执行一个模块的修改，随后运行测试并保存结果。

这样做有三个好处：一是更容易控制消耗；二是触及限制后不至于丢失任务状态；三是每个阶段都有可回滚的代码版本。对于生产项目，阶段化执行本来就是比“一句话完成全部工作”更可靠的工程方法。

3. 减少无效上下文和重复扫描

如果项目已经建立了明确的目录结构和任务说明，就不必每次都让代理重新扫描全部仓库。可以提前准备架构说明、测试命令、编码规范和关键模块说明，减少模型反复读取相同内容的次数。

同时，尽量避免把“分析、实现、测试、发布说明”全部塞进一个请求。单次任务越长，越容易出现中途失败后重复消耗的问题。

4. 不要把5小时限制理解成每5小时清零

这是最容易产生误解的地方。滚动窗口不是固定时刻重置，而是按照使用记录逐步释放。用户在上午9点集中使用一批额度，这批额度可能在下午2点左右开始恢复；9点半使用的部分，则可能要到下午2点半左右释放。

因此，产品显示的具体恢复时间比“今天还能用几次”更有参考价值。

OpenAI的产品信号：代理能力越强，套餐越像算力订阅

ChatGPT Plus恢复5小时限制，说明AI代理产品的成本结构已经明显不同于传统聊天机器人。

普通文本问答的成本主要与输入输出Token数量相关，用户还能大致根据对话长度判断消耗。但Codex这类代理会把一次自然语言指令扩展成一连串内部动作：读取文件、搜索符号、执行命令、解析日志、生成补丁、再次运行测试。模型输出的字数只是表面，后台工具链和推理轮次才是更重要的成本来源。

这会推动AI订阅从“每月不限次数”逐渐走向多层配额模式：短周期限制负责平滑峰值，周额度负责控制总消耗，更高价方案则购买更大的并发和连续使用能力。

从商业上看，OpenAI这次选择保留Pro的豁免，也是在给高强度用户一个明确的升级路径。Plus更像面向广泛用户的通用套餐，Pro则更接近面向重度开发者、研究人员和专业工作流的算力套餐。问题在于，价格差距是否足以匹配用户获得的连续性，以及额度消耗是否足够透明。

我们的判断：限制本身合理，体验设计仍不够成熟

5小时滚动限制对于固定月费的代理产品是合理的，但OpenAI目前最大的问题是额度机制不够透明。

在Codex需要调用模型、沙箱和工具链的情况下，完全不设短周期限制很难长期维持。尤其当新模型上线、用户集中尝试高推理任务时，瞬时负载可能快速上升。与突然降速、排队或服务不稳定相比，明确的窗口限制至少给出了可预期的边界。

但这种机制要真正被用户接受，还需要三个改进：

实时显示短周期和周额度的分别消耗量，不要只提供模糊的剩余提示；
在大型任务开始前预估可能消耗的额度，让开发者能决定是否拆分任务；
把Codex、ChatGPT Work等共享额度的关系说明白，避免用户误以为每个产品都有独立配额。

目前的体验更像是模型已经进入了“云计算资源管理”阶段，但产品界面仍在用“聊天次数”的方式解释它。对于轻度用户，这种差异可能不明显；对于每天依赖代理写代码的人，它会直接决定工具是否能进入正式工作流。

截至2026年9月7日，Plus和Business Standard用户应当检查自己的Codex、ChatGPT Work页面，确认5小时窗口是否已经生效，以及当前账户究竟受到短周期限制、周额度限制，还是工作区策略限制。Pro用户暂时可以继续保持高强度使用，但OpenAI后续是否调整豁免范围，仍取决于模型成本、基础设施容量和用户需求变化。