---
library: zod
library-latest: "4.5.2"
library-latest-verified: 2026-08-29
model: claude-opus-5 (spawned via Agent model alias "opus")
model-self-reported-cutoff: 2026-05
model-believed-latest: "4.1.x; expects unknown 4.1.x/4.2.x patches since; 'I am not aware of a Zod 5'"
test-date: 2026-08-29
battery: zod/v1 (6 idiomatic tasks + 3 direct questions)
tool-uses-during-test: 0
verified-against: https://zod.dev/v4/changelog · https://registry.npmjs.org/zod/latest
status: open (no retest yet)
json: opus-5.json
---

# Zod × Claude Opus 5 — findings

## F1 · S4 wrong-metadata · version recency lag *inside* the training window
Model believes the latest Zod is the 4.1.x line (dated to ~August 2025) and states it is unaware
of anything past 4.2.x. Truth at test date: 4.5.2.
The model's self-reported training cutoff is **May 2026** — nine-plus months *after* the point
where its Zod knowledge actually stops. Cutoff date is not knowledge recency.
Cite: https://registry.npmjs.org/zod/latest (version 4.5.2, fetched 2026-08-29).

The model named the mechanism itself, unprompted: "my knowledge of any given library thins out
well before the nominal cutoff — recency in the training corpus is uneven, and for a fast-moving
package like Zod the last few months before a cutoff are always sparsely represented."
This is the single most product-relevant sentence produced by the harness so far. It means a
"recent cutoff" is not a defence against stale priors, and it means the Index has a job even for
frontier models — see JOURNAL/004.

Mitigating: calibration was excellent. It graded its own confidence per claim ("high for 'the
current major is 4'... low for the precise current patch version") and instructed the reader to
check npm. It did not invent a changelog.

## No S1/S2/S3 findings on battery v1
All six code tasks produced correct, current Zod 4 code, and the direct questions were answered
correctly. Beyond the battery it volunteered several genuinely current v4 facts: `z.partialRecord()`,
exhaustive records for enum keys, `.merge()` changed in favour of `.extend()`,
`z.treeifyError` / `z.flattenError` / `z.prettifyError`, `z.stringbool()`, `z.toJSONSchema()`,
Standard Schema interop, and Zod Mini.

## Method notes
- Battery v1 is **saturated** for this subject — designed against a pre-v4 model, it no longer
  discriminates. See `prompts/zod.md` v2 TODO.
- This is a self-test: the operator model testing itself. Recorded transparently. It is a weaker
  result than an independent test and should be read as such, though nothing here depends on
  self-assessment — every finding is a diff against a fetched primary source.

## Unverified candidate (do NOT ship as a finding until confirmed)
Model asserted Zod 4 **removed** `.deepPartial()`. The Zod GitHub releases page appears to show
`z.deepPartial()` *returning* in a functional form in a post-4.1 release, alongside
`.exactPartial()`. If confirmed, this is a stale prior of a new and more interesting kind: not
"model is stuck on v3", but "model is stuck on an intermediate v4 minor whose removal was later
reversed." Verify against zod.dev before shipping. Probe in v2.
(The releases page returned internally inconsistent dates during extraction, so no dates from it
are recorded as fact anywhere in this dataset.)