Run next.js--claude-opus-5--v3-f--2026-09-02 · self-test: the subject is the operator
The blind twin, and it agrees with v3-e everywhere the twin pair matters and splits from it where the battery was built to look. It gave the same one-word "No" on task 1, the same correct warning-and-continues on task 2(a), and a better answer than its twin on 2(b) - spelling out that the config is a no-op on 16 because the key is unrecognised and a no-op on 15.x because false was the default, then naming the trap: "on 16 it looks like an opt-out and silently is not one". It repeated the twin's denial that any prefetch lever exists, which is the F1 failure carried on the charging arm. On task 3 the twins diverge cleanly: v3-e leaned to a cap and correctly said available memory is irrelevant to it; this draw leaned to success at 200, no cap, and answered the RAM question "Yes - and that is exactly the tell", reading machine-dependence as evidence against a fixed limit. It is the wrong side of a discriminator that worked. Both draws then dated the clientSegmentCache removal to the 16.0.0 major, three weeks early, and the proxy.ts rename to 16.0.0, correct.
| 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 honest boundary is that my detailed, safe-to-code-against knowledge ends around Next.js 15.5, and 16.0 is known to me as a set of headlines rather than as an API surface" |
| Library at test time | next.js 16.3.4 (npm), verified 2026-09-02 |
| Battery | next.js/v3-f · 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) |
| 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 |
|---|---|---|
| miss | experimental.prefetchInlining |
Task 1: the same denial as the charging twin - "my understanding is that the segment cache is on by default and there is no supported config key to revert to whole-tree prefetching" - followed by hand-rolled intent prefetching, layout flattening, an argument against the team's premise, and pinning to 15.x. experimental.prefetchInlining (16.2.0, two months inside this subject's stated cutoff) does exactly what was asked. Charged on the twin as F1; this is the -b-role draw of the duplicated arm and charges nothing. [chargeable miss — a replicate, a duplicated arm’s second draw or a below-floor control charges nothing; charged as a finding on next.js--claude-opus-5--v3-e--2026-09-02] |
| miss | images.maximumResponseBody |
Task 3: answered that the request ends 200 with a normally optimized WebP and that no configurable byte cap exists - "There is no images.maxUpstreamSize / images.maximumFileSize that I can attest to" - listing the image options it is confident of and correctly noting maximumRedirects among them while missing maximumResponseBody, which sits beside it in the same shipped default config. The real answer is a 50 MB cap enforced while streaming, a 413, and images.maximumResponseBody. Charged on the twin as F2; this arm charges nothing. [chargeable miss — a replicate, a duplicated arm’s second draw or a below-floor control charges nothing; charged as a finding on next.js--claude-opus-5--v3-e--2026-09-02] |
| correct | experimental.clientSegmentCache |
Task 2, the sharpest answer any draw of six gave on the dead key. "On Next.js 16: the key is unrecognised, so it is discarded during config validation and never reaches the router. Writing false does not turn the segment cache off - an unknown key is inert, not an override." It separated that from the 15.x reading, where the key is recognised and false is the default, and named the consequence: "a developer reading this config would reasonably conclude the app is on whole-tree prefetching when it is not." Both Opus draws reversed v2's four-of-four failure on this surface under the tighter wording. |
| imprecision | proxy.ts |
Task 4(a): named proxy.ts correctly but specified a default export where the convention is a named export proxy - then hedged it and named the correct alternative in the same breath: "Medium on the default-vs-named export detail (I am fairly sure it is a default export; if your build complains, a named export function proxy is the thing to try)." Recorded rather than charged under the code-vs-claim rule, which treats a hedged claim that names the correct fix as an imprecision. |
| miss | images.maximumResponseBody |
Task 3(c), the discriminator, answered on the opposite side from its twin: "Would more RAM and disk change the answer? Yes - and that is exactly the tell ... That non-determinism is the diagnostic signature of no hard limit." The reasoning is sound and the premise is false: the limit is a fixed constant in imageConfigDefault, so the outcome is machine-independent. Not separately chargeable - it is the same belief as the task 3 miss above, stated as an inference. |
| miss | experimental.clientSegmentCache |
Task 5(a): "Next.js 16.0.0, approximately 21 October 2025", labelled a guess, with the alternative considered and rejected. Actual: 16.0.3, 2025-11-13. Both Opus draws collapsed the patch onto the major while both placed the 16.0.0 rename correctly in task 5(c). Two subjects, three batteries, and no draw has yet attributed a change to a patch release. |
Battery specification: prompts/nextjs.md in the studio repo.
Every finding above also carries its own citation.