Knowledge cutoff vs the live web: the real gap is wider

A model's spec page gives one date, and it is tempting to treat it as the day the model stopped learning. Two things make the real gap wider. Vendors now publish more than one cutoff, and research shows that what a model actually knows about a given source can be older than any date on the spec page. This post turns both into a number of months you can compare with the pages your app depends on.

Two dates on the spec page

Start with the dates the vendor publishes. Anthropic's model pages list two: a reliable knowledge cutoff, described as the date through which the model's knowledge is most extensive and reliable, and a training data cutoff, described as the broader range of data used.

They are not always the same month. Claude Haiku 4.5 lists a reliable knowledge cutoff of February 2025 and a training data cutoff of July 2025, a spread of 5 months. Claude Opus 4.6 lists May 2025 and August 2025, a spread of 3 months. The current lineup in the overview table lists June 2026 for both.

Use the reliable knowledge cutoff for planning. By the vendor's own description, it is the last month for which the model's knowledge is most extensive and reliable.

The effective cutoff can be earlier still

The 2024 paper "Dated Data: Tracing Knowledge Cutoffs in Large Language Models" asks a sharper question: for a given source, which version of it does the model actually know? The authors call the answer the effective cutoff. They estimate it by measuring a model's perplexity on monthly versions of the same documents and taking the month where perplexity is lowest.

They built two test sets for this: 5,000 frequently edited Wikipedia documents, collected monthly from April 2016 to April 2023, and New York Times articles from January 2016 to July 2020. Their main finding is that effective cutoffs often differ from reported cutoffs, and that they differ between sources inside the same model.

The clearest case is RedPajamas, a dataset that includes an explicit 2023 Wikipedia dump. Models trained on it still matched 2019 versions of the Wikipedia pages best. In the paper's search of the training data, over 80% of the Wikipedia-like documents came from versions older than 2023.

The paper names two causes:

• Old pages in new crawls. A 2023 CommonCrawl dump contained many Wikipedia versions going back to 2016. A new crawl is not a crawl of new content.
• Deduplication that misses near-copies. Versions that differ only in whitespace or reference numbers survived, and one article appeared 10 times in one dataset. Repeated old versions outweigh the single new one.

Two limits apply. The study measured models trained on open datasets, and the authors call their estimates for models with unpublished training data speculative. So treat this as a reason to assume your model's knowledge of a topic may be older than the stated date, not as a number for any specific commercial model.

Compute the gap in months

The gap that matters runs from the model's reliable cutoff to the day a user asks the question. It has two parts.

The first part exists before anyone uses the model. Claude Haiku 4.5 was released on October 15, 2025, 8 months after its February 2025 reliable cutoff. Claude Opus 4.6 was released on February 5, 2026, 9 months after its May 2025 reliable cutoff.

The second part grows every day the model stays in service. Claude Opus 4.6 is listed with a retirement date of not sooner than February 5, 2027. An app still calling it on that day asks a model whose most reliable knowledge is 21 months old.

Run the same sum for your own model:

1. Take the reliable knowledge cutoff from the vendor's model page.
2. Count the months from that date to today.
3. Treat that number as the minimum age of the model's knowledge, and assume some topics are older.

Compare the gap with the page

Now put the gap next to the pages your app answers from. The guide on why LLM apps need live web data sorts page types by how fast they change: status pages in minutes, docs and changelogs in days, pricing in days to weeks, policies in weeks to months.

The decision follows. If a page type changes faster than your gap, the model's memory of it is likely out of date, and the only way it sees the current version is a read of the page at question time. With a gap of 8 months or more, that covers almost every page type except reference and history pages.

When you pass the page, pass its fetch time with it, so the model can weigh the page against its memory:

Today is 2026-11-10. Your training data is older than the sources below.
If a source and your memory disagree, the source wins; say when it was fetched.

[source 1]
url: https://example.com/docs/changelog
fetched_at: 2026-11-10T08:05:12Z
---
(page Markdown)

The fetch timestamps post covers the header format in detail.

A quick test with your own pages

Pick one public page your users ask about that changed after your model's reliable cutoff, such as a changelog entry. Ask the model a question about it twice: once with no context, once with the current page in the prompt. If the first answer describes an older version with confidence, you have measured your gap on a real page, and you know which questions need the live read.

Where Live Web Data API fits

Live Web Data API reads public pages you name and returns them as Markdown, plain text or HTML. Every request fetches the page live; there is no cache. Each URL comes back with statuses[].fetchedAt, which fills the fetched_at line above. It does not search for pages or crawl a site, so you bring the URL. To see what your test page looks like as Markdown before you put it in a prompt, try a URL in the playground.