Claude’s Knowledge Cutoff by Model

Anthropic publishes a training data cutoff for every Claude model, and for the current generation it publishes a second, earlier date it calls the reliable knowledge cutoff. The gap between them explains most of what people find confusing about what a model does and does not know.

The documented dates

The authoritative list is the model comparison table on Anthropic’s model overview, which has a training data cutoff column. As of this page’s date it gives, among others:

• Claude 3 Opus and Claude 3 Haiku — August 2023.
• Claude 3.5 Sonnet — April 2024.
• Claude 3.5 Haiku — July 2024.
• Claude 3.7 Sonnet — November 2024.
• Claude Opus 4 and Claude Sonnet 4 — March 2025, with a documented reliable knowledge cutoff of January 2025.

Why there are two dates, not one

A training corpus is not a clean snapshot taken on one day. Data is collected, filtered and processed over months, and the closer an event is to the end of collection, the less of the internet has finished writing about it. An event from three years before the cutoff has been summarised, corrected, argued about, referenced in a thousand later documents and quietly fixed where it was wrong. An event from three weeks before the cutoff appears once, in early reporting, with none of that reinforcement.

So the model’s knowledge does not stop at a wall. It thins out over the final months of the corpus. The training data cutoff is the end of collection; the reliable knowledge cutoff is Anthropic’s published estimate of the point up to which the model can be depended on. The tail between them is where the model has heard of something but gets details wrong — which is a worse failure than not knowing, because it comes back fluent.

It is also why “knowledge cutoff” and “training data cutoff” are not synonyms even though they are used as such everywhere. One is a fact about the corpus and the other is a claim about behaviour, and only the first has a precise value. Where Anthropic publishes both for a model, the earlier one is the number to plan against; where it publishes only a training cutoff, assume the reliable edge sits some months before it rather than exactly on it.

A further wrinkle is that the cutoff bounds what the model absorbed, not what it can handle. A model with an early-2025 cutoff can work perfectly well with a library released last month if you put that library’s documentation in the context — the cutoff constrains recall, not comprehension. Conversely, no amount of prompting recovers a fact that was never in the corpus. Keeping those two apart is what turns the cutoff from a limitation you complain about into a parameter you design around.

This also explains a related behaviour that reads as a bug: a model being confidently wrong about its own release, its own name, or its successor. It cannot have been trained on documents about a model that did not exist when its corpus was collected.

Why asking the model is unreliable

“What is your knowledge cutoff?” is the obvious way to find out and the wrong one. The answer is generated the same way every other answer is: as a plausible continuation. Three separate things make it untrustworthy.

• The corpus thins near the end, so the model has seen relatively little about its own training period and is answering from documents about earlier models.
• The system prompt frequently states a date, and on Anthropic’s own products it does. A model repeating a date from its system prompt is reporting configuration, not introspection — and through the API, where you write the system prompt, it has nothing to repeat.
• The answer varies with phrasing and sampling. A fact you can get two different values for by asking twice is not a fact you can build on.

The model comparison table is the source. The model is not.

Finding the effective edge for your domain

The published date is a property of the corpus, not of your subject. Coverage of a heavily documented area — a mainstream programming language, a large public API — extends closer to the cutoff than coverage of a niche one, because there was simply more written about it sooner. So the question worth answering is not “when does the model stop knowing things” but “when does it stop knowing my things”, and that is answerable with a short, honest test you run yourself.

1. Pick fifteen to twenty facts from your own domain with known dates, spread across the eighteen months before the published cutoff. Version releases, renamed fields, deprecated endpoints, changed defaults — anything with a date you can verify independently.
2. Ask about each one in a neutral form that does not leak the answer. “What is the default value of X?” rather than “Is it true that X now defaults to Y?”, which invites agreement.
3. Use temperature: 0 and an empty or minimal system prompt, with no date supplied. You are measuring recall, and a date in the system prompt changes what the model will guess.
4. Score against the real answers and plot correctness by the date of the fact. What you are looking for is not a cliff but the month where accuracy starts sliding.

The result is a number you can act on: the point past which your application must supply the facts rather than rely on recall. It also tends to settle arguments about whether a newer model is worth migrating to, because it converts “its cutoff is four months later” into a statement about the things you actually ask it.

Designing around a cutoff

For anything time-sensitive, the cutoff is a property to engineer around rather than to wait out.

1. Put today’s date in the system prompt. One line — "Today is 2026-08-11." — removes a whole class of error where the model assumes the present is its training period and computes relative dates wrongly.
2. Supply the facts you need it to be current about. Retrieval is not a workaround for a cutoff; it is the design. A model reading a document you provided has no cutoff problem with respect to that document.
3. Instruct it to distinguish recall from provided context. Asking for an explicit note when an answer comes from memory rather than from supplied material makes the stale answers visible instead of blended in.
4. Pin the model ID. The cutoff belongs to a specific dated model, and an alias that silently moves to a newer model moves the cutoff with it. That is usually an improvement and it is still a change in behaviour you did not schedule. See pinning a Claude model version.

One consequence worth stating plainly for anyone writing code with model assistance: library APIs released after the cutoff are exactly the territory where a model produces confident, plausible, wrong calls. The fix is the same as above — put the current documentation in the context — and it works far better than asking the model whether it is sure.