Your customer-support app routes requests through gemini-2.5-pro. Nobody deploys a change, yet on December 1 a different model starts answering under that same ID and billing follows the destination model. If you wait for automatic routing, a production request could be the first place you discover that your tool call or JSON contract needs work. Google announced on November 2, 2026 that Gemini 2.5 Pro and Gemini 2.5 Flash are being deprecated in AI Studio and will have new API destinations.

What the announcement actually changes

Effective December 1, 2026, requests to gemini-2.5-pro will automatically route to gemini-3.8-flash; requests to gemini-2.5-flash will route to gemini-3.5-flash-lite. Google says the destination model's rates will apply. The two 2.5 models can no longer be selected in Google AI Studio, and API access before the switch is limited to existing users who actively used them. Gemini 2.5 Flash-Lite is not part of this deprecation. Its similar name makes it easy to include by mistake in a bulk replacement.

Automatic routing does not promise a drop-in migration. Google's deprecation schedule and migration guides flag breaking changes in function calling and thought_signature validation, thinking_level replacing thinking_budget, and removal of certain sampling parameters and prefilled model turns. Which change matters depends on your request shape. The announcement is not evidence that every application will fail.

A migration check you can run today

1. Inventory affected calls. Look in source code, environment variables, scheduled jobs, and copied examples. Run the following read-only search from your repository root:

rg -n 'gemini-2\.5-(pro|flash)' .

Review any gemini-2.5-flash-lite hit separately. It is neither one of the retired IDs in this announcement nor an automatic destination. Record the owner of each call path so a nightly job does not keep the old string after the app is updated.

2. Set the intended model explicitly. Map Pro to gemini-3.8-flash or Flash to gemini-3.5-flash-lite where that choice fits the task. Avoid a blind repository-wide substitution. A long reasoning job that used Pro deserves a different evaluation from a low-cost classifier.
3. Audit request fields. Work through Google's 3.8 Flash migration guide or 3.5 Flash-Lite guide. If your code uses tools, thought signatures, thinking_budget, sampling settings, or a prefilled turn, make each one an explicit test case.
4. Compare real but de-identified inputs. Select ten representative requests: a normal one, ambiguous ones, a missing-field case, and one that must go to a human. Check the output schema, tool calls, latency, and billable tokens for both routes. An HTTP 200 alone does not prove that a user-facing decision still works.

For example, a lead-triage app may require {category, urgency, needs_review} every time. The contract is that the keys and types remain valid, uncertain cases trigger review, and the model does not invent a category. Save before-and-after outputs using your own anonymized sample. This is a proposed test; we did not run Gemini requests in a live account or measure model performance for SoyJB.

Cost and the decision to make

The destination also changes pricing. Check Google's current pricing page and estimate from your actual input, output, reasoning, and tool usage. Do not infer cost from “Flash” or “Lite” in the name. If a gateway or aggregator sits between your app and Google, confirm when that layer will route requests and who bills you. Google's notice describes its own API, not every third-party path.

If either affected ID appears in your production inventory, migrate in a test environment before December 1 and decide using saved outputs. If neither appears, log the announcement and leave a working integration alone. The practical point is that the same model string will stop meaning the same model.