What is an LLM's knowledge cutoff, and why is it fuzzy rather than a hard date?

## What the cutoff is A model's parametric knowledge — what it can say with no tools and nothing in the prompt — is a compressed statistical summary of the text it was trained on. That text was collected up to some point in time. Anything that happened afterwards is simply absent from the weights. That boundary is the knowledge cutoff. It gets reported as a single month because a single month is easy to communicate. The reality underneath is a gradient. ## Four reasons the boundary is soft **Coverage decays toward the end.** Writing about an event accumulates for months or years afterwards — analyses, tutorials, forum threads, follow-up reporting. A crawl run in month N sees years of material about month N-24 and almost nothing about month N-1. So the model's grasp of the last stretch before its cutoff is measurably weaker than its grasp of a year earlier, even though both are technically inside the window. **Sources lag.** Archives, dumps, curated datasets and licensed feeds are assembled and processed before they reach a training pipeline. Much of the corpus is effectively older than the crawl date stamped on it. **Later stages can add newer data.** A mid-training refresh or post-training material may include text more recent than the bulk pretraining crawl. This means the model can have patchy awareness past its nominal cutoff — strong on whatever the late data covered, absent on everything else. **The model does not know its own cutoff.** There is no internal timestamp. Asked directly, it generates a plausible date the way it generates any other text, which may be a date it saw repeated in documents. Treat a self-reported cutoff as a guess, not as metadata. ## The failure this produces Consider a model asked about a technical specification. The crawl captured revision 3, which was superseded three months later. The model describes revision 3 fluently, with correct detail — and with no signal at all that a newer revision exists, because nothing in the weights marks a fact as expired. Confidence is a function of how often something appeared in the corpus, not of whether it is still true. This is why staleness is more dangerous than ignorance. A model that says "I don't know" is easy to handle. A model that gives you a well-formed, superseded answer looks exactly like a correct one, and the domains where it hurts most — regulations, standards, prices, APIs, medical guidance, security advisories — are precisely the ones that revise on a schedule. A second, related artefact runs the other way. Because writing about a topic accumulates after the fact, questions about things *near* the cutoff often produce answers built from early, preliminary coverage — the initial announcement rather than the settled understanding. ## What actually mitigates it The only reliable fix is to put the current facts in the model's input: retrieved documents, tool results, a current-date statement, or the authoritative record itself. A model reasons well over text it is given even when its weights are stale, so the design instinct is to treat parametric knowledge as background and time-sensitive facts as something the system must supply. Supporting practices: state the current date in the prompt rather than letting the model assume; design prompts so unsupported claims about volatile subjects are discouraged; and for anything regulated or fast-moving, require a citation to supplied material rather than accepting an unsourced recollection. What does *not* work is telling the model to "only use current information" — it has no way to distinguish current from stale inside its own weights. ## The related corpus-side artefact: contamination The same crawl that creates the cutoff also creates a scoring hazard. Public evaluation questions circulate on the web in blog posts, tutorials and repositories, so they can end up inside the pretraining corpus. When they do, a reported score reflects partly recall of the answer rather than capability, which is why data pipelines run decontamination — removing documents matching held-out evaluation text — and why teams keep private or freshly collected evaluations that no crawl can have seen. Contamination is hardest to catch when the leaked material is paraphrased rather than verbatim, since string-matching removal will miss it. ## What interviewers are checking That you understand the cutoff as a property of *data collection*, not a switch; that you can name why the boundary is gradual; and that you reach for supplying context rather than prompt wording as the mitigation. Mentioning that the model cannot report its own cutoff reliably is a good signal, because it is a mistake people make in production.