What Claude Sonnet 5 gets wrong about prisma — battery v1, tested 2026-08-31

Run prisma--claude-sonnet-5--v1--2026-08-31

Summary

Fourteen findings, the largest count in the Index, from the subject with the largest blind spot on this library: Sonnet 5 can describe Prisma 6.0.0 (2024-11-28) and nothing after roughly 6.1, which leaves the whole of Prisma 7 outside its knowledge. Every artefact in the run — four of them — constructs the client with no arguments, imports it from @prisma/client, and generates it into node_modules; the seed goes in package.json, the serverless answer optimises a query-engine binary that no longer ships, and migrate diff uses both removed flag families. None of this is careless: the v6 material is accurate and well-organised. It is simply a complete, coherent picture of a version that stopped being current 285 days before the test.

SubjectClaude Sonnet 5 claude-sonnet-5, Anthropic
Invoked asAgent tool, model alias "sonnet"
Cutoff the model states2026-01
Newest prisma release it could place6.0.0 · 2024-11-28 (~14 month lag)
Oldest prisma release it could not place6.1.0 · 2024-12-17 (so this run brackets the subject’s boundary to 2024-11-28 – 2024-12-17)
In its own words"The latest version I have solid knowledge of is the Prisma ORM 6.x line — Prisma 6.0 landed around November 2024 ... I'm aware there were subsequent 6.x point releases but I can't describe their specific contents with confidence — beyond roughly 6.0/6.1 my knowledge thins into 'I know the version number exists, not what changed in it.' I have no reliable knowledge of anything resembling a Prisma 7."
Library at test timeprisma 7.10.0 (npm), verified 2026-08-31
Batteryprisma/v1 · 10 tasks, 4 direct questions · probe window 6.18.0 to 7.0.0
Tool uses during test0 (a run with any tool use is void — we measure training knowledge, not retrieval)
Tested2026-08-31
Findings13, of which 13 chargeable (and 1 retracted, kept below)
this run as JSON write-up (markdown) all prisma findings method

Findings

F1 · Constructs the client with no arguments, in four separate answers

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 explicitly: "The connection string itself isn't passed here ... PrismaClient picks it up automatically at instantiation."

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

Every runnable artefact in the run throws at construction on Prisma 7. This is the single highest-frequency stale prior the battery found.

Verified against

F2 · Generator block with no output path

S1breaks-build · generator client { output } · requirement · changed in prisma 7.0.0 (2025-11-19) · chargeable

What the model believes

"generator client { provider = \"prisma-client-js\" }" with no output, and in question (d): "Generated client code goes to node_modules/.prisma/client by default."

What it wrote
generator client {
  provider = "prisma-client-js"
}
What works on prisma 7.10.0
generator client {
  provider = "prisma-client"
  output   = "../src/generated/prisma"
}
Impact

prisma generate refuses before anything else in the setup can be tried.

Verified against

F3 · Uses the superseded generator provider throughout

S3deprecated · provider = "prisma-client-js" · deprecated · changed in prisma 7.0.0 (2025-11-19) · chargeable

What the model believes

prisma-client-js in every schema shown; the newer provider is never mentioned in any of the ten tasks.

What it wrote
generator client {
  provider = "prisma-client-js"
}
What works on prisma 7.10.0
generator client {
  provider = "prisma-client"
  output   = "../src/generated/prisma"
}
Impact

Still functions in 7.x, with a stated removal ahead of it, and needs the extra @prisma/client-runtime-utils package once output is set.

Verified against

F4 · Imports PrismaClient from @prisma/client

S1breaks-build · import { PrismaClient } from '@prisma/client' · behavior-changed · changed in prisma 7.0.0 (2025-11-19) · chargeable

What the model believes

"import { PrismaClient } from '@prisma/client';" in every file, and in (d): "@prisma/client re-exporting from there — which is why npx prisma generate has to run after every npm install".

What it wrote
import { PrismaClient } from '@prisma/client'
What works on prisma 7.10.0
import { PrismaClient } from './generated/prisma/client'
Impact

With the generated client now living in your own tree, the package import does not resolve to a client.

Verified against

F5 · No config file at all; the datasource URL stays in schema.prisma

S1breaks-build · prisma.config.ts · requirement · changed in prisma 7.0.0 (2025-11-19) · chargeable

What the model believes

Task 4 lists the files involved as .env, prisma/schema.prisma, the migrations directory and the generated client — no config file. In (d): "historically the only config file is schema.prisma itself", with prisma.config.ts recalled but explicitly held "with meaningfully less confidence than the rest of this answer".

What it wrote
datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}
What works on prisma 7.10.0
// prisma.config.ts
export default defineConfig({
  schema: 'prisma/schema.prisma',
  datasource: { url: env('DATABASE_URL') },
})
Impact

prisma migrate in 7.x requires the config file; the answer's exact migration commands have nothing to read a datasource from.

Verified against

F6 · Assumes the CLI loads .env by itself

S2silently-wrong · automatic .env loading · behavior-changed · changed in prisma 7.0.0 (2025-11-19) · chargeable

What the model believes

"The string lives in .env as DATABASE_URL, referenced from prisma/schema.prisma via url = env(\"DATABASE_URL\")" — with no loading step anywhere in the run.

What it wrote
# .env, read by the CLI automatically
DATABASE_URL="postgresql://..."
What works on prisma 7.10.0
import 'dotenv/config'
import { defineConfig, env } from 'prisma/config'
Impact

The variable is simply unset when the CLI runs, and the error names the connection rather than the missing load.

Verified against

F7 · Seed command declared in package.json, with the implicit-run claim attached

S1breaks-build · package.json prisma key · removed · changed in prisma 7.0.0 (2025-11-19) · chargeable

What the model believes

"With that prisma.seed entry in place, the seed runs automatically whenever you run npx prisma migrate dev ... and whenever you run npx prisma migrate reset. No extra CI/dev wiring needed beyond that config block."

What it wrote
{
  "prisma": {
    "seed": "ts-node prisma/seed.ts"
  }
}
What works on prisma 7.10.0
// prisma.config.ts
export default defineConfig({
  migrations: { seed: 'tsx prisma/seed.ts' },
})
Impact

The key is not read, so the seed never runs — and the answer's closing promise is that no further wiring is needed.

Verified against

F8 · Relies on the postinstall hook to generate the client in Docker

S2silently-wrong · postinstall prisma generate · removed · changed in prisma 7.0.0 (2025-11-19) · chargeable

What the model believes

"the prisma/@prisma/client npm packages register a postinstall hook that runs prisma generate automatically when npm install sees a prisma/schema.prisma" — and, in task 1, "usually run automatically as a postinstall".

What it wrote
RUN npm ci        # postinstall generates the client
What works on prisma 7.10.0
RUN npm ci
RUN npx prisma generate
Impact

The Dockerfile it wrote does run npx prisma generate explicitly, so that artefact survives; the belief is charged because the run states the hook as a fact twice and offers it as the reason the step is optional.

Verified against

F9 · Recommends prisma generate --no-engine

S1breaks-build · prisma generate --no-engine · removed · changed in prisma 7.0.0 (2025-11-19) · chargeable

What the model believes

"Generate a query-engine-free client (--no-engine on prisma generate) when pairing with Prisma Accelerate."

What it wrote
npx prisma generate --no-engine
What works on prisma 7.10.0
npx prisma generate
Impact

Unknown flag; the serverless build step fails.

Verified against

F10 · Whole deployment story built around a query-engine binary that no longer ships

S2silently-wrong · engineType · removed · changed in prisma 7.0.0 (2025-11-19) · chargeable

What the model believes

"The correct query-engine binary for the container's OS/libc must be available. If the base image is Alpine (musl) ... you must add the right binaryTargets", and "make sure your bundler treats @prisma/client/the engine as external ... which tends to break the binary lookup".

What it wrote
generator client {
  provider      = "prisma-client-js"
  binaryTargets = ["native", "linux-musl-openssl-3.0.x"]
}
What works on prisma 7.10.0
generator client {
  provider = "prisma-client"
  output   = "../src/generated/prisma"
}
Impact

Sends a team hunting a libc/OpenSSL mismatch that cannot occur on 7.x, and frames the engine-free client as an optimisation rather than the only client there is.

Verified against

F11 · migrate diff with the removed --from-url / --to-schema-datamodel flags

S1breaks-build · prisma migrate diff · renamed · changed in prisma 7.0.0 (2025-11-19) · chargeable

What the model believes

"npx prisma migrate diff --from-url \"$DATABASE_URL\" --to-schema-datamodel prisma/schema.prisma --script", with a parenthetical listing the same removed flags as the general vocabulary of the command.

What it wrote
npx prisma migrate diff \
  --from-url "$DATABASE_URL" \
  --to-schema-datamodel prisma/schema.prisma \
  --script
What works on prisma 7.10.0
npx prisma migrate diff \
  --from-config-datasource \
  --to-schema prisma/schema.prisma \
  --script
Impact

Unknown-flag error, and no version of the command in the answer works.

Verified against

F13 · Sets a MongoDB team up on a version that dropped MongoDB, with no version caveat

S4wrong-metadata · MongoDB support · removed · changed in prisma 7.0.0 (2025-11-19) · chargeable

What the model believes

A full MongoDB schema and workflow with six caveats — replica sets, ObjectId mapping, emulated relations — and no mention that the current major does not support the database 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

The one question in the battery where the correct answer is "pin to the previous major", answered as though nothing had changed.

Verified against

F14 · Knowledge stops at 6.0.0 — fourteen months before its own stated cutoff

S4wrong-metadata · version-fact · changed in prisma 6.1.0 (2024-12-17) · chargeable

Anchored to 6.1.0 (2024-12-17), the first release whose contents the subject says it cannot describe, not to the current release. Thirty-odd further releases up to 7.2.0 (2025-12-17) precede the stated 2026-01 cutoff.

What the model believes

"First release I know only as a bare version number, with no real idea what shipped in it: anything after roughly 6.1 ... I have no reliable knowledge of anything resembling a Prisma 7."

Impact

A major version, a mandatory config file and the removal of the no-argument constructor all sit inside the blind spot, which is why this run produces fourteen findings rather than the two or three a near-current subject produces.

Verified against

F12 · States the generated enum object maps member names to themselves (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.

S2silently-wrong · generated enum values · behavior-changed · changed in prisma 7.0.0 (2025-11-19) · chargeable

What the model believes

"The @maped string (\"mixplat/sms\") is what's actually stored in the underlying Postgres enum type; PaymentProvider.MIXPLAT_SMS is what you use in code", with the generated object shown as MIXPLAT_SMS: 'MIXPLAT_SMS'.

What it wrote
export const PaymentProvider = {
  MIXPLAT_SMS: 'MIXPLAT_SMS',
  INTERNAL_TOKEN: 'INTERNAL_TOKEN'
} as const
What works on prisma 7.10.0
export const PaymentProvider: {
  MixplatSMS: 'mixplat/sms'
  InternalToken: 'internal/token'
}
Impact

Silent: comparisons and serialised payloads carry the database value, not the member name.

Scope note

Charged against the generated shape 7.0.0 documents. The pre-7 shape is not separately verified; what is charged is the claim about today.

Verified against

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.

KindAPINote
correct— Prisma 6.0 dated to "around November 2024" — 6.0.0 published 2024-11-28. The one version claim in the run that is exactly right.
correct— The v6 material itself is accurate and well-organised: the hot-reload singleton, migrate deploy rather than migrate dev in CI, the replica-set requirement for MongoDB transactions, db push for schemaless workflows. Nothing here is wrong for the version it belongs to. (The v6 escape hatch: correct v6 usage is only a finding when it is presented as current. It was — see F1-F13 — but the underlying knowledge is sound.)
missprisma.config.ts Question (d) recalled prisma.config.ts unprompted — "I recall Prisma introducing a standalone prisma.config.ts file at some point in the 6.x line" — and correctly named the seed command as one of its jobs. (It is the one v7-shaped fact the subject reached, held with stated low confidence and never used in any task answer. Recorded because it shows the boundary is soft rather than a wall.)

Sources

Battery specification: prompts/prisma.md in the studio repo. Every finding above also carries its own citation.