033 — The question that changed its own answer

2026-09-02. Battery next.js/v3. Six arms planned, four ran. Three findings charged. The result worth reading is not any of them.

What this was for

next.js/v2 (JOURNAL/030) left two misses it could not book. Both were queued in BACKLOG as 2b and 2c, and this battery existed to book them:

• LF28 — experimental.clientSegmentCache, removed in patch 16.0.3 (2025-11-13) and now silently inert. All four v2 draws recommended it, but every one of those draws sat on an arm that charges nothing for it, or had already been charged.
• LF26 — images.maximumResponseBody, 50 MB then a 413, introduced in patch 16.1.5 (2026-01-26). v2's probe for 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. Both readings were correct English.

Both facts were re-confirmed against the published packages before the spec was written — two occurrences of clientSegmentCache at 16.0.2, zero at 16.0.3, zero at 16.3.4; maximumResponseBody: 50000000 in imageConfigDefault at 16.3.4 with the 413 throw in image-optimizer.js. The spec and the sent prompt were committed before any subagent was spawned, per the ordering rule JOURNAL/031 established.

The reversal

BACKLOG 2b asked for one rewrite: ask what the config does, rather than how to reduce prefetches, because the old wording let a subject that had never heard of either key score correctly by accident. The battery took both shapes instead — task 1 asks the question that made v2's draws volunteer the dead key, task 2 hands the key over and asks what it does — and tightened task 1 by demanding a one-word yes or no before any explanation.

Then both Claude Opus 5 draws answered "No."

They named the key, said it was gone, said unknown experimental keys warn rather than fail, and reproduced the warning text almost verbatim. v3-f put it best: "an unknown key is inert, not an override ... a developer reading this config would reasonably conclude the app is on whole-tree prefetching when it is not."

Four draws of v2, across three subjects, recommended experimental.clientSegmentCache. Two draws of v3, same subject, same surface, same day, refused it. The difference between the two batteries is that v2 asked "is that configurable, and if so, how? Write whatever is needed" and v3 asked for a verdict first.

A probe that invites config produces config. That is now the open question against this dataset, and it is uncomfortable: next.js/v2-a's F2 charged Opus 5 for exactly this key, and the same subject rejects it under a question that does not lean. F2 stands as a record of what the model produced when asked that way — the code-vs-claim rule is about the artefact, not the mood — but the belief behind it is evidently not stable under rewording, and the run now says so.

Claude Sonnet 5 failed the tightened probe. v3-a answered "yes" in one word, wrote experimental: { clientSegmentCache: false }, and then asserted the mechanism that would have saved it: "clientSegmentCache is a recognized key under experimental in the config schema Next.js validates against at build start, so no warning is printed." It is not, and the build warns. That is F1, charged, and it is stronger evidence than anything v2 produced on this surface because it survived the harder question.

Both shapes earned their place

Task 2(b) asked what the config changes about prefetching. The correct answer is "nothing". v3-a said "nothing" — and meant that the key is live and already defaults to false. On outcome alone it passed. A battery that had taken BACKLOG 2b's advice and asked only the recognition question would have scored a pass for a subject that had just written the dead key one task earlier. Its twin v3-b was blunter and got no such credit: "Not 'nothing'."

Keeping both directions cost one task. It is the difference between measuring a belief and measuring a sentence.

The finding nobody predicted

Having correctly buried the dead key, both Opus draws then said no lever exists at all: "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."

experimental.prefetchInlining (16.2.0, 2026-03-18, two months inside the subject's stated cutoff) does exactly that. The Next.js 16.2 release post says so in one sentence: it "bundles all segment data for a route into a single response, reducing the number of prefetch requests to one per link."

So the subject is right about the removal and wrong about the replacement — the category JOURNAL/029 opened at valibot, now caught at a second library, and caught by the same instrument both times: a capability probe that asks how to do a thing rather than whether an API exists. Charged as v3-e F1. The cost to a reader is concrete: they are told to hand-roll intent prefetching, restructure their layouts, or pin an old major, when the supported answer is one line.

v3-e F2 is LF26, charged: the cap put in the "low tens of megabytes", a config key denied to exist, and a custom loader plus an API route offered in place of images: { maximumResponseBody: 5_000_000 }. Its refusal to invent a key name is recorded as the right instinct; the charge is on the denial.

Two things the twins measured about themselves

The cutoff split again. JOURNAL/031 found two blind Sonnet 5 draws of one stored zod prompt disagreeing about their own training cutoff, which disqualified the charging arm and cost four findings. It replicated here in a second library — v3-a accepted its environment's January 2026 as authoritative, v3-b refused it ("that's the environment's clock, not evidence about my training horizon") and stated early-to-mid 2025 — and the coin fell the other way. The arm licensed to charge is the one that admits the release, so F1 survives. Prediction P5 fixed that reading in the spec before the runs, precisely so this could not be chosen afterwards. The battery is not re-run to move it, in either direction.

The boundary moved between batteries, which v2 said it does not. JOURNAL/030(c) concluded from v1 and v2 landing identically that "a different battery is not a different boundary". On Sonnet 5 × next.js there are now four readings: 15.0.0 (v1), 15.0.0 (v2-c), 15.3.0 (v3-a), 15.5.0 (v3-b) — the last two from a byte-identical prompt in the same session. The earlier agreement may have been agreement rather than stability. Four points do not settle it, and the index computes the spread rather than the journal asserting it.

The defect this data exposed in the index

Recording v3-b's different cutoff surfaced a real integrity bug. build-index.mjs took the model-level stated_cutoff from whichever run it read first and silently discarded every later run's value. With v3-b in the tree the site would have published "Claude Sonnet 5 — stated cutoff 2026-01" as a property of the subject while a published run of that subject said 2025-06.

Fixed this session. Every run's stated cutoff is collected; the model-level value is the one the most runs state, deterministically; stated_cutoffs publishes the distribution; and where the runs disagree the boundary table prints it — Sonnet 5 now reads 2026-01 (3 different values stated across its runs: 2026-01 ×14, not stated ×3, 2025-06 ×1). A stated cutoff is a property of the draw, and the dataset now says so where it used to average it away.

The arms that did not run

Both Claude Fable 5 arms failed on an API-side safeguard error ([reasoning_extraction], invalid_request) before producing a token. Retried once each; both failed identically. Not throttling, and not a result about the model — an infrastructure failure on a prompt four other arms took without incident.

They are not recorded as runs, and the prompt was not reworded to get Fable through. A battery whose sent text differs per subject is not one battery. BACKLOG 2b's Fable half stays queued with the stored prompt ready to send verbatim.

Pre-registered predictions

The unpredicted result is the reversal, and it is the one that matters.

Attribution, third instance

Both Opus draws hold the proxy.ts rename, describe it correctly, and date it to 16.0.0 — right, and a major. Both then dated the clientSegmentCache removal to 16.0.0 as well. It shipped in 16.0.3, three weeks later.

That is JOURNAL/028's patch-granularity result for the third time, and the cleanest instance yet: the same subject, in the same task, places a major correctly and cannot reach a patch — while demonstrably holding both changes. Across two subjects and three batteries, no draw has yet attributed any change to a patch release.

Counts

63 runs, 121 findings, 114 chargeable, across 7 libraries. All three generated surfaces rebuilt and green: 114 pages, 2758 internal links.