8月23日消息,一名 ChatGPT Pro 用户发布了一份针对 Codex 配额异常消耗的审计,指控 Codex 的“计算机历史”(Computer History)功能在后台持续记录本地活动并产生数千万 Token 的上下文,认为这是自己每周配额神秘耗尽的根源。这一指控目前只有该用户一例审计支撑,OpenAI 未予证实;OpenAI 方面本周给出的官方解释是另外两个原因:部分用户缓存命中率下降,以及相当比例的配额投诉来自不被支持的 sub2api 共享用法。本文要做的是把爆料的主张拆开,看公开信息能支持到哪一步。
这份审计具体说了什么
这名用户审计了自己账户在8月20日上午至8月22日凌晨约 40 小时内的计算机历史原始数据,称共产生 190 个文件、约 9240 万个字符,包括 segments 目录下的分段事件文件(events.jsonl)。按每 Token 约 4 个字符的常见换算,相当于约 2310 万个 Token;用 cl100k_base 分词器逐词计算的结果更高,仅 events.jsonl 就有约 3490 万个 Token。按这个速度外推,一周的计算机历史大约相当于 9800 万到 1.4 亿个 Token。
爆料的核心指控是:这些历史记录会被作为上下文处理,即使用户没有发送长提示词,Token 消耗也会激增。该用户还提到,为了完成这次审计,自己用 GPT-5.3 Codex Spark 检查历史数据,仅约 12 条提示词就消耗了 5 小时 Spark 配额的 48%。其建议是,Plus 和 Pro x5 用户除非确实需要活动审计,否则不要默认开启这一功能。
不过,该说法目前无法独立验证:审计数字出自单一用户,没有第二例同类复核,爆料者也没有公开证明这些本地记录进入了服务端计费链路。
公开信息能支撑到哪
爆料涉及的组件是真实存在的。公开的安全研究资料中确实出现过 Codex 的计算机历史存储路径(~/.codex/memories/extensions/skysight/),对应一个名为 Skysight 的扩展,记录应用切换、窗口焦点、键鼠事件等结构化活动。也就是说,“Codex 有一个会持续记录本地活动的功能”这一点与公开信息相容。
Codex 后台功能消耗配额也有先例。在 OpenAI 官方的 Codex 仓库中,今年6月有用户记录到桌面端的环境建议功能在没有任何用户请求的情况下于后台消耗了约 7 万个 Token。GitHub issues 中长期存在大量配额异常消耗的投诉,包括“闲置状态下配额跑满”“仪表盘显示用量与配额消耗对不上”等情形。
官方本周的一个表态也与爆料的方向部分相容。OpenAI Codex 负责人 Tibo Sottiaux 表示,他们注意到本周部分用户的缓存命中率低于前几周的稳定状态,这可以解释为什么这些用户的额度消耗得更快,因为持续命中缓存是保持高效使用的重要组成部分。缓存命中率下降意味着同样的上下文会被收取更多费用,这与“后台上下文推高账单”的机制并不冲突。
同样成立的解释不止一个
爆料逻辑中有一个关键环节目前没有证据:本地日志文件的存在,不等于这些 Token 被服务端计费。配额消耗发生在服务端,而爆料者审计的是本地文件,两者之间是否存在计费关联,OpenAI 从未确认过,爆料本身也没有给出证明。
官方给出的解释指向别处。Tibo Sottiaux 在8月21日表示,OpenAI 调查了配额消耗存在差异的反馈,发现许多受影响的用户在使用 sub2api——把订阅账号转化为 API 流量转售或供多人共享,这类用法会被反欺诈系统标记。他同时划清了被支持的路径:通过 Sign in With ChatGPT 使用订阅,无论是官方客户端还是 Pi、OpenCode 等支持账号登录的开源客户端,都没有问题。OpenAI 还强调,不会在不与社区沟通的情况下更改使用限制。 此外还有两个已知的消耗变量:GPT-5.6 Sol 成为默认模型后带来了更大的上下文窗口,官方客户端用户同样报告配额消耗加快;ChatGPT Work 与 Codex 共享同一个配额池,其他场景的用量会挤占编程额度。这些变量都能独立解释“配额比以前跑得快”,不需要借助计算机历史这一项。
能确认的结论是:计算机历史功能真实存在,后台消耗配额有先例,官方承认本周缓存命中率异常,并且承诺将发布调查更新。不能确认的是:计算机历史产生的 Token 是否计入配额、它是否是任何用户配额耗尽的主因。在那之前,这名用户的审计只能作为一个待证实的假设。关心自己配额去向的用户可以直接检查本地 ~/.codex/memories/extensions/skysight/ 目录的体积,并对照账户使用页的实际消耗——这是目前不依赖任何人表态就能做的事。