The Fundamental Limitation: Training Data Has a Cutoff

Every large language model, including the models you call through the OpenAI SDK, is trained on a fixed snapshot of text collected up to a certain point in time. Once training finishes, the model's internal knowledge stops updating. It does not learn about events, prices, releases, or changes that happen after that cutoff, no matter how much time passes before you actually call the API.

This matters because a model's weights encode statistical patterns learned from its training corpus, not a live connection to the world. When you ask a model "what is the current version of a library" or "who holds this record today," the model can only answer from what it saw during training. If the true answer changed afterward, the model has no way to know that changed — it will confidently state the old answer as if it were still true.

This is different from a bug. It is a structural property of how these models work. A model does not "forget" recent information; it simply never had it. Understanding this distinction matters because it tells you the fix is not "wait for a smarter model" — it is "give the model a way to look things up."

Unit 9, Lesson 1 introduced the web search tool as one of the built-in tools available through the Responses API, mostly as a feature tour: how to turn it on and get a response that includes fresh information. This lesson goes deeper into the underlying problem web search solves, why it solves it in a fundamentally different way than trying to keep a model "more up to date," and when reaching for search is the right engineering decision versus when it is not.

Categories of Information That Go Stale

Not all knowledge decays at the same rate. It helps to think of information in three rough categories:

Stable knowledge rarely or never changes: the syntax of a well-established programming language, the boiling point of water, how HTTP status codes are grouped. A model trained a year ago is just as reliable on this as one trained yesterday.

Slow-moving knowledge changes over months or years: the current major version of a popular framework, a company's leadership, the population of a country. A model can be wrong here without anyone noticing quickly, which makes it a particularly dangerous category — the answer sounds plausible and often was correct at some point.

Fast-moving knowledge changes daily or hourly: stock prices, sports scores, breaking news, current weather, whether a service is experiencing an outage right now. A model has effectively zero reliability here unless it can reach outside its own weights.

Web search exists to cover the second and third categories. If your application only ever touches the first category, adding search is unnecessary overhead. If it touches the second or third, skipping search means shipping a feature that will quietly produce wrong answers, and the failure mode is worse than an error message — it is a wrong answer delivered with full confidence.

Why Retraining or "Just Using a Newer Model" Is Not a Real Fix

A natural first reaction is: "surely a newer model release solves this." It helps, but only partially, and understanding why clarifies what search actually buys you.

Training a large model takes weeks to months, plus additional time for evaluation and safety review before release. By the time a model ships, its training data is already months old. Even immediately after release, the model has a rolling blind spot for anything that happened during and after that training window. A few months later, that blind spot has only grown, because no further training is happening between releases.

Retraining also does not solve queries about things that are inherently transient rather than merely "not yet known" — there is no training run that will ever teach a model today's exchange rate, because that value does not exist as a stable fact to learn. It changes by the minute.

Web search sidesteps this entirely by not asking the model to know the answer. Instead, the model is given a tool that fetches current information at the moment of the request, reads it, and reasons over it. The model's job shifts from "recall a fact" to "read a document and summarize or extract from it," which is a task large language models are already very good at, and which does not degrade as time passes after training.

A Simple Illustration Without Search

Before looking at the tool itself, it is worth seeing the failure mode directly, because it motivates everything that follows in this unit.

from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-5.6-terra",
    input="What is the latest stable version of the 'requests' library for Python, and when was it released?",
)

print(response.output_text)

Running this without any tool enabled will produce an answer that reflects whatever the model last saw during training — which may well be an outdated version number, or a release date that is no longer current. The response will typically be phrased with full confidence, with no indication to the caller that the information might be stale. That absence of a warning is the core danger: a wrong answer that looks exactly like a right answer.

This example does not use any special configuration — it is a plain, tool-free responses.create() call, the same shape introduced back in Unit 1. The point is not the code itself, which is trivial, but the behavior: nothing here reaches outside the model's training data, so the model can only pattern-match to whatever version numbers and dates were common in its training set.

Where Grounding Comes In

The term you will see throughout this unit is grounding: producing an answer that is tied to actual retrieved evidence rather than solely to the model's internal parameters. A grounded answer is one where you can point to a specific source document and say "this claim came from there," as opposed to an ungrounded answer, which is the model's best guess based on patterns learned during training.

Web search is one mechanism for grounding — arguably the most general one, since it can reach almost any current, publicly available information — but it is not the only one. Retrieval over your own private documents (embeddings-based search over a database) is another form of grounding, and one you may combine with web search in more advanced applications later in this course. The distinction to hold onto for this unit is:

This unit focuses entirely on the middle row. By the end of it, you will be able to build applications that fetch current information, cite where that information came from, and handle the messier realities of the open web — conflicting sources, low-quality pages, and the need to test that your application's answers actually stay fresh over time.

When You Do Not Need Web Search

It is worth being explicit about the other side of this, because reaching for search by default has real costs: added latency (a search round trip takes time), added cost (search-enabled calls typically cost more per request), and added complexity (you now depend on an external, occasionally unreliable network resource).

Skip web search when:

• The question only touches stable knowledge, such as language syntax, mathematical facts, or well-established historical events far enough in the past to be settled.
• You already have the necessary current information in your own database or documents, in which case retrieval over your own data is a better fit than the open web.
• Latency is critical and the small risk of a stale answer is acceptable for your use case — for example, a casual chat feature where minor inaccuracies about non-critical facts are low stakes.

Reach for web search when the value of an answer depends on it being current, when the topic is one your users will notice is wrong if it is stale, or when your application explicitly promises "up to date" behavior, such as a research assistant, a news summarizer, or a price checker. The rest of this unit builds exactly that kind of application, starting in the next lesson with how to actually enable and call the web search tool through the Responses API.