Knowledge Cutoff

A knowledge cutoff is the date after which a language model's training data ends. Everything published after it is absent from the model's weights, and because the model has no internal sense of what is missing, it answers questions about later events in the same confident register it uses for things it genuinely learned.

The cutoff exists because pretraining runs against a frozen corpus. Collecting, filtering, and deduplicating a web-scale dataset takes months, the training run takes more, and evaluation and safety work take more still, so a model usually ships with a cutoff somewhere between several months and a year before its release date. Providers publish that date on the model card. What the card does not describe is the decay around it: coverage thins well before the stated date, because the web had not finished writing about the most recent months when the snapshot was taken. A model whose card says March is often noticeably weaker on January than on the previous June.

The resulting failure mode is easy to miss in testing. The model does not decline to answer. It quotes last year's price, names a model version that has since been superseded, or describes a company as independent after it has been acquired. Tavily, for instance, was acquired by Nebius Group; a model trained before that closed will describe Tavily as a standalone startup, fluently and without qualification. Nothing in the output signals staleness, so the error reaches a user rather than a monitor.

There are exactly three ways a fact gets to a model, and they price very differently. Training it in means another pretraining or fine-tuning run: a large fixed cost, a long lead time, no per-query cost afterwards, and a corpus that begins going stale the day it freezes. Retrieving it from a prebuilt index means calling an AI search API that queries a crawl someone else maintains. That is the cheap middle: as of July 2026 Linkup publishes €5 per 1,000 standard searches, Tavily bills credits at $0.008 each with a basic search costing one credit, and Exa publishes separate line items for search requests and for page contents. Freshness there is bounded by how often the provider recrawls. Fetching it live means the agent retrieves the page at request time, which is the only route that is current to the minute and also the slowest and most expensive per document.

For a product team the practical move is to decide per feature rather than per product. A support assistant answering questions about your own docs can tolerate an index refreshed nightly. A pricing comparison or a news summarizer cannot, and needs a live fetch on the specific fields that change. The mistake worth avoiding is treating the cutoff as a single hard boundary and assuming everything before it is safe. Where a claim has a date attached and a wrong answer has a cost, ground it, and log which route supplied the answer so you can tell a retrieval failure from a model failure later.