Knowledge Cutoff

A knowledge cutoff is the date after which a language model has no training data. Everything the model learned came from a corpus collected up to that point. A product launched later, a library API that changed, an executive who moved companies, a price that went up: none of it reaches the model unless you hand it the information when you call it. The cutoff is a property of how models are built, not a defect the next release fixes, and much of the retrieval and tooling layer around a production model exists to work around it.

Why does a model have a cutoff?#

A training run works on a fixed snapshot of data and takes months, so the corpus is frozen before training starts. Once training ends, the weights are static files. Serving a model is inference only: the same parameters answer every request, and nothing the model reads in production flows back into them. A provider's updated model is a new training run on a newer snapshot, not a refresh of the old one.

As of October 2026, Anthropic lists a cutoff of June 2026 for its current models, Claude Opus 5.5 among them, and OpenAI lists April 30, 2026 for GPT-6 Astra and May 18, 2026 for GPT-6 Luna. So the newest models are already four to six months behind the date of this page, and the gap grows every day until the next release. Older models stay in service for months after a successor ships, so the model behind a product you use may be further behind than the newest one.

Is the cutoff on the model card the real one?#

Not exactly. Cheng and colleagues showed in their 2024 paper "Dated Data" that a model's effective cutoff, what it knows reliably, often differs from the reported one and varies by topic. They traced two causes. Web crawls such as CommonCrawl carry a lot of old text inside new dumps, so a corpus labelled with a recent date is mostly older writing. And deduplication schemes, which should strip repeated copies, run into trouble with near-duplicates and reworded copies of the same text. Add the plain fact that the web has written less about last month than about last year, and the final stretch before any cutoff is thinly covered.

Anthropic makes the gap visible by publishing two dates per model: a training data cutoff and a reliable knowledge cutoff, the date through which knowledge is "most extensive and reliable". Claude Sonnet 4.6, released in February 2026 and still available, has training data through January 2026 and a reliable cutoff of August 2025, a five-month band of partial awareness. On the current models both dates read June 2026. Treat the last months before any stated cutoff as patchy whatever the label says, because the thin coverage of recent events comes from the data, not from how the vendor writes the date. Look up both dates for every model you deploy, including the older ones still in production.

What goes wrong after the cutoff?#

The harm comes from how the model answers anyway. A language model is a next-token predictor, not a database with empty rows, so when asked about something after its cutoff it does not return "no record found". It writes the most plausible answer from what it did learn, in the same fluent tone it uses for facts it knows. Ask for the current version of a fast-moving library and it names the last version it saw. That is hallucination with a specific, predictable cause, and it is hard to spot because the answer is usually almost right: a real product with old pricing, a real API with a parameter that has since been removed.

Code generation shows it most plainly. A developer asks for an integration against an SDK that changed its auth flow after the model's cutoff. The model writes clean, idiomatic code against the old flow. It compiles, it looks reviewed, and it fails only at runtime. Nothing in the output signals that it is stale.

The model also does not know today's date unless you tell it, so "the latest", "this year" and "recently" are computed from wherever its training data ends. Bigcircle recommends putting the current date in the system prompt of any assistant that answers time-sensitive questions, because it costs a dozen tokens and stops the model treating its cutoff as the present.

How do RAG, tools and web search close the gap?#

RAG fetches current documents from your own corpus at query time and places them in the prompt, so the model reasons over text it can see now rather than text it memorised then. Update the index and the next query sees the change, with no retraining. Tool calling does the same for live systems: a model that can query your database or a pricing API pulls post-cutoff facts on demand. OpenAI and Anthropic both offer hosted web search tools that return results with citations.

Two things these do not fix. They help only when the system calls them, and models can be reluctant to reach for a tool, so a production prompt often needs a plain instruction such as "for anything time-sensitive, search before answering". And they do not change what the model believes: retrieved text competes with memorised text, and a model can blend a fresh document with a stale belief. That is why fine-tuning is the wrong tool for freshness. It writes today's facts into weights that go stale tomorrow, while an index can change before the next query. Show a date or a source on any time-sensitive answer, so the user can judge how fresh it is.

Freshness is a property of the data, not only of the model. On Prospex, our own prospect-research engine, recency is carried as metadata from the moment a source is ingested, so a stale source can be recognised as stale instead of being read as current. Store a date on every document in the index and pass it to the model with the passage, or the index goes stale the same way the weights do.