Is Opus 5.5 Nerfed? No Confirmed Drop Yet; Check Effort First

As of October 21, 2026, there is no confirmed nerf of Claude Opus 5.5. Anthropic has published nothing about its output quality since the September 22 launch, and the two public trackers both read inside their noise range: BridgeBench's Nerf Bench had it at 105.8% of launch on October 16, and LiveNerf's first 10-day window came back "no change." Neither tracker can rule out a small drop, though. LiveNerf can't see changes under about 6.6 points.

What is documented are several things that make Opus 5.5 answer worse in a specific setup without anyone touching the model. Its default effort is medium, while Opus 5 ran at high and the launch benchmarks ran at max. An old saved effort setting in Claude Code does not carry over to it. Security or biology content can silently move your session to Opus 4.8 or Opus 5. Claude Code bugs that dropped earlier thinking or redid finished work were fixed between versions 2.1.287 and 2.1.293. And many "nerfed" posts are really about usage limits draining, which is a different problem.

If it still feels worse after you rule those out, compare runs of a fixed set of tasks over time instead of comparing memories. The script and test output below show how.

Five checks before you call Opus 5.5 nerfed

Start by deciding whether the complaint is about limits or about answers. For answers, effort is the first thing to check. The first four rows cover every documented cause of an Opus 5.5 session behaving worse; the fifth is for whatever is left.

The sections below explain each check and what the result means.

What the Opus 5.5 nerf trackers show as of October 21, 2026

Both public trackers say the same thing so far: no change larger than their own noise. They measure differently, so it helps to know what each number means before quoting it.

BridgeBench Nerf Bench: 105.8% of launch power on October 16

BridgeBench's Nerf Bench page for Claude Opus 5.5 reruns a fixed set of 50 private coding tasks, three attempts each, single response, no tools. Its readings so far:

BridgeBench treats 90% to 110% of launch as normal variance, and a reading outside that band has to hold for two sessions before it calls a nerf. The 94.2% on October 2, which circulated on X as evidence of a nerf, was inside the band. The biggest drop between two tests was 9.6 points, from October 1 to October 2. As of October 16, none of the models it tracks (Opus 5.5, Sonnet 5.5, GPT-6 Astra, GPT-6.1 Sol) was outside the band.

Three details matter before you lean on any single reading, all from the Nerf Bench methodology post:

• "Power" is not pass rate. It is 100 × (0.6 × pass rate + 0.2 × output-token score + 0.2 × cost score) against the first session. A shorter, cheaper answer can move power even when the pass rate is the same.
• BridgeBench says that for a model passing 70% of attempts, "chance alone moves power by up to about 9 points either way, 95% of the time."
• The method promises at least three sessions a week, but the Opus 5.5 page shows seven tests in 25 days, and it does not say which provider or effort level its Opus 5.5 series uses.

LiveNerf: "no change" in window 1, earliest verdict around October 24

LiveNerf is an open-source tracker that runs once a day through headless claude -p on a Max plan, with Claude Code pinned at 2.1.280, effort high, and no tools, MCP servers or CLAUDE.md. Its panel is 78 questions that Opus 5.5 gets right only some of the time (GPQA Diamond, MMLU-Pro, competition math, AIME), screened from 2,336. Opus 5 runs alongside as a control.

Its first comparison window (days 11–20, starting October 4) came back at +0.7 ± 1.8 points against the launch-week baseline, decision "no change." As of October 20, it had 27 of 30 days collected. Its rule needs two consecutive windows to call a change, so the first possible verdict is around October 24, 2026.

LiveNerf states its own limits plainly. It detects changes of about 6.6 points per 10-day window. In validation, swapping Opus 5 in for Opus 5.5 was not distinguishable at 99% confidence (−3.8 ± 6.3 points). So "no change" means no change this instrument can detect, not proof that nothing changed.

Where to check for newer readings

Both trackers update after this date. Read the BridgeBench page for the latest power reading and the LiveNerf README's Results table for the window-2 decision. A single new low reading on BridgeBench is not a nerf by its own rule unless the next session also falls outside 90%–110%.

Did Anthropic nerf Opus 5.5? What Anthropic has said

Anthropic has said nothing about Opus 5.5 output quality as of October 21, 2026. The platform release notes, the Claude apps release notes and the Claude status page have no entry about it. The only status incident naming Opus 5.5 is "Elevated errors for Claude Opus 5.5" on October 6, which lasted 19 minutes and was about errors, not answer quality.

Two first-party statements set the boundaries of what "nerf" could mean:

• A model ID keeps the same weights. The Anthropic model IDs and versions page says Anthropic "does not update the weights or configuration of an existing model ID." The same page adds that the serving infrastructure around a model, including "the request router, safety classifiers, and sampling logic," can change, and that infrastructure updates occasionally "produce minor differences in observable behavior."
• Past quality drops were real, but came from infrastructure and Claude Code changes. The September 2025 postmortem traced weeks of complaints to three infrastructure bugs and stated: "We never reduce model quality due to demand, time of day, or server load." The April 23, 2026 postmortem admitted that Claude Code's default effort had been lowered from high to medium on March 4 ("This was the wrong tradeoff") and reverted on April 7. It also covered a thinking-clearing bug and a verbosity line in the system prompt. "The API was not impacted."

Those two cases say nothing about Opus 5.5 directly. They do show where earlier drops were found: in the serving layer and in Claude Code, and only after weeks of reports. That is where the checks below look.

Usage limits draining faster is a separate problem from a nerf

Many "Opus 5.5 got nerfed" posts are about limits, not answers. The most viral one, on October 20, 2026 ("Hey Claude users, bad news Opus 5.5 just got nerfed.", over 700,000 views), attached a screenshot of the Usage panel: session limit 95% used, weekly limit 41% used. The replies were about usage draining fast. Nothing in it shows a worse answer.

On October 11, Boris Cherny, who leads Claude Code at Anthropic, replied on X to a user asking whether Max 20x limits had been cut: "no changes on our end," and asked for the output of claude -p /usage (his reply on X). He was talking about usage limits, not model quality.

To see where your usage goes, run this in a terminal:

claude -p /usage

On Claude Code 2.1.306 with a Max subscription, it prints the current session and weekly percentages, then a section headed "What's contributing to your limits usage?" for the last 24 hours and 7 days. That section lists request and session counts, suggestions such as "Start fresh when you switch tasks · run /clear," and the skills, subagents, plugins and MCP servers taking the largest share. The wording may differ in other versions. Inside an interactive session, /usage shows the same meters.

If the problem is limits, Claude Code Usage Limits: Check, Audit, and Reduce Token Usage walks through reading that output and cutting usage. For what each plan includes, see Claude Usage Limits by Plan: What 5x and 20x Actually Multiply. The September 22 limit reset and price changes are covered in Claude Opus 5.5 Pricing and Limit Reset: What Each One Changes.

Opus 5.5 defaults to medium effort, but the launch benchmarks ran at max

If answers feel shallower than at launch, check effort first. It is the largest documented setting that changes how much Opus 5.5 thinks.

• API: Anthropic's What's new in Claude Opus 5.5 page says "The default effort is medium. A request that omits effort runs at medium; on Claude Opus 5 it ran at high."
• Claude Code: the Claude Code model configuration docs give high as the default on every model that supports effort, except Opus 5.5, Sonnet 5.5 and Haiku 5.5, which default to medium.
• Launch charts: the footnote on the Claude Opus 5.5 launch page says "all Claude Opus 5.5 results use adaptive thinking at max effort."

So the model in the launch charts thought at max. The model in your terminal thinks at medium unless you changed it. That gap alone can make launch-week impressions and daily use feel different.

An old saved effort setting doesn't apply to Opus 5.5

This catches people who set high or xhigh for Opus 5 and assume it carried over. In Claude Code, "a top-level effortLevel in your user settings file doesn't count for Opus 5.5." That key is the older format /effort wrote before levels were saved per model. It still applies to Opus 5 and earlier, but Opus 5.5 starts at medium until you pick a level for it with /effort or the /model picker. The 2.1.280 changelog entry that added Opus 5.5 made this change.

Check and set it inside Claude Code:

/effort status
/effort high

For one session from the command line, or for every session through the environment:

claude --effort high
export CLAUDE_CODE_EFFORT_LEVEL=high

On the API, send effort explicitly on each request instead of relying on the default.

How much does medium effort cost you in quality?

A few points on hard tasks, by every published measurement:

The Anthropic figure was described as directional, not a guarantee. A few points on a benchmark can still feel like a different model on the tasks where it lands, which are the hard ones. If your work is mostly hard debugging or long refactors, try high for a day before concluding the model changed. Claude Sonnet 5.5 vs Opus 5.5: When Half the Price Really Saves covers when the extra effort is worth its cost.

Check whether Opus 5.5 actually answered: safety fallback to Opus 4.8 or Opus 5

Opus 5.5 runs safety classifiers. When one flags a request, Claude Code re-runs it on another model: cybersecurity-flagged requests go to Opus 4.8, and biology-flagged requests go to Opus 5. Three details from the Claude Code model configuration docs make this easy to mistake for a nerf:

• The session stays on the fallback model. "After a fallback, the session continues on the fallback model. To return to your original model, run /model."
• It can happen before you type anything unusual. "Fallback can trigger on the first request of a session … because the first request carries workspace context such as your CLAUDE.md content and git status." A repo containing security or biology material can trip it on that context alone.
• Effort carries over. A session at Opus 5.5's default medium that falls back to Opus 4.8 stays at medium, although Opus 4.8 defaults to high.

Claude Code shows a notice in the transcript when it switches. If you missed it, run /model to see and reset the current model. To test whether your CLAUDE.md, skills, MCP servers or hooks trip the classifier, start with:

claude --safe-mode

That disables those customizations. Git status and directory names are still sent. If you'd rather decide each time, run /config and set Switch models when a message is flagged to Ask each time.

For scripted checks, the JSON output names the model that answered. This was run with Claude Code 2.1.306 on October 21, 2026:

claude -p "Reply with OK" --model opus --output-format json \
  | python3 -c 'import json,sys; d=json.load(sys.stdin); [print(k, v.get("provider"), "thinking:", v.get("thinkingTokens")) for k, v in d.get("modelUsage", {}).items()]; print("fallback_credit:", d.get("usage", {}).get("fallback_credit"))'

On that run, modelUsage was keyed by claude-opus-5-5 with provider firstParty, and fallback_credit was empty. A different model name there means something other than Opus 5.5 answered. Run it from the project directory you actually work in, because the workspace context is what can trigger the fallback. Even this one-line prompt wrote 26,297 cache-creation tokens with default tools loaded, about $0.21 at list price. On a subscription that comes out of your limits, not your wallet.

Security research, capture-the-flag work and biology-adjacent codebases trigger fallback often. Anthropic's docs call this "expected routing for these domains, not an account flag." On the API, a refused request carries its category in stop_details.category.

Claude Code bugs fixed in 2.1.287–2.1.293 that looked like a dumber model

Several Claude Code fixes since the Opus 5.5 launch describe exactly the symptoms people post as a nerf: forgetting earlier reasoning, losing context after a resume, redoing finished work. From the Claude Code changelog, with npm release dates:

If you were on an older build during the early-October complaints, some of what you saw could have been one of these. Check with claude --version. The changelog lists no system-prompt change to response length in this period, the kind of change the April 2026 postmortem described.

Long sessions also change behavior on their own. Since 2.1.299 (October 14), a conversation over 200K tokens left idle for about 54 minutes is compacted, so the model continues from a summary instead of the full history. If Opus 5.5 seems to forget details after a break, that is the likelier reason. Start a fresh session with /clear when you switch tasks, and use /context to see what fills the window. For compaction failures by exact error message, see Claude Code Error Compacting Conversation: Fix by Exact Message.

How to test Opus 5.5 for a nerf yourself

If the first four checks come back clean and it still feels worse, the only way to know is to run the same tasks, with the same settings, on different days, and compare the results. Memory of how good it was last week is not a measurement. Neither is re-running one prompt once, because the same prompt gives different answers from run to run.

A useful check holds these constant:

• The model and effort: pass --model and --effort explicitly, so defaults can't change underneath you.
• The harness: no tools, MCP servers, slash commands or session history, and the same Claude Code version. LiveNerf's README warns that "a changed harness looks exactly like a changed model."
• The grading: automatic tests, not your impression of the answer.
• What actually answered: log the model name from modelUsage on every run, so a fallback can't hide in the data.

A fixed-task script for Claude Code

The script below sends three small Python tasks to Claude Code, grades each answer against fixed tests, and appends one JSON line per run with the model that answered, the effort, pass/fail, output and thinking tokens, list-price cost and duration. It needs Python 3 and Claude Code 2.1.306 or later, logged in. It executes the code the model writes, so run it in an empty scratch directory.

#!/usr/bin/env python3
"""Fixed-task drift check for Claude Code (claude -p).

Runs the same small, auto-graded coding tasks with a pinned model and effort,
and appends one JSON line per run: date, requested model, model actually used,
effort, pass/fail, output and thinking tokens. Rerun it later (same tasks, same
flags) and compare the lines instead of comparing memories.

Usage: python3 nerf_check.py --model opus --effort high --repeat 2 --log runs.jsonl
"""
import argparse, json, re, subprocess, datetime, traceback

TASKS = {
    "intervals": {
        "prompt": (
            "Write a Python 3 function merge_close(intervals, gap) that takes a list of "
            "[start, end] integer pairs (start <= end, any order) and an integer gap >= 0. "
            "Merge intervals that overlap or whose distance is <= gap (distance = next.start - prev.end). "
            "Return a sorted list of [start, end] lists. Empty input returns []. "
            "Output only one ```python code block, no explanation."
        ),
        "tests": [
            ("merge_close([], 0)", []),
            ("merge_close([[5,7],[1,3]], 0)", [[1,3],[5,7]]),
            ("merge_close([[5,7],[1,3]], 2)", [[1,7]]),
            ("merge_close([[1,10],[2,3],[11,12]], 1)", [[1,12]]),
            ("merge_close([[1,1],[3,3],[6,6]], 2)", [[1,3],[6,6]]),
            ("merge_close([[0,0]], 5)", [[0,0]]),
        ],
    },
    "duration": {
        "prompt": (
            "Write a Python 3 function parse_duration(s) that converts strings like '1h30m', '2d', '45s', "
            "'1h 5m 3s', '-15m', '1.5h' into an integer number of seconds. Units: d, h, m, s (lowercase only). "
            "Spaces between parts are allowed. A leading '-' negates the whole value. Decimal numbers are allowed; "
            "round the final total to the nearest integer with round(). Each unit may appear at most once and units "
            "must appear in the order d, h, m, s. Raise ValueError for an empty string, unknown units, repeated "
            "or out-of-order units, a number without a unit, or any other text. "
            "Output only one ```python code block, no explanation."
        ),
        "tests": [
            ("parse_duration('1h30m')", 5400),
            ("parse_duration('2d')", 172800),
            ("parse_duration('1h 5m 3s')", 3903),
            ("parse_duration('-15m')", -900),
            ("parse_duration('1.5h')", 5400),
            ("parse_duration('0.5s')", 0),
            ("_raises(lambda: parse_duration(''))", True),
            ("_raises(lambda: parse_duration('5m1h'))", True),
            ("_raises(lambda: parse_duration('5m5m'))", True),
            ("_raises(lambda: parse_duration('10'))", True),
            ("_raises(lambda: parse_duration('3w'))", True),
            ("_raises(lambda: parse_duration('1H'))", True),
        ],
    },
    "roman": {
        "prompt": (
            "Write a Python 3 function roman_strict(s) that converts a Roman numeral string to an int, accepting "
            "only canonical (standard modern) forms for 1..3999 in uppercase. Reject non-canonical forms such as "
            "'IIII', 'VV', 'IC', 'XM', 'IIX', 'MMMM', 'VX', 'LC', 'DM', 'IL', empty string and lowercase by raising "
            "ValueError. Output only one ```python code block, no explanation."
        ),
        "tests": [
            ("roman_strict('MCMXCIV')", 1994),
            ("roman_strict('MMMCMXCIX')", 3999),
            ("roman_strict('XLIX')", 49),
            ("roman_strict('CDXLIV')", 444),
            ("_raises(lambda: roman_strict('IIII'))", True),
            ("_raises(lambda: roman_strict('IC'))", True),
            ("_raises(lambda: roman_strict('IIX'))", True),
            ("_raises(lambda: roman_strict('MMMM'))", True),
            ("_raises(lambda: roman_strict('VX'))", True),
            ("_raises(lambda: roman_strict('XCX'))", True),
            ("_raises(lambda: roman_strict('CMC'))", True),
            ("_raises(lambda: roman_strict('xiv'))", True),
            ("_raises(lambda: roman_strict(''))", True),
        ],
    },
}


def _raises(fn):
    try:
        fn()
    except ValueError:
        return True
    except Exception:
        return False
    return False


def grade(code, tests):
    ns = {"_raises": _raises}
    try:
        exec(code, ns)
    except Exception:
        return 0, len(tests), "exec error: " + traceback.format_exc(limit=1).strip().splitlines()[-1]
    ok = 0
    fails = []
    for expr, want in tests:
        try:
            got = eval(expr, ns)
        except Exception as e:
            got = f"<{type(e).__name__}>"
        if got == want:
            ok += 1
        else:
            fails.append(f"{expr} -> {got!r}")
    return ok, len(tests), "; ".join(fails)[:400]


def run_one(task, model, effort, timeout):
    cmd = ["claude", "-p", TASKS[task]["prompt"], "--model", model, "--effort", effort,
           "--output-format", "json", "--tools", "", "--strict-mcp-config",
           "--disable-slash-commands", "--no-session-persistence"]
    p = subprocess.run(cmd, capture_output=True, text=True, timeout=timeout, stdin=subprocess.DEVNULL)
    d = json.loads(p.stdout)
    m = re.search(r"```(?:python)?\n(.*?)```", d.get("result", ""), re.S)
    code = m.group(1) if m else d.get("result", "")
    ok, total, fails = grade(code, TASKS[task]["tests"])
    used = d.get("modelUsage", {})
    name = next(iter(used), None)
    mu = used.get(name, {}) if name else {}
    return {
        "time": datetime.datetime.now().isoformat(timespec="seconds"),
        "task": task, "model_requested": model, "model_used": list(used.keys()),
        "provider": mu.get("provider"), "effort": effort,
        "passed": ok == total, "score": f"{ok}/{total}", "fails": fails,
        "output_tokens": mu.get("outputTokens"), "thinking_tokens": mu.get("thinkingTokens"),
        "cost_usd_list": d.get("total_cost_usd"), "duration_ms": d.get("duration_ms"),
        "fallback_credit": d.get("usage", {}).get("fallback_credit"),
    }


if __name__ == "__main__":
    ap = argparse.ArgumentParser()
    ap.add_argument("--model", default="opus")
    ap.add_argument("--effort", default="high")
    ap.add_argument("--repeat", type=int, default=2)
    ap.add_argument("--tasks", default=",".join(TASKS))
    ap.add_argument("--log", default="runs.jsonl")
    ap.add_argument("--timeout", type=int, default=300)
    a = ap.parse_args()
    for _ in range(a.repeat):
        for t in a.tasks.split(","):
            try:
                row = run_one(t, a.model, a.effort, a.timeout)
            except Exception as e:
                row = {"time": datetime.datetime.now().isoformat(timespec="seconds"), "task": t,
                       "effort": a.effort, "error": f"{type(e).__name__}: {e}"[:300]}
            with open(a.log, "a") as f:
                f.write(json.dumps(row) + "\n")
            print(json.dumps(row))

Save it as nerf_check.py and run it at the effort you normally use:

python3 nerf_check.py --model opus --effort high --repeat 2 --log runs.jsonl

Each run is one fresh claude -p call with tools, MCP servers, slash commands and session saving turned off, so your CLAUDE.md and skills don't vary between days. Run it again on later days with the same flags and the same Claude Code version, then compare pass rates and thinking tokens across dates.

What the script showed on October 21, 2026

The script ran on October 21, 2026, on Claude Code 2.1.306 on macOS with a Max subscription: Opus 5.5 at --effort low and --effort high, two runs of each task, 12 runs in total.

Every run reported claude-opus-5-5 from firstParty with no fallback. On the duration task, high used about 3.5 times the thinking tokens of low (an average of 992.5 against 282.5) and took about 17–18 seconds against about 10. All 12 runs together came to about $0.29 at list price, drawn from subscription limits.

That result says nothing about whether Opus 5.5 got worse. Every run passed at both effort levels, which means these three tasks are too easy to show a difference. A task the model always passes can't reveal a drop, and neither can one it always fails. This is the same reason LiveNerf screened 2,336 questions down to 78 that Opus 5.5 gets right only sometimes. One machine, one day and two runs per cell is a demonstration of the method, not a benchmark.

To make the script useful for your own work:

1. Replace the tasks with ones Opus 5.5 sometimes fails. Take real problems from your codebase where it passed some days and failed others, and write tests for them. Keep candidates that pass roughly half the time across several runs and drop the rest.
2. Keep everything else fixed. Use the same effort, the same Claude Code version (turn off auto-update while you compare), and the same tasks and tests.
3. Run enough samples. With a handful of tasks, a pass rate can swing widely from chance alone. BridgeBench needs 150 attempts per session and still allows about 9 points of noise. Compare several days, not two runs.
4. Watch tokens as well as pass rate. LiveNerf found that lowering effort shows up in output tokens before it shows up in accuracy. A steady fall in thinking tokens at the same effort setting is worth noting even if the pass rate holds.

If the pass rate on tasks that used to pass about half the time drops and stays down across several days, with the same version, effort and model name in every log line, you have something worth reporting, with the logs to back it up.

Opus 5.5 nerf FAQ: Reddit, quantization, Opus 5 and Fable 5.5

Is the "Opus 5.5 nerfed" Reddit consensus right?

Reddit threads such as "Confirmed: Opus 5.5 has been nerded" have hundreds of comments, mostly agreeing, but the evidence in them is anecdotal: a phrase the model keeps repeating, a prompt that went better last week. The tracker numbers don't back them up so far. The complaints also came in waves. The first was launch week, when the medium default was new. The second, October 1–3, overlaps the Claude Code thinking-loss fixes and BridgeBench's 94.2% reading. The third, on October 20, was led by a usage screenshot.

Is Opus 5.5 quantized now?

No public evidence shows that. Anthropic's model ID policy says the weights and configuration of an existing model ID are not updated. Infrastructure such as routing and sampling can change, and has caused real drops before, but no document, status incident or tracker reading points to such a change for Opus 5.5 as of October 21, 2026.

Is Opus 5 better than Opus 5.5?

Not by any clear margin on these trackers. LiveNerf could not tell Opus 5 and Opus 5.5 apart at 99% confidence (−3.8 ± 6.3 points for Opus 5). Opus 5 also defaulted to high effort while Opus 5.5 defaults to medium, so comparing them at defaults compares two effort levels as well as two models.

Is Opus 5.5 cheaper than Opus 5?

Per token, yes: $4 input and $20 output per million tokens, which Anthropic says is 20% less than Opus 5. Anthropic's claim that it costs 40% less on typical workloads is "at default settings," and the default effort is now medium instead of high. Claude Opus 5.5 Pricing and Limit Reset: What Each One Changes has the full price table.

Will Opus 5.5 be nerfed before Fable 5.5?

Posts on X link a perceived nerf to an upcoming Fable 5.5, but that is speculation. Nothing from Anthropic connects the two. A model ID's weights are not updated after release, so the checks above apply whatever comes next.

Does this apply to Opus 4.6?

The causes overlap, but the defaults and fallback models differ. For the older model, see Claude Opus 4.6 Got Worse? How to Diagnose Thinking, Context Loss, and Routing Problems in 2026.