Gemini's Knowledge Cutoff by Model

Google publishes a knowledge cutoff for each Gemini model as a field on its model card. It is the most misunderstood number in the specification: it is not the date the model was released, not a guarantee about anything before it, and not a limit you can move.

Where the figure is published

The authoritative source is the Gemini API models page, which lists a “Knowledge cutoff” row in each model’s specification table alongside its token limits and supported capabilities. Vertex AI publishes the same figure on its own model cards for the equivalent model ids.

Two things follow from it being a per-model field rather than a per-family one. First, models released on the same day can carry different cutoffs, because they were trained on different data snapshots. Second, the value can differ between a preview model id and the general-availability id it becomes, so a cutoff you read during a preview is not necessarily the one you get later.

The documented cutoffs

Read from Google’s models page on 11 August 2026:

Model                Knowledge cutoff (as documented)
-------------------  --------------------------------
Gemini 2.5 Pro       January 2025
Gemini 2.5 Flash     January 2025
Gemini 2.0 Flash     August 2024

What the date actually means

It is the boundary of the training corpus snapshot, and it behaves like a soft edge rather than a wall. Three properties are worth holding onto.

Coverage thins out well before the date

Text about an event does not appear on the internet the moment the event happens; it accumulates for months. A corpus cut in January 2025 contains years of discussion about 2023 and comparatively little about December 2024. So a model is reliably weaker on the final few months before its own cutoff than the single date suggests. The practical rule: treat the last quarter before the cutoff as partial coverage, not full coverage.

Some knowledge crosses the boundary anyway

Post-training — instruction tuning, safety tuning, preference data — happens after the pre-training snapshot and can introduce facts newer than the stated cutoff. A model may therefore know something dated after its documented cutoff. This is not a contradiction in the documentation; the cutoff describes the pre-training corpus.

It says nothing about correctness

Being inside the window is not a claim that the model has the fact right. The cutoff bounds what could have been learned, not what was. A model can be confidently wrong about something from two years before its cutoff, and the date gives you no protection against that.

Why asking the model does not work

The obvious test — prompting “what is your knowledge cutoff?” — is unreliable in both directions and should not be used to establish the figure. The model has no introspective access to its training data boundary. It answers from whatever the system prompt told it, from patterns in its tuning data, or by guessing from documents it saw about earlier models. Answers drift between calls and across temperatures.

A better empirical probe, if you need one rather than the documented figure: ask about a set of specific, well-covered events with known dates spread across the months around the documented cutoff, at temperature: 0, with grounding disabled. Where the model switches from detail to vagueness is the practical edge of its coverage, and it will usually sit slightly earlier than the published date for the reason in the previous section. That is a probe of behaviour, not a reading of the specification, and it should be described as such.

What makes the cutoff dangerous rather than merely limiting is what the caller actually sees when a question falls past it. There is no error, no flag on the response, and usually no hedge in the text. The model produces a fluent answer built from the most recent state it learned, presented with the same confidence as anything else. A question about the current version of a library returns the version that was current when the corpus was cut; a question about who holds a role returns whoever held it then. Both read as facts, and neither is marked.

When grounding is enabled, the response carries groundingMetadata alongside the text, with the search queries used and the supporting sources. That is the field to surface if you need to distinguish a claim that came from retrieval from one that came from the weights — the text itself will not tell you, and a grounded response can mix both in the same paragraph.

Working past the cutoff

The cutoff is a fixed property of the weights. Nothing you set in generationConfig changes it. Every workable approach is a way of putting newer information into the context window:

• Grounding with Google Search. A server-side tool that retrieves current results and returns citations with the answer. This is the built-in answer to the question and is covered in grounding a Gemini response with Google Search.
• Your own retrieval. Fetch the current documents and put them in the prompt. With a million-token input limit on the Flash line, “just include the whole thing” is more often viable on Gemini than elsewhere.
• Say the date in the system instruction. Cheap and underused. A model that is not told today’s date will frequently assume it is near its cutoff, which makes every relative reference — “last year”, “recently” — wrong in a way that is hard to spot.
• Not fine-tuning. Tuning adapts behaviour and format far more reliably than it installs facts, and it is an expensive way to fail at a job retrieval does well.

Finally, pin your model id. An alias that silently moves to a newer model moves the cutoff underneath an application whose prompts assumed the old one — see what the version suffix on a Gemini model id means.