Gemini 2.5 Pro is Google's best model and it shows

Google released Gemini 2.5 Pro Experimental this week. It is a reasoning model, it tops several public leaderboards, and it ships with a one-million-token context window with two million stated as coming.

Google has been claiming long context for over a year. This is the first release where the claim is genuinely useful rather than technically true.

the long-context question#

Everyone's first objection to a million-token window is correct: a model can accept a million tokens without being able to use them. Retrieval degrades in the middle of long contexts, attention gets diffuse, and a needle-in-haystack benchmark measures something much easier than actual reasoning over a large document set.

2.5 Pro is noticeably better here. Not perfect — performance still degrades as you fill the window, and anyone telling you otherwise is selling something — but the degradation curve is shallow enough that new workflows become practical.

The concrete one for developers: put the whole repository in the context.

Not a RAG pipeline over the repository. Not embeddings and chunk retrieval. The files, concatenated, in the prompt. For a codebase in the low hundreds of thousands of tokens — which is most codebases people actually work in — this works, and it works better than retrieval, because retrieval loses the thing that makes code comprehensible, which is the relationships between distant parts.

# crude and effective
find src -name '*.ts' -not -path '*/node_modules/*' \
  | xargs -I{} sh -c 'echo "=== {} ==="; cat {}' > context.txt
wc -c context.txt

If that file is under about 3 MB you can probably just send it. That sentence would have been absurd eighteen months ago.

what this does to the RAG industry#

Uncomfortable question that a lot of infrastructure companies are currently avoiding: if context windows keep growing and long-context quality keeps improving, how much of the vector database and chunking-strategy ecosystem is solving a temporary problem?

The honest answer is: some of it, not all of it. Retrieval still wins when the corpus is genuinely large (millions of documents), when you need citations to specific sources, when latency matters (prefill on a million tokens is not free), and when cost matters (you pay for every token in the window, every call).

But the default architecture for "answer questions about this moderately-sized document set" is shifting from retrieval to just-put-it-in-the-prompt, and a lot of complexity is going to evaporate.

the caching detail that makes it economic#

Context caching is what makes this viable. Send the repository once, cache the prefix, then ask fifty questions against it at a fraction of the input cost per call. Every major provider now offers some form of this and the pricing difference between cached and uncached input is large enough to change architecture decisions.

If you are sending the same large prefix repeatedly and not using caching, you are lighting money on fire. Check your provider's docs today.

the competitive picture#

Google spent 2023 and most of 2024 visibly behind. They are not behind now. The combination of a genuinely competitive model, the largest context window, TPU economics that let them price aggressively, and distribution through products a few billion people already use is a strong hand.

The thing they still have not solved is the developer experience. The API surface is more confusing than it needs to be, the model naming is chaotic, and the documentation assumes you already know how Google Cloud works. Those are fixable and they are currently costing real adoption.