What Claude Fable 5.1 gets right about react-router — battery v1-a, tested 2026-09-09

Run react-router--claude-fable-5-1--v1-a--2026-09-09

Summary

The charging half of the test arm, and it charged nothing. It reproduced both of the battery's designed failures — generatePath stated in the present tense as returning the pattern unsubstituted, and a full instrumentation setup built on three unstable_-prefixed names that have zero occurrences in 8.3.1's shipped dist — and then disqualified itself on the cutoff question, offering "late 2025" as the effective cutoff for this library. That question used the STANDING plain wording, which is the wording JOURNAL/056 measured as the one under which this subject affirms, so the repudiation is new evidence about the instrument rather than a known cost. Boundary 7.10.0 / 7.11.0, which falsifies the battery's loud-library prediction. Its one unhedged recommendation was right and is the correction the Index will ship: href() substitutes a suffixed param at every release tested.

SubjectClaude Fable 5.1 claude-fable-5-1, Anthropic
Invoked asAgent tool, model alias "fable"; prompt sent verbatim from prompts/sent/react-router-v1.txt. Pre-registered as the CHARGING half of the test arm, duplicated at birth with `v1-b`. It is the only subject for whom this battery had more than one live fact — and it disqualified itself on direct question (b), so all three of its reproduced failures are chargeable misses.
Cutoff the model statesnot stated
Newest react-router release it could place7.10.0 · 2025-12-02 (~6 month lag)
Oldest react-router release it could not place7.11.0 · 2025-12-17 (so this run brackets the subject’s boundary to 2025-12-02 – 2025-12-17)
In its own words"The highest version I believe exists is somewhere in the 7.1x line — I am fairly sure 7.13.0 shipped in early 2026, and I would not be surprised by a few more after it. The most recent release whose contents I can actually describe is 7.9.0 (September 2025), with only partial knowledge of 7.10.0 (roughly November 2025). I do not have knowledge of a released React Router 8.0.0 with contents I can describe." BRACKET PROVENANCE — The two direct questions disagree by one release and the disagreement is recorded rather than resolved silently. Question (a) says the most recent release whose contents it can describe is 7.9.0, "with only partial knowledge of 7.10.0". Question (c) — the designated ruler, asked last — lists 7.10.0 WITH contents at "partial confidence" (unstable_instrumentations, unstable_pattern on loader/action args) and then names 7.11.0 as "the first release I know only as a version number". This is HARNESS.md § Grade the rungs, disclose the cell you do not have arriving from the hedged side: an arm that qualifies a rung and then describes it. The bracket is taken from (c), the ruler question, so stops_at is 7.10.0 and the gap opens at 7.11.0. NOTHING IN THIS RUN TURNS ON THE CHOICE: the battery's prediction is falsified under both readings (7.10.0 is 2025-12-02 and 7.9.0 is 2025-09-12; the falsification threshold is 2025-12-15), and every charge is barred by the cutoff repudiation regardless. Its content attribution for 7.10.0 is also approximately right and slightly early by the Index's own bisect — unstable_pattern is present from 7.9.5 (JOURNAL/108), which under the Index's minor-granularity convention belongs to the 7.9 line.
Library at test timereact-router 8.3.1 (npm), verified 2026-09-09
Batteryreact-router/v1-a · 4 tasks, 4 direct questions · probe window 7.12.0 to 7.15.0
Tool uses during test0 (a run with any tool use is void — we measure training knowledge, not retrieval)
Tested2026-09-09
Findings0, of which 0 chargeable
this run as JSON all react-router findings method

Findings

None. Every task in this battery produced code that works on the current release, and every direct question was answered correctly. A run with nothing to charge is kept in the Index at full weight: it is the control that makes the other runs mean something, and it is the evidence for what this model does not need correcting on. What the subject actually said is recorded below.

What it got right, and near misses

Recorded so the run cannot be read as a hit list. A model that is right for an obsolete reason is recorded here, not as a finding.

KindAPINote
missgeneratePath LF1, reproduced and uncharged. Asked for the concrete URL, it wrote generatePath(BOOK_JSON, { id }) with the comment // intended: "/books/7.json" and then answered (b) in the present tense: "The current generatePath is segment-based ... :id.json is one segment and does not match that regex, so the segment is passed through untouched. As I remember the implementation, the call above returns /books/:id.json unchanged for "7" — and it does not throw." It said it "would not ship the above without a test". Executed this session: react-router@8.3.1 returns "/books/7.json"; @7.11.0, the release below the boundary, returns "/books/:id.json". The belief is 7.11.0's behaviour stated as current, seven months after 7.12.0 fixed it — the same failure v1-c is charged S2 for. Barred here by the cutoff repudiation only. Charged nowhere: the only arm licensed to charge in this battery is a DIFFERENT SUBJECT (Claude Opus 5, v1-c), and a miss is only ever charged on another arm of the same subject. (Direct question (b) offered a library-scoped substitute date as the effective cutoff, which HARNESS.md reads as a repudiation.) [chargeable miss — the arm licensed to charge states a cutoff below the release under test; absent from the finding count]
missinstrumentations LF3, reproduced and uncharged, and it is the one failure in this battery whose artifact does NOT compile. Task 2's shipped code is import type { unstable_Instrumentation } from "react-router", a handler reading info.unstable_pattern, and three wiring sites — export const unstable_instrumentations = [timing], <HydratedRouter unstable_instrumentations={[timing]} /> and createBrowserRouter(routes, { unstable_instrumentations: [timing] }). Counted in the shipped dist/ this session: unstable_Instrumentation appears 24 times at 7.11.0 and 7.14.2 and 0 times at 8.3.1; unstable_instrumentations 156 times and 0; unstable_pattern 164 / 148 and 0. The names are gone, not aliased (LF3), so the type import fails to resolve, the option is silently ignored and info.unstable_pattern is undefined. Under the battery's pre-registered mapping this is S1 breaks-build. It is not an invention: every identifier it used is real below 7.15.0, which is what makes it a stale prior rather than a confabulation. (Cutoff repudiated; and no other arm in this battery is above 7.15.0's park line, so this failure is charged nowhere.) [chargeable miss — the arm licensed to charge states a cutoff below the release under test; absent from the finding count]
imprecisionurl Task 3 reads the URL with new URL(request.url) and never mentions the normalised url loader argument (LF2). Working code and an imprecision under the additive-API rule — it did not claim no such argument exists. Its (b) answer contains a claim the Index CANNOT adjudicate and must not pretend to: "Client-side navigations hit the server as /books/7.data?_routes=.... The router strips the .data suffix and the _routes param before calling your loader, so you should see the clean URL." That is LF2's second clause, in the opposite direction, and it is the exact clause data/react-router/facts.json records as never executed — createStaticHandler does not produce a client data request, so the bisector has no probe for it and neither does this session. Recorded as an open question, not as a finding in either direction.
correcthref THE ANSWER THAT WOULD HAVE BEEN THE BATTERY'S BEST FINDING IF IT HAD GONE THE OTHER WAY, AND IT IS RIGHT. Having declared generatePath unusable for this pattern, it recommended the typed helper instead — "use the typed href() helper, which does a /:param substring replace rather than whole-segment matching" — and gave href("/books/:id.json", { id: "7" }); // "/books/7.json". Executed this session at three rungs: href returns "/books/7.json" at 7.11.0, 7.14.2 AND 8.3.1. The recommendation is correct at every release tested, including the ones below LF1's boundary where generatePath really did fail. v1-c reached the opposite conclusion about the same helper on the same prompt and was wrong.
correct— The attribution anchor holds. Task 4 produced a working framework-mode scaffold — the @react-router/dev/vite plugin, react-router.config.ts typed with Config, app/routes.ts with index/route, a route module using Route.LoaderArgs/Route.MetaArgs/Route.ComponentProps from ./+types/, and the rootDirs typegen wiring — and dated 7.0.0 to "Nov 2024" (actual 2024-11-22). The arm is well above the floor and its boundary answer is readable.
context— The poison rung produced no false positive. 7.19.0 has never been published and this arm declined it — "Unknown. At the ~monthly cadence, 7.19 would fall around mid/late 2026, at or past my effective knowledge; I cannot confirm it was published" — while asserting 7.9.0, 7.5.0 and 7.13.0 as real. 7.13.0 IS real (2026-01-23) and it dated it "roughly February 2026", one month late and above its own stated gap, which it flagged as undescribable content. It abstained on both 8.x rungs. So the rung licenses reading this arm's boundary: nothing in its version answers is confabulated.
context— THE PREDICTION IS FALSIFIED ON THIS ARM, and under both readings of its bracket. Predicted: a boundary later than this subject's 2025-12-15 median across the seven measured libraries — react-router being the loudest library the Index has probed, and JOURNAL/015's mechanism holding that a loud library looks newer to a model than a quiet one. Measured: 7.10.0 (2025-12-02) on the ruler question, 7.9.0 (2025-09-12) on question (a). Both are below the threshold. This subject's boundary on react-router is EARLIER than its median across seven other libraries, not later.

Open questions from this run

Sources

Battery specification: prompts/react-router.md in the studio repo. Every finding above also carries its own citation.