AREX Feed Article
Tibo 公布 Codex 用量异常三项根因：明日修复、付费订阅用量全额重置
8 月 23 日，OpenAI Codex Thibault "Tibo" Sottiaux（@thsottiaux）发布 Codex 速率限制调查更新：用量异常有三项根因——长会话多次压缩（compaction）时使用图片存在低效、Computer History 功能的 p95+ 用量偏高、用于生成对话标题的功能消耗超出预期（）。
他已组建 tiger team 逐项排查，修复将于次日上线；作为修复的一部分，所有付费订阅用户的用量将全额重置。
这是 Tibo 围绕"用量消耗过快"的第三次表态。8 月 22 日，他承认部分用户的缓存命中率（cache hit rate）低于此前稳定水平、"可能解释用量消耗偏快"，并承诺次日更新（）；8 月 21 日，他刚宣布为庆祝 Codex 活跃用户达到 2000 万向用户发放 banked reset（）。
从"没看到异常"到一项假设，再到今天的三项根因清单——这是 Tibo 首次给出具体根因。
三项根因：图片、Computer History 与标题生成
第一项是长会话多次压缩时使用图片的低效。compaction 是 Codex 在长会话中自动压缩早期上下文的机制——Tibo 此前介绍 1M 上下文配置时解释过，上下文接近上限时模型会把更早的材料总结压缩（）。
也就是说，带图片的长会话在反复压缩时，图片相关的处理成本没有被有效控制。
第二项是 Computer History 的 p95+ 用量偏高。p95 指第 95 百分位，p95+ 即用量分布中处于长尾高位的部分，Tibo 说这部分用户在 Computer History 上的消耗偏高。第三项是标题生成：一个本意用于生成对话标题的功能，消耗超出预期（"draining a bit more usage than intended"）。
与前一天把矛头指向缓存命中率不同，这份清单没有再提及缓存。三项根因都指向用户的实际使用方式。
这种消耗在评论区能找到具体样本。用户 Super Chris（@cdenczek，自称 $100 套餐用户）在回复中贴出自己的插件用量统计：$imagegen 运行 131 次、@browser 132 次、@computer-use 32 次（）。他说自己"整个会话都在生成图片"，一个月来用量一天之内就耗尽，"一直不知道自己正在做坏事，全程被削"。
tiger team 明日修复，付费订阅用量全额重置
Tibo 称 tiger team 正在逐项排查（"combing through everything"），修复将于次日上线。作为修复的一部分，所有付费订阅的用量将全额重置。他随后在回复中补充：重置"大约在明天太平洋时间下午 2 点"落地——先误写成"14pm"（），三分钟后自行更正为 2pm（）。
这是不到一周内的第二次全员重置。8 月 21 日那轮 banked reset 覆盖 ChatGPT Work 与 Codex 的全部付费用户，预告"太平洋时间晚 8 点前到账"（），随后确认"已落地"（）。这一轮则覆盖所有付费订阅。
截至本文写作时，这条更新已获得近 1 万点赞、超过 112 万次浏览。
认领场景的、质疑漏项的、后悔用早了 reset 的
评论区很快分成几拨。独立游戏开发者 Rising Sun Interactive（@RisingSunInt_，法国）对号入座：用量只剩 17%，正常重置要等到 8 月 27 日，而他大量用图片生成做 sprite sheets，"显然正好踩中你找到的 bug 之一"（）。
Altura Innovation 的 CEO Dave Charland 说开了新功能后"半周烧完一周的用量"，他的会话大多很长、多次压缩（）。earmark_ai 创始人 Sanden Gocka 补充了一个可观察现象：长会话多次压缩图片时，线程会占用数 GB 磁盘空间（）。
质疑同样直接。Steven Zimmerman（@EffortlessSteve，CPA）列出自己的用法——"没有图片、没有 computer history、标题也少（长跑 codex CLI）"——结论是"有别的东西在降低 token 效率"（）。用户 Fist 更激烈：消耗涨了"1000 倍"，这不像是小低效，应该直接回滚周三以来的全部改动（）。
也有人为时间差懊恼。Chris Pearson（@Snoaper）说已经用掉了 banked reset，"本来可以等的"（）；Diego Tellez 问"能把自愿 reset 还给我吗？16 小时前刚用了"（）。还有用户直接追问这次全额重置是 banked 还是普通形式（）。
正面反馈也有：PolyTraderBot 作者 Tradi3 称赞这是"实打实的客户服务"——认真听取用户、尝试修复，而不是无视（）。在 OpenAI 开发者社区，用户 SimplyKat 把这次更新转贴进"Codex limits spark frustration among subscribers"帖子，并提醒："有些人可能该重新想想自己给系统施加的负载"（）。
一项"完全无关"的提效方案，下周开工
更新最后还夹带了一条与本次事故无关的消息：团队找到了一种"能显著提升效率的新方法"，与本次问题完全无关，下周着手推进。推文没有给出任何细节。
三项根因与前一天提到的缓存命中率异常是什么关系，这次更新也没有说明。对用户来说，明天太平洋时间下午 2 点前后的用量面板，就是这次修复的第一个验收现场：重置是否到账、修复后的消耗是否回到正常。