Gemini Will Keep the Old Model Name. Your App Still Needs a Migration.

Google has offered developers a way to keep calling two retiring Gemini model names. That could prevent an obsolete identifier from immediately breaking an application. It does not promise that the application will behave as it did before.

In its November 2 Gemini API release notes, Google said requests addressed to gemini-2.5-pro will automatically go to gemini-3.8-flash from December 1, 2026. Requests for gemini-2.5-flash will go to gemini-3.5-flash-lite. Each route will use the destination model’s prices. Both older models have already disappeared from the Google AI Studio model selector.

The practical question is whether a team can leave its application alone and let Google handle the transition. My answer is conditional: automatic routing is useful continuity assistance, but it cannot replace checking the application’s requests and results. The safest November task is to select the destination explicitly, test the real integration and choose a launch date before Google chooses one for you.

First, identify which Google service you use

Gemini is a model family used through several products. An application calling the Gemini Developer API is different from a consumer using the Gemini app, and from an organization buying models through Google Cloud’s enterprise platform, formerly known as Vertex AI. The November 2 notice concerns the Gemini API documented in Google AI Studio. It should not become a universal shutdown date for everything named Gemini 2.5.

Google’s deprecation page also says access to the 2.5 models is restricted to users who previously used them. That matters for testing: a fresh project may not reproduce an established project’s access. A developer who cannot select an old model in AI Studio has not thereby demonstrated that an existing API application has already stopped working.

A useful example of this distinction comes from Open Chat Studio’s September 16 migration issue, posted by the account ocs-percy. It separated Cloud and AI Studio configurations, and called for finding workloads still explicitly using old models after defaults changed.

That historical record does not establish a current fault in Open Chat Studio. It illustrates why a team should inspect each workload’s actual settings. A saved assistant may still use a model that is no longer the application’s default.

A successful connection can hide a changed request

Imagine a document extraction service that sends an invoice and expects a small structured response. Its health check asks the model to say hello. Both requests reach the same API, but passing the greeting test tells you little about whether the invoice parser still works.

Google’s migration guides identify changes that reach beyond the model string. Gemini 3.8 Flash replaces the older numerical thinking_budget control with thinking_level. The supported choices are low, medium and high, with medium as the default; minimal is not supported. Gemini 3.5 Flash-Lite, by contrast, defaults to minimal, with higher effort recommended for more demanding tool workflows.

Those are different operating choices. Copying one shared configuration into both destinations could apply a setting one does not support, or allocate reasoning effort poorly for the task. A team should make the choice deliberately instead of treating the two replacement names as interchangeable upgrades.

There is a quieter change in output control. Google says the sampling settings temperature, top_p and top_k are deprecated and ignored in the relevant migration guide, with errors planned for future model generations. An application may therefore keep receiving answers even though its old variability controls no longer do what its developer expects. Remove them and test the output requirements directly.

Prefilled model turns create a more visible failure. Some applications supply the beginning of an assistant answer to encourage a particular format. Google’s guide says a request whose last non-empty turn has the model role is rejected with HTTP 400. Its recommended alternatives include system instructions and structured outputs. An invoice service that depends on such a prefix needs a request change, even if the automatic route preserves its model name.

The distinction matters when scheduling work. Repairing a rejected payload is a compatibility task. Checking whether a valid result still contains the right invoice fields is an application task. Finishing the first does not complete the second. Google’s notice does not establish how every older request will be translated by the December route; that is another reason to test the destination directly.

Test the conversation after the pause

Tool-using applications add another boundary. A model may request an external action, receive the result and continue reasoning. The application has to preserve enough state across those turns for the new model and API to accept the conversation.

Google calls one part of that state a thought signature: an encrypted representation of reasoning state. In the Interactions API’s stateful mode, the server manages this material when the client enables server-side storage and continues with its previous interaction ID. A stateless client managing its own history must preserve the returned thought blocks, including relevant built-in tool signatures. The older generateContent API represents signatures differently.

This is not a reason to make every team switch APIs at once. It is a reason to inspect the route already in use. An integration that lets a supported library handle the complete conversation may have little extra work. One that saves a partial transcript, waits for human approval and reconstructs the next request has more to validate.

Open Chat Studio’s issue supplies a useful counterexample to an alarmist migration story. Its described tool loop ran as one uninterrupted execution and already circulated signatures, so that investigation required no signature change. The same record warned that adding persistence or splitting the loop across tasks would change the assessment. Neither result establishes how a different application will behave.

For a purchasing assistant, the revealing test might be a pause before an approved order resumes. For an extraction pipeline, it might be restarting after a worker stops. These are suggested tests, not failures observed in a TechReadly trial. Run them with test data and controlled tools: confirm that the resumed request is accepted, that the result attaches to the right action and that recovery does not repeat an external operation.

December and January are different budgets

The new route does not automatically mean a higher token price. On Google’s published paid Standard rates, the text, image and video input price for 2.5 Flash matches 3.5 Flash-Lite, and their output rates match too. For 2.5 Pro prompts up to 200,000 tokens, the December destination has lower input and output rates.

Tokens are the units used to measure model input and generation. The following figures are US dollars per million tokens. Output prices include thinking tokens; these are unit prices, not forecasts of a complete application bill.

Google lists higher 2.5 Pro rates for prompts above 200,000 tokens. Audio, caching, tools and other service tiers also need their own comparison. A claim that every Gemini customer faces the same price change would erase those differences.

A team moving from Pro should prepare two forecasts: one for December’s introductory Flash price and one for January’s scheduled price. The January input rate in this table is above the old short-prompt Pro rate, while the output rate remains below it. Which direction the bill moves depends on the workload’s mix and how the replacement behaves.

For the Flash path, equal listed text rates are a real benefit. They still do not demonstrate equal monthly spend if output length, retries or tool use changes. The useful budget question is specific: can this application meet its quality and response-time requirements within the allowance its owner has approved?

Give the migration an owner and an acceptance test

Google’s own migration reference distinguishes a model upgrade from moving between API interfaces. That distinction can save work. A small service may need a configuration change and focused tests; it should not inherit an unnecessary rewrite just because a newer API is available.

Start by listing the actual provider, model string, request builder and owner for each production workload. Include saved user configurations and scheduled jobs. Search code as well as configuration, because a default chosen for new users does not necessarily update an existing assistant.

Then send representative requests directly to the intended destination before the deadline. Include ordinary successes and the cases your service finds difficult: an incomplete invoice, a long conversation, an empty tool result or a required output field. Define success in the application’s terms. An HTTP response is useful evidence of transport and request compatibility; it is not evidence that a total, classification or action is correct.

For systems that use tools, include the pause and restart cases. For systems that parse structured answers, check the parser against actual responses. Measure response time and usage on the same cases, and keep the chosen thinking setting in the record. These tests allow a small migration to stay small while exposing places where more work is justified.

Make the change on a date with an owner available to watch it. Keep the earlier configuration and results for comparison during November, while access permits. That is a testing opportunity, not a promise that the retiring model will remain a fallback after December 1. A recovery plan might instead pause a failing feature or use another already tested destination.

Automatic routing has a legitimate place here. A compatible, simple application could continue serving users with little disruption and favorable rates. Google’s transition may spare its owner an abrupt failure caused solely by an old identifier. The condition is that compatibility and acceptable results actually hold.

The task for November is to establish that condition. Choose the model, repair the affected requests, test the work users depend on and approve the December and January budgets separately. Then the automatic route becomes a useful safety net instead of the application’s first production test of a different model.