One Hacker News commenter says their Fable workflows went from a "~85%" success rate to "~10%" about two weeks ago. Another says Opus 5.5 is "suddenly fumbling basic tool calls" and failing to finish tasks even at high effort. A third says nothing happened at all: "It's just a new summarizer, the model and performance itself is unchanged."
So is Claude Opus 5.5 nerfed? I read everything Anthropic has published since launch (the Claude Code changelog, the status page, the API docs) and put it next to the HN thread that grew out of this post, submitted as "Is Opus 5.5 nerfed? Thinking patterns changed on November 3." I couldn't find anything in that record showing the model got dumber. What I found was a pile of default changes that make it behave differently, and the worst one is this: if you set effortLevel in ~/.claude/settings.json before Opus 5.5 shipped, Claude Code ignores it on Opus 5.5 and runs it at medium.
What Anthropic actually changed around November 3
There is no announcement of a new Opus 5.5 checkpoint. The model ID is still claude-opus-5-5, the same one Claude Code made the default Opus model in 2.1.280 on September 22. What did ship is a run of Claude Code releases that touch effort, thinking and context. From the changelog:
| Version | Date | Change that could feel like a "nerf" |
|---|---|---|
| 2.1.311 | Oct 26 | ultrathink now runs its turn at xhigh effort on Opus 5.5 |
| 2.1.312 | Oct 27 | Automatic model switches after a flagged message now also cover custom model names (CLAUDE_CODE_DISABLE_REFUSAL_FALLBACK=1 turns them off) |
| 2.1.314 | Oct 30 | Idle compaction in VS Code and the desktop Code tab: a 200K+ token conversation left idle gets summarized |
| 2.1.316 | Oct 31 | New CLAUDE_CODE_SUBAGENT_EFFORT env var for subagent effort |
| 2.1.317 | Nov 3 | Subagents on a different model "use that model's saved effort level or its default, instead of the session's effort level" |
| 2.1.318 | Nov 4 | Removed the 2.1.288 fix that kept earlier thinking when resuming old conversations; "that thinking can now be dropped" |
Look at the November 3 row. Say your main session runs Fable 5.1 at high and your subagents run on Opus 5.5. Before 2.1.317 they inherited high. From that day on, unless you saved a level for Opus 5.5, they get Opus 5.5's default, which is lower than most people assume.
The status page has seven incidents between October 25 and November 9. All seven describe elevated errors; the Nov 8 one is titled "Degraded performance", but its text is about errors on Fable 5.1. None mentions output quality, and only one (Oct 25) names Opus 5.5 at all.
Opus 5.5 defaults to medium effort and ignores your old effortLevel
If I had to bet on one thing behind most of the thread, it's this. Per the effort docs, most Claude models default to high. Opus 5.5 and Haiku 5.5 default to medium. The migration guide spells it out: "Set effort explicitly: the default is medium, where Claude Opus 5's is high."
Claude Code makes it worse. The settings reference says a top-level effortLevel in ~/.claude/settings.json "keeps applying where it applied before, on Opus 5, Fable 5.1, and earlier models. Opus 5.5 and models released after it ignore it and start at their own default."
None of this landed in November. It shipped with Opus 5.5: the 2.1.280 changelog entry (September 22) says a level saved before /effort became per-model no longer applies to newly released models. Project, local and managed settings still apply effortLevel to every model; it's the user-level file that gets skipped.
So if you put "effortLevel": "high" in your user settings back in the Opus 5 days and never touched it again, you've been running Opus 5.5 at medium the whole time while believing you were on high. I'm not surprised it feels worse.
The "thinking looks different" complaint is mostly display
On Opus 5.5 you can't turn thinking off. Adaptive thinking is always on, and thinking: {"type": "disabled"} or a manual budget_tokens gets rejected with a 400. On top of that, thinking.display defaults to "omitted", so thinking blocks come back empty unless you ask for "summarized". The short notes the model writes between tool calls also now arrive as thinking blocks, which are empty by default (migration guide).
In Claude Code, showThinkingSummaries defaults to false, and the docs say plainly that "Redaction changes only what you see, not what the model generates." If what bothers you is a different-looking summary or a collapsed stub, that's the summarizer you're looking at, and it tells you nothing about the model's output. The HN commenter who blamed the summarizer has a point, and so does listedb: "the change in display adds to the feel."
Reports no config change explains
Some of the thread doesn't fit any config change I could find:
- jdcasale's 85% to 10% drop is a big number, but it's on Fable, it's one person's workflow, and there's no repro attached. They say themselves they might be projecting.
- At least four commenters say their usage limits burned much faster than usual, and one says their 5-hour limit ran out in minutes and took 50% of their weekly Fable limit with it. Higher effort or more thinking would do that, but so would a metering bug.
- Asmod4n had a session running for "around 50 days" that started producing garbage, while a fresh session was fine. That one I'd put on 2.1.318 dropping old thinking on resume, plus compaction, before blaming the weights.
Nobody from Anthropic replied in the thread. One commenter pointed out that sites tracking model performance over time don't show these nerfs. That's not proof either way, because a provider could detect benchmark traffic and treat it differently, as a couple of others speculated. Which is why I'd rather run my own test than keep arguing from vibes.
How to check if Claude Opus 5.5 got worse for you
The idea is to pin everything first and only then measure.
1. Pin the model ID instead of the alias
The opus alias "updates over time" per the model config docs. Use the full ID:
claude --model claude-opus-5-5 --effort high 2. Save effort per model, where Opus 5.5 reads it
In ~/.claude/settings.json:
{ "model": "claude-opus-5-5", "modelSettings": { "claude-opus-5-5": { "effortLevel": "high" } }, "showThinkingSummaries": true } If you use subagents, the surest fix for the November 3 change is to set effort in each subagent's definition. CLAUDE_CODE_SUBAGENT_EFFORT=high (2.1.316+) also helps, but the changelog only promises it applies "when nothing else names one". Want to rule out a fallback model sneaking in? Set CLAUDE_CODE_DISABLE_REFUSAL_FALLBACK=1.
3. Run a 10-prompt regression set and keep the results
Pick ten tasks from your real work that have a checkable answer: a failing test to fix, a SQL query with a known result, a refactor that has to compile, a bug you already solved. Store the prompt and the pass condition. Then run them headless against the API with the effort set explicitly:
#!/usr/bin/env bash # regress.sh: run each prompt in prompts/*.txt 3x at a fixed model + effort MODEL=claude-opus-5-5 EFFORT=${1:-high} OUT="runs/$(date +%F)-$EFFORT" mkdir -p "$OUT" for f in prompts/*.txt; do for i in 1 2 3; do jq -n --arg m "$MODEL" --arg e "$EFFORT" --rawfile p "$f" '{ model: $m, max_tokens: 64000, output_config: {effort: $e}, thinking: {type: "adaptive", display: "summarized"}, messages: [{role: "user", content: $p}] }' | curl -s https://api.anthropic.com/v1/messages \ -H "x-api-key: $ANTHROPIC_API_KEY" \ -H "anthropic-version: 2023-06-01" \ -H "content-type: application/json" \ -d @- > "$OUT/$(basename "$f" .txt)-$i.json" done done # output tokens per run, for comparing against last week for r in "$OUT"/*.json; do echo "$(basename "$r") $(jq -r '.usage.output_tokens // .error.message' "$r")" done The 64k max_tokens comes from the migration guide's advice for xhigh and max, since thinking counts against it. Each prompt runs three times, because one sample tells you nothing. Score pass/fail by hand or with a check script, and keep the token counts next to it. Do it today, before the next "nerfed" thread, and again whenever it feels off. If pass rates hold and token counts hold, it's you or your config. If pass rates drop at the same pinned model and effort, you've got a real regression and a repro to attach to a bug report, which beats another comment saying "it feels dumber."
My take: Anthropic made this mess easy to fall into. Changing the default to medium, ignoring your old effortLevel, hiding thinking by default and changing subagent effort inheritance in a point release is a lot of silent behavior change. Most of it is documented, in places nobody reads. That's a fair thing to be angry about, but it's a different complaint from "they swapped the weights."
Have you noticed Opus 5.5 behaving differently since early November, and on what kind of task? And before you answer: what was your effort actually set to?
