Does Claude Sonnet 5 know react-router 8?

Not by version attribution: in 5 runs, Claude Sonnet 5 places its react-router boundary at 7.0.0 (2024-11-22) and 7.3.0 (2025-03-06) — below react-router 8.0.0 (2026-06-17), the first release of react-router 8. That is ~10 to ~13 months below the training cutoff the subject stated in those runs (2026-01). 1 finding is currently charged against Claude Sonnet 5 on react-router (1x S1 breaks-build), 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
v2-c 2026-09-10 7.0.0
2024-11-22
7.1.0
2024-12-20
~13 months
v3-a 2026-09-22 7.0.0
2024-11-22
7.1.0
2024-12-20
~13 months
v3-b 2026-09-22 7.0.0
2024-11-22
7.1.0
2024-12-20
~13 months
v4-a 2026-09-23 7.3.0
2025-03-06
7.6.0
2025-05-08
~10 months
v4-b 2026-09-23 7.3.0
2025-03-06
7.6.0
2025-05-08
~10 months

How repeatable is this?

5 measurements of this pair, giving 2 different boundaries — 104 days apart, 5 releases apart. Of those, 4 came in 2 groups: the draws inside a group were sent the same stored prompt file, concurrently and blind, and each group had its own file. All 2 groups agreed exactly.

react-router published 12 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 Sonnet 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 Writes the whole middleware and context surface under its pre-7.9.0 unstable_ spellings — unstable_createContext, unstable_RouterContextProvider, the unstable_middleware route key and unstable_getContext — none of which react-router has exported since 7.9.0
middleware / createContext / RouterContextProvider / getContext
7.9.0
2025-09-12
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 Sonnet 5 on the other libraries: