What “Knowledge Cutoff” Differences Mean for a Migration

A cutoff is published as a month, which makes it look like a switch: before this date the model knows things, after it the model knows nothing. It behaves nothing like that, and the difference is what decides whether a cutoff change matters to your application.

What a cutoff actually is

The stated cutoff is the boundary of the training corpus, not a boundary of the model’s competence. What the model actually has is a density gradient. An event from three years before the cutoff has been written about extensively, summarised, argued over and cross-referenced across thousands of documents; an event from three weeks before it exists in a handful of announcement posts that had not yet been discussed anywhere. Both are inside the corpus. Only one is well learned.

So recall degrades continuously as you approach the cutoff from below, and it does not stop cleanly above it either — a model can know about a thing announced after its cutoff because the announcement was trailed, predicted or leaked into the corpus in some other form. The practical statement is that a cutoff is a soft rolloff whose width is on the order of months, and a migration that moves the cutoff by nine months does not add nine months of reliable knowledge. It adds nine months of thinning knowledge on top of a few months of newly thickened knowledge in the region that used to be the old model’s edge.

That second part is the underrated half. The old model’s worst region — the last months before its own cutoff — becomes well-covered territory in the new one. If your application was quietly compensating for weak recall in that window, the compensation is now unnecessary and possibly harmful.

The model is a poor source on its own cutoff

Asking the model when its knowledge ends is a common shortcut and it is not reliable. The model has no privileged access to its own training configuration; any answer it gives is a generation conditioned on statements about model cutoffs that appeared in the corpus, which means it is systematically anchored to the cutoffs of earlier models it read about.

There is direct evidence of this in vendor documentation rather than only in argument. Anthropic’s prompting guidance includes a section on model self-knowledge whose recommendation is to tell the model which model it is, in the prompt, if the application needs it to identify itself or emit the correct model string (Anthropic, prompting best practices). A vendor recommending that you supply the identity in context is a vendor telling you the model does not reliably have it.

Where the shift changes behaviour

Four categories, in rough order of how often they bite.

• Implicit “now”. A model with no date in context infers the current date from its training distribution, and that inference lands near its cutoff. Any prompt containing “current”, “latest”, “recent” or relative date arithmetic changes meaning when the cutoff moves. This is the single highest-yield audit target and the fix is trivial: inject the real date into every prompt that has any temporal content.
• Latent API and library knowledge. Code-generating prompts that name a framework without pinning a version rely on the model’s recall of that framework’s shape. A later cutoff means newer idioms, which is usually an improvement and occasionally a break — generated code that targets a version your runtime does not have.
• Few-shot examples containing dated facts. An example that states something true at authoring time is now a statement the model may recognise as wrong. A model that follows instructions more literally will reproduce the pattern anyway; one that reasons more will hedge or correct it mid-answer, which is a formatting change your parser did not expect.
• Terminology drift. Product names, org names and technical vocabulary that changed between the two cutoffs. If your internal glossary was written to teach the old model a term it did not know, the new model may know a different, later meaning for the same string, and your glossary is now fighting it. That collision is the subject of glossary and terminology migration.

Where retrieval already covers it

If a fact arrives in the context from a retrieved document, the cutoff is irrelevant to whether the model knows it. That covers more ground than people assume and it is why cutoff panic is usually misplaced in RAG applications: the answer comes from the chunk.

But retrieval covers the fact, not the conflict. Two failure modes survive it. The first is a genuine contradiction between the retrieved corpus and the model’s parametric knowledge, where a model with a later cutoff is more likely to disagree with a stale internal wiki and more likely to be confident about it — and whether it defers to the context or to itself is a post-training property that differs between families. The second is that retrieval only fires on queries the retriever recognises; anything the router decided did not need a lookup is answered parametrically, and the cutoff applies in full. Both are worked through in the RAG implications page.

Auditing the prompt library

This is a grep, not a project. Three passes over the prompt directory and one addition to the template layer:

1. Grep for temporal language: current|latest|recent|today|now|this year|as of. Every hit is a prompt whose meaning depends on an inferred date. Most are harmless; the ones that are not are obvious on sight.
2. Grep for unpinned technology names against your dependency manifest. Any framework named in a prompt without a version is a latent-knowledge dependency.
3. Grep the few-shot example bodies for years and dates. Examples age silently because nobody re-reads them.
4. Add the current date to the shared prompt preamble as an explicit statement, rendered at request time. This removes the entire first category permanently and costs a handful of tokens per call.
5. Add one regression case per category to the suite: a question whose correct answer depends on today’s date, a code-generation case asserting the pinned version’s idiom, and a retrieval case where the chunk contradicts widely-known parametric knowledge so you can observe which one the new model trusts.

The last case is the one worth keeping permanently. Context-versus- parametric conflict is the cutoff behaviour most likely to differ between families, it is invisible in aggregate quality metrics, and it is the one your users will notice first.