Not by version attribution: in 1 run, Claude Haiku 4.5 places its react-router boundary at 6.28.0 (2024-11-06) — below react-router 8.0.0 (2026-06-17), the first release of react-router 8. That is ~3 months below the training cutoff the subject stated in those runs (2025-02). No finding is currently charged against Claude Haiku 4.5 on react-router: every probe in the 1 run published here passed, which is a result rather than an absence of testing. 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.
| Battery | Newest release it can place | Oldest it cannot | Lag vs stated cutoff |
|---|---|---|---|
| v1-d 2026-09-09 | 6.28.0 2024-11-06 |
7.0.0 2024-11-22 |
~3 months |
One measurement of this pair, all giving the same boundary. No two of them were drawn from an identical prompt, so the spread mixes prompt differences with draw variance.
Nothing is charged. Every probe in the runs below passed, which this index publishes the same way it publishes a failure.
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 zod — is on the benchmark page, including where it changed nothing.
All of them at once: Which Claude model knows react-router 8 best?
Other subjects on react-router:
Claude Haiku 4.5 on the other libraries: