Does Claude Sonnet 5 know zod 4?

Partly: in 2 runs, Claude Sonnet 5's zod attribution reaches 4.0.0 (2025-07-10), inside zod 4, and stops there — zod was at 4.5.4 when this index last verified against it (2026-09-06). That is ~6 months below the training cutoff the subject stated in those runs (2026-01). 11 findings are currently charged against Claude Sonnet 5 on zod (2x S1 breaks-build, 9x S2 silently-wrong), each reproduced in a published run and checked against zod's own release notes. Read the boundary precisely: it is the newest release whose contents the model can correctly attribute to that release, not the newest zod feature it can use. Past it a model often writes working code with a newer API while naming the wrong release for it.

Answer class inside, decided by one rule applied to every page of this kind: every measured boundary is at or above the first release of the major named in the question. Every figure below is read from the dataset at build time; nothing on this page is written by hand.

The measurements

BatteryNewest release it can placeOldest it cannotLag vs stated cutoff
v2 2026-08-29 4.0.0
2025-07-10
4.1.0
2025-08-23
~6 months
v4-b 2026-09-02 4.0.0
2025-07-10
4.1.0
2025-08-23
~6 months

2 further runs of this pair established only one end of the interval, or measured the instrument rather than the library; they are listed under Runs below.

How repeatable is this?

4 measurements of this pair, all giving the same boundary. Of those, 2 came from the same stored prompt file, sent concurrently and blind: they agreed exactly.

zod published 5 minor or major releases in the twelve months before this model’s stated cutoff, which is the scale a spread should be read against.

What Claude Sonnet 5 gets wrong about zod

“Chargeable” means the change was published before this model’s own stated cutoff, so it had the opportunity to know it.

SeverityBeliefChanged inChargeableProof
S1breaks-build .extend() overwrite on a refined schema throws
.extend() / .safeExtend()
4.1.0
2025-08-23
yes run · source
S1breaks-build .pick() on a refined object schema throws
.pick() / .omit()
4.3.0
2025-12-31
yes run · source
S2silently-wrong asserts z.fromJSONSchema() does not exist, with high confidence
z.fromJSONSchema()
4.2.0
2025-12-15
yes run · source
S2silently-wrong hand-rolls exclusive-or, then advises abandoning schema-based validation
z.xor()
4.2.0
2025-12-15
yes run · source
S2silently-wrong Denies that the library can consume a JSON Schema document at runtime and prescribes Ajv as a new dependency
z.fromJSONSchema()
4.2.0
2025-12-15
no run · source
S2silently-wrong Denies that the library has an exclusive union primitive
z.xor()
4.2.0
2025-12-15
no run · source
S2silently-wrong Denies that the library has any way to make an object key omittable while rejecting an explicit undefined value, and argues the gap is structural
.exactOptional()
4.3.0
2025-12-31
no run · source
S2silently-wrong States that an intersection of two strict object schemas cannot parse an object carrying keys from both sides
intersections involving z.strictObject()
4.3.2
2025-12-31
no run · source
S2silently-wrong claims Zod cannot distinguish a missing key from an explicit undefined
z.undefined() object properties
4.4.0
2026-04-29
no run · source
S2silently-wrong wrong runtime prediction for tuple defaults
z.tuple() defaults
4.4.0
2026-04-29
no run · source
S2silently-wrong misses z.httpUrl(), frames the leniency as a security problem to hand-roll around
z.httpUrl()
4.4.0
2026-04-29
yes run · source

What to do about it

The zod correction pack states what is true now for each corrected fact, with a primary-source citation, as markdown you can paste into a rules file (raw). What a correction pack measurably changed when one was tested — a pre-registered run on zod — is on the benchmark page, including where it changed nothing.

Runs

The same question, asked of the others

All of them at once: Which Claude model knows zod 4 best?

Other subjects on zod:

Claude Sonnet 5 on the other libraries: