How Real-Time Data Reaches Grok: Fed Into Context, Not Fine-Tuned In

“Grok has real-time access to X” is a claim about a retrieval pipeline, not about the model. Nothing about the weights knows what was posted this morning. Something in front of them fetched it and pasted it into your prompt.

The mechanism is retrieval

A language model is a function from a token sequence to a distribution over the next token. It has no clock, no network and no memory between calls. The only way a fact from this morning can affect the answer is if that fact is in the token sequence — which means something put it there.

xAI implements that as server-side tools. You declare a tool in the tools array of a Responses request; when the model decides it needs it, xAI runs the search on its own infrastructure, places the results in the model’s context, and the model writes its answer with those results in front of it. You never see a tool call come back for you to execute, which is the difference between these and the function tools in ordinary function calling.

curl https://api.x.ai/v1/responses \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $XAI_API_KEY" \
  -d '{
  "model": "grok-4.5",
  "input": [
    { "role": "user", "content": "What are people saying about xAI on X?" }
  ],
  "tools": [ { "type": "x_search" } ]
}'

That request is xAI’s own example, and its shape is the whole argument of this page: the live data arrives as a tool result inside one request. Nothing was fine-tuned, nothing was learned, and the freshness of the answer is the freshness of the search index rather than a property of the model.

The weights still have a cutoff

xAI documents a knowledge cutoff of 1 February 2026 for Grok 4.5. That number does not move when search is enabled — search does not update the model, it appends to the prompt. The distinction shows up in a specific failure: ask about something after the cutoff without a search tool enabled and you get a confident answer built from pre-cutoff priors, with no signal that retrieval did not happen.

So treat “did a search actually run?” as a thing to check rather than assume. The response reports server-side tool usage — which tools were invoked and how many times — and returns citations for what was read. If your answer has no citations and no tool invocations, it came from the weights, and it is as old as they are.

That check is worth wiring in rather than performing manually, because the model decides whether to search and it will sometimes decide not to. Declaring a tool makes it available; it does not make it used. For any answer whose value depends on being current, treat “zero server-side tool invocations” as a failed request rather than as a cheap one, and either retry with a prompt that states the recency requirement explicitly or tell the user the answer is not fresh.

There is a reproducibility consequence too. A search-backed answer is a function of an index that changes continuously, so the same request on two consecutive days is not the same request — and an evaluation suite that pins a model but leaves search enabled is measuring the news, not the model. Where you need repeatable results, capture the retrieved content once and replay it as ordinary context.

x_search and its filters

The X Search tool is the one that has no equivalent anywhere else, for the ordinary reason that xAI and X are the same company. xAI documents it as performing keyword search, semantic search, user search and thread fetch on X, with optional image and video understanding for media attached to posts.

• allowed_x_handles — consider posts only from these handles, maximum 20.
• excluded_x_handles — exclude these handles, maximum 20. It cannot be set in the same request as allowed_x_handles.
• from_date and to_date — an ISO 8601 range bounding the search.
• enable_image_understanding and enable_video_understanding — analyse media inside the posts rather than only their text.

The handle allow-list is the parameter to reach for first in anything resembling a monitoring application. Unfiltered social search over a contested topic returns a sample of a public argument, and the model will summarise that sample faithfully — which is a different thing from summarising reality. Twenty handles is a small enough budget that you have to choose sources deliberately, which is the right pressure.

web_search and domain limits

The web tool is declared the same way, as { "type": "web_search" }, and xAI documents it as searching the internet, opening pages and extracting the relevant parts. Its filters are the mirror image of the X tool’s: allowed_domains and excluded_domains, a maximum of five each, and the two cannot be combined in one request.

Five domains is tight, and it is tight in a useful direction: it is enough to pin a question to your own documentation site plus a couple of primary sources, and not enough to pretend you are searching the whole web with guardrails. There is also enable_image_search, which embeds found images in the response and — importantly for your token bill — puts those images into the model’s context to be read before the answer is written.

What it costs in tokens and time

Retrieved content is prompt tokens. Everything that reaches the model from a search is charged as input on the same schedule as the text you wrote, and it counts against the same window. That makes search the fastest way to cross the 200k threshold where the per-token rate doubles without changing a line of your own prompt — a handful of long articles or a deep thread fetch will do it.

Latency behaves the same way. A search turn is a network round trip on xAI’s side, then a prefill over everything that came back, then generation. Time to first token on a search-enabled request is not comparable to the same model without it, and averaging the two into one latency figure hides which one you have a problem with.

The design conclusion is unglamorous: enable search on the turns that need it, not on the route. If a request can be answered from context you already have, a tool the model is allowed to reach for is a tool it sometimes will. The same reasoning applies to grounded generation elsewhere, where the retrieval is a different index attached to the same mechanism.