Concept · Foundational
Training cutoff
The date a model's knowledge stops. Simple in principle, and the source of more quiet errors than almost anything else, because the model does not reliably know where its own boundary is.
Last verified 11 August 2026 · Per-model dates live on Model facts
A model is a snapshot, not a subscription
Training happens once. An enormous quantity of text is gathered, the model learns from it over a period of months, and then it is finished and shipped. From that point on, the thing you are talking to does not learn. It does not read the news. It is not quietly updated overnight. What it absorbed during training is what it has, permanently.
This runs hard against the instinct that software gets better in the background. The chat product around the model changes constantly, so the whole thing feels live. The model underneath is a fixed artefact, and the only way it learns anything new is if you or the product put that information in front of it. Which is exactly what a search tool does, and why models with one behave so differently on anything current.
There are actually two dates, and the gap matters
Here is the part that almost nobody covers. A single "cutoff" implies a clean line: everything before it known, everything after unknown. The reality is blurrier, and at least one vendor is now honest enough to publish both edges. Anthropic lists two separate dates for every model:
- Training data cutoff — the outer edge of the material used. Nothing after this date was seen at all.
- Reliable knowledge cutoff — the earlier date through which the model's knowledge is, in Anthropic's own wording, most extensive and reliable.
Between those two dates sits a band where the model has some coverage, but thin and patchy coverage. And thin coverage is arguably more dangerous than none, because a model with fragments of a topic will confidently assemble them into a whole, whereas a model with nothing at all is at least more likely to say so.
The gap is not trivial. On at least one current model the two dates sit several months apart. Both are on Model facts, per model, side by side.
The practical reading
Treat the reliable date as the real cutoff for anything you care about, and treat the months after it as a zone of confident half-knowledge rather than a bonus.
The model doesn't know its own cutoff
This one surprises people, and it's the reason you can't simply ask.
Everything a model knows, it knows from training data. So for a model to know its own cutoff date, that date would have to have been well documented in text that existed before the model was trained. Which it obviously wasn't. At training time, the model's own release was still in the future.
So when you ask a model when its knowledge ends, it is not consulting a specification. It is inferring, from a sense of which events feel recent and which feel well covered. That inference is systematically biased early: the most recent months before a cutoff are always underrepresented, because the internet had not yet finished writing about them when the data was collected. A model therefore tends to underestimate its own cutoff, sometimes by a lot, and will state the wrong date with the same steady confidence it applies to everything else. → Hallucination
It also doesn't know what today is
A model has no clock. It cannot perceive the passage of time between your messages, and it has no idea how long ago it shipped. Chat products handle this by quietly inserting the current date into the conversation before you ever see it, which is why an assistant usually gets today's date right.
Strip that away — call the model directly through an API without supplying the date — and ask what year it is, and you'll get a guess anchored near the training data. If you're building anything where the current date matters, you have to tell it. It will not ask.
Where this bites
Version-specific technical detail. The worst category, and the one that catches builders. Library APIs, framework conventions, config syntax, deprecations. A model will confidently give you code against the version it learned, and stale code is uniquely nasty because it looks completely correct and fails for reasons that seem unrelated. Anything version-sensitive should come from current documentation, not from recall.
Prices and product specifics. Never trust a model on pricing. It changes without notice, promotional rates expire, and the model has no way to know that. This site's Model facts page exists precisely because that information cannot live in a model's head or in an undated paragraph.
Its own family. A model cannot tell you about models released after it, including its own successors. Asked to compare itself to something newer, it will either not recognise the name or reason about it from nothing. If a model tells you it's the latest available, that statement carries no information at all.
Anything that changed recently. Regulations, rankings, who holds which job, whether a company still exists, what the current advice is on something. All of it silently frozen.
The asymmetry that makes this hard. The model has no internal flag marking a topic as post-cutoff. It cannot detect the boundary from the inside — there's no felt difference between recalling something it learned and constructing something plausible about a period it never saw. Which means the burden of noticing sits entirely with you.
What to do about it
Give it a way to look things up. The single fix that addresses the root cause. A model with a working search tool is not limited to its training data. This is the main reason to prefer an assistant that can search over a raw model for anything factual, and it converts a recall problem into a reading problem.
Paste current material in. Same move as everywhere else on this site: put the up-to-date documentation, page or figures on the desk rather than asking the model to remember them. → Context windows
State the date when it matters. If you're working via an API, or asking anything time-sensitive, say what today is. Cheap, and it removes a whole class of confusion.
Look up the cutoff rather than asking for it. Vendors publish these dates. The model's own answer is a guess. Check the documentation, or Model facts.
Ask "as of when?" and treat the answer as a prompt to verify, not as an answer. It's a useful habit because it surfaces that a claim is time-sensitive at all, which is the part people miss.
Why this concept shaped this site
Worth being explicit, since it's the clearest example of the idea in action. Every page here carries a "last verified" date because of exactly this problem. Written content has a cutoff too, and it has the same defect as a model: an undated page cannot tell you how stale it is, and it goes on sounding just as authoritative years later.
A date stamp is the smallest possible fix. It doesn't make a page current, it makes the page's currency checkable, and that's the part that lets you calibrate how much to trust it. The same logic is why every hard number on this site is quarantined onto one dated page instead of scattered through prose that would rot invisibly.
Where this page stops
The two engineering answers to this problem each get their own page. Tool use covers how a model reaches outside itself to search and fetch. RAG and retrieval covers pulling in your own documents at question time.
Sources
The two-date distinction, and the definitions quoted for each, come from Anthropic's models overview, fetched 11 August 2026, which publishes a reliable knowledge cutoff and a training data cutoff separately for every model. Anthropic is the only major vendor known to us to publish both; if others have begun doing so, this page should be updated to say so. The explanation of why models underestimate their own cutoff is a mechanical argument from how training data accumulates, not a vendor claim, and is presented as reasoning rather than citation.
Related → Hallucination · Context windows · Is what you're reading out of date? · All → Concepts