Knowledge Cutoff

A knowledge cutoff is the date after which a model simply does not know what happened. Everything a model learned, it learned from a training corpus collected up to a fixed point in time. A product launched after that point, a library API that changed, an executive who switched companies, a price that moved: all of it is invisible to the model unless you hand it the information at query time. The cutoff is not a bug or a limitation to be patched in the next release; it is a structural property of how models are built, and most of the retrieval and tooling layer of modern LLM engineering exists to work around it.

Why the cutoff exists#

Training a frontier model takes months and tens of millions of dollars, so the training data is frozen as a snapshot and the model is trained on that fixed corpus. Once training finishes, the weights are static files. Serving a model is pure inference: the same parameters answer every request, and nothing the model reads in production flows back into them. There is no background process keeping it current. When a provider ships an updated model, that is a new training run on a newer snapshot, not an incremental refresh.

The numbers make the gap concrete. As of June 2026, OpenAI's GPT-5.5 has a knowledge cutoff of December 1, 2025, and GPT-5.4 sits at August 31, 2025. Anthropic's Claude Opus 4.8 has a reliable knowledge cutoff of January 2026, Claude Sonnet 4.6 of August 2025, and Claude Haiku 4.5 of February 2025. So even the newest frontier models are running five to sixteen months behind the present, and that gap only grows until the next release. A model answering a question about a framework version shipped in March 2026 may be working from documentation that is two major versions stale.

Reported vs effective: the cutoff is blurrier than the label#

The single date on a model card overstates how clean the boundary is. Cheng and colleagues showed in their 2024 paper "Dated Data" that a model's effective cutoff, what it actually knows reliably, often differs from the reported one, varying by topic and source. Two mechanisms drive this. Web crawls like CommonCrawl contain large amounts of older material inside newer dumps, so a "January 2026" corpus is mostly text written well before that. And events near the cutoff are thinly represented: something that happened three weeks before the snapshot appears in far fewer documents than something from two years earlier, so the model has seen it but barely learned it.

Anthropic now makes this distinction explicit by publishing two dates per model: a training data cutoff and an earlier "reliable knowledge cutoff." Claude Sonnet 4.6, for example, has training data through January 2026 but a reliable cutoff of August 2025: a five-month band where the model has partial, patchy awareness. The practical reading: treat the months just before any stated cutoff as a gray zone, not solid ground.

The trap: confident wrongness#

The dangerous part is not the missing knowledge; it is the delivery. A language model is a next-token predictor, not a database with null values, so when asked about a post-cutoff event it does not return "no record found." It generates the most statistically plausible answer from the patterns it did learn, in the same fluent, authoritative tone it uses for facts it genuinely knows. Ask a model with an August 2025 cutoff for the current version of a fast-moving library and it will confidently name the last version it saw, possibly with a plausible-sounding changelog. This is hallucination with a specific, predictable cause, and it is especially insidious because the answer is usually almost right: a real product name with outdated pricing, a real API with a removed parameter.

A worked example from code generation: a developer asks for an integration against an SDK that shipped a breaking auth change in February 2026. A model with a late-2025 cutoff produces clean, idiomatic code against the old auth flow. It compiles, it looks reviewed, and it fails only at runtime. Nothing in the output signals staleness. The fix is process, not prompting: any question whose answer can change over time, versions, prices, people, laws, current events, should be grounded in retrieved sources rather than trusted to model memory.

How RAG, tools, and web search bridge the gap#

The cutoff is the original reason the grounding stack exists. RAG fetches relevant, 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 memorized then; update the index and the next query sees the change, no retraining required. Tool calling generalizes this to live systems: a model that can query your database, hit a pricing API, or call a search endpoint pulls post-cutoff facts on demand. Provider-hosted web search tools (both OpenAI and Anthropic ship them) do the same for the open web, with citations.

Two things these bridges do not fix. They only help when the system actually invokes them, and models can be conservative about reaching for tools; production prompts often need explicit instructions like "for anything time-sensitive, search before answering." And they do not update the model's priors: retrieved text competes with memorized text, so a model may blend a fresh document with a stale belief. This is why fine-tuning is the wrong tool for freshness; it bakes today's facts into weights that go stale tomorrow, while retrieval keeps facts in a store you can update in seconds.

Practical takeaways#

Look up the actual cutoff for every model you deploy, and treat the months just before it as unreliable, not just the time after it. Never let model memory answer questions about versions, prices, people, or events; route those through retrieval, tools, or web search, and instruct the model explicitly to do so. Display dates or sources on time-sensitive answers so users can judge staleness. And when evaluating a new model release, remember that "newer model" means a newer snapshot, not a live one: the gap between cutoff and today starts growing again the day it ships.