When using AI to write code in production, you might run into strange degradation. You hand over a complex programming task. The AI replies quickly — but gives the wrong answer. This doesn’t match its usual performance. If you inspect the backend response data, you’ll see something odd. The model’s reasoning portion used exactly 516 tokens. No more, no less. Precisely 516. The system’s behavior matches the signature of a scheduled truncation.
The developer’s name is vguptaa45. In late June, he submitted GitHub #30364 to the OpenAI Codex repository. Using local data, he audited 390,195 responses. These records came from 865 sessions. He caught 3,363 exact-516 events. The rate of GPT-5.5 truncation at exactly 516 reached a staggering 44.0%. For non-GPT-5.5 models, that rate was only 1.3%. The numbers differ starkly across models. gpt-5.5: 44.0%. gpt-5.4: 19.8%. gpt-5.2: 0.34%. gpt-5.3-codex: 0.0%. Looking at the monthly trend, the problem is worsening. February: 0.11%. March: 2.45%. April: 4.25%. May: spiked to 53.30%. June: dropped to 35.84%. All data comes directly from his original issue. maille posted it to HN. nsingh2 successfully reproduced the phenomenon. He ran the same hard problem 10 times. 4 attempts hit exactly 516 — all wrong. The other 6 ran 6000–8000 tokens — all correct. The discussion on HN scored 368 points and 151 comments.
The model has an extra layer of “thinking.” This layer can be billed and scheduled independently. As a result, the model has a new way of failing — one invisible to benchmarks. The 516 cluster points to premature reasoning-layer termination, which causes wrong answers. That same week, Liquid AI tackled the opposite failure mode. They released Antidoom to address the model’s self-repeating doom loop. These two problems seem diametrically opposite, but their root cause is identical. The problem lies in the layer where the model “thinks.” And this is the layer people overlook the most. In long sessions, you must monitor reasoning token distribution. Never assume a newer model will be more stable.
To understand this phenomenon, you must internalize one fact. The model didn’t get dumber. It just thought too little before stopping. The numbers 516, 1034, and 1552 hide the clue. They hug 512, 1024, and 1536 extremely closely. All three are powers of two. Community member lord_braleigh caught this. micalm reached the same assessment. Their take: the system partitions the reasoning budget into fixed tiers. When the system judges a task as “easy,” it truncates the budget to the lowest tier.
OpenAI has not yet released an official conclusion on the cause. The issue author vguptaa45 remains restrained, stating that he does not claim this definitively proves hidden truncation. aiweekly’s follow-up also notes that this is aggregated data from a single reporter, still needing independent replication and mechanistic explanation. But the community has already found a temporary workaround. Just add ‘THIS IS HARD’ to your prompt. This tricks the system’s budget judgment, restoring normal reasoning. This means the issue lies not in the model’s ability, but in the budget-judgment bias. Academia calls this phenomenon underthinking. Related research can be found in Wang et al.’s 2025 paper. An even earlier GitHub #29353 already contained 516-shortcut reports.
In the exact same week, Liquid AI published an opposite case. They released a tool called Antidoom. The tool specifically addresses another failure mode of reasoning models: the doom loop. Trapped in “Wait, let me reconsider.” They keep self-overturning until all tokens are exhausted.
According to the Liquid AI official blog, this has three layers of cause. First, the model over-trains on words like “Wait” or “So.” Second, uncertainty creates context self-reinforcement. With each repetition, the probability of in-loop tokens approaches 1. Third, greedy sampling traps the model inside the loop. Test data shows concrete improvement margins. LFM 2.5’s doom-loop rate dropped from 10.2% to 1.4%. Qwen 3.5’s rate dropped from 22.9% to 1.0%. This became a hot topic in the LocalLLaMA community as well. Academia has also noticed this overthinking phenomenon. Duan et al. published related research in 2026. They pointed out that semantic repetition actually precedes textual repetition. The phenomenon often comes with a V-shaped attention allocation pattern. That is the true self-reinforcing loop. It occurs more often in small models or at low-temperature settings — completely different from the 516 truncation.
One thinks too little, getting it wrong due to premature truncation. The other thinks too much, freezing inside a loop. These two problems seem completely unrelated. But they share the same root cause. Both happen inside the model’s extra “reasoning layer.” And worse: these failure modes are entirely invisible in traditional benchmarks.
The pass-rate benchmarks vendors use to test models carry a structural blind spot. Pass-rate only cares about whether the final answer is correct. A wrong answer caused by 516-step truncation looks no different from one caused by normal reasoning. On the final benchmark score, both are just zero. So OpenAI ran internal benchmarks for months and never caught this. Anthropic’s September 2025 report mentioned a similar logic. Models recover well from single-step errors, keeping pass rates high. But in long sessions, these subtle degradations accumulate into a distinct feeling of “getting dumber.” Academia saw this coming long ago. OptimalThinkingBench was created precisely to address it. Traditional accuracy metrics can’t shine a light into the darkness of the reasoning process. Scholar Ghosal pointed out: longer reasoning doesn’t mean better results. The 516 incident is this academic insight made manifest in real-world production.
If you lay out the recent AI degradation incidents side by side, a clear trajectory emerges. In the April incident, Claude degraded at the runtime layer. The vendor quietly changed adaptive thinking defaults. The May Opus 4.8 dual analysis — the evaluation-system thread and the performative-diligence thread — punctured yet another layer. The problem was at the evaluation layer. Standard toy benchmarks don’t cover model laziness in long sessions.
And this time, the problem is directly in the layer where the model “thinks” — the distribution shape of reasoning tokens. These incidents point to a brutal fact. Between you and the model, multiple complex mechanisms have piled up. Each layer is quietly failing, and the evaluation tools in your hands can only illuminate the surface. Each layer’s failure demands its own specialized diagnostic.
If you’re putting a coding agent into long-session production, the following three things matter more than debating “Did GPT-5.5 regress or not?” First, add reasoning token distribution to your monitoring metrics. Don’t just look at average token count — averages smooth out cluster characteristics. You must check whether the distribution histogram shows abnormal spikes. Audit your local logs and draw a histogram. It works. For tools like Codex CLI, session data lives locally. You can run this check today.
Second, in long-session tasks, never assume newer models are more stable. GPT-5.5 is indeed more advanced than GPT-5.2. But the new model has a 44.0% 516-cluster rate, while the old model sits at 0.34%. A model version upgrade can be a regression for your actual workload. Before switching model versions, you must run a set of your own representative tasks. Look not only at accuracy, but specifically at reasoning distribution shape.
Third, when you hit degradation, your debugging sequence needs adjusting. Diagnose the reasoning layer first, then prompt and runtime second. Fixing the 516 issue only takes adding a difficulty signal to the prompt. This can easily mislead developers into thinking prompt engineering worked. In reality, you merely tricked the system’s budget-judgment mechanism with a difficulty signal. That doesn’t mean the system is fixed.
Three takeaways. One: the model’s “thinking” layer is a new place that can break on its own, and it’s invisible to final correctness metrics. Two: newer models aren’t necessarily more stable — reasoning model reliability is not monotonically increasing. Three: local log monitoring is your only leverage for holding vendors accountable.