The Stale Priors Index

Read this before the boundary numbers

A boundary is a draw, not a constant. It is a self-report elicited by a battery, and when the same battery goes to the same model twice — byte-identical prompt, same model alias, same day, the runs concurrent and blind to each other — the draws do not always agree. The widest disagreement measured so far is Claude Sonnet 5 on langchain, where 2 measurements gave 2 answers 399 days apart: 0.3.0 (2024-09-13) against 1.0.0 (2025-10-17) — one release apart.

Days are the wrong ruler on their own. Those two draws named adjacent releases; the calendar gap is that wide only because langchain published no minor or major release in between. Counted in releases — how many candidate answers the instrument actually slid across — the worst pair is a different one: Claude Opus 5 on prisma, 13 releases apart across 204 days. Both numbers are published per pair in index.json, counted from the release timelines stored alongside the runs.

26 of the 28 model×library pairs behind this page have been measured more than once, and 6 of those disagree. The other 2 are single draws of the same instrument, and their spread is unknown. Treat any of those dates as one sample rather than a measured constant — and treat any intersection computed from them the same way. Where a model’s brackets no longer share a common date, this page prints that instead of a window.

Recomputed from the runs on every build. Replicates are published in full like any other run, and a replicate never supersedes what it replicates — the runs behind the example above are v1r-a, v1r-b. The reasoning, including what it does not undermine, is in JOURNAL 023 and JOURNAL 024.

How sharp is a model’s attribution boundary?

Each run brackets one subject’s boundary on one library: it is somewhere at or after the newest release whose contents the model could correctly attribute to it, and strictly before the oldest release it could not. If a model has a single attribution boundary, every one of its brackets contains that date, so they intersect. Intersecting them is therefore a test, and it can fail.

This measures version attribution — whether the model can say which release carried a feature — not whether it knows the feature. The two come apart, and we have measured them coming apart: see what the boundary does and does not measure.

0 of 4 subjects measured on two or more libraries have a boundary that one date can explain. For the others, no date fits — but that failure is made of two different things and we separate them. For 3 of 4, it is the cross-library reading: the model knows a later release of one library than of another, so “what does this model know?” has no answer that is not per-library. For 1 — Claude Opus 5 — it is not: the libraries can be reconciled with each other, and what cannot be reconciled is the same library measured twice. That is the instrument disagreeing with itself, and it is reported as such rather than counted as evidence about the model. Whether an attribution boundary is a date at all is a property of the model, not of the method.

The brackets this is computed from

Recomputed from the runs on every build, never asserted. Superseded runs are excluded; a subject measured on fewer than two libraries is omitted because one bracket intersects only with itself. Both ends of every bracket are release dates from the primary sources cited on the run pages.

The result we did not expect

On 7 of the 7 libraries where we have tested more than one subject, the model with the latest stated training cutoff is not the least stale one.

• On better-auth: Claude Fable 5.1 states the latest cutoff (2026-06) and lags ~11 months, while Claude Fable 5 (cutoff 2026-01) lags only ~6. run Both stop at the same release (1.3.0, 2025-07-19), so the later cutoff bought no later knowledge — the entire difference is the cutoff date.
• On langchain: Claude Fable 5.1 states the latest cutoff (2026-06) and lags ~8 months, while Claude Fable 5 (cutoff 2026-01) lags only ~3. run Both stop at the same release (1.0.0, 2025-10-17), so the later cutoff bought no later knowledge — the entire difference is the cutoff date.
• On next.js: Claude Fable 5.1 states the latest cutoff (2026-06) and lags ~6 months, while Claude Sonnet 5 (cutoff 2025-06) lags only ~0. run They stop at different releases (16.1.0 vs 15.5.0), so the later-cutoff model genuinely knows less of this library.
• On prisma: Claude Fable 5.1 states the latest cutoff (2026-06) and lags ~7 months, while Claude Opus 5 (cutoff 2026-05) lags only ~5. run Both stop at the same release (7.0.0, 2025-11-19), so the later cutoff bought no later knowledge — the entire difference is the cutoff date.
• On tailwindcss: Claude Fable 5.1 states the latest cutoff (2026-06) and lags ~14 months, while Claude Fable 5 (cutoff 2026-01) lags only ~9. run Both stop at the same release (4.1.0, 2025-04-01), so the later cutoff bought no later knowledge — the entire difference is the cutoff date.
• On valibot: Claude Fable 5.1 states the latest cutoff (2026-06) and lags ~13 months, while Claude Fable 5 (cutoff 2026-01) lags only ~8. run Both stop at the same release (1.1.0, 2025-05-06), so the later cutoff bought no later knowledge — the entire difference is the cutoff date.
• On zod: Claude Fable 5.1 states the latest cutoff (2026-06) and lags ~10 months, while Claude Fable 5 (cutoff 2026-01) lags only ~5. run Both stop at the same release (4.1.0, 2025-08-23), so the later cutoff bought no later knowledge — the entire difference is the cutoff date.

Computed from the runs below on every build, not asserted. If a retest stops supporting it, this box disappears on its own. The mechanism is not “one model is better”: on 6 of these 7 libraries the two subjects stop at the same release regardless of cutoff, which is the cleanest statement of the result: a later training cutoff does not buy later library knowledge.