What Claude Fable 5 gets wrong about prisma — battery v1, tested 2026-08-31
Run prisma--claude-fable-5--v1--2026-08-31
Summary
Thirteen findings, and the result that matters is the last one. Fable 5's Prisma knowledge stops at 6.7.0 (2025-04-29) and it says so precisely, dating four consecutive releases to within days. That is six months earlier than the same model's boundary on zod, Next.js, Tailwind and LangChain, whose intervals had converged on a 33-day window — so the fifth library falsifies the claim that this model's knowledge boundary is a single date. The code it wrote is a coherent 6.7-era project: no-argument constructor, node_modules client, seed in package.json, engine binaries matched to the container's libc. It knows the Rust-free client, the prisma-client generator and prisma.config.ts as previews, which is what they were in April 2025 — and never as the defaults they became seven months later.
Subject
Claude Fable 5 claude-fable-5, Anthropic
Invoked as
Agent tool, model alias "fable"
Cutoff the model states
2026-01
Newest prisma release it could place
6.7.0 · 2025-04-29 (~8 month lag)
Oldest prisma release it could not place
6.8.0 · 2025-05-15 (so this run brackets the subject’s boundary to 2025-04-29 – 2025-05-15)
In its own words
"The latest version I'm confident exists is in the Prisma 6.x line — I have awareness of version numbers into roughly 6.13–6.16 (second half of 2025), but only as numbers. The most recent release whose contents I can actually describe with confidence is roughly 6.7 (around May 2025) — the queryCompiler + driverAdapters engine-less client preview era ... First release I know essentially only as a version number: around 6.8 onward."
Library at test time
prisma 7.10.0 (npm), verified 2026-08-31
Battery
prisma/v1 · 10 tasks, 4 direct questions · probe window 6.18.0 to 7.0.0
Tool uses during test
0 (a run with any tool use is void — we measure training knowledge, not retrieval)
Tested
2026-08-31
Findings
12, of which 12 chargeable (and 1 retracted, kept below)
F1 · Constructs the client with no arguments in every runnable artefact
S1breaks-build
· new PrismaClient()
· removed
· changed in prisma 7.0.0
(2025-11-19)
· chargeable
What the model believes
"const prisma = new PrismaClient()" in tasks 1, 2, 3 and 5, with the mechanism stated: "the client picks it up automatically, so nothing about the URL appears in this file."
What it wrote
const prisma = new PrismaClient()
What works on prisma 7.10.0
const adapter = new PrismaPg({ connectionString: process.env.DATABASE_URL })
const prisma = new PrismaClient({ adapter })
Impact
Throws at construction on Prisma 7 before any query runs.
generator client { provider = "prisma-client-js" } in all three schemas; in (d), "with the classic prisma-client-js generator, into node_modules/.prisma/client".
prisma-client-js throughout the tasks, while question (d) and the serverless answer both describe the newer prisma-client generator accurately — it is simply never the one written.
Task 4 lists the files after migrate dev as .env, prisma/schema.prisma, the migration SQL and migration_lock.toml. No config file appears in any of the ten tasks, though question (d) describes one.
What it wrote
datasource db {
provider = "postgresql"
url = env("DATABASE_URL")
}
Task 4: "The connection string lives in .env at the project root ... the Prisma CLI loads it automatically — this is the CLI's own dotenv handling." Question (d): "when prisma.config.ts is in play, the CLI no longer auto-loads .env for you — you load env yourself."
What it wrote
# .env — loaded automatically by the CLI
DATABASE_URL="postgresql://..."
What works on prisma 7.10.0
import 'dotenv/config'
import { defineConfig, env } from 'prisma/config'
Impact
The variable is unset when the CLI runs. Charged under the code-vs-claim rule: the working instructions assert the auto-load, and the correction appears only in the leading belief probe, four answers later.
"With that \"prisma\".seed key wired up, seeding runs automatically as part of the normal workflow: prisma migrate dev triggers it ... prisma migrate reset always runs it" — followed by "(Note: in newer Prisma versions that use prisma.config.ts, the seed command moves into the config file's migrations.seed field instead of package.json — see (d).)"
Neither half works on 7.x: the key is not read, and migrate no longer runs the seed.
Scope note
The hedge names the correct destination — migrations.seed in the config file — and is the most nearly-exempt claim in the run. Charged because the artefact it shipped is the package.json form and the parenthetical treats the config file as an alternative for "newer versions" rather than the current one.
"its query engine binary must match the container's OS", with binaryTargets = ["native", "linux-musl-openssl-3.0.x"] and "the generated client lives in node_modules/.prisma/client with the engine binary inside".
This is now replaced with just --[from/to]-schema. The usage is otherwise the same.
F12 · Sets a MongoDB team up on the current major, which dropped MongoDB
S4wrong-metadata
· MongoDB support
· removed
· changed in prisma 7.0.0
(2025-11-19)
· chargeable
What the model believes
A full MongoDB setup with eight caveats — none of them the version. Its closing advice was to "evaluate Mongoose or the raw driver honestly" if greenfield, on the grounds that Mongo support "gets features later or not at all".
What it wrote
datasource db {
provider = "mongodb"
url = env("DATABASE_URL")
}
What works on prisma 7.10.0
// MongoDB: stay on Prisma 6
// npm i -D prisma@6 && npm i @prisma/client@6
Impact
Directionally right about the neglect, wrong about the consequence: the current major does not support the database at all.
Currently, MongoDB is not supported in Prisma 7. For folks using MongoDB, please stay on Prisma v6.
F13 · Knowledge stops at 6.7.0 — eight months before its own stated cutoff, and six months earlier than the same model's boundary on four other libraries
Anchored to 6.8.0 (2025-05-15), the first release the subject says it knows only as a number. Twenty-five further releases up to 7.2.0 (2025-12-17) precede the stated 2026-01 cutoff.
What the model believes
"The most recent release whose contents I can actually describe with confidence is roughly 6.7 (around May 2025) ... First release I know essentially only as a version number, with no real idea of its contents: around 6.8 onward. I believe 6.8-6.16 exist, but I can't describe them individually with any confidence."
Impact
This is the finding that breaks the Index's own four-library result. On zod, Next.js, Tailwind and LangChain this model's boundary fell inside 2025-10-22 to 2025-11-24; on Prisma it falls six months earlier, so no single date explains all five libraries for this subject. See JOURNAL/015.
we're currently working on moving the core of Prisma from Rust to TypeScript
F11 · Says the mapped value is invisible to application code (retracted)
Retracted 2026-09-03. The subject was right and this Index was wrong. Prisma reverted the 7.0.0 mapped-enum change in 7.3.0 (2026-01-21), so at every release from 7.3.0 onward — including the 7.10.0 that was current when this run was scored — the generated enum object maps each member name to itself, which is what the subject wrote. The charge rested on the 7.0.0 release note and was never verified against a generated client.
See JOURNAL/048. This charge is excluded from every
count on this site, from the prisma correction pack and from the MCP tools.
The text below is exactly as it was published and is not edited to match the retraction.
"The generated TypeScript uses the Prisma-level names — the @map is invisible in your app code ... If you need the raw DB string at the edge of your system, keep a small explicit mapping table; the generated client doesn't expose the @map values."
Prescribes a hand-maintained lookup table for values the client now hands you directly, and any string comparison against the member name silently fails.
Scope note
Charged against the generated shape 7.0.0 documents; the pre-7 shape is not separately verified here.
We now support the @map attribute for enum members, which can be used to set their expected runtime values
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.
Kind
API
Note
correct
—
Its release history is accurate where it claims confidence: 6.7 as the Rust-free/queryCompiler preview (published 2025-04-29), 6.6 as the ESM prisma-client generator plus D1 and MCP work (2025-04-08), 6.2 as omit going GA (2025-01-07), 6.1 as tracing (2024-12-17). Four correct attributions, dated within days.
correct
postinstall prisma generate
The Dockerfile runs npx prisma generate explicitly rather than trusting the postinstall hook, and says why: "if you prune or re-install prod deps in the runtime stage, you must re-run prisma generate". The removal of implicit generation does not break this artefact. (Correct on 7.x by construction, though for a v6 reason.)
miss
prisma.config.ts
The serverless answer names the prisma-client generator with a required output outside node_modules as the modern path, and question (d) describes prisma.config.ts, defineConfig from prisma/config, the seed moving out of package.json, and the loss of automatic .env loading — every one of which is a 7.0.0 fact. (All of it is reachable from 6.6/6.7, where these landed as early access — the subject frames them as previews rather than defaults, which is exactly right for 6.7 and exactly wrong for today. The boundary shows as an unfinished trajectory rather than an absence.)