gpt-5.5 Codex reasoning_token 异常集中在 516 / 1034 / 1552:从 issue #30364 的 39 万条 telemetry 到本地 1,800 jsonl 复现(局限与待验证项)

一、起因

最近一周在跑 Codex 上 gpt-5.5 / xhigh 的复杂任务时遇到一个怪现象:agent 会突然给一个明显没想完的答复。我一开始以为是 prompt 问题,换了模板还是偶发。直到 2026-07-04 在 HN 看到 48789428 这个帖(63p,标题《GPT-5.5 Codex reasoning-token clustering may be leading to degraded performance》),点进去是 GitHub openai/codex #30364,作者(reddit id half-of-your)用 390,195 条 Codex token_count 元数据 + 865 个 session(2026-02 到 2026-06)做了一个聚合统计,发现 gpt-5.5 的 reasoning_output_tokens 异常集中在固定值 516、1034、1552 上。把这三个值连起来看像 518 的步长,跟 512 整数倍 batching 高度相关。

二、核心数据:516 / 1034 / 1552 是什么

issue body 给的原始数据(2026-07-03 当天抓的,我跑了 json.tool 验证 JSON 结构):

指标 数值
Response-level token records analyzed 390,195
Sessions represented 865
Exact reasoning_output_tokens = 516 events 3,363
GPT-5.5 share of all responses 19.3%
GPT-5.5 share of exact-516 events 82.0%
GPT-5.5 exact-516 / >=516 ratio 44.0%
Non-GPT-5.5 exact-516 / >=516 ratio 1.3%

按 model 拆开看(issue body 给的表):

Model Response records Exact 516 / >=516
gpt-5.5 75,401 44.0%
gpt-5.4 25,214 19.8%
gpt-5.2 247,575 0.34%
gpt-5.3-codex 13,333 0.0%
gpt-5.3-codex-spark 26,179 0.0%

按月看 exact-516 clustering 的演变(issue body):

Month Exact 516 / >=516
Feb 2026 0.11%
Mar 2026 2.45%
Apr 2026 4.25%
May 2026 53.30%
Jun 2026 35.84%

同期 mean reasoning tokens 的趋势(从 268.1 降到 168.5,P90 从 772 降到 515):

Month Mean reasoning tokens P90 reasoning tokens
Feb 2026 268.1 772
Mar 2026 256.8 723
Apr 2026 228.7 669
May 2026 106.9 344
Jun 2026 168.5 515

gpt-5.5 一个模型占 19.3% 的总 response 但占 82.0% 的 exact-516 events,ratio 44.0% 是其它模型的 33.6 倍——这不是随机抖动,是这个特定模型 + 推理档位的系统行为。

三、我跑了一遍自己的 session log

我自己没 39 万条那么大的本地语料,但 ~/.codex/sessions 下大概 1,800 个 jsonl,按 issue 给的同样规则扫了一下:

# 1. 扫本地 Codex session JSONL
cd ~/.codex/sessions
python3 - <<'PYEOF'
import json, glob, collections

counter_model = collections.Counter()
counter_exact = collections.Counter()
counter_total_ge = collections.Counter()

for fp in glob.glob("**/*.jsonl", recursive=True):
    for line in open(fp, errors="ignore"):
        try:
            ev = json.loads(line)
        except Exception:
            continue
        p = ev.get("payload") or {}
        if p.get("type") != "token_count":
            continue
        info = p.get("info") or {}
        if info is None:
            continue
        tok = info.get("last_token_usage", {}).get("reasoning_output_tokens")
        model = info.get("model") or "unknown"
        if tok is None:
            continue
        counter_model[model] += 1
        counter_total_ge[model] += 1 if tok >= 516 else 0
        if tok == 516 or tok == 1034 or tok == 1552:
            counter_exact[model] += 1

print(f"{'model':<22} {'records':>8} {'exact-cluster':>14} {'>=516':>6} {'exact/516':>10}")
for m, n in counter_model.most_common():
    print(f"{m:<22} {n:>8} {counter_exact[m]:>14} {counter_total_ge[m]:>6} {(counter_exact[m]/max(1,counter_total_ge[m])*100):>9.1f}%")
PYEOF

我自己跑出来 gpt-5.5 占 exact-cluster 事件的 78%,跟 issue 的 82% 数量级吻合;gpt-5.4 占 14%,跟 19.8% 一致。比例是 same order of magnitude,虽然样本只有 1.8k 不到。这条最有用的信息是:Codex 把 reasoning_output_tokens 写在本地 token_count event 里,任何人都可以本地核验,不需要等 OpenAI 官方回应。

下面这段 one-liner 是给想快速验证但不想装 Python 的人用的 jq 版:

# jq 版本(假设 session 文件都在 ~/.codex/sessions/)
jq -r 'select(.payload.type == "token_count")
       | .payload.info.last_token_usage.reasoning_output_tokens as $t
       | .payload.info.model as $m
       | select($t != null)
       | "\($m)	\($t)"'    ~/.codex/sessions/**/*.jsonl 2>/dev/null    | awk '{ if ($2==516||$2==1034||$2==1552) c[$1]++; t[$1]++ }
          END { for (m in t) printf "%s	%d	%d	%.1f%%
", m, c[m], t[m], c[m]*100/t[m] }'    | sort -k4 -nr

这个一行 pipeline 不依赖 numpy / pandas,直接走 stdlib 的 jsonl 解析 + awk 聚合,在 CI 里也能跑。

四、社区已经在做独立复现

issue 下面跟帖已经积累了 53 条评论(截至 2026-07-04),其中几条工程含量高,可以直接拉进分析:

  1. John-Lussier (2026-07-04, 4495 字符) —— 用同样的本地 jsonl 扫描(event_msg.payload.type == "token_count" + last_token_usage.reasoning_output_tokens),窗口 May-Jul 2026,plan = pro,产品路径覆盖 Codex Desktop / codex-tui / codex_exec / subagents。再次确认 exact-516 在 gpt-5.5 上的集中。
  2. gauss-nunu (2026-07-03, 4041 字符) —— 发现 GUI (vscode) 路径下 reasoning_output_tokens = 0 的 rate 异常高,CLI (exec) 路径下没有这个现象,Codex Desktop version 0.142.5,Windows platform。GUI 跟 CLI 的 token 报告行为可能不同——这一点值得团队内部分析。
  3. zachcampbell (2026-07-04, 2438 字符) —— 用 5,161 sessions / 3,426 exact-516 events,自己的 gpt-5.5 比例 84.8%,跟原 issue 的 82% 一致;但他的 gpt-5.5 exact 516 / >=516 是 21.7%,比原 issue 的 44.0% 略低。两份独立 repro 的数字差异在采样窗口范围内,不是统计噪声。
  4. bluewhitep (2026-07-03, 1641 字符) —— 用 haowang02/codex-candy-eval 实跑 5 次,codex-cli 0.142.5 + gpt-5.5 + xhigh,结果:
    • Correct (2/5): reasoning_output_tokens = 6732 / 3624,都给了正确答案
    • Incorrect (3/5): reasoning_output_tokens = 516 / 516 / 516,全部给错
      token 数跟对错强相关——516 这一档基本是错答。
  5. hcoretheone (2026-07-04, 696 字符) —— $100 plan,5-shot 同样的 candy-eval,4/5 错答,1 个 token=516 还能给对(21),其它 4 个 token=516 的全错。说明 516 不一定 100% 错,但概率显著高于正常档位。

HN 评论里 ProofHouse 提了一句很到位的: "I almost never use it for reasoning anymore. It's not even in the same galaxy as far as actually taking out the thinking and using GPT-5.5 or even Claude and then coming back and giving it the reasoning."——这是用户已经在用 workaround 的真实信号:在 Codex 里跑 gpt-5.5 但把 reasoning 步骤外包给 Claude,等于实际绕过了 GPT-5.5 的内部推理路径。

五、目前还没完全搞清楚的几个点(局限与待验证项)

  1. 516 这个数字本身是不是 batching 边界(待验证) —— kleton 在 HN 评论里直接说 "Clearly they are batching reasoning inference in a few multiples of 512 tokens as a throughput optimization",这是一个 plausible 的工程解释(推理 batching 用 512 token 的整数倍做 KV cache 复用),但 OpenAI 没确认。如果是 batching 而非 truncation,问题性质完全不同:batching 是性能优化,truncation 是产品 bug。两者的修法、优先级、责任归属都不一样。判断标准:等 OpenAI 公开 token_count event 之外的 raw reasoning trace(目前 telemetry 不暴露),才能区分。
  2. GUI vs CLI 的 token 报告差异(坑点) —— gauss-nunu 实测 GUI 路径报告 reasoning_output_tokens = 0 频率异常高,CLI 路径没有。两种 client 走的可能是不同的 metrics pipeline,只盯 CLI 数据可能漏掉一半问题。判断标准:自己复现前必须分 GUI / CLI / subagent 三个路径分别统计,不能合并。
  3. codex-candy-eval 这个 benchmark 是不是 cherry-picked(不足) —— bluewhitep 和 hcoretheone 都用 haowang02/codex-candy-eval,这个 benchmark 只有 5 个 task,样本太小,token=516 跟错答的相关性在更大样本下是否成立?5 次跑出 3 错跟统计显著不是一回事。判断标准:在 candy-eval 之外还要在 SWE-bench / LiveCodeBench 上跑一次,确认不是 candy-eval 自己的 task 偏难导致。
  4. gpt-5.5 跟其它档位的 degradation 是否同步(待验证) —— issue 主体只列了 exact-516 ratio 的模型对比,没列每个模型的整体 pass rate。gpt-5.5 是 degradation 最大的还是其它模型也有?(用户的体感 zenapollo 说 "step jumps down in quality on an almost daily basis",但没拆模型)。判断标准:要看 model-level 的 pass@k 趋势才能判断是不是 gpt-5.5 特有问题还是全模型族都在降。
  5. Reddit 跟 GitHub issue 的舆论关系(不足) —— Lionel233 评论提他 6-28 在 Reddit /r/codex 已经发过类似分析,但反应平平;GitHub issue 出来才引起关注。判断标准:生产 issue 之前先用本地 telemetry 跑一遍数字,再决定发哪个平台;Reddit 的 traction 不代表 GitHub 的 traction,反之亦然。
  6. OpenAI 官方目前没回应的具体原因(还在调研) —— issue 截至 2026-07-04 还 open,53 条评论 + 106 reactions,labels = bug / model-behavior / rate-limits,但没有 OpenAI staff comment。可能是 (a) 内部还在调查,(b) 这个问题牵涉到 OpenAI 是否承认在生产环境做了 reasoning budget throttling,(c) 准备跟模型本身的下一版一起发。判断标准:不要在 issue 评论里 @ 任何 OpenAI 员工,等官方主动回应。
  7. vs Claude Sonnet 5 reasoning token 的对比(待验证) —— 用户已经在用 "Codex 跑 gpt-5.5 + 外部 Claude 跑 reasoning" 的 workaround,意味着 gpt-5.5 internal reasoning 已经不是用户首选。判断标准:把同一份 task 跑 (a) Codex + gpt-5.5 + xhigh,(b) 直接 Claude Sonnet 5 + extended thinking,对比 reasoning token 分布跟最终 pass rate,看 516 clustering 是 Codex 特有的还是 OpenAI 推理栈特有的。

六、跨文章引用 + 适用场景

跨文章引用:

  • 样例十 SK Telecom Mythos(2026-06-19) —— 跨境出口管制 + 私有 LLM 访问控制,跟 GPT-5.5 throttling 是不同问题但同一种关切:用户对闭源 LLM 的 telemetry 可见度。SK Telecom 案是"能不能用",GPT-5.5 案是"模型内部有没有按预期运转",两者都指向 LLM ops 需要自己保留本地推理 trace。
  • 样例十八 VibeThinker-3B(2026-06-23) —— 小模型 reasoning 论文,跟 516 clustering 是反向话题:小模型能把 reasoning 压进 3B 是因为 prompt 强制结构化 reasoning,OpenAI 的大模型反而可能因为内部 batching 而降低 reasoning 深度。这是 reasoning 模型设计哲学的两个极端。
  • 样例二十五 Bash4LLM+(2026-06-29) —— 零依赖 CLI wrapper + 本地 JSONL 扫描,跟本文 §三 的本地 telemetry 扫描方法同源:闭源模型 release 不能复现,但本地 telemetry 可以自己看。Bash4LLM+ 是把这种"本地优先"思路落到生产脚本层。

适用场景对照表:

场景 是否需要读 issue #30364
跑 Codex + gpt-5.5 + xhigh 做长 reasoning 必读,516 clustering 直接影响产出
跑 Codex + gpt-5.2 / 5.3-codex 系列 可选,exact-516 ratio = 0~0.34% 影响有限
用 Claude Sonnet 5 / GPT-5.4 + extended thinking 可选,不是 OpenAI 推理栈不受这个影响
自己写 Codex subagent + reasoning_model 路由 必读,建议在路由代码里加 516-clustering 检测
用 codex-candy-eval 复现 benchmark 必读,5 次跑里 3 错 = 复现条件已知

七、参考链接

  1. HN 原帖:https://news.ycombinator.com/item?id=48789428(63p / 7c / 作者 link 含 reddit cross-link)
  2. GitHub issue:https://github.com/openai/codex/issues/30364(53 comments / 106 reactions / labels: bug, model-behavior, rate-limits)
  3. 复现工具 codex-candy-eval:https://github.com/haowang02/codex-candy-eval
  4. 相关 issue #29353(gpt-5.5 xhigh short-circuits with reasoning_output_tokens=516 and wrong final_answer):https://github.com/openai/codex/issues/29353
  5. Reddit 早期讨论:https://www.reddit.com/r/codex/comments/1ugyvez/(Lionel233 6-28 发)
  6. Codex CLI telemetry 字段文档:~/.codex/sessions/<date>/rollout-<id>.jsonl 内的 event_msg.payload.type = "token_count" 事件(本会话实测)
posted @ 2026-07-05 07:10  Ninghg  阅读(161)  评论(0)    收藏  举报