Opus 5.5’s benchmark score rebounded; the latest run is 12 days old.

Call: mixed monitor movement, not evidence of a broad decline or deliberate nerf. BridgeBench’s 16 October results put all four published NerfBench series inside its 90–110% band. Claude Opus 5.5 rose 10.1 points from 95.7% on 9 October to 105.8% on 16 October. The composite includes correctness, output tokens, and cost; it does not establish what typical users experienced.

What the board shows

The BridgeBench results board says none of its four tracked series is outside the stated ±10% range. Its last displayed point is 12 days old on this review date. Its methodology says each tracked model is tested at least three times a week; the dates visible on the board do not show that cadence. The public record does not say whether this reflects unpublished sessions, incomplete sessions, or a change in testing. The board is not a real-time alert on 28 October.

What “power” counts

BridgeBench describes 50 private tasks, each run three times per session, for 150 attempts. The first session when tracking begins becomes the frozen 100% reference; the method does not show that this is the model’s actual release-day performance. Its headline combines 60% correctness, 20% output tokens, and 20% cost. A cheaper run can therefore raise the composite while task pass rate falls. Codex does not report cost, so the method reallocates weights to 75% correctness and 25% tokens. OpenRouter-reported cost is used for its API route, and Claude Code uses the CLI’s list-price figure.

The publisher says a result must be outside the 90–110% band in two complete, comparable sessions in a row before it publishes a confirmed movement. Its stated sampling illustration estimates about nine points of chance variation in either direction at 95% for a model with a 70% pass rate; it also says lower pass rates vary more. The public method does not show calibration for other baseline pass rates or dependence among repeat attempts on the same fixed tasks. The board publishes composite percentages, not individual correctness, token, or cost components, outputs, or session-completeness records, so outside readers cannot reproduce the displayed score.

What can be compared

The method locks provider, model, and effort within a series and stores fingerprints for the suite and prompts, adapter, provider/model, effort, runtime and CLI versions, output limit, timeout, concurrency, and retry limit. A changed profile is not compared with the old reference. However, the OpenRouter series uses default upstream routing and does not pin the upstream provider or temperature. The score is therefore a measurement of a selected served path, not an attribution to model weights alone. The overview describes a $10,000 pledge for future benchmarking; it does not report a verified expenditure.

Other changes are separate

Reader’s next check

If the request did not finish, save the error and timestamp and check the provider status record. If a task completed poorly, rerun a safe fixed task with the same prompt, product surface, model selection, effort, and context; save the final output and score correctness separately from tokens, price, and correction time. Treat the Opus score rebound as one narrow coding-suite signal, not a promise about every Opus conversation.

See the current evidence ledger · Read the comparison method · Return to the current answer