Does Claude Opus 5.5 know react-router 8?

Not by version attribution: in 3 runs, Claude Opus 5.5 places its react-router boundary at 7.9.0 (2025-09-12) — below react-router 8.0.0 (2026-06-17), the first release of react-router 8. That is ~9 months below the training cutoff the subject stated in those runs (2026-06). 2 findings are currently charged against Claude Opus 5.5 on react-router (1x S1 breaks-build, 1x S2 silently-wrong), each reproduced in a published run and checked against react-router's own release notes. Read the boundary precisely: it is the newest release whose contents the model can correctly attribute to that release, not the newest react-router feature it can use. Past it a model often writes working code with a newer API while naming the wrong release for it.

Answer class below, decided by one rule applied to every page of this kind: every measured boundary is below the first release of the major named in the question. Every figure below is read from the dataset at build time; nothing on this page is written by hand.

The measurements

BatteryNewest release it can placeOldest it cannotLag vs stated cutoff
v5 2026-09-27 7.9.0
2025-09-12
7.10.0
2025-12-02
~9 months
v6-a 2026-09-28 7.9.0
2025-09-12
7.10.0
2025-12-02
~9 months
v6-b 2026-09-28 7.9.0
2025-09-12
7.10.0
2025-12-02
~9 months

How repeatable is this?

3 measurements of this pair, all giving the same boundary. Of those, 2 came from the same stored prompt file, sent concurrently and blind: they agreed exactly.

react-router published 10 minor or major releases in the twelve months before this model’s stated cutoff, which is the scale a spread should be read against.

What Claude Opus 5.5 gets wrong about react-router

“Chargeable” means the change was published before this model’s own stated cutoff, so it had the opportunity to know it.

SeverityBeliefChanged inChargeableProof
S1breaks-build Builds the per-route cache decision on match.unstable_shouldCallHandler(), which react-router removed at 7.10.0 — on the current release every navigation throws a TypeError and no loader runs
dataStrategy (match.shouldCallHandler / match.shouldRevalidateArgs)
7.10.0
2025-12-02
yes run · source
S2silently-wrong Wires the client error tracker to unstable_onError on both <RouterProvider> and <HydratedRouter>, a prop react-router stopped recognising at 7.11.0 — the app renders clean and reports nothing
onError (HydratedRouter / RouterProvider prop)
7.11.0
2025-12-17
yes run · source

What to do about it

The react-router correction pack states what is true now for each corrected fact, with a primary-source citation, as markdown you can paste into a rules file (raw). What a correction pack measurably changed when one was tested — a pre-registered run on prisma and zod — is on the benchmark page, including where it changed nothing.

Runs

The same question, asked of the others

All of them at once: Which Claude model knows react-router 8 best?

Other subjects on react-router:

Claude Opus 5.5 on the other libraries: