The Codex issue report is a nice reminder that the interesting failures don’t show up in a single trace. The claim: across ~390k logged responses, GPT-5.5 Codex disproportionately stops at exactly 516 reasoning tokens, with echo spikes at 1034 and 1552. GPT-5.5 is 19% of the responses but 82% of the exact-516 events, and its exact-516-to-≥516 ratio sits around 44% against roughly 1% for everything else. The reporter also charts the clustering climbing from near-zero in February to past 50% by May, while overall reasoning intensity drifts down.

What makes this an LLM-ops story and not a curiosity is where it’s visible. One agent run ending short looks like the model just being terse. You only see a cliff at a suspiciously round number after you’ve aggregated hundreds of thousands of traces and bucketed the reasoning-token counts. That’s an observability property, not a model property — and most teams running agents in production log latency and cost but never histogram the hidden reasoning budget, so a truncation this sharp would sail straight through their dashboards.

It’s still an unconfirmed allegation — no maintainer response, no root cause, and a linked report (#29353) suggesting the 516-token runs correlate with wrong answers on harder tasks. That correlation is the part I’d want instrumented before trusting any of it: reasoning-length distribution joined to task success, not vibes. If a fixed-value cutoff really is silently capping the reasoning pass, it’s the kind of regression a normal eval suite misses because per-example accuracy averages it away.

The HN thread has the usual split between “obvious quantization or budget artifact” and “collection bug in the logging harness.” Both are testable. So here’s the question I’d put to anyone running a Codex-style loop at scale: are you even logging the reasoning token count as a distribution, or only the mean?