OpenAI 表示 Codex 修复可将使用额度延长最多 50%

OpenAI 表示，在工程师修复多项消耗使用额度的 bug 后，Codex 用户的可用额度应可延长 10% 至 50%。这项通过 Google News 扩散的更新，还包括面向付费 Codex 和 ChatGPT Work 用户的重置。两者结合起来听上去像是直接提升了容量，但这一标题数字涵盖的是多项不同修复措施，以及差异很大的工作负载。

这一区别很重要，因为 OpenAI 并未宣布统一提升 50% 配额。该公司表示，改善幅度取决于每个人使用 Codex 的方式。运行大量图像相关会话的用户可能看到一种结果，而受到失控目标影响的用户则可能看到完全不同的情况。

这次更新发生在数月以来用户抱怨额度消耗速度快于预期之后。一些报告涉及个别账户限制，另一些则描述了不必要的模型循环、重复工具调用，或自动化计划触发过于频繁。OpenAI 现已承认存在多种可能浪费使用额度的机制，但尚未公布可复现的整体改善基准。

因此，核心冲突并非 OpenAI 与另一款编程助手之间的竞争，而是 OpenAI 的效率承诺与用户对 Codex 计量机制有限的可见性之间的矛盾。该公司表示已修复具体问题，但客户仍无法独立将每一次配额变化对应到模型响应、工具调用、后台 worker 或失败的自动化任务。

OpenAI 表示已修复 Codex 中的哪些问题

此次更新针对的是浪费的智能体活动，而非单一计费错误或对账户限额的普遍扩展。

OpenAI 工程负责人 Thibault Sottiaux 表示，公司已审查数千份报告，并推出了一系列修复措施。对其 usage update 的公开转发列出了与上下文压缩、记忆 worker、目标、自动化和子智能体有关的问题。

上下文压缩是指缩短长对话，以便智能体能在可用的上下文窗口内继续工作。Sottiaux 表示，Codex 有时会在这一过程中保留旧图像。这些图像可能使上下文仍然足够庞大，从而触发又一次压缩循环。

OpenAI 估计，修正这一行为后，频繁处理图像的用户使用额度可减少约 10% 的消耗。这类用户可能包括让 Codex 检查截图、浏览器状态、设计参考资料或视觉测试失败情况的开发者。

记忆问题影响范围更窄，但存在更严重的长尾情况。后台记忆 worker 可能继承停止钩子，即当智能体尝试完成任务时执行的规则。阻止任务完成的钩子，可能使 worker 不断检查自己是否获准停止。

OpenAI 表示，受影响用户不到 1%。不过，据报道，该公司发现有一个线程检查自己能否停止多达 15,000 次。这个例子说明，看似罕见的编排 bug 也可能消耗可观的容量。

目标功能带来了另一种故障模式。已配置的目标可能已经完成，但智能体有时仍会越过预定停止点继续执行。Codex 也可能不断重试损坏的工具，而不是识别出该操作已不再有成效。

OpenAI 表示，观察到的案例消耗了每周额度的 15% 至 70%。这一范围并非平均值，也不应被如此解读。它描述的是系统未能正确停止工作时，问题长尾中出现的案例。

自定义自动化也可能比预定计划更频繁地运行。无人值守的任务若触发过于频繁，尤其难以诊断，因为用户在发生消耗时可能并未留意。

子智能体修复涉及模型选择。子智能体是处理大型任务中受委派部分的辅助智能体。OpenAI 表示，包括 Luna 在内的较小模型有时会选择能力更强的辅助智能体，即便用户并未提出这一请求。

能力更强的辅助智能体，其额度消耗方式可能不同于用户预期运行的模型。修正这一行为应使任务执行更可预测，尽管 OpenAI 并未公布子智能体改动带来的单独节省估计。

这些在技术上是彼此不同的 bug。一个扩大了上下文，一个阻碍 worker 终止，一个忽略了目标边界，另一个则提高了自动化运行频率。将它们合并为“10% 至 50%”的标题，确实让公告更易理解，但也掩盖了其中巨大的差异。

随附的重置机制进一步增加了解读难度。重置会刷新额度，而效率修复则会改变未来工作消耗额度的速度。与此同时获得两项变化的用户，无法通过比较更新前和更新后立即看到的仪表盘，来评估工程改进带来的效果。

为什么 Google News 标题需要谨慎解读

“最多可延长 50%”描述的是有利工作负载下的结果，而非对每个付费 Codex 账户的保证性提升。

通过 Google News 流传的报道准确反映了 OpenAI 公开声明中的上限。然而，“最多”这类表述始终需要一个分母。读者需要了解：改善的是哪项使用指标、测试了哪些模型，以及哪些任务模式带来了最大的收益。

OpenAI 并未表示每个账户都获得了 50% 更多的每周容量。它也没有公布一份简单的调整表，表明原有额度已变为 1.5 倍。该说法实际上是指，在消除多种浪费来源后，现有使用额度理论上应能支持更多工作。

用一个假设性例子可以更清楚地说明这种差异。如果某项工作负载此前会触发不必要的压缩循环，修复这些循环后，相同额度就能支持更多有用工作。名义限额可以保持不变，而实际有效容量得到提升。

另一位用户可能从未遇到过该 bug。此人从同一修复中获得的收益将接近于零。他们仍可能受益于目标、工具、子智能体或等待行为的改动，但前提是其工作流会进入这些路径。

OpenAI 自己的 Codex guidance 表示，消耗情况取决于模型、任务复杂度、上下文、推理、速度和工具。Codex、ChatGPT Work 及其他符合条件的智能体功能，也可能共享同一额度和积分池。

这一共享机制使随意比较变得不可靠。用户可能将仪表盘的变化归因于一次 Codex 编程会话，尽管另一项智能体功能也造成了影响。同样，措辞相近的两个提示，在其中一个触发大量工具交互时，其消耗也可能不同。

因此，10% 至 50% 的范围应被理解为运营层面的估计。它表明 OpenAI 预计多种工作负载中的浪费会减少。它并未提供提示、token、已完成任务和订阅配额之间稳定的换算关系。

Google News 在这里与其说是主张的来源，不如说是信息发现渠道。底层声明来自 OpenAI 的一位工程负责人，而独立文章则将其包装后呈现给更广泛的受众。Google 并未测试 Codex，也没有验证所报告的改善。

这一归属很重要，因为聚合传播可能压缩不确定性。简洁的标题几乎没有空间区分自动重置、修复后的后台 worker 与效率估计。读者很容易将三者都理解为一次永久性的配额增长。

该公告也缺乏分布结果。OpenAI 尚未公开展示中位数改善、高百分位改善，或预计会接近所述范围任一端的用户比例。

在缺少这些信息的情况下，50% 这一数字告诉用户某些工作负载可能会有怎样的体验，却无法说明这种结果有多常见。对某一群体而言，较低的 10% 下限或许更具参考价值；而此前受到影响的极端案例，则可能看到大得多的实际恢复。

因此，不应将此次更新简单视为营销措辞。披露的 bug 具体且合理，确实可能导致工作被浪费。不过，公开证据支持的是效率应当提升这一主张，而非每位 Codex 用户如今都拥有 50% 更多容量的结论。

Codex 使用限额已成为产品可靠性问题

配额消耗如今会影响智能体能否完成任务，这使计量行为成为产品可靠性的一部分。

传统聊天机器人通常会在一次回复中完成大多数交互。智能体系统则可以检查文件、搜索代码库、调用工具、等待进程、委派工作，并重新审视先前的决策。因此，一项用户请求可能产生许多底层模型循环。

每一次不必要的循环都很重要。重复重试工具不仅会延迟回答，还可能消耗共享额度、扩大活跃上下文，并为更多重试创造额外机会。

这使停止 bug 比笨拙的界面缺陷更为严重。如果目标已经完成，随后每一个动作都代表用户未曾请求的工作。系统可能看似仍在运行，却悄然减少了可供后续任务使用的容量。

上下文压缩也面临同样的问题。长会话期间，压缩是必要的，因为智能体无法在每次新的模型请求中携带无限历史记录。然而，失败的压缩策略可能反复处理本应被丢弃的信息。

图像尤其相关，因为它们可能占用大量上下文。使用截图进行界面调试的开发者，可能比处理小型纯文本代码库的用户经历更激进的上下文增长。

自动化又增加了一层风险。用户创建计划任务，往往正是因为他们不想监督每次执行。如果计划运行得过于频繁，受影响最严重的工作流也最不可能得到及时的人工干预。

OpenAI 此前已记录过 2026 年 6 月发生的一起范围较窄的 Codex 事件。其 status report 表示，部分账户被滥用和欺诈防范系统错误地施加速率限制。该公司称影响有限，且未观察到更广泛的服务劣化。

不应将该事件与最新修复合并为同一原因。6 月的问题涉及某些账户被错误速率限制；较新的披露则描述了 Codex 可能执行不必要内部工作的多种方式。

不过，两者合在一起解释了为何用户报告一直难以解读。额度迅速下降，可能源于长任务、高成本模型选择、共享的智能体使用、过多上下文、失控目标，或账户层面的限制。

用户无法仅凭一个百分比仪表可靠地区分这些可能性。他们可以查看重置时间和大类额度，但无法获得完整的逐轮明细账，将每一项内部操作映射到配额消耗。

随着 Codex 的使用范围超出软件开发，这一问题愈发突出。OpenAI 在 6 月表示，Codex 的每周活跃用户已超过 500 万；自桌面应用于 2 月发布以来，其用户规模已扩大逾六倍。该公司还在其 adoption report 中表示，知识工作者约占用户的 20%。

这些用户越来越多地要求 Codex 创建报告、分析数据、准备演示文稿和自动化工作流程。与经常检查流程日志的开发者相比，他们诊断代理循环的经验可能更少。

失败的终端命令是可见的。后台内存工作器数千次检查停止条件则不是。因此，更广泛的采用提高了使用说明的重要性——这些说明必须能让缺乏深厚系统知识的人也能理解。

团队还面临额外的规划难题。当消耗取决于上下文形态、模型选择、工具行为和隐藏的编排机制时，项目经理很难估算每周额度能支持多少项委派任务。

这些修复减少了若干已知的波动来源，但并未消除对可预测计量方式的需求。要让 Codex 成为可靠的基础设施，用户必须信任它完成的工作，也必须信任围绕这些工作的计费方式。

真正的对手是验证鸿沟

OpenAI 提供了一套可信的改进机制，但用户仍缺乏复现其核心结论所需的数据。

Codex 代码库中的一个公开问题说明了这一鸿沟。其作者要求 OpenAI 明确定义“使用时长更长”衡量的是什么，并披露这类说法背后的工作负载、模型、推理级别和观察周期。

该问题还解释了重复的代理步骤如何放大消耗。当工具将控制权交还给模型时，Codex 可能会在决定下一步行动前重新处理对话上下文。额外循环可能增加缓存输入、推理及其他按额度加权计算的活动。

使用量分析中引用的社区测试发现，明确进行批处理有时可降低估算消耗。这些实验是有价值的工程信号，但无法揭示 OpenAI 私有的订阅计费账本。

其局限性同样重要。样本规模较小，任务偏向读取密集型调查，且部分比较涉及不同的上下文或推理条件。估算的 API 等价成本也不等同于实际的 Codex 额度变化。

该问题指出了核心未解问题。OpenAI 尚未公开定义，这项改进衡量的是原始 token、加权内部使用量、已完成工作、实际耗时，还是其他代理指标。

它也没有提供百分位结果。单一平均值仍会掩盖公告中描述的长尾失败情况。用户需要了解，典型工作负载与此前反复触发压缩或失控停止行为的工作负载有何不同。

发布边界也仍不明确。一些修复可以完全在 OpenAI 的服务器上完成，另一些则可能依赖 Codex 应用或命令行更新。公开声明没有为每项更改提供最低客户端版本要求。

这种不确定性并不证明改进是虚假的。它表明该说法无法根据公开数据独立验证。已披露的机制与用户报告的行为一致，而且每项修复从逻辑上都应减少浪费的工作。

然而，有效容量并不等同于已完成任务的质量。只有当 Codex 仍能产出正确且完整的结果时，减少模型循环的优化才显得高效。一个有用的基准必须同时衡量消耗和结果。

任务多样性也很重要。代码库研究、界面调试、代码生成、长时间运行的测试、浏览器自动化和多代理工作，对系统不同部分施加压力。单一的综合数字无法告诉用户每个类别发生了怎样的变化。

重置也带来了暂时的测量问题。假设用户在 OpenAI 刷新其每周百分比的前后立即进行比较，这揭示的是重置，而不是修复代理行为节省的额度。

更干净的测试应在重置后开始，并重复一项受控任务。它应使用相同的代码库状态、提示词、模型、推理级别、权限、工具和客户端版本，然后比较已完成工作和实际额度变化。

即使这种方法也有局限，因为模型输出具有概率性。需要进行多次运行，并应交替执行顺序以减少环境偏差。用户通常没有足够的时间和额度来进行这样的研究。

OpenAI 更适合发布这类证据。它可以观察内部操作、识别受影响群体，并将模型 token 与编排开销区分开来。它还可以在不暴露客户内容的情况下，比较数千个生产工作负载的结果。

在此之前，最有依据的解读应保持谨慎。OpenAI 修复了几种有时会大量浪费额度的具体行为。该公司预计，不同用户的有效使用量可提升 10% 至 50%，但公众尚无法复现这一区间。

这些修复对开发者和团队意味着什么

实际收益是减少不可见的失败，但团队仍应将使用量仪表板视为有限的诊断工具。

依赖 Codex 执行长时间代码库任务的开发者最有理由关注这一点。完成后仍持续运行的目标，可能浪费原本用于测试、审查或后续修复的剩余额度。

即使名义限制保持不变，这项更改也能改善工作流连续性。更多额度应投入用户请求的工作，而不是重复停止检查、过期图像、损坏工具或意外的辅助模型。

图像密集型开发可能会因上下文压缩修复而直接受益。常见示例包括审查界面截图、比较渲染页面、检查图表，或调试基于浏览器的验收测试。

用户不应假设每项视觉任务都会便宜 10%。OpenAI 将这一估计与大量使用图像的人群相关联，但没有公布样本定义。上下文长度和任务结构仍可能改变结果。

自动化负责人应仔细审查定时任务。OpenAI 表示已修复可能运行过于频繁的自定义计划，但历史使用量不会自动揭示哪些执行并非预期。

团队可以将自动化时间戳与预期计划进行比较。过去意外发生的执行或许能解释异常消耗，但不能证明新披露的 bug 导致了每一项差异。

目标驱动型工作流也值得同样关注。团队应定义可观察的完成条件，并检查最终输出是否符合该条件。修复应能减少持续执行，但明确的验收标准仍然有用。

损坏的工具是另一个警示信号。如果外部服务不可用或命令无法成功，重复重试可能变得昂贵。设计良好的工作流应设置重试边界，并保留足够信息以便后续尝试。

使用子代理的用户还应在信息可用时检查哪些模型参与了委派工作。OpenAI 的修复应能防止较小模型在未经请求时选择能力更强的辅助模型，从而改善用户意图与执行成本之间的一致性。

对于组织而言，这些变化强化了对提示词、决策、日志和最终输出建立可搜索记录的需求。本地工程知识库可帮助团队将意外结果与相关文件和指令联系起来。

这类记录无法替代 OpenAI 的使用量遥测数据，但能为团队提供有关任务范围、工具故障和完成情况的自身证据。当额度意外下降时，这些细节能让支持报告更具可操作性。

团队应避免比较简单的提示词数量。一个 Codex 请求可能基于现有上下文作答，另一个则会启动测试、搜索文件、等待进程并委派工作。已完成任务单元是更有用的运营衡量指标。

一种实用的内部指标可以跟踪每个额度窗口内已接受的更改、已审查的文档或已完成的分析。它还应记录失败的运行，因为消耗更少却产出不可用工作的代理，并未提升生产力。

开发者应将暂时性重置与持续效率区分开来。刷新后的仪表板会立即创造余量，但长期价值取决于之后等效任务消耗这些余量的速度。

同样的谨慎也适用于 Google News 摘要和社交媒体帖子。它们是有用的发现工具，但运营决策应以底层声明和直接产品证据为依据。标题无法揭示某个特定工作流是否触及任何已修复的代码路径。

OpenAI 发布的帮助材料引导用户通过使用量仪表板和 /status 命令查看账户信息。这些工具展示了大致可用情况，但不提供完整的按操作归因。

如果使用量看起来仍不一致，用户应记录模型、推理级别、客户端版本、任务开始时间、工具、上下文特征和观察到的额度变化。这组信息能让 OpenAI 更清楚地区分预期消耗与另一项缺陷。

Google News 热度飙升后该关注什么

下一项考验是，OpenAI 是否能将一次性修复更新转化为可持续、可衡量的 Codex 效率。

第一个信号是重置效应消失后的使用稳定性。在多个额度窗口中，可比任务应消耗更少，或至少变得更可预测。如果关于无法解释的下降的报告持续出现，当前修复就只解决了部分问题。

这一观察必须考虑工作负载变化。切换模型、启用更多推理、增加工具或扩大代码库上下文的用户，无法进行干净的前后比较。

第二个信号是更好的归因。OpenAI 已经提供大致的使用信息，但用户需要更清楚地了解额度变化与模型轮次、工具循环、自动化、子代理和后台工作之间的联系。

按任务报告将使未来的回归更容易识别。当可见百分比的变化速度快于用户预期时，它也能减少猜测。

第三个信号是公布 10% 至 50% 区间的方法论。OpenAI 可以定义指标、描述测试的工作负载、说明哪些客户端版本重要，并展示中位数和长尾结果。

即使某些类别的收益低于标题中的最高值，这种披露也会强化公司的说法。在定义明确的工作负载上实现透明的 10% 改进，比用户无法映射到自身工作的更大数字更有用。

竞争对手的行为将提供辅助背景。其他代理提供商同样面临长时间自主运行与可预测额度之间的基本张力。随着编程代理处理更大规模的项目，更清晰的使用量计费可成为产品优势。

目前，开发者应将这次更新视为有意义的维护工作，但其测量问题尚未解决。OpenAI 点名了若干具体缺陷，描述了严重的异常行为，重置了付费用户的额度，并预计现有额度将支持更多工作。

剩余的不确定性涉及幅度、分布和持久性。Google News 让 50% 的上限获得广泛关注，但只有重置后反复出现的结果，才能显示典型用户实际处于哪个区间。

关注接下来几项可比任务，记录 Codex 的行为，并将已完成工作与仪表板变化区分开来。如果相同额度现在能产出更多被接受的结果，说明修复在真正重要的地方发挥了作用。如果无法解释的消耗仍持续存在，OpenAI 将需要新一轮工程工作和更清晰的证据。