What Claude Fable 5 gets wrong about next.js — battery v3-c, tested 2026-09-02

Run next.js--claude-fable-5--v3-c--2026-09-02

Summary

The Fable 5 half of next.js/v3, run 2026-09-02 after both Fable arms of the original battery died on an API-side safeguard error without emitting a token. The stored prompt was re-sent verbatim; nothing was reworded. This is the charging arm and it charges one finding: asked in one word whether per-part prefetching can be turned off, it answered "Yes" and wrote experimental: { clientSegmentCache: false }, a key removed in patch 16.0.3 on 2025-11-13, two months inside its own stated cutoff. Handed the same key back in task 2 it said the build accepts the config, and in task 5(a) it committed to the key still being recognised on current stable. What separates this draw from the Sonnet 5 draw that failed the same probe is that it did not assert a mechanism it lacked: it put the whole answer at about 60 percent, named the opposite branch explicitly, and reproduced the exact warning string the build would print if the key were gone - which it is. The finding is charged on the artefact under the code-vs-claim rule and the hedge is recorded with it. On the internal control it passed cleanly, naming proxy.ts exporting proxy and dating the rename to 16.0.0, which is right and is a major; the same draw could not reach a patch for the removal. Its twin v3-d, blind to this one, answered task 1 "No" and got the entire surface right, which falsifies the battery's first prediction. Both Fable draws read the same boundary this battery read in v1 and v2 - 16.0.0 describable, 16.1.0 not - so on this subject the boundary did not move between batteries or between twins.

SubjectClaude Fable 5 claude-fable-5, Anthropic
Invoked asAgent tool, model alias "fable"
Cutoff the model states2026-01
Newest next.js release it could place16.0.0 · 2025-10-22 (~3 month lag)
Oldest next.js release it could not place16.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 line I'm aware of is Next.js 16.1.x, from roughly December 2025, with patches possibly into January 2026. The most recent release whose contents I can actually describe with confidence is 16.0 (~October 21, 2025)"
Library at test timenext.js 16.3.4 (npm), verified 2026-09-02
Batterynext.js/v3-c · 5 tasks, 2 direct questions · probe window 16.0.3 to 16.0.3
Tool uses during test0 (a run with any tool use is void — we measure training knowledge, not retrieval)
Tested2026-09-02
Findings1, of which 1 chargeable
this run as JSON all next.js findings method

Findings

F1 · Answers "yes" and configures experimental.clientSegmentCache, a key removed in patch 16.0.3

S2silently-wrong · experimental.clientSegmentCache · removed · changed in next.js 16.0.3 (2025-11-13) · chargeable

Removed 2025-11-13, two months before this draw's stated cutoff of January 2026. Not back-filled from another run: the twin v3-d states the same cutoff independently and charges nothing, because it got the surface right.

What the model believes

Task 1(a), one word: "Yes." Task 1(b): "It is controlled by the clientSegmentCache flag ... Disabling it reverts to the older whole-route prefetch - one RSC payload request per link". Task 2(a): "the key is still recognised, so the build accepts the config". Task 2(b): "With false you get the legacy behaviour - a single prefetch per link carrying the route's RSC payload, duplicating shared-layout data across links". Task 5(a): "I believe experimental.clientSegmentCache is still recognised on current stable (it flipped default rather than disappearing)".

What it wrote
experimental: { clientSegmentCache: false }
What works on next.js 16.3.4
experimental: { prefetchInlining: true }
Impact

The team asked how to collapse a prefetch burst into one request per link and gets a config file that builds, deploys and does nothing. An unrecognised key under experimental warns and is dropped rather than failing the build, so the file reads as applied and the burst continues unchanged. The reader is also told the reverted behaviour will duplicate shared-layout data across links, which is a specific and false description of what their app will now do.

Scope note

The hedge is part of the record and is not deducted from the charge. This draw put the answer at "moderate (~60%)", wrote out the branch in which it is wrong, and reproduced the warning the build actually prints - "Invalid next.config.ts options detected: Unrecognized key(s) in object: 'clientSegmentCache' at experimental" - as the counterfactual. It is charged because the task demanded a one-word verdict before any explanation, the verdict was "Yes", and the configuration written under it is inert. The code-vs-claim rule (prompts/nextjs.md v1) scores the artefact a reader would copy. Compared against next.js/v3-a, which failed the same probe while asserting the key "is a recognized key under experimental in the config schema Next.js validates against", this is the same wrong answer delivered with the uncertainty intact - the same severity, because the failure mode of a silently inert config does not depend on how confident its author was.

Verified against

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
correctproxy.ts / export function proxy Task 4, the internal control, passed cleanly. Named proxy.ts at the project root with the named export proxy, wrote a correct matcher-scoped redirect, named middleware.ts / export function middleware as the older form, and said correctly that it still works on 16 and warns. It also correctly identified the Next 12 per-directory _middleware.ts as a still older form that was removed in 12.2. Under JOURNAL/030(b) this is what makes the run's attribution answers readable at all: the subject holds the change, so its dating of it measures attribution rather than absence.
missimages.maximumResponseBody Task 3, and the reason it is not charged against this subject. Answered that the browser receives a resized AVIF or WebP with HTTP 200 and that no documented byte-size cap on the source file exists in self-hosted Next.js. The truth is a fixed 50 MB body cap that throws a 413 while streaming. images.maximumResponseBody arrived in 16.1.5 on 2026-01-26, the same month as this subject's stated cutoff, so it sits outside the fairness window under the same-month rule and is not a chargeable miss - the battery fixed this reading in advance for v3-a and v3-c both. Two details worth keeping: the draw declined to invent a key or a number, saying so explicitly - "I cannot honestly write a 5 MB config, and I won't invent one" - and it reached instead for sharp's 268 megapixel input limit and the keys experimental.imgOptMaxInputPixels and experimental.imgOptTimeoutInSeconds. Those two key names were not verified this session and the Index makes no claim about them either way.
correctimages.maximumResponseBody Task 3(c), the fixed-policy versus resource discriminator, answered correctly and for the correct reason despite the wrong answer in (a) and (b): "No. Neither limit is resource-adaptive: the pixel cap is a decompression-bomb guard and the timeout is fixed config, so more RAM/disk changes nothing about the defined behaviour." It then separated an undefined failure - the process being OOM-killed mid-decode - from a framework limit. This is the sub-question next.js/v3-e and v3-f landed on opposite sides of; both Fable draws land on the correct side.
contextexperimental.clientSegmentCache Attribution, and the patch result holds for a fourth draw. This draw dates the middleware-to-proxy rename to 16.0.0, ~October 21 2025, which is right to the release and is a major it demonstrably holds. Asked in the same task for the release at which clientSegmentCache stopped being recognised, it committed to the key still being recognised and named 16.0.0 as the fallback if it were wrong. The removal is 16.0.3. Across two subjects and three batteries no draw has yet attributed any change to a patch release, and this draw shows the split inside one task: the major it holds is dated correctly, the patch is unreachable even as a hypothetical.
context— The boundary did not move for this subject, which is the contrast the battery could not draw from Sonnet 5. Fable 5 x next.js now has four readings across three batteries - v1, v2-d, and both v3 twins - and all four are identical: 16.1.x known by name, 16.0.0 (2025-10-22) the most recent release whose contents it can describe, nothing describable at 16.1.0 (2025-12-18). Sonnet 5 on the same library reads 15.0.0, 15.0.0, 15.3.0 and 15.5.0 across the same three batteries. JOURNAL/033 left open whether v3 moved Sonnet's boundary or whether v1 and v2 happened to agree; this run does not settle that, but it does show the instrument holding perfectly still on a second subject over the same three batteries, so whatever moves Sonnet's reading is not something every battery does to every subject.
context— The arm ran. Both Fable arms of this battery failed on 2026-09-02 with an API-side safeguard error (invalid_request, [reasoning_extraction]) before emitting a token, were retried once each and failed identically, and were recorded in JOURNAL/033 as void rather than as runs. The stored prompt at prompts/sent/nextjs-v3.txt was re-sent byte-identical in a later session and both arms completed without incident. The earlier failure is therefore transient and infrastructural, and is not a property of this prompt or this subject. No wording changed between the void attempt and this run.

Open questions from this run

Sources

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