Codex 额度缩水真不是错觉：OpenAI 承认有 Bug，连会话标题都在吃额度
OpenAI Codex 负责人 Tibo 公开确认，图片长会话多次 compaction、Computer History 高分位用量和会话标题生成器存在额外 usage 消耗问题，并表示 reset 已向付费账号推进。它补充了此前 sub2api 反欺诈解释：Codex 额度异常可能同时包含风控触发和产品自身 inefficiency，reset 也不等于长期效率已经翻倍。
结论
OpenAI Codex 负责人 Tibo 在 8 月 23 日更新称，团队找到几类会让 Codex usage 比预期消耗更快的问题：图片进入长会话并经历多次 context compaction 时的效率损失、Computer History 在 p95 以上用户中的异常高用量，以及一个本来只生成会话标题的功能消耗偏高。随后他表示 reset 会落地，并预告更多效率改进。
这给前几天的“Codex 额度缩水”争议补上了重要一块，但不能把它简化成“OpenAI 承认所有限额都算错了”。此前 Tibo 也提到，团队联系的一些异常账号使用了 sub2api 等订阅转 API 方案，可能触发反欺诈机制。现在更接近事实的说法是：反欺诈影响与产品自身 usage inefficiency 可能同时存在。
三天前，大家还在争论是不是 sub2api
Codex 用户最近抱怨的不是模型答错，而是额度掉得太快。有人说同样的工作流以前能撑几天，现在一天就见底；也有人在 OpenAI 社区写明自己没有 MCP 或类似工具，只使用官方 Codex Desktop，工作量也没有明显变化，却感觉 weekly limits 消耗更快。
Tibo 对一批异常用户的调查曾指向 sub2api：把 ChatGPT/Codex 订阅通过 OAuth 或中间层包装成 API，甚至用于共享账号池，可能触发反欺诈系统。这解释了部分账号，却无法自动解释所有正常使用者的体感。
现在 OpenAI 自己承认：Codex 确实有额外浪费
Tibo 8 月 23 日的公开更新列出三类问题：
- 图片出现在长会话、且经历多次 compaction 时，存在效率损失；
- Computer History 在 p95 以上的重度用户中用量偏高；
- 一个原本用于生成会话标题的功能，比预期多消耗了一些 usage。
第三项最有画面感。用户以为额度都花在“修登录 Bug”上，实际上 Agent 产品背后还跑着标题生成、历史记录、缓存、compaction、工具和审查等服务。只要其中一个环节在长会话里重复浪费，最终都会反映到同一个百分比上。
为什么长 Agent 会把小问题放大
普通聊天通常是一问一答。Codex 则可能读仓库、搜文件、改代码、跑测试、看截图、操作 Computer、压缩上下文，再继续工作。
如果图片处理每轮多消耗一点，compaction 每次多带入一点冗余，或者历史记录在高分位用户中异常昂贵，短会话可能感觉不明显，连续跑数小时的 Agent Session 却会把差距放大。
这也解释了为什么 Reddit 和社区里会同时出现两种相反体验：有人说额度半天就没了，有人几个小时只掉一点。模型、项目规模、图片、缓存命中率、工具调用和 compaction 次数都不同，他们未必互相矛盾。
Reset 是补偿，不等于长期效率已经翻倍
Tibo 随后表示 reset 将在付费账号落地，并回复用户“明天”的时间安排。这里要分清两件事：一次全局 usage reset 是把当前额度重新补回去；修复 inefficiency 才是让之后同样的工作少烧一点。
OpenAI 还预告了与这三项问题无关的额外效率方案。它如果真正进入生产，才会改变 Codex 的长期性价比。现在不能因为 reset 后数字回到满额，就写成“Codex 限额永久恢复”或“每周额度提升了几倍”。
社区已经有人感觉更耐用，但证据仍很薄
社交平台上已有用户自报，修复后连续运行高强度模型约半小时，Plus 周额度只下降约 2%；他此前使用另一档模型执行类似任务时，单次可能下降 3%–5%。
这个反馈值得记录，但不能当作 Benchmark。任务上下文、项目大小、缓存、是否带图片、compaction 和 reasoning effort 都会改变消耗。至少目前，它只能说明部分用户开始观察到改善，不能推导所有套餐的固定提升幅度。
所以“全是 OpenAI 偷砍”也不准确
目前没有证据证明 OpenAI 主动把所有付费用户的限额统一砍半；同样，也没有证据证明所有异常都来自 sub2api。
更稳妥的拼图是：
- 一部分账号可能因为订阅转 API、共享或类似行为触发反欺诈；
- Codex 自身也存在已被负责人公开确认的 usage inefficiency；
- 不同用户的工作流触发条件不同，所以额度体感差异很大；
- reset 能缓解当下感受，但长期结果要等修复后的真实用量记录。
这不是替 OpenAI 解释一切，而是把已经公开的两条证据放回各自的位置。
Codex 用户现在可以怎么测
如果你此前觉得额度消耗异常，最有价值的不是凭印象争论，而是做一次小型前后对照：
- 记录开始和结束的 usage 百分比；
- 使用相同模型和 reasoning effort；
- 尽量选相近大小的项目和任务；
- 标记是否有图片、Computer History、compaction 和 subagent；
- 运行 30–60 分钟，记录完成的工作量和总时间。
这样才能回答“修复后我的工作流有没有改善”，而不是把别人的套餐、缓存和任务混在一起。
我们的判断
这次最重要的不是 OpenAI 又送了一次 reset，而是官方说法出现了补全。前几天把所有额度异常归结为 sub2api，解释不了没有使用这些工具的用户；今天把所有问题归结为 OpenAI 偷改限额，也没有证据。
Codex 正在从一个聊天窗口变成长期运行的 Agent 系统。用户看到的只是一个 usage 百分比，背后却是模型、缓存、图片、历史、compaction、标题生成和工具调用共同构成的账单。只要平台不把这些消耗拆开，任何一次异常都会先被理解成“限额被砍了”。
仍然要观察
- reset 是否覆盖所有付费计划，以及到账时间是否一致；
- 三类已确认问题修复后，长图片会话和多次 compaction 的消耗是否下降；
- Computer History 的高分位用量是否回到合理水平；
- 预告中的额外效率方案何时上线，能否被用户重复测出；
- OpenAI 是否最终提供更细的 usage breakdown，让用户知道额度究竟花在了哪里。
来源与证据边界
- 一手更新：Tibo（OpenAI Codex）8 月 23 日关于 rate limits 的公开说明
- 一手回复：Tibo 关于 reset 时间的公开回复
- 社区记录：OpenAI Developer Community 的 Codex limits 讨论与用户反馈
- 用户自报：修复后用量变化的个案，不能视为官方统计
本文确认的是 OpenAI 负责人公开列出的 inefficiency 与 reset 说明，不把它扩大成所有额度异常的唯一原因，也不把个别用户反馈写成统一的套餐提升。