OpenAI 的 Codex 在 6 月 29 日至 30 日连续两天宣布额度重置，这已是本月第二次大规模补偿。此前，有开发者发现仅发送一条消息，Codex 的全部额度就被瞬间烧光，5 小时限制直接归零。这一现象并非个例，随着讨论扩散，开发者社区对额度透明度的质疑集中爆发，产品负责人 Tibo 被直接喊话回应。这场风波背后，是 Codex 团队激进协作模式与系统稳定性之间的典型矛盾。调查结果于 6 月 30 日公布，Tibo 承认问题并非单一 bug，而是多个因素在特定场景下叠加放大。具体包括：自动代码审查机制触发频率过高，导致后台提前启动分析；任务拆解机制异常，一个 prompt 被拆成多个子任务；失败 prompt 在后台发生重复重试；用量统计与分类显示出现偏差。这些 bug 共同导致额度在用户无主动操作时持续下降，甚至出现“后台偷跑”现象。OpenAI 已回滚相关改动，并修复了重复生成、重复调度和异常重试的问题。为应对补偿浪费问题，Codex 团队发明了“重置卡”（banked reset）机制。此前只有硬重置（hard reset），即官方直接重置额度，但若用户周限额即将自动刷新，补偿重置可能撞在自然刷新前夜，造成浪费。现在，官方将重置额度以“重置卡”形式存入用户账户，由用户自行决定使用时机。这一创新在一定程度上缓解了用户的不满，但仍有开发者表示不买账，认为问题根源在于团队过于激进的协作模式。Codex 团队采用“区域联防”协作方式，工程师、设计师、PM 谁离问题最近谁直接解决，不再等待完整 PRD。这种模式使更新速度惊人，但也导致产品在前飞、bug 在后追。早在 2025 年底出现计费异常时，团队就曾重写计费系统底层逻辑，但额度问题仍未彻底消失。对于开发者而言，建议在问题彻底解决前，密切关注账户额度变化，合理使用重置卡，并避免在关键任务中过度依赖 Codex 的自动化功能。未来，Codex 能否在速度和稳定性之间找到平衡，将决定其在开发者社区中的长期口碑。