Knowledge Cutoff

An LLM doesn't know what happened yesterday unless you feed it yesterday.

It doesn't know what happened yesterday, unless you feed it yesterday.

Training corpora stop on a certain date. The world after that day is something the model has never seen. It won't go silent about it, though—it will extrapolate.

Signs you'll recognize:

• It writes code the way a library worked two years ago, long after the API changed.
• You ask for the latest model version and it states an outdated one with total certainty.
• It miscalculates how many days until next Wednesday, because it doesn't know what today is.

What the cutoff is

Training starts by collecting a corpus, and that collection has a cutoff date. Afterward come months of training, safety evals, and internal testing before a public release. So the model you use always knows less than today—and usually less than its own release date by several months. Claude's model documentation, for example, publishes a "reliable knowledge cutoff" for every model, often down to the month. claude-models

Two details are easy to miss.

Knowledge near the cutoff is thin. After an event happens, the web takes a while to accumulate enough discussion about it. So the months right before the cutoff are sparsely represented, and the model understands that stretch worse than earlier eras. Don't treat the cutoff as a clean line with "knew everything before, nothing after."

The cutoff the model reports isn't reliable either. Ask it when its knowledge stops and the answer is generated text—it may come from the system prompt or it may be invented. For an accurate date, check the official docs.

Why it's wrong with such confidence

"I don't know" is not a state the model has. For anything past the cutoff it has no memory—but it has plenty of patterns for what such things look like. So it extrapolates: increment the version number, follow the usual roadmap convention, guess an appointment the way the industry normally does. The result is perfectly reasonable and simply not true.

The most dangerous territory is fields that change fast and have rigid formats, because those two traits together produce the most convincing fabrications:

The last two rows get ignored most often. Whenever your prompt uses "latest," "current," or "this year," ask yourself: does it know what day it is?

How to feed it today

The fix isn't on the model's side; it's on yours. One sentence covers it: anything that can go stale must be provided in this request—don't count on the model remembering.

• Put today's date in the system prompt. It costs almost nothing and pays off disproportionately. A single line, "Today is August 31, 2026," fixes relative-date math and reminds the model how old it is when you ask for the latest something.
• Retrieve facts before answering. Pull the actual source text into the context and have it answer from the material. That converts a recall question into a reading-comprehension one, where the model is far stronger. Just constrain it: answer only from these materials.
• Declare priority explicitly. Say "where the material conflicts with your existing knowledge, the material wins." Skip that line and it may blend the new information with old memories into a version that's wrong on both counts.
• Route real-time data through tools. Inventory, prices, order status—anything changing by the minute—should be looked up by calling an API. That kind of information should never come from the model's memory.

Two product-level moves round this out. First, pin versions: when asking for code against a library, name the version and ideally the key API signatures. Second, show the age of information in the UI: if an answer comes from model memory, say it reflects knowledge up to a certain date; if it comes from live retrieval, show the source and when it was fetched. When users can see the timestamp, misjudgments cost much less.