What Claude Opus 5 gets wrong about next.js — battery v3-e, tested 2026-09-02
Run next.js--claude-opus-5--v3-e--2026-09-02 · self-test: the subject is the operator
Summary
The arm that was supposed to be a repeat and was not. Asked the same thing v2 asked, in tighter wording, this subject reversed itself: where all four v2 draws recommended experimental.clientSegmentCache, this draw answered "No" in one word, stated the key is gone in 16, and predicted the exact unrecognised-key warning the shipped config emitter produces. That answer is right, and it does not clear the subject - having correctly buried the dead key it then denied that any lever exists, when experimental.prefetchInlining (16.2.0) does precisely what the task asked for. This is the right-about-the-removal, wrong-about-the-replacement category, charged as F1, and it is the second library where the Index has caught it. Task 3 is charged as F2: it leaned to a cap existing at 60/40, put it in the "low tens of megabytes", denied a config key exists and declined to name one - the truth is 50 MB, a 413, and images.maximumResponseBody. On the internal control it named proxy.ts and dated the rename to 16.0.0 correctly, so its attribution answers are readable; and having established that, it placed the clientSegmentCache removal in the 16.0.0 major when it shipped in the 16.0.3 patch. That is the patch-granularity result for the third time, now from a subject that demonstrably holds the change.
Subject
Claude Opus 5 claude-opus-5, Anthropic
Invoked as
Agent tool, model alias "opus"
Cutoff the model states
2026-05
Newest next.js release it could place
16.0.0 · 2025-10-22 (~7 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 release whose contents I can actually describe is 16.0, published around 21 October 2025 ... For 16.1 (roughly December 2025) my recall is partial and I would not want to assert specifics."
Library at test time
next.js 16.3.4 (npm), verified 2026-09-02
Battery
next.js/v3-e · 5 tasks, 2 direct questions · probe window 16.1.5 to 16.2.0
Tool uses during test
0 (a run with any tool use is void — we measure training knowledge, not retrieval)
Published 2026-03-18, two months before this draw's stated cutoff of May 2026, which it accepted. Not probed as a finding by v2: v2's task 8 charged the dead key this draw correctly rejects, and never reached the question of what replaced it.
What the model believes
Task 1(a), one word: "No". Task 1(b): "There is no config key, no <Link> prop, and no runtime API that says 'give me one whole-tree prefetch response per link' any more." It then offered five alternatives - prefetch={false}, a hand-rolled intent-delay wrapper, flattening the route tree, an argument that the team's premise is wrong, and pinning to 15.x - and closed with "high (~85%) that there is no supported off switch on 16".
What it wrote
<Link href="/a/b/c" prefetch={false}>Go</Link>
What works on next.js 16.3.4
experimental: { prefetchInlining: true }
Impact
The team asked for one prefetch request per link. There is a config flag that does exactly that, and they are told it does not exist, then handed a client component that delays prefetching, advice to restructure their layouts, and a suggestion to pin an old major. Every one of those is real work; the supported answer is one line. This is the failure mode the capability probe exists to catch - the removal is known, the replacement is not, so the subject argues from the gap rather than reporting it.
Scope note
prefetchInlining is still flagged experimental at 16.3.4. The finding is the denial that any lever exists, not a claim that a stable API was missed.
The new experimental.prefetchInlining option bundles all segment data for a route into a single response, reducing the number of prefetch requests to one per link.
Published 2026-01-26, four months before this draw's stated cutoff. The probe was rewritten for this battery because v2's version of it was void - it said "default image configuration" while handing over a remote src, and three of four draws answered about the remotePatterns allowlist instead. This version states the whole config file and stipulates that remotePatterns matches.
What the model believes
"My belief is that the cap is a fixed constant in the low tens of megabytes - if forced to a single figure I would say on the order of 10 MB" and "I do not believe there is a documented, stable images.* key that lowers it. I specifically decline to invent a key name here." It leaned to a 400 status at 60/40. The real answer is 50 MB, a 413, and images.maximumResponseBody.
What it wrote
images: { loader: 'custom', loaderFile: './image-loader.ts' } // plus an /api/img route doing a HEAD content-length check
What works on next.js 16.3.4
images: { maximumResponseBody: 5_000_000 }
Impact
The one-line config the task asked for is replaced by a custom loader, a route handler, a HEAD request per image and an acknowledged race ("a hostile origin can lie"). The refusal to invent a key name is the right instinct and is recorded as such; the charge is on the denial that the key exists, which sends a reader who could have set one option down a path that reimplements the optimizer's own check less well.
Scope note
Verified in the published packages, not executed against a live 80 MB fetch. The 413 and the 50 MB constant are read from the shipped optimizer and the shipped default config.
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(a) and 2, and the reason this battery is not a repeat of v2. Every draw of v2 recommended experimental.clientSegmentCache; this draw refused it - "The thing that used to control it (experimental.clientSegmentCache) is gone" - answered task 2(a) with "It prints a warning and continues", reproduced the unrecognised-key warning almost verbatim, and answered 2(b) "Nothing" with the correct mechanism: "in 16 the segment cache is the router, there is no other code path, and no code reads that key any more." Correct on every part. Whether the reversal is knowledge or wording is the open question below.
correct
middleware.ts / proxy.ts
Task 4, the internal control, passed cleanly: proxy.ts exporting proxy, with middleware.ts named as the older spelling and correctly described as still working with a deprecation warning. Task 5(c) then dated the rename to 16.0.0, 21 October 2025, correct to the release. This subject holds the change and can place it in the major, which is what makes its failure on 5(a) readable as an attribution result rather than a knowledge gap.
miss
experimental.clientSegmentCache
Task 5(a), the patch-granularity probe. Dated the clientSegmentCache removal to "Next.js 16.0.0, approximately 21 October 2025" and rated it moderate confidence, explicitly weighing and rejecting the alternative that it survived into 16.0 and was deleted later. It shipped in 16.0.3, three weeks after 16.0.0. The subject holds the change - it described the key's removal correctly in tasks 1 and 2 - and still cannot reach the patch. Not charged: the version-attribution S4 rule charges recency against the subject's own boundary, and this is the battery's designed attribution reading rather than a separate belief failure.
correct
images.maximumResponseBody
Task 3(c), answered correctly and for the correct reason while the rest of task 3 was wrong: "If a cap applies it is a fixed byte constant compiled into the optimizer, not a function of os.freemem() ... a 256 GB machine gets the same 400 as a 512 MB one." Its blind twin v3-f answered the same sub-question the other way, calling machine-dependence "the diagnostic signature of no hard limit". The discriminator worked: it separated the fixed-policy world from the resource world, and the twins landed on opposite sides of it.
Open questions from this run
Is the reversal on clientSegmentCache knowledge or wording? v2's task 8 asked whether reducing prefetch requests was configurable "and if so, how? Write whatever is needed", and got the dead key from four draws of four across three subjects. v3's task 1 demands a one-word yes or no before any explanation, and got a correct denial from both Opus draws. Same subject, same surface, same day, opposite outcomes. If the wording is what moved it, then a probe that invites config produces config, and several charged findings in this dataset may be measuring the invitation. — open
The Index has now caught right-about-the-removal-wrong-about-the-replacement at valibot and next.js. Both were found by a capability probe that asks how to do a thing rather than whether an API exists. Whether that category is common enough to be a product claim, or is two instances, is not established. — open