Knowledge cutoff
The date after which a model's training data ends; it knows nothing newer unless you supply it in the prompt or through tools.
A model learns from Training data collected up to a certain date, its knowledge cutoff. Anything after that — new laws, prices, product releases, software versions — is unknown to it.
Worse, it may not realise this and confidently give an outdated answer. To use current information you supply it at question time, through Retrieval-Augmented Generation (RAG), web search or other tools.
Someone back from a year at a remote research station. They are knowledgeable, but their news stops on the day they left, and they may not notice what has changed.
Trusting the model to know it is out of date. It usually answers in the present tense with stale facts; you must supply the date and fresh sources explicitly.
The cutoff is set by the Pretraining snapshot, sometimes extended by later post-training data. Models ship 3–12 months after their cutoff and stay in production for 12–24 months, so the effective staleness gap at the moment a user asks is often 1–3 years. Coverage near the cutoff is thin because the web had not yet written much about recent events; Cheng et al. (2024) found that a model's effective cutoff for a given resource often differs from the reported one, partly because of deduplication and stale copies in crawls.
Models misstate their own cutoff and the current date. Engineering responses: inject today's date into the system Prompt & system prompt; retrieve anything time-sensitive with effective dates; cite sources with dates (Attribution & citations); include post-cutoff questions in evals to test Abstention & relevance thresholds; and version your RAG store. Fine-tuning is a poor way to keep knowledge current — expensive to repeat and unreliable for fact injection. Providers publish training-data cutoffs per model; record them in your model registry.
Today's date and key current facts (product versions, policy effective dates) in every system prompt; retrieval or search for any time-sensitive question with effective dates in the index; model cutoff recorded in the model registry; ≥ 20 post-cutoff questions in the Golden set that the model must answer from retrieval or abstain on.
Developer-docs assistant: a team's codebase upgraded to a library major version released after the model's cutoff. The assistant kept suggesting removed APIs; 14% of generated snippets failed CI. Adding retrieval over the pinned version's docs (resolved from the lockfile) plus 'today is <date>; library X is at version <v>' in the system prompt cut failures to 2% and made answers cite the version-specific doc page.
Part of 'why RAG?': cutoff and private data are the two gaps retrieval fills. Staff line: 'A model's knowledge is a snapshot; anything that changes faster than its release cycle belongs in retrieval, not weights — and I test that with post-cutoff eval questions.' Expect: 'how do you know the model's cutoff?' — the provider's model card, then verify with dated probe questions.
Numbers worth knowing
- Release lag
- 3–12 months after cutofftypical across major providers
- Service life
- 12–24 monthsbefore deprecation
- Effective staleness at query time
- 1–3 yearsrelease lag + time in service
How to decide
| When | Do this |
|---|---|
| Facts change faster than every 6 months (prices, versions, regulations) | Retrieve them at query time; never rely on weights. |
| The model must reason about 'now' | Inject today's date and timezone in the system prompt. |
| A new model has a later cutoff | Still keep retrieval; re-run post-cutoff evals rather than trusting the card. |
Cost maths
Freshness via retrieval costs tokens: 2,000 retrieved tokens × 1M questions/month × $3/M input = $6,000/month (illustrative), less with caching of stable documents. Compare with one wrong regulatory or tax answer reaching a customer — the incident review alone costs more.
Operating it
- Post-cutoff eval accuracy < 90% → add or fix retrieval for those topics
- User corrections citing 'outdated' > 1% of feedback
- A dependency, regulation or price list changes → refresh index and add eval cases the same week
- Accuracy on post-cutoff eval questions < 90%
- Share of answers citing a dated source on time-sensitive routes < 95%
- User feedback tagged 'outdated' > 1%
When it goes wrong
A coding assistant suggested APIs that had been removed in the team's current major version of a library; 14% of generated snippets failed CI.
CI failure rate on assistant-generated PRs, plus a spike in 'deprecated' review comments.
The library's new major version was released after the model's knowledge cutoff; the assistant had no version context and answered from stale weights.
Retrieved docs for the exact versions in the repo's lockfile, put the versions and today's date in the system prompt, and added post-cutoff API questions to the eval set.
Related terms
Sources
- Dated Data: Tracing Knowledge Cutoffs in Large Language Models — Cheng et al., 2024paper
- Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks — Lewis et al., 2020paper
- Models overview (training data cutoffs) — Anthropic, 2026docs
Check yourself
Three questions. Every option is explained once you answer.