Google announced the deprecation of Gemini 2.5 Pro and Gemini 2.5 Flash on November 2, 2026. Its API notice sets December 1 for automatic routing to replacement models. Developers still using those identifiers have a concrete compatibility review to complete.
Two identifiers, two destinations
The notice routes Gemini 2.5 Pro requests to Gemini 3.8 Flash and Gemini 2.5 Flash requests to Gemini 3.5 Flash-Lite, with the destination model’s rates. The older models are no longer selectable in Google AI Studio. Automatic routing is a future transition, rather than a claim that all existing requests stopped on November 2.
Google directs developers to the migration guides before changing the model string. Those guides matter because the destination is not simply an identical model under a new name. Applications need to verify the request and response behavior they depend on.
A model migration is an application change
The notice highlights function calling, thought-signature validation, thinking configuration, and removed request options among compatibility concerns. A client that constructs requests manually can depend on details an SDK handles differently. The appropriate migration checklist should reflect the actual interface the application uses.
Our engineering analysis is to start with captured, non-sensitive examples of representative requests. Include streaming, structured output, tool use, and multi-turn state where those features are part of the product. Verify both a successful response and the application’s handling of an unsupported input.
Measure behavior as well as transport
A request returning successfully is the beginning of acceptance testing. Compare whether the replacement follows the current instructions, uses the supplied evidence, and produces the result the user needs. Include ambiguous requests and situations where the model should ask for missing information.
Keep latency and total task cost beside quality. A changed response length, number of tool calls, or retry pattern can alter operating cost even when one token rate looks attractive. Test the complete workflow instead of estimating from a single generated answer.
For longer conversations, check that the application preserves all state required by the documented protocol. A migration can expose a client that previously discarded fields without a visible failure. Treat validation errors as information about the contract, rather than bypassing checks to restore a superficially working request.
Make the transition observable
Record the intended destination model, deployed client version, and acceptance evidence. Give failures a clear owner and verify the runtime actually uses the configuration tested. Retain a supported recovery plan appropriate to the service’s published availability.
The November announcement provides time to perform that work before automatic routing changes the behavior behind an old identifier. A deliberate migration produces a known application contract and a measured outcome, rather than relying on the old name to imply continuity.