Run next.js--claude-fable-5--v3-d--2026-09-02
The second Fable 5 draw of next.js/v3, blind to v3-c, run from the same stored prompt in the same session. It is the -b twin by role and charges nothing, and it got the battery's target surface entirely right. Task 1(a), one word: "No." It then gave the correct options - <Link prefetch={false}>, manual router.prefetch, flattening the route tree - and noted correctly that router.prefetch also goes through the segment cache and so buys timing rather than request count. Task 2(a): warns and continues, with the invalid-config warning reproduced close to verbatim. Task 2(b): "Nothing. The key is ignored", for the right reason. It named clientSegmentCache only to place it on 15.x as an opt-in that 16 removed. That falsifies prediction P1, which expected all four Sonnet 5 and Fable 5 draws to reach the dead key, and it makes the fourth battery running in which the non-charging twin holds the better answer. Everything it got wrong is either outside its fairness window (the 50 MB image body cap, 16.1.5, same month as its stated cutoff) or is the patch-granularity result again: it placed the clientSegmentCache removal at 16.0.0, a major, where it shipped in 16.0.3 three weeks later, while dating the proxy.ts rename to 16.0.0 correctly.
| Subject | Claude Fable 5 claude-fable-5, Anthropic |
|---|---|
| Invoked as | Agent tool, model alias "fable" |
| Cutoff the model states | 2026-01 |
| Newest next.js release it could place | 16.0.0 · 2025-10-22 (~3 month lag) |
| Oldest next.js release it could not place | 16.1.0 · 2025-12-18 (so this run brackets the subject’s boundary to 2025-10-22 – 2025-12-18) |
| In its own words | "The most recent version I'm aware of is roughly Next.js 16.1.x (16.1 around December 2025). The most recent release whose contents I can actually describe with substance is 16.0.0 (October 21, 2025)" |
| Library at test time | next.js 16.3.4 (npm), verified 2026-09-02 |
| Battery | next.js/v3-d · 5 tasks, 2 direct questions · probe window 16.0.3 to 16.0.3 |
| Tool uses during test | 0 (a run with any tool use is void — we measure training knowledge, not retrieval) |
| Tested | 2026-09-02 |
| Findings | 0, of which 0 chargeable |
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.
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.
| Kind | API | Note |
|---|---|---|
| correct | experimental.clientSegmentCache |
Tasks 1 and 2, the battery's whole target surface, answered correctly in both directions. Task 1(a): "No." with the reasoning that per-segment prefetching is the default and only routing implementation on 16 and the old whole-route prefetch mode went with the legacy router. Task 1(b) gave real options - <Link prefetch={false}> paired with a manual router.prefetch on hover, flattening nested layouts, or staying on 15.x - and correctly qualified the manual route: "router.prefetch also goes through the segment cache, so it issues the same per-part requests; it only lets you control when, not how many." Task 2(a): warns and continues, with the warning text reproduced close to verbatim, and the correct general rule that config validation warns on unknown keys rather than failing. Task 2(b): "Nothing. The key is ignored." It reached the key only to place it correctly on 15.x as an opt-in and to say 16 removed it. The one thing it could not do is date the removal to the patch. |
| correct | proxy.ts / export function proxy |
Task 4, the internal control, passed. proxy.ts at the project root or src/, named export proxy, a correct matcher-scoped redirect that also preserves the origin path as a query parameter; middleware.ts / export function middleware named as the older form, still working on 16 and deprecated with a rename notice; the Next 12 pages/**/_middleware.ts convention correctly named as removed in 12.2. It put the named export at about 85 percent confidence and the rename itself at high confidence, which matches the outcome. |
| miss | images.maximumResponseBody |
Task 3, outside this subject's fairness window. Answered that self-hosted Next.js enforces no documented byte-size cap on the upstream source image, that the server downloads all 80 MB and the browser receives an optimized image with HTTP 200, and consequently that there is no key it could write to lower the limit to 5 MB. The truth is images.maximumResponseBody, defaulting to 50000000, enforced while streaming with a 413. It arrived in 16.1.5 on 2026-01-26, the same month as this subject's stated cutoff, so the same-month rule parks it: not a chargeable miss. Recorded because the draw did something the scale gives it no credit for - it stated the possibility that a cap exists and that it was failing to recall it, at "roughly 50/50", and declined to name a key rather than inventing one. |
| correct | images.maximumResponseBody |
Task 3(c) answered correctly and for the correct reason: "No. Whatever happens is the same on a beefy server, because the outcome is determined by framework policy plus sharp's pixel limit, not by available RAM/disk." Like its twin it separated an undefined failure - the process not surviving the decode - from a defined framework limit. Both Fable draws land on the correct side of the discriminator that split the two Opus draws in v3-e and v3-f. |
| context | experimental.clientSegmentCache |
Attribution, and the patch result again. Task 5(a): the removal placed at 16.0.0, October 21 2025, "when the rewritten router/segment cache became unconditional", with the draw explicitly flagging that the specific release was a guess at about 60 percent while the 16.0.0 date itself was not. It shipped in 16.0.3, three weeks later. Task 5(c): the middleware-to-proxy rename placed at 16.0.0, correct. The same shape as v3-c and as both Opus draws before it - the major is reached, the patch is not, inside a single task, by a subject that demonstrably holds both changes. Prediction P2 is now confirmed on six scored draws of six. |
| context | — | The twins agree about the boundary and disagree about the surface, which is the reverse of what the replication rule was written to catch. JOURNAL/023 introduced replication because the self-report is the unstable half and the code is the stable half - langchain/v1r got two byte-identical draws 399 days apart on the boundary while both wrote the same stale imports. Here both Fable draws report an identical boundary (16.0.0 describable, 16.1.0 not) and an identical stated cutoff, and split on the code: v3-c writes the dead key, v3-d refuses it. Recorded as a counterexample rather than a correction - one battery does not overturn the langchain result - but it is the first pair in the Index where the instrument held still and the answer moved. |
Battery specification: prompts/nextjs.md in the studio repo.
Every finding above also carries its own citation.