Did Claude Opus 5.5 Quietly Get Dumber? What the Data Actually Shows

What's going on

Since early November, accusations have been piling up that Anthropic secretly degraded Claude Opus 5.5, or "nerfed" it, as the community puts it. It started with a November 7 post by developer Shane Melaugh that racked up more than 450,000 views. Two days later came the Hacker News thread "Is Opus 5.5 nerfed? Thinking patterns changed on November 3" with 817 points and 511 comments. According to i10x, there were at times around 2,700 posts in 24 hours. As of November 11, Anthropic hasn't commented. We found no sign of a changed model on either the status page or the changelog.

Our take: much of the supposed evidence doesn't measure the model at all. It measures a separate model that writes the thinking summaries, changed settings in the Claude Code coding tool, or plain random variation. That said, real degradations without a new model do happen. Anthropic has admitted it twice.

Four measurements side by side

What definitely changed on November 3: the summaries

Opus 5.5 doesn't show you its raw chain of thought. According to Anthropic's thinking documentation, the summary is created by a different model than the one you queried, and the thinking model never sees it. You're still billed for the full thinking tokens.

Melaugh's chart shows a jump starting around 6 p.m. UTC on November 3. After that, about 61 percent of thinking blocks started with "I'm…", while phrases like "I should" dropped to about 11 percent. Theo Browne found the same pattern in his logs: "I'm…" rose from 27 to 61 percent, and "I should / I need to" fell from 47 to 13 percent. His accounts switched at different times between October 30 and November 4, though, one of them at 6 p.m. UTC on November 3. Theo's conclusion:

Anthropic appears to be rolling out a change to the reasoning summarizer account by account. I'm seeing no signs of degraded capabilities.

Melaugh himself concedes in his chart's footer that the data shows a behavioral change in the summaries, not changed weights. Another user, @argofowl, analyzed 67,000 messages. For him, tool calls per message stayed at 1.06, and failed calls actually dropped from 1.9 to 1.8 percent.

The contradiction on thinking tokens remains unresolved. Melaugh measures the median before the first tool call, Theo the mean per response. As aitoolranked points out, both numbers can be true at the same time. From the public information, it's unclear whether Melaugh's analysis counted billed tokens or visible summary text.

The hidden lever: effort

The effort setting determines how much compute goes into thinking. According to Anthropic's docs, a request with no setting runs at "medium" on Opus 5.5, while on Opus 5 it ran at "high". Anthropic claims Opus 5.5 on medium is at least as good as Opus 5 on high in its own tests. That's a vendor claim.

Claude Code has several pitfalls here. Since version 2.1.280, effort is stored per model. That means an older effortLevel in your user settings file no longer applies to Opus 5.5, as a dev.to post shows. According to the official changelog, version 2.1.317 shipped on November 3 (on npm, according to aitoolranked, on November 2 at 23:57 UTC). Since then, subagents, helper instances that take on subtasks, running on a different model use that model's own stored or default effort instead of the session's effort. Version 2.1.318 also allows older thinking to be discarded when resuming very old conversations.

LiveNerf's validation shows how much this matters. Medium instead of high cost 4.2 points of accuracy and 26 percent of tokens there; low cost 8.3 points and 62 percent. Melaugh reports a bug that Opus 5.5 on high couldn't fix in over three hours, which Gigazine says amounted to 160 interactions. With "xhigh", it got there in five.

Our take: if you silently fall back to medium, you'll experience exactly that "dumber" model without anything changing on Anthropic's servers. Melaugh's measurement ran on high, though, and he says his CLI version stayed the same. So this doesn't fully explain his data.

The re-run from Japan

The only controlled before-and-after test so far comes from Qiita author suwa_nobu. He happened to collect measurements on November 2 and repeated the runs on November 11 at the same time of day with the same Claude Code version, 2.1.316. The task: generate a PR description and a README section in English and Japanese from a diff file, under three conditions with three repetitions each. That came to 36 runs per day and tool. He compared the days with a permutation test, a statistical method that checks how often a difference that large would arise just by shuffling the data.

The results: - On both days, not a single one of the four or six core facts was missing. - Bold headings without a rules file rose from 6 to 8 out of 12 runs. At p=0.68, that's not significant. - Median cost per run rose from $0.126 to $0.133 (p=0.013), and the total from $4.41 to $4.66. That's 5.7 percent more.

We recalculated the cost breakdown using Anthropic's list prices:

The total of roughly $0.135 matches the measured median. Output accounts for only about 20 percent. So the extra cost could just as easily come from caching as from more thinking. The author says so too.

Two caveats matter. First, feature flags, meaning server-side toggled features, can't be disabled in 2.1.316. The relevant environment variable CLAUDE_CODE_DISABLE_FEATURE_FLAGS only arrived in 2.1.319. So the tool wasn't fully frozen. Second, the author didn't record thinking tokens on November 2, which means the very metric in dispute is missing. The control test is revealing: with OpenAI's Codex, runtime rose significantly from 6 to 9.5 seconds (p<0.001), and missing core facts went from 12 to 15. Day-to-day fluctuations happen elsewhere too.

Trackers and the strongest single finding

LiveNerf answers 78 fixed questions from GPQA, MMLU-Pro and math competitions every day, with a pinned Claude Code version 2.1.280 and Opus 5 as a control model. Windows 1 through 3 (through November 2) came in at +0.7, −1.5 and +2.8 points versus launch week. That's no change. The decisive window 4, from November 3 to 12, is still running. The detection limit is 6.6 points per window. A fallback from high to medium (−4.2 points) might therefore go unnoticed, and so might a swap to Opus 5. The repo admits as much. It also only measures a single Max account, so it could miss a change rolled out account by account.

BridgeBench NerfBench consistently put Opus 5.5 within the normal band of 90 to 110 percent of its launch score, most recently at 105.8 percent on October 16. We couldn't find any November figures.

The most serious evidence is GitHub issue #105112. In it, one user's correction rate rose from 5.2 percent (5,738 responses) to 25.4 percent (900 responses). But the jump falls between October 18 and 19, two weeks before November 3. In the cleanest variant, which only counts first responses, it's 5.2 versus 15.4 percent, then 17.0 percent in early November. Among other things, the script counts responses that start with "you're right". On October 20, the author added a rule to his CLAUDE.md telling the model to admit its own mistakes. That could skew the rate. However, pure corrections by the user also rose, from 3.3 to 20.2 percent. Anthropic still hasn't responded.

Why "no finding" doesn't mean "nothing happened"

Anthropic has publicly admitted twice that Claude got worse without new weights. In its September 2025 postmortem, the company described three infrastructure bugs. One was a routing error that, at its peak on August 31, misrouted 16 percent of Sonnet 4 requests. Around 30 percent of Claude Code users were affected at least once. There was also a TPU misconfiguration and a compiler bug in token selection. Anthropic's own tests hadn't caught any of it. Back then, Anthropic wrote:

We never reduce model quality due to demand, time of day, or server load.

In its April 23, 2026 postmortem, Anthropic admitted to three product changes. The first was lowering the default effort from high to medium, in hindsight "the wrong tradeoff." The second was a caching bug that wiped old thinking on every turn. The third was a system prompt that dragged code quality down by 3 percent. The kicker: a change in how thinking was displayed masked the caching bug in most internal sessions at the time. Anthropic promised to explain product decisions via @ClaudeDevs and GitHub going forward. We found no such explanation for a per-account change to the summarizer.

How to check whether your model is slipping

1. Check effort: In Claude Code, /effort status and /model show what's actually running. Set effort explicitly per model, and for subagents use CLAUDE_CODE_SUBAGENT_EFFORT=high if needed.
2. Pin your tooling: Stick to a fixed Claude Code version while testing. From 2.1.319 on, you can disable feature flags with CLAUDE_CODE_DISABLE_FEATURE_FLAGS.
3. Build a mini test set: Take about ten real tasks with verifiable results and run each one three times, using the fixed model ID claude-opus-5-5 instead of an alias. Run each batch at the same time of day. The dev.to post mentioned above includes a ready-made script.
4. Log the right numbers: Record success rate, usage.output_tokens_details.thinking_tokens (the billed thinking tokens) and the model that actually responded. The summary text tells you nothing about how much thinking happened.
5. Use your own history: The transcripts under ~/.claude/projects (.jsonl) show retries and failed tool calls before and after a cutoff date.
6. Be patient with the stats: Over 30 runs, one or two extra failures are often just chance. Report real outliers via /bug with the request ID.

The bigger picture

Only one thing is proven so far: around November 3, the style of the visible thinking summaries changed, apparently account by account. Those summaries come from a different model. It's also established that Opus 5.5 runs with a lower default effort and that Claude Code updates have changed the effort logic several times. None of the four measurements shows that Opus 5.5 itself got worse. The Japanese re-run finds the same quality at roughly 6 percent higher cost, for reasons that remain unclear.

Our take: most of the "proof" on social media is a reading from the wrong instrument. Still, users have a point. Anthropic changes visible parts of its product without announcement, which makes it hard to tell summary, tooling and model apart. By its own April promises, an explanation is overdue. Things will become clearer at the earliest when the LiveNerf window closes on November 12. Whether issue #105112 points to a real server-side problem remains open as long as Anthropic stays silent.