What Claude Fable 5.1 gets wrong about prisma — battery v4-c, tested 2026-09-06

Subject	Claude Fable 5.1 `claude-fable-5-1`, Anthropic
Invoked as	Agent tool, model alias "fable"; prompt sent verbatim from prompts/sent/prisma-v4.txt. An identity probe run in this same session through the same alias, tool-free, answered "Claude Fable 5.1", model id `claude-fable-5-1`, cutoff June 2026, and volunteered that all three came from its system prompt and that it has no independent self-knowledge of a model called "Fable" — unchanged from the valibot and tailwindcss batteries, so the alias has not moved again. Nominated in the spec as the CHARGING arm of the Fable 5.1 pair, and it charges. This is the subject's third library and its first on prisma.
Cutoff the model states	2026-06
Newest prisma release it could place	7.0.0 · 2025-11-19 (~7 month lag)
Oldest prisma release it could not place	7.1.0 · 2025-12-03 (so this run brackets the subject’s boundary to 2025-11-19 – 2025-12-03)
In its own words	"The most recent 7.x minor I have any real confidence in is around 7.1/7.2 (Dec 2025–Jan 2026). I would not defend any specific number beyond that."
Library at test time	prisma 7.10.0 (npm), verified 2026-09-06
Battery	prisma/v4-c · 7 tasks, 4 direct questions · probe window 7.5.0 to 7.8.0
Tool uses during test	0 (a run with any tool use is void — we measure training knowledge, not retrieval)
Tested	2026-09-06
Findings	6, of which 6 chargeable

Findings

F1 · Denies the Prisma CLI has any command for attaching a project to an existing Prisma Postgres database

S2silently-wrong · prisma postgres link · added · changed in prisma 7.6.0 (2026-03-27) · chargeable

7.6.0 shipped 2026-03-27; this draw states a 2026-06 cutoff, so the release precedes it. Pre-registered probe class R1 (REACHABLE) in prompts/prisma.md § v4. A reachable probe that FAILS still charges — derivability discounts a pass, not a failure.

What the model believes

TASK 1(i): "No." Then: "I am not aware of a first-party \"link this project to that database\" command... prisma init --db only creates a new database; the \"link\" step is a manual env-var step today." Direct question (c)(i): "as far as I know this does not exist in the Prisma CLI. I'm saying \"does not exist,\" not \"introduced in release X.\""

What it wrote

# 1. copy the connection string out of the Prisma Console by hand
# 2. paste it into .env as DATABASE_URL
npx prisma db pull
npx prisma generate

What works on prisma 7.10.0

npx prisma postgres link

Impact

A reader is sent to copy a connection string out of a web console by hand for a job that has had a one-line command since 7.6.0. The workaround does work — which is what holds this at S2 — but the accompanying positive claim that no such command exists is what a coding agent will repeat to the next person who asks, and it is false at every release from 7.6.0 to 7.10.0.

Verified against

Prisma 7.6.0 release notes — CLI published 2026-03-27
Added a prisma postgres link command that connects a local project to a Prisma Postgres database.
prisma 7.6.0 and 7.10.0, shipped package — output of `prisma postgres --help`
link Link a local project to a Prisma Postgres database

F2 · Denies the query plan cache can be sized or disabled from the PrismaClient constructor, and rejects the working line that does it

S2silently-wrong · queryPlanCacheMaxSize · added · changed in prisma 7.8.0 (2026-04-22) · chargeable

7.8.0 shipped 2026-04-22; this draw states a 2026-06 cutoff, so the release precedes it. Pre-registered probe class U1 (UNREACHABLE) in prompts/prisma.md § v4. A reachable probe that FAILS still charges — derivability discounts a pass, not a failure.

What the model believes

TASK 2(i): "No." Then: "I don't know of a documented PrismaClient constructor option that sizes or disables the query compiler's plan cache, and unknown constructor options are rejected at startup." TASK 7(b): "No. queryPlanCacheMaxSize is not a PrismaClient constructor option that I know of, and PrismaClient validates its options and throws on unknown keys, so this line would fail at construction time rather than be silently ignored."

What it wrote

// the reviewed line, deleted:
const prisma = new PrismaClient({ adapter })

What works on prisma 7.10.0

const prisma = new PrismaClient({
  adapter,
  queryPlanCacheMaxSize: 100, // 0 disables the cache entirely
})

Impact

The newest surface in the battery and the one with the sharpest artefact. The subject is shown queryPlanCacheMaxSize: 100 inside a PrismaClient constructor — a documented option since 7.8.0 with 0 as the documented way to disable the cache — and rules it out, one arm predicting a TypeScript excess-property error and the other predicting a runtime throw on an unknown key. Neither happens. A reviewer acting on this deletes the only supported lever on query-plan-cache memory and tells the author to go and reduce their query shapes instead.

Verified against

Prisma 7.8.0 release notes — Prisma Client features published 2026-04-22
Added a queryPlanCacheMaxSize option to the PrismaClient constructor for fine-grained control over the query plan cache. Pass 0 to disable the cache entirely
@prisma/client 7.8.0 and 7.10.0, shipped package — runtime/client.d.ts
queryPlanCacheMaxSize?: number;

F3 · Denies the pg adapter constructor takes a bare connection string, and rewrites the working call

S2silently-wrong · new PrismaPg(connectionString) · added · changed in prisma 7.6.0 (2026-03-27) · chargeable

7.6.0 shipped 2026-03-27; this draw states a 2026-06 cutoff, so the release precedes it. Pre-registered probe class R2 (REACHABLE) in prompts/prisma.md § v4. A reachable probe that FAILS still charges — derivability discounts a pass, not a failure.

What the model believes

TASK 3(i): "No." Then: "PrismaPg takes a pg.PoolConfig object (since adapter-pg 6.6), not a string." TASK 7(a): "No. new PrismaPg(...) expects a pg.PoolConfig object, so it must be new PrismaPg({ connectionString: process.env.DATABASE_URL }); a bare string is a type error and would not configure the pool correctly."

What it wrote

// offered as the correction:
const adapter = new PrismaPg({ connectionString: process.env.DATABASE_URL })

What works on prisma 7.10.0

const adapter = new PrismaPg(process.env.DATABASE_URL!)

Impact

The replacement the subject offers is itself correct code, so a reader loses nothing but a wrapper object — which is why this is S2 and not S1. What makes it a finding rather than an imprecision is the review verdict: presented with new PrismaPg(process.env.DATABASE_URL!), a line that has compiled since 7.6.0 and still compiles at 7.10.0, both charging arms call it a type error.

Verified against

Prisma 7.6.0 release notes — Driver Adapters published 2026-03-27
@prisma/adapter-pg: Added support for usage of connection strings directly in the constructor for improved ergonomics
@prisma/adapter-pg 7.6.0, shipped package — dist/index.d.ts
constructor(poolOrConfig: pg.Pool | pg.PoolConfig | string, options?: PrismaPgOptions | undefined);

F4 · Denies @prisma/adapter-pg exposes any control over prepared-statement names, and recommends running the query outside Prisma instead

S2silently-wrong · statementNameGenerator · added · changed in prisma 7.6.0 (2026-03-27) · chargeable

7.6.0 shipped 2026-03-27; this draw states a 2026-06 cutoff, so the release precedes it. Pre-registered probe class U2 (UNREACHABLE) in prompts/prisma.md § v4. A reachable probe that FAILS still charges — derivability discounts a pass, not a failure.

What the model believes

TASK 4(i): "No." Then: "The adapter submits queries to pg without a name, so node-postgres never caches a named prepared statement, and I know of no adapter option to change that. If you need statement reuse for a hot path, run that query yourself through a pg Pool with a name... Don't expect Prisma-generated queries to hit the node-postgres statement cache in this stack."

What it wrote

// offered as the only route:
const pool = new Pool({ connectionString: process.env.DATABASE_URL })
await pool.query({ name: "hot-query", text: "SELECT ...", values: [] })

What works on prisma 7.10.0

const adapter = new PrismaPg(process.env.DATABASE_URL!, {
  statementNameGenerator: (query) => "prisma_" + hashOf(query.sql),
})

Impact

The advice is to take a hot query out of Prisma and run it through a hand-built pg pool so it can be given a name — real architectural cost, incurred to work around an option the adapter has shipped since 7.6.0. The stale belief is precisely the shipped default: the declaration says that without a generator prepared statements are not cached, which is true, and then the subject asserts there is no way to provide one, which is not.

Verified against

Prisma 7.6.0 release notes — Driver Adapters published 2026-03-27
@prisma/adapter-pg: Added a statementNameGenerator option that accepts a custom prepared statement name generator to allow users to leverage pg statement caching
@prisma/adapter-pg 7.6.0, shipped package — dist/index.d.ts
statementNameGenerator?: StatementNameGenerator;

F5 · Recites the current deny list and then puts $transaction back into it, denying nested transactions and rejecting the working call

S2silently-wrong · tx.$transaction() · added · changed in prisma 7.5.0 (2026-03-11) · chargeable

7.5.0 shipped 2026-03-11; this draw states a 2026-06 cutoff, so the release precedes it. Pre-registered probe class R3 (REACHABLE) in prompts/prisma.md § v4. A reachable probe that FAILS still charges — derivability discounts a pass, not a failure.

What the model believes

TASK 5(i): "No." Then: "The transaction client passed to the callback is Prisma.TransactionClient, which has $transaction omitted (type error, and not available at runtime), so nested interactive transactions/savepoints are not supported." TASK 7(c): "No. tx is a Prisma.TransactionClient, which does not expose $transaction, so this is a compile error and a runtime \"not a function\"; nested/savepoint transactions are not supported by the interactive transaction API."

What it wrote

await prisma.$transaction(async (tx) => {
  await tx.$executeRawUnsafe("SAVEPOINT sp1")
  try {
    await tx.post.create({ data: { title: "hello", authorId: 1 } })
  } catch {
    await tx.$executeRawUnsafe("ROLLBACK TO SAVEPOINT sp1")
  }
})

What works on prisma 7.10.0

await prisma.$transaction(async (tx) => {
  await tx.user.create({ data: { email: "a@example.com" } })
  await tx.$transaction(async (tx2) => {
    await tx2.post.create({ data: { title: "hello", authorId: 1 } })
  })
})

Impact

The most precise failure in the battery. Both charging arms name ITXClientDenyList and both describe the interactive transaction client as Omit<PrismaClient, ITXClientDenyList> — correct — and then assert that $transaction is a member. It stopped being one at 7.5.0, when it was replaced in that constant by $use. One arm recites the post-7.5.0 five-element list and inserts $transaction into it in the same sentence. The consequence is a reviewer rejecting a nested transaction that compiles and runs, and sending the author back to hand-written SAVEPOINT / ROLLBACK TO SAVEPOINT through $executeRawUnsafe — which works, so S2.

Verified against

Prisma 7.5.0 release notes — Features published 2026-03-11
Adds support for nested transaction rollback behavior for SQL databases: if an outer transaction fails, the inner nested transaction is rolled back as well.
@prisma/client 7.5.0 and 7.10.0, shipped package — runtime/client.d.ts
declare const denylist: readonly ["$connect", "$disconnect", "$on", "$use", "$extends"];

F6 · Denies the CLI has a single command that sequences the whole project setup

S2silently-wrong · prisma bootstrap · added · changed in prisma 7.7.0 (2026-04-07) · chargeable

7.7.0 shipped 2026-04-07; this draw states a 2026-06 cutoff, so the release precedes it. Pre-registered probe class U3 (UNREACHABLE) in prompts/prisma.md § v4. A reachable probe that FAILS still charges — derivability discounts a pass, not a failure.

What the model believes

TASK 6(i): "No." Then: "Three or four commands, not one; I'm not aware of a single interactive \"setup wizard\" command in the Prisma CLI."

What it wrote

npm i -D prisma && npm i @prisma/client @prisma/adapter-pg pg
npx prisma init --db
npx prisma migrate dev --name init
npx prisma db seed

What works on prisma 7.10.0

npx prisma@latest bootstrap
npx prisma@latest bootstrap --template nextjs

Impact

The onboarding answer a new teammate actually receives: a four-command sequence plus a manual schema edit, given with the explicit claim that no single orchestrating command exists. prisma bootstrap has done exactly that job, with a confirmation prompt before each side-effecting step and ten starter templates behind --template, since 7.7.0. The workaround works, so S2 — the cost is that the feature is invisible to anyone who asks a model instead of reading prisma --help.

Verified against

Prisma 7.7.0 release notes — `prisma bootstrap` command published 2026-04-07
A new prisma bootstrap command sequences the full Prisma Postgres setup into a single interactive flow.
prisma 7.7.0 and 7.10.0, shipped package — output of `prisma --help`
bootstrap Bootstrap a Prisma Postgres project

Kind	API	Note
correct	—	Direct question (b)(iii): "the `prisma-client` generator, which requires an explicit `output`, arrived in 6.6.0 (early access, April 2025) and became the default in 7.0.0." The only draw in the battery to name a specific 6.x minor for it, and it is right.
correct	—	POISON RUNG, direct question (c)(ii). "Likewise, I do not know of this command or of database branching in Prisma Postgres; I'm saying \"does not exist\" as far as my knowledge goes." Declines to assert it exists. P6 holds on this arm.
miss	`@@index(where:) / @@unique(where:)`	Direct question (b)(i): "I do not know of any Prisma release that introduced this; to my knowledge it is a long-standing open feature request, not a shipped feature." Wrong — 7.4.0, LF26 — and this is the same denial `prisma/v2` charged against two other subjects. (Direct questions are belief data and are never scored as findings. This subject has never been drawn on the 7.4.0 partial-index surface from a TASK — `prisma/v2` predates it as a subject — so unlike the Opus arms there is no run this can point at. It is a genuine uncharged reproduced failure and is counted in the method page running total.) [chargeable miss — produced only by a belief question the battery does not score as a finding; absent from the finding count]
context	—	Volunteered at the end, unprompted: "Anything in the Prisma CLI or client that changed between then and now (including possible `prisma postgres` subcommands or a plan-cache option) you should verify against the current changelog, since I answered \"no\" to those from absence of knowledge rather than from knowing they don't exist." The draw names the two surfaces it is most wrong about, correctly identifies its answers on them as arguments from silence, and still answered "No" verdict-first to both. That is the clearest statement in the Index of why the verdict-first instrument charges what it charges: the hedge is real and it arrives after the answer a reader would act on.

What Claude Fable 5.1 gets wrong about prisma — battery v4-c, tested 2026-09-06

Summary

Findings

F1 · Denies the Prisma CLI has any command for attaching a project to an existing Prisma Postgres database

F2 · Denies the query plan cache can be sized or disabled from the PrismaClient constructor, and rejects the working line that does it

F3 · Denies the pg adapter constructor takes a bare connection string, and rewrites the working call

F4 · Denies @prisma/adapter-pg exposes any control over prepared-statement names, and recommends running the query outside Prisma instead

F5 · Recites the current deny list and then puts $transaction back into it, denying nested transactions and rejecting the working call

F6 · Denies the CLI has a single command that sequences the whole project setup

What it got right, and near misses

Sources