---
library: next.js
library-latest: "16.3.3"
library-latest-verified: 2026-08-31
model: claude-fable-5 (spawned via Agent model alias "fable")
model-self-reported-cutoff: 2026-01
model-believed-latest: "16.1.x line (~mid-December 2025) known to exist; 16.0 (21 October 2025) is the last release whose contents it can describe"
test-date: 2026-08-31
battery: next.js/v1 (10 idiomatic tasks + 3 direct questions; probes restricted to 16.0.0, published 2025-10-22)
tool-uses-during-test: 0
verified-against: https://nextjs.org/blog/next-16 · https://nextjs.org/docs/app/guides/upgrading/version-16 · https://api.github.com/repos/vercel/next.js/releases
status: open (no retest yet)
json: fable-5.json
---

# Next.js × Claude Fable 5 — battery v1 findings

The strongest result in this dataset so far, and the second recording of a pattern that is
starting to look like the real story.

Fable 5 answers nine of ten tasks like a model that has read Next.js 16: `proxy.ts`,
`cacheComponents: true`, unprefixed `cacheLife`/`cacheTag`, the `eslint` script that replaced
`next lint`, Turbopack as the default bundler, `images.qualities` defaulting to `[75]`, and the
four-hour image cache TTL **correctly attributed to 16** — the only subject to get both the value
and the release right.

It knows 16.1 exists and shipped "around mid-December 2025." 16.1.0 shipped 2025-12-18, two weeks
before its stated 2026-01 cutoff. It then correctly declines to describe what is in it.

**No version-recency finding is charged against this subject.** It is the only run in the dataset
where a model's library knowledge actually reaches its own cutoff.

## The dissociation, again

Fable 5 states a cutoff of **2026-01**. Opus 5 states **2026-05**, four months later. On this
library Fable 5 is the more current model: it configures Cache Components correctly where Opus 5
ships the removed `experimental.ppr` flag, and it dates the `proxy` rename correctly where Opus 5
puts it a whole major early.

This is the same shape recorded on zod on 2026-08-29, on entirely different APIs. Two libraries is
not enough to say whether this is a property of the model or of these two libraries — that is
logged as an open question, not a conclusion, and separating it needs a third library with a
different release rhythm.

## F1 · S1 breaks-build · single-argument `revalidateTag`

```ts
'use server'
export async function updateProduct(id: string, formData: FormData) {
  await db.product.update({ where: { id }, data: { ... } })
  revalidateTag('products')
}
```

The surrounding prose is correct — it notes that in Next 16 `revalidateTag` "accepts a cache-life
profile as a second argument" and that `updateTag` gives read-your-writes semantics — and at
question (c) it gives the right answer outright: "In Next 16 ... it accepts up to two:
`revalidateTag(tag, profile)`."

It then wrote the one-argument form in the code.

> "revalidateTag now requires a second argument specifying a cacheLife profile. The single-argument
> form is deprecated and will produce a TypeScript error."
> — Upgrading: Version 16

That is the same knowing-but-not-applying failure Opus 5 shows on the same line, and it is why the
correction pack leads with this one: **all three subjects generated this identical call**, including
the two that could state the correct signature when asked.

## F2 · S2 silently-wrong · says a parallel route builds without `default.js`

> "Strictly, the route builds without `default.tsx`, but the moment you add child routes under
> `/dashboard`, any route the slot can't match hard-404s on reload — so treat `default.tsx` as
> required in practice."

The failure mode is inverted. As of 16.0.0:

> "Parallel routes `default.js` | All parallel route slots now require explicit `default.js` files;
> **builds fail without them**. Create `default.js` that calls `notFound()` or returns `null` for
> previous behavior"
> — Next.js 16 release announcement, Behavior Changes table

So it is a build failure, not a runtime 404. A developer who accepts "strictly, it builds without
it" and trims the file gets a red CI run they were told to expect as a browser 404.

The model's own file listing does include `default.tsx`, so the generated code is correct — only
the claim about it is wrong. That is why this is S2 and not S1, and it is the distinction the
code-vs-claim rule exists to make.

## Not findings

- **Task 4** — `cacheComponents: true` at the top level, explicitly identified as subsuming the old
  `experimental.ppr`. The only subject to get this right; both others shipped removed config.
- **Task 1** — `proxy.ts` with a default-exported `proxy`, correctly dated to 16, correctly
  described as a rename with `middleware.ts` deprecated but still functional.
- **Task 10** — "The default changed in Next 16: 4 hours (14400 seconds). On Next ≤15 the default
  was 60 seconds." Correct value, correct release.
- **Task 8** — claims the optimizer "rejects qualities not in the allowlist with a 400 Bad Request,"
  self-rated "slightly less than certain it 400s rather than clamping." The guide says the quality
  is coerced to the nearest allowed value. Hedged and paired with the correct fix (add 90 to
  `images.qualities`), so not charged under the code-vs-claim rule.
- **Task 7** — says `images.domains` is "deprecated and removed in Next 16." Deprecated, not
  removed. No consequence; it used `remotePatterns`.