9月16日消息,一名开发者在 openai/codex 仓库提交 issue 指控:Codex 桌面应用在触发安全检查后,把他选定的 gpt-6-astra 请求静默改由 gpt-5.5 模型服务,应用界面始终显示 gpt-6-astra,会话文件与日志里均无切换记录。这份编号 #44637 的 issue 于9月10日提交,目前处于 open 状态,OpenAI 尚未回应,也无人复现。它由用户 cypherair 提交、作者注明由 AI 协助起草,目前是该指控的唯一来源——本文要判断的是:这份指控的证据链可信到什么程度。
爆料说了什么,证据链长什么样
报告者 cypherair 的环境是 Codex 桌面应用(版本 26.903.71938)、ChatGPT Pro 订阅。9月9日,他在使用 gpt-6-astra 时收到提示"This request requires additional safety checks, which can take extra time",界面同时给出"retry with a faster model"(改用更快的模型重试)选项;他关闭了提示、拒绝了重试。此后界面一直显示 gpt-6-astra,但用量页面显示,当天大部分请求实际由 gpt-5.5 服务。他在 issue 里写道:"My work was done by a less capable model than the one I selected, without notice or consent, while the UI said the opposite."(我选的模型换成更弱的在干活,没有告知也没有征得同意,界面却说着相反的事。)
支撑这一指控的技术论证有三层。其一,会话文件里每一轮都记录为 gpt-6-astra,客户端从未发出过 gpt-5.5 请求,说明切换发生在服务端。其二,客户端感知重路由的信道只有两处:websocket 握手或 SSE 流里的 openai-model 响应头;他统计了9月2日以来的 55 次握手,没有一次携带这个头,而连接会复用数小时,握手期的响应头无法反映后续切换。其三,应用本身有重路由提示条("Your request was routed to {toModel}."),那次从未出现;ModelReroute 与 SafetyBuffering 两个事件类型是瞬态的,不会写入会话文件——安全检查和切换因此不留任何本地痕迹。
逐项看:哪些部分更可信,哪些存疑
第一层主张——请求实际由 gpt-5.5 服务——与已知机制相容度最高。重路由机制本身是官方设计:issue 引用的提示条文案和"改用更快模型"选项都是 Codex 应用内真实存在的 UI,OpenAI 也维护着公开的部署安全体系,安全检查触发降级路径在逻辑上说得通;用量页显示 gpt-5.5 是报告者账号内的真实数据。但整个证据链出自报告者一方,用量页的统计口径是否存在 bug、会话文件记录的到底是"客户端请求的模型"还是"服务端实际执行的模型",都无从验证。
第二层主张——切换是静默的——论证最细致,信源也最单薄。55 次握手采样、瞬态事件不落盘,这些分析指向"客户端无法感知切换",但不能穷尽全部信道,也排不除提示曾短暂出现过而未被注意的可能。
第三层主张——拒绝之后仍被切换、未经同意——存在交互语义的歧义:点掉"改用更快模型重试"是否等于关闭该会话后续所有降级路径,官方没有定义过。至于报告者暗示的"刻意不透明",issue 自己也没有断言是故意设计,更可能是机制缺陷,这一层无法判断。
目前的状态与用户的自证手段
目前,OpenAI 未就此公开回应,issue 保持 open,没有其他用户复现,媒体亦无报道——这是一份孤证爆料,以上所有判断都可能被一份服务端日志推翻。
对 Codex 及其他付费订阅用户,这份 issue 里最有用的信息是自证方法:应用的模型选择器不可信,用量页面(usage)记录的才是实际服务的模型,定期对照两者是目前唯一的核查手段。