Real-time search

Real-time search is the practice of fetching current documents while an answer is being written, rather than answering only from what a model absorbed during training. It is what separates an assistant that can tell you today's price from one that can only tell you what a price was when its training data was frozen.

The name predates the current use. It was originally applied to search products that surfaced social and news content within seconds of publication. The term now more usefully describes a runtime capability: a model deciding, mid-turn, that it needs a document it does not have, issuing a query or a fetch, and writing from what comes back.

The mechanism

Operators expose it as a tool the model may call, not as a step that always runs.

Anthropic's web search tool documentation describes the loop plainly: Claude determines when to search based on the prompt, the API runs the searches and provides the results, this can repeat multiple times within a single request, and at the end of its turn Claude produces a final response with cited sources. A separate web fetch tool retrieves the full text of a named URL, including PDFs.

Two constraints on that loop matter to anyone hoping to be read. The first is budget: a max_uses parameter caps searches per request, and Anthropic notes that simple factual queries typically use one to three searches while comparative or multi-entity research can use ten or more. The second is cost: web search is priced at $10 per 1,000 searches on the Claude API. Searching is rationed because it is metered, which is why a page that fails to answer on the first fetch often does not get a second chance.

Google's Grounding with Google Search works to the same shape — the model analyses the prompt, decides whether a search improves the answer, executes queries, and returns text carrying inline url_citation annotations that tie spans of the answer to source URLs. Google's documentation states the project is billed for each search query the model decides to execute.

Why it decides whether you are quotable

Because it is the only path by which something you published after the training cutoff can appear in an answer.

A purely parametric answer draws on training data fixed months earlier; nothing you publish now reaches it, and any URL in it is reconstructed from memory rather than retrieved. A real-time answer fetches a live document, which means your current page is eligible, the answer can carry a working link, and a correction you ship is live in the next answer rather than the next model.

It also puts access upstream of quality. A fetch is an HTTP request from a named agent, and Anthropic documents a url_not_allowed error code for URLs blocked by domain filtering or by restrictions such as private addresses and robots.txt. A page the agent may not retrieve is not a weak candidate — it is not a candidate. See robots.txt and crawling and indexing for what you actually control there.

Failure modes

• You are never fetched. Blocked by robots.txt, behind auth, or outside an allowed_domains list the operator configured. Nothing downstream can rescue this.
• You are fetched but truncated. Anthropic's max_content_tokens parameter caps how much of a document reaches the context and truncates the rest, so material below the cut may as well not exist. The same page notes roughly 2,500 tokens for an average 10 kB page and about 25,000 for a 100 kB documentation page.
• You are fetched but filtered. With dynamic filtering, the model writes and runs code that discards parts of the result before it reaches the context window. A qualifier that sits far from its claim can be dropped while the claim survives.
• You are read from cache. Anthropic states the web fetch tool caches results and that returned content may not always reflect the latest version at the URL. A correction is not instantaneous.
• You are unreadable. The web fetch tool does not support pages rendered dynamically with JavaScript, and only handles text, HTML and PDF content types.
• You are read correctly and still misused. Retrieval and generation fail separately. A citation records which document was fetched, not that it supported the sentence attached to it.

What to do about it

1. Be fetchable first. Server-rendered HTML, no auth wall, no robots.txt rule that excludes the agent you want to be read by, a URL well under 250 characters.
2. Front-load the answer. Truncation and filtering both cut from the middle and the end. The fact belongs in the first passage, not the conclusion.
3. Keep the qualifier in the sentence with the claim. A caveat two paragraphs above does not survive a filter that keeps only the matching passage.
4. Date everything. A real-time system is choosing between your page and a fresher one; an undated page loses that comparison by default.
5. Assume the page is read once, partially, by a machine in a hurry. That is the actual reader. See source citation for what makes a passage attributable once it has been read.