Gemini 2.5 Flash and Pro Deprecation: Migrate by Dec 1

Since this was written, OpenRouter's model feed lists Gemini 4 Carbon in place of Gemini 2.5 Pro, gemini-2.5-pro-preview and Gemini 3.1 Pro Preview; Claude Opus 5.5 in place of Claude Opus 5; GPT-5.4 Mini in place of gpt-5-mini; GPT-5.4 Nano in place of gpt-5-nano.

What Google's December 1 reroute does to every gemini-2.5-pro and gemini-2.5-flash call, what breaks, what it costs before and after January 1, where to move each workload, and a 23-day plan to get there before Google moves you

On December 1, 2026, a request your code sends to gemini-2.5-pro will be answered by a different model. Google's deprecations page states that from that date "all API requests to gemini-2.5-pro will automatically route to gemini-3.8-flash" and be billed at Gemini 3.8 Flash rates, while every request to gemini-2.5-flash routes to gemini-3.5-flash-lite at Gemini 3.5 Flash-Lite rates - Gemini API deprecations. Nothing returns an error that morning. The model string in your code stays the same, the HTTP status stays 200, and your invoice simply starts carrying a different model's name.

That is what makes this Gemini 2.5 Flash deprecation unusual. Most retirements are loud: a model is switched off, calls fail, someone gets paged, someone fixes it. This one is quiet. A Pro-tier model becomes a Flash-tier model, a mid-tier Flash becomes a Flash-Lite, and the newer models enforce API rules the 2.5 generation never did. Google's own release note lists the breaking changes: "function calling and thought_signature validation, thinking_level replacing thinking_budget, and removed sampling parameters and prefilled model turns" - Gemini API release notes. Some of those turn into hard 400 errors on the first rerouted request. Others change what your product says without changing any status code at all.

The notice was short. Google posted the deprecation on November 2, which leaves 29 days between announcement and reroute. Six weeks before that, on September 18, the same release notes had told developers the 2.5 models "are not deprecated and will continue to be served until further notice", while limiting access to users who had actively used them - Gemini API release notes. And if your Gemini traffic runs through Google Cloud rather than an AI Studio key, the clock already ran out: on what used to be called Vertex AI, Google's lifecycle table lists October 20, 2026 as the retirement date for gemini-2.5-pro, gemini-2.5-flash and gemini-2.5-flash-lite - Google Cloud model lifecycle.

This guide is written for the people who have to act on that: founders whose product calls Gemini, developers who inherited an integration, and anyone who wrote gemini-2.5-flash into a tutorial-shaped prototype a year ago and never looked at it again. It explains exactly what changes and where, why a reroute is riskier than a shutdown, every breaking change and quiet behavior change in the new models, the real cost math on both sides of the January 1 price step, how to choose a replacement for each workload rather than accepting the one Google picked, how to find every call, the before-and-after code, a dated runbook for the 23 days left, and how to build so the next reroute is a non-event.

Contents

1. What Google Changes on December 1, Word for Word
2. Why a Silent Reroute Is Riskier Than a Shutdown
3. Vertex AI, Firebase and Gateways: Where the Rules Differ
4. What Breaks on the First Rerouted Request
5. The Quiet Changes: Thinking, Verbosity, Refusals and Knowledge
6. The Cost Math After December 1, and After January 1
7. Where to Land: Choosing a Replacement per Workload
8. Find Every Call Before Google Moves It for You
9. The Code Changes, Before and After
10. A 23-Day Migration Runbook
11. Build So the Next Reroute Is a Non-Event
12. Conclusion: The Window That Closes on December 1

1. What Google Changes on December 1, Word for Word

Start with the exact wording, because the details are in it. For Gemini 2.5 Pro, Google's caution box reads: "gemini-2.5-pro is deprecated and is no longer available to select in Google AI Studio. Access through the API is limited to existing users who have actively used it in the past. Effective December 1, 2026, all API requests to gemini-2.5-pro will automatically route to gemini-3.8-flash and be billed at Gemini 3.8 Flash rates." - Gemini API deprecations. The Gemini 2.5 Flash box says the same thing with a different destination, routing to gemini-3.5-flash-lite at Flash-Lite rates, and adds one sentence that matters for planning: "gemini-2.5-flash-lite is not deprecated and remains available through the API until further notice."

Three facts sit inside those sentences. First, the change is a reroute, not a shutdown: the endpoint keeps answering. Second, billing follows the model that actually answers, not the one you named, so your cost per call changes on December 1 whether or not you touch your code. Third, the 2.5 models are already a closed club. Since September 18, API access has been "limited to users who have actively used them in the past", and Google told everyone else to start new projects on 3.5 Flash-Lite or 3.8 Flash - Gemini API release notes. That last point has a practical consequence covered in the runbook: if you create a fresh Google project to test your migration, it may not be able to call 2.5 at all, so the comparison has to run from the project that already has access.

The pricing page repeats the reroute next to the old prices, which is the clearest picture of what changes on your invoice - Gemini API pricing. Here is the whole family as of November 8, 2026, at standard paid-tier rates per million tokens:

The Gemini 3.8 Flash price has a date attached because it is introductory. Google's migration guide says the model "is available at an introductory rate of $0.75/1M input tokens and $3.75/1M output tokens through December 31, 2026", with "standard pricing of $1.50/1M input tokens and $7.50/1M output tokens" from January 1, 2027 - What's new in Gemini 3.8 Flash. So a 2.5 Pro workload that is rerouted on December 1 gets one month at a discount and then a doubling. Gemini 3.5 Flash-Lite has no such schedule: it costs $0.30 per million input tokens and $2.50 per million output tokens, which is exactly what Gemini 2.5 Flash costs for text today.

There is also a general caveat printed at the top of the deprecations page: "The shutdown dates listed in the table indicate the earliest possible dates on which a model might be retired." - Gemini API deprecations. That softens most rows, but not these two. The 2.5 Pro and 2.5 Flash boxes do not say "no earlier than"; they say "Effective December 1, 2026", and the November 2 release note tells developers to "update your model string" before that date. Treat December 1 as fixed.

The diagram below shows the whole change in one picture. Your code does not change. What answers it does.

Who does this apply to? The reroute is a rule of the Gemini Developer API: the one you reach at generativelanguage.googleapis.com with an API key from Google AI Studio, directly or through the Google GenAI SDK, Firebase AI Logic's Developer API provider, or a framework that wraps either. Google Cloud's enterprise surface follows a different, already-expired schedule, covered in section 3. If you do not know which of the two your product uses, that is the first thing to find out, because the answer decides whether you are facing a December 1 behavior change or a model that has been gone since October 20.

Finally, the reroute is not the only change in the window. Gemini 4 Argon, which Google calls its flagship reasoning model, doubles its price on the same morning, from $2 to $4 per million input tokens and from $10 to $20 per million output tokens - Gemini API pricing. That matters because Argon is the obvious "stay on Pro" alternative for 2.5 Pro users, and its introductory price ends the day before the reroute begins. We covered Argon's launch and pricing in more depth in our Gemini 4 Argon guide.

2. Why a Silent Reroute Is Riskier Than a Shutdown

To see why this deserves more attention than a routine model update, start with what a model ID actually is. When you write model="gemini-2.5-pro" you are not naming a brand. You are naming a fixed set of weights with a fixed behavior, a fixed price and a fixed set of API rules, and everything you built on top (your prompts, your parsers, your evaluation thresholds, your cost model, the expectations of your users) is calibrated to that fixed thing. Google's own documentation describes the contract: "Stable models usually don't change. Most production apps should use a specific stable model." - Gemini models overview. Pinning a stable ID is the thing developers are told to do precisely so that nothing changes under them.

A shutdown breaks that contract loudly. The call fails, the error is visible, and the failure is concentrated in time, on one day, in one error class. Monitoring catches it, because that is what monitoring is built to catch. A reroute breaks the same contract silently. The call succeeds, the status is 200, and the failure (if there is one) is spread across thousands of slightly different answers: a JSON field that is now sometimes missing, a classification threshold that no longer fits, a summary that is shorter, a refusal where there used to be an answer, a latency that crept up by five seconds. None of those trigger an alert by default. The developer who filed the tracking issue in the open-source llm-exe library put it directly: because calls keep succeeding, users will not get an error, and that is worse than a 404 "because nobody will notice" - llm-exe issue #935.

Why Google reroutes instead of switching models off

The structural reason is capacity. Serving an older model means keeping accelerators loaded with weights that newer releases have superseded, and every chip serving Gemini 2.5 is a chip not serving the models Google is now selling. Google said as much when it limited 2.5 access in September: the restriction "helps us maintain sufficient capacity for both ongoing legacy workflows and new applications" - Gemini API release notes. A reroute frees that capacity without the cost of a shutdown, which is that every customer whose integration breaks is forced to re-evaluate their provider at exactly the moment they have to change code anyway. Rerouting keeps the traffic, and the revenue, flowing.

Look at which models Google picked and a second logic appears: the destinations were chosen by price, not by tier name. Gemini 2.5 Flash costs $0.30 in and $2.50 out for text; Gemini 3.5 Flash-Lite costs the same $0.30 and $2.50. Routing 2.5 Flash to 3.8 Flash, the same tier by name, would have raised the input price 2.5 times in December and five times in January. Gemini 2.5 Pro costs $1.25 in and $10 out for prompts up to 200,000 tokens; Google's generally available flagship, Gemini 4 Argon, costs $4 and $20 from December 1, which would have more than tripled input bills overnight. The GA model closest to 2.5 Pro's price is 3.8 Flash. So the reroute is designed to keep invoices roughly flat, and the variable left to move is behavior. That is a reasonable choice for Google's billing team. It is not the same as choosing the right model for your workload.

This is also not a one-off. Rerouting has become Google's standard way to retire Gemini models. On October 8, gemini-3.7-flash was deprecated and its API requests "are automatically routed to gemini-3.8-flash", effective immediately, and gemini-3.5-flash requests were routed to gemini-3.6-flash the same day - Gemini API release notes. The deprecations page shows the same pattern for gemini-embedding-2-preview (routed to gemini-embedding-2 on November 6) and gemini-omni-1.1-flash (routed to gemini-omni-1.2-flash from December 3) - Gemini API deprecations. If you build on the Gemini API, a reroute is now the normal shape of a retirement, and the habits in section 11 are worth more than any single migration.

How the other labs handle the same problem

The contrast with OpenAI and Anthropic is instructive, because all three retire models constantly and all three face the same capacity economics. OpenAI's deprecations page commits to "at least 6 months" of notice for generally available models and states that at shutdown "the model or endpoint will no longer be accessible" - OpenAI deprecations. Its most recent batch follows that rule: developers using the original gpt-5, gpt-5-mini, gpt-5-nano and o3 snapshots were notified on June 11, 2026 for a December 11 shutdown. OpenAI also exposes the date programmatically, as an optional shutdown_date field on its List models endpoint, so a script can catch a retirement before a human reads about it. Anthropic promises "at least 60 days' notice before model retirement for publicly released models" and retires rather than reroutes - Anthropic model deprecations. Claude Sonnet 4.5's notice went out on September 30 for a November 30 retirement.

The chart below puts the notice periods side by side, counting days from the published notice to the day the old model stops being what answers.

A fair reading has to include the case for Google's approach, because there is one. For an app nobody maintains (a hackathon project, an internal tool whose author left, a side project that earns a little each month) a reroute is kinder than a shutdown: the app keeps working, probably at similar cost, and on many tasks the newer model is better. Google's own comparison says 3.5 Flash-Lite scores 18.0% on Humanity's Last Exam against 11.0% for 2.5 Flash, and 74.5% against 63.7% on the CharXiv chart-reasoning benchmark - What's new in Gemini 3.6 Flash and 3.5 Flash-Lite. If your product is abandoned, the reroute may be the best thing that happens to it this year.

If your product is not abandoned, the reroute is an unreviewed deploy that Google ships into your production on a date it chose. You would never let a teammate swap the model behind your main feature without a test run, a cost check and a rollback plan. The reroute does exactly that, minus the review. The right response is not outrage; it is to make the change yourself, on your schedule, with your tests, so that December 1 changes nothing because you already moved.

3. Vertex AI, Firebase and Gateways: Where the Rules Differ

Google sells Gemini through two front doors that look alike and run on different rules, and the 2.5 retirement exposes the difference sharply. The Gemini Developer API (AI Studio keys, generativelanguage.googleapis.com) is where the December 1 reroute applies. The Google Cloud surface, long called Vertex AI and now documented as the Gemini Enterprise Agent Platform, has its own lifecycle table, and on it Gemini 2.5 Pro, 2.5 Flash and 2.5 Flash-Lite all carry a retirement date of October 20, 2026 - Google Cloud model lifecycle. The Cloud model page for 2.5 Pro still opens with "Important: This model is being retired on October 20th, 2026" and adds a footnote that captures the split: listed retirement dates "refer to retirement of support in Gemini Enterprise Agent Platform", models "may remain accessible through the Gemini API after these dates have passed", and "the Gemini API is not a Google Cloud offering and is subject to its own terms of service" - Gemini 2.5 Pro on Google Cloud.

Firebase's documentation states the outcome in one line: "For the Agent Platform Gemini API (formerly Vertex AI), all general-use Gemini 2.5 models have shut down. For the Gemini Developer API, starting December 1, 2026, requests to the general-use Gemini 2.5 Flash and Pro models will be automatically routed to newer models (which may cause breaking changes)." - Firebase AI Logic models. So the same model ID has three different fates depending on where you call it:

Two rows in that table are traps. The first is gemini-2.5-flash-lite: on the Developer API it is the one 2.5 model that keeps working, while on Cloud it retired with the rest, so code that runs on both surfaces cannot treat it as a safe harbor. The second is gemini-3.6-flash. On the Developer API it looks like a reasonable migration target with no end date, but Google Cloud lists it among the "models available for shorter availability periods" with a retirement date of November 19, 2026 and gemini-3.8-flash as its replacement. A team that migrates its Cloud traffic from 2.5 Flash to 3.6 Flash this month would be migrating again in eleven days.

Google Cloud's lifecycle rules are, in one respect, more predictable than the Developer API's. The Cloud page promises that its models remain available "for at least 12 months after initial release", that a short-term model's retirement date gives "at least 45 days to migrate", and that retirement timelines "won't be moved to an earlier date than what is listed." - Google Cloud model lifecycle. The 2.5 models got their full year: they were released June 17, 2025 and retired October 20, 2026. The Developer API has no published minimum for stable models; its models page commits only that preview models "will be deprecated with at least 2 weeks notice" and that a -latest alias gets "a 2-week notice" by email before the model behind it changes - Gemini models overview.

How to tell which surface you are on

There are three quick tests. Look at the hostname your requests go to: generativelanguage.googleapis.com is the Developer API, while aiplatform.googleapis.com (often with a region prefix) is Google Cloud. Look at the credential: a bare API key from AI Studio means the Developer API, and service-account credentials with a project and location usually mean Cloud. And look at how the SDK client is built: in the Google GenAI SDK, Cloud access is switched on with genai.Client(vertexai=True, project=..., location=...) - Gemini migration to Google Cloud. Many products use both, for example the Developer API in development and Cloud in production for data-residency reasons, which is exactly the setup in which a migration tested in one environment fails in the other.

If you build on Firebase AI Logic, check which Gemini API provider your app initializes: the Developer API provider gets the December 1 reroute, the Agent Platform provider already lost 2.5. Firebase also changed its own rules in the same window: its documentation notes that "starting November 2, 2026, Firebase App Check enforcement will be required to use Firebase AI Logic", so a mobile app that ships a model-string fix without App Check configured may trade one failure for another.

Gateways and routers

If you reach Gemini through a model gateway, the gateway passes your model name upstream, and what happens on December 1 depends on which Google surface it uses behind the scenes. As of November 8, OpenRouter still lists google/gemini-2.5-pro at the original $1.25 input and $10 output per million tokens - OpenRouter. A listing at the old price tells you what the gateway charges, not which model will answer after December 1. Ask your gateway how it will handle the date, or better, move your traffic to an explicit successor ID so the question does not arise. If you route between several models with your own logic, our guide to cutting agent costs with model routing covers how to keep a routing table honest about which model actually served each call.

4. What Breaks on the First Rerouted Request

The reroute does not translate your request for the new model. It hands the request you wrote for Gemini 2.5 to a Gemini 3 model, and Gemini 3 models enforce rules that 2.5 never did. Google introduced most of them with the 3.6 Flash and 3.5 Flash-Lite generation and says they "apply to these models and all future Gemini model releases" - What's new in Gemini 3.6 Flash and 3.5 Flash-Lite. Some fail loudly, which is the good case. Others are silently ignored, which is the case to worry about. Here is each one, in the order you are likely to hit it.

Prefilled model turns now return HTTP 400

A prefill is a trick many developers used with 2.5: you end the conversation you send with the start of the model's own answer, such as a lone {, so the model continues from there and returns clean JSON without a preamble. On Gemini 3 this is forbidden. Google's rule is plain: "If the last non-empty turn in the request is a model turn, the API returns a 400 error." - What's new in Gemini 3.6 Flash and 3.5 Flash-Lite. A prompt that worked for a year will start failing on December 1 with no change on your side.

The fix is to ask for the shape you want instead of starting it. Move the instruction into a system_instruction ("Output only the JSON object, with no introductory text") or, better, use structured outputs, where you pass a JSON schema and the API constrains the answer to it - Gemini structured outputs. Structured outputs is the more robust replacement anyway, because a prefill only controlled the first character while a schema controls every field. If your product parses model output into a database, our guide to why AI apps corrupt data explains why schema-constrained output is the safer contract regardless of this migration.

Missing thought signatures in tool loops now return HTTP 400

This is the change most likely to break agents. Gemini's thinking models attach an encrypted thought signature to parts of their responses, a compact record of the model's reasoning state that lets it continue a multi-step task coherently. On 2.5 the advice was gentle: if you receive a signature, pass it back. On Gemini 3 it is enforced: "When using Gemini 4 and Gemini 3 models, you must pass back thought signatures during function calling, otherwise you will get a validation error (4xx status code)" - Gemini thought signatures. The error names the problem: "Function call FC1 in the 1. content block is missing a thought_signature."

The rule is scoped. The API looks back through your history to the most recent user message that contains ordinary content (text, an image, not a function response), treats every model function call after it as "the current turn", and requires that the first function call part in each step of that turn carries its signature. Older turns are not validated. That scoping tells you exactly who breaks on December 1:

• Agents that rebuild history. If your app stores each step as plain text plus a function name and arguments, and reconstructs the conversation from those rows on every call, the signatures were never stored and cannot be sent back.
• Conversations that straddle the date. A tool loop that starts on 2.5 Pro at 23:59 on November 30 and continues after midnight carries function calls produced by a model that did not require signatures, now validated by one that does.
• Histories you assemble yourself. Code that injects synthetic function calls (a deterministic step you ran on the client, or a trace imported from another model) has no signature to send.
• Misordered parallel calls. When the model returns two function calls at once, Gemini 3 expects your reply in the order "FC1 + signature, FC2, FR1, FR2"; interleaving them as "FC1 + signature, FR1, FC2, FR2" returns a 400.

For the first two, the fix is to store and resend the model's response parts whole, signature fields included, or to use the SDK's chat helpers or the Interactions API in stateful mode, where Google's server keeps the signatures and you never touch them. For injected calls that genuinely have no signature, Google documents an escape hatch: set the signature field to one of the dummy values "context_engineering_is_the_way_to_go" or "skip_thought_signature_validator" to skip validation for that part. It exists for exactly the case of history the API did not generate. Use it there, not as a blanket workaround.

Your thinking configuration changes meaning

Gemini 2.5 controlled reasoning with thinking_budget, a number of tokens. Gemini 3 uses thinking_level, a named setting (minimal, low, medium, high, depending on the model). Google calls the numeric budget "no longer recommended across all Gemini 3.x models", and its guides describe two behaviors you need to know - What's new in Gemini 3.5 Flash. A legacy budget sent on its own is still accepted for backward compatibility (on Gemini 4 it "maps to the nearest thinking_level and returns a warning"), and sending both a budget and a level in one request "will return a 400 error." Code that was half-migrated, with a new level added beside an old budget, fails outright.

Two 2.5 habits have no exact equivalent. On 2.5 Flash, thinking_budget=0 switched thinking off entirely. Gemini 3 Flash-Lite models cannot fully switch it off: Google's thinking guide says they "do not support full thinking-off, but the minimal setting means the model likely will not think (though it still potentially can)" - Gemini thinking guide. And Gemini 3.8 Flash supports only low, medium and high; its model page warns that "minimal is not supported and returns an error." That second point bites after a deliberate migration more than during the reroute: copy a working 3.5 Flash-Lite config that says minimal onto 3.8 Flash and every call fails. Google does not document which level a specific 2.5-style budget lands on when a rerouted request arrives, so test the calls that set one.

Temperature, top_p and top_k are silently ignored

This one never returns an error, which is why it matters. On Gemini 3.6 Flash, 3.5 Flash-Lite and later, "temperature, top_p, and top_k are deprecated and ignored. In future model generations, supplying these parameters returns an HTTP 400 error." - What's new in Gemini 3.6 Flash and 3.5 Flash-Lite. Gemini 3.8 Flash's own checklist tells you to remove them too - What's new in Gemini 3.8 Flash. Any workload that relied on temperature=0 for repeatable output (classification, extraction, test fixtures, evaluation harnesses that compare answers across runs) loses that control on December 1 without being told. Google's suggested substitute is to "define a system instruction with explicit rules for your specific use case", and structured outputs does much of the same work for anything with a fixed shape.

candidate_count, FunctionResponse fields and cached content

Three smaller changes complete the list. candidate_count is "unsupported in Gemini 3 and later" - What's new in Gemini 3.8 Flash. So code that asks for several candidates per call (for self-consistency voting or reranking) has to make separate calls instead. On the generateContent API, Google's 3.8 Flash checklist adds: "Ensure all FunctionResponse objects include call_id and name." And explicit context caches are bound to a model: Google's caching reference states that "cached content can be only used with model it was created for" - Gemini caching API reference. The deprecation notice does not say how a request that references a cache created for gemini-2.5-pro is treated once that request is answered by 3.8 Flash, so do not find out in production. Recreate long-lived caches against the model you migrate to, and note that the storage price changes too (section 6).

Your client library may branch on the old name

The last breaking change is not in Google's API at all, and almost nobody will think to check it. Client libraries make decisions from the model name you pass, because that is the only signal they have about which rules apply. LangChain's Google integration is a clear example. In its source as of November 4, 2026, it decides whether to patch missing thought signatures in the current tool loop, whether to drop the default temperature, and how to shape message content by testing the model string with helpers named _is_gemini_25_model and _is_gemini_3_or_later - LangChain Google GenAI source. Its signature patch, which fills a missing signature in the current tool loop with Google's bypass value, runs only when the model name says Gemini 3 or later. Pass gemini-2.5-pro after December 1 and the library takes its 2.5 path and skips that patch, while a Gemini 3 model enforces Gemini 3 rules on the other end. The same file keeps an explicit allowlist of models that reject prefills and ignore sampling parameters, and at that commit it names gemini-3.5-flash-lite and gemini-3.6-flash but not gemini-3.8-flash. The point is not that LangChain is wrong; its maintainers wrote the allowlist precisely because Gemini version numbers "are not monotonic across variants." The point is that a reroute makes the model string lie to every layer of software that reads it. Changing the string yourself is what makes those layers right again.

The table summarizes what to look for.

5. The Quiet Changes: Thinking, Verbosity, Refusals and Knowledge

Even a request that passes every check in section 4 comes back from a different model, and the differences that matter most to users never show up as errors. They are worth understanding in advance, because each one suggests a specific test.

The default amount of thinking moves in opposite directions

If your code never set a thinking configuration, it ran on each model's default, and the defaults change. Google's thinking guide lists Gemini 2.5 Pro and 2.5 Flash as thinking "On" by default (2.5's dynamic thinking, which lets the model decide how much to reason). Gemini 3.8 Flash defaults to medium. Gemini 3.5 Flash-Lite defaults to minimal - Gemini thinking guide. So a 2.5 Flash workload that quietly depended on the model reasoning through a multi-step question is rerouted to a model that, by default, likely will not reason at all. Google's own migration advice for 3.5 Flash-Lite says to leave minimal for "high-volume extraction, routing, or classification", and for "autonomous subagents with tool calls, code execution, or multi-step reasoning" to set thinking_level to medium or high "to prevent premature tool termination" - What's new in Gemini 3.6 Flash and 3.5 Flash-Lite. The rerouted request carries no such setting unless your code adds it.

Gemini 3.8 Flash works longer, by design

The 2.5 Pro side moves the other way. Google is unusually candid about it: "Gemini 3.8 Flash can use more tokens on longer running and complex tasks, by design. To deliver higher-quality results on difficult, multi-step goals, the model takes smaller reasoning steps, calls tools iteratively, and verifies its work along the way." - What's new in Gemini 3.8 Flash. Independent measurement agrees. Running the Artificial Analysis Intelligence Index v5.0.1, Gemini 3.8 Flash at high effort generated 126 million output tokens against a median of 72.6 million for comparable models, took 14.8 minutes per index task against a median of 12.6, and posted a time to first answer token of 19.93 seconds - Artificial Analysis. Output tokens include thinking tokens and are billed at the output rate, so a model that thinks more costs more per answer even at a lower price per token. For a user-facing chat product, the latency matters as much as the bill: a reply that starts five seconds later feels broken even when it is better.

Gemini 3.5 Flash-Lite sits at the other extreme. On the same index it ran at 289 output tokens per second with a time to first answer token of 4.46 seconds, scoring 12 against 3.8 Flash's 31 - Artificial Analysis. Those scores are not a verdict on your use case; they show the distance between the two destinations. Google's reroute sends a Pro-tier model's traffic to a slower, more thorough Flash, and a mid-tier Flash's traffic to a much faster, much lighter model.

Refusals and safety behavior shift

Safety tuning changes between generations, and for some products that changes what the product can do. Google's model card for 3.5 Flash-Lite reports, against the 3.1 Flash-Lite it was built from, an increase of 5.32 percentage points in unjustified refusals, which the card describes as a slight regression from more refusals on sensitive topics - Gemini 3.5 Flash-Lite model card. The same card shows text-to-text safety violations down 8.14 points, which is the trade being made. If your product handles medical, legal, financial, security or other sensitive content, build a small test set of the questions it must answer and the ones it must decline, and run both models on it before December 1.

Knowledge and capability move, mostly up

Gemini 2.5 Pro's knowledge cutoff is January 2025, per its model page. Google's 3.8 Flash model card gives March 2026 for some domains and January 2025 for others, "in line with the Gemini 3 model family" - Gemini 3.8 Flash model card. For most products a fresher model is a gain, but it can break tests and cached expectations that encode the old model's answers about 2025 events.

On capability, the honest summary is "newer on paper, unproven on your workload." Google's launch post for 3.8 Flash reports 54.9% on HLE-Verified and says the model beats most larger frontier models on the DeepSWE v1.1 software-engineering benchmark - Google. Its evaluation table, reproduced below, compares 3.8 Flash with Gemini 3.7 Flash and with Claude and GPT models as of September.

What the table does not contain is the comparison that matters for this migration: none of Google's 3.8 Flash materials benchmark it against Gemini 2.5 Pro, and Artificial Analysis lists no v5 index score for 2.5 Pro at all. The model card's own numbers show 3.8 Flash at 89.4% on Terminal-bench 2.1 but 19.1% on the harder Terminal-bench 4.0, where Claude Opus 5 reaches 51.8%, which is a reminder that a Flash model's strengths are uneven. The only benchmark that can tell you whether the reroute is safe for your product is one built from your product's own requests.

6. The Cost Math After December 1, and After January 1

Prices are the part of this migration you can work out exactly, so it is worth doing carefully. The chart shows list prices per million tokens before and after the reroute, at standard paid-tier rates for text.

Gemini 2.5 Pro to 3.8 Flash: cheaper in December, a coin toss in January

Per-token prices only tell you part of the story, because the mix of input and output tokens differs by workload and because 3.8 Flash may produce more output for the same task. The table works through three common shapes of 2.5 Pro request, priced per 1,000 requests. Gemini 2.5 Pro costs $1.25 in and $10 out up to 200,000 tokens of prompt, and $2.50 in and $15 out above that - Gemini API pricing. Gemini 3.8 Flash has a single rate at any prompt length.

Three conclusions follow, and none of them is "it is cheaper." First, December flatters the migration. At the introductory price almost every workload looks like a saving, which is exactly the month most teams will glance at the bill and move on. Budget against January prices, not December's. Second, input-heavy work under 200,000 tokens gets more expensive in January, because 3.8 Flash's standard input price of $1.50 is higher than 2.5 Pro's $1.25. Retrieval-augmented products that stuff a large context into every call and ask for a short answer are the clearest losers. Third, very long prompts get much cheaper, because 2.5 Pro doubled its input price above 200,000 tokens and 3.8 Flash does not tier at all. The fourth column is the scenario to measure rather than assume: if 3.8 Flash's extra reasoning grows your output by three quarters, as its verbosity on the Artificial Analysis index suggests is possible on hard tasks, a chat workload ends up costing more than it does today. Lowering the thinking level is the lever, and our guide to setting the effort dial shows how to measure where quality starts to drop.

Gemini 2.5 Flash to 3.5 Flash-Lite: the same price, unless you choose otherwise

For 2.5 Flash, Google picked a destination with identical text prices, so the reroute itself barely moves the bill. Two details can still move it. Audio input gets cheaper: 2.5 Flash charges $1.00 per million audio input tokens, while 3.5 Flash-Lite charges $0.30 for text, image, video and audio alike - Gemini API pricing. And the switch from dynamic thinking to minimal will, for most workloads, cut the thinking tokens you pay for, which lowers cost at some risk to quality.

The real cost question appears if you decide the reroute target is too weak and move to 3.8 Flash instead, the same "Flash" tier by name. Take a typical 2.5 Flash request of 3,000 input and 800 output tokens: it costs $2.90 per 1,000 requests today and the same on 3.5 Flash-Lite, but $5.25 per 1,000 on 3.8 Flash in December and $10.50 from January, more than three and a half times as much. That gap is why the choice of destination deserves a test per workload rather than a blanket rule (section 7).

Grounding with Google Search changes from per prompt to per query

If your app uses Grounding with Google Search, read this part twice, because it is the largest cost change in the migration and it is easy to miss. On Gemini 2.5 models, grounding is billed per prompt, with 1,500 grounded requests per day free and then $35 per 1,000 grounded prompts. On Gemini 3 and newer models, "your project is billed for each search query that the model decides to execute", with 5,000 free search requests per month shared across all Gemini 3 models and then $14 per 1,000 - Gemini Search grounding. Google's own example: a single prompt that triggers two searches "counts as two billable uses of the tool."

The rate is lower, but the free allowance shrinks from about 45,000 grounded prompts a month (1,500 a day) to 5,000 searches a month, and a prompt can now cost several searches. Consider an app that sends 1,000 grounded prompts a day on 2.5 Flash. Today it pays nothing for grounding, since it stays under the daily free allowance. After the reroute, at one search per prompt, it pays for 25,000 searches beyond the free 5,000, which is $350 a month; at an average of two searches per prompt, it pays $770 a month. There is also a ceiling to plan for: Google's rate-limit page says grounding on Gemini 3 and newer models "is subject to a default limit of 1,500 requests per day (RPD) per project" - Gemini API rate limits. Check the active limits for your project in AI Studio before December 1, because a grounded app with steady traffic can reach that limit in a way it never did on 2.5.

Caching, batch and flex

Context caching changes in both price and mechanics. Gemini 2.5 Pro charges $0.125 per million cached input tokens and $4.50 per million tokens per hour of storage - Gemini API pricing. Gemini 3.8 Flash charges $0.075 and $0.50 per hour through December, then $0.15 and $1.00 per hour from January. Storage gets far cheaper, which changes the break-even for keeping a large cache warm, and our prompt caching guide works through that calculation. Remember from section 4 that caches are bound to the model that created them.

For work that does not need an immediate answer, the Batch API and Flex tiers halve the price: 3.8 Flash runs at $0.375 in and $1.875 out in December and $0.75 and $3.75 from January, and 3.5 Flash-Lite at $0.15 and $1.25 - Gemini Batch API. If part of your 2.5 Pro traffic is overnight processing, moving it to batch on 3.8 Flash more than offsets the January increase. Do not let a batch job straddle December 1, though: submit 2.5-era batches early enough to finish by November 30, or submit them on the new model ID.

Spend limits can turn a cost increase into an outage

One last mechanism connects cost to availability. The Gemini API enforces spend-based rate limits on a rolling 10-minute window: $10 per 10 minutes for Tier 1 projects and $200 for Tiers 2 and 3, returning 429 RESOURCE_EXHAUSTED when exceeded, alongside billing tier caps that start at $250 for Tier 1 - Gemini API rate limits. A migration that raises cost per request, whether through more thinking tokens or per-query grounding, can push a busy Tier 1 project into those limits at peak hours. If your traffic is close to them today, request an increase before the reroute rather than after the first 429s.

7. Where to Land: Choosing a Replacement per Workload

Google's reroute answers the question "which model should replace this model ID?" That is the wrong question. A single 2.5 model ID in a real product usually serves several jobs with different needs: the same gemini-2.5-flash string might classify support tickets, summarize documents and drive a tool-using agent. The right question is "which model should do this job from now on?", and it is answered per workload, from your own tests, with the January prices in view.

Start with the options. The table lists the realistic destinations, with prices per million tokens at standard rates and what each model's documentation says about its lifespan.

The prices for the Gemini rows come from Google's pricing page, and the defaults from its thinking guide; Gemini 3.1 Flash-Lite's May 7, 2027 shutdown is on the deprecations page, and Claude Sonnet 5.5's earliest retirement date is on Anthropic's model status table - Anthropic model deprecations. Two rows deserve a comment. Gemini 3.6 Flash is effectively dominated: it costs exactly what 3.8 Flash costs through the same introductory schedule, it is the previous generation, and on Google Cloud it retires in eleven days. Gemini 2.5 Flash-Lite is the cheapest model in the table and the only 2.5 model not deprecated on the Developer API, but it is restricted to existing users, already retired on Cloud, and almost certainly next. Moving to it postpones the migration rather than completing it.

If you are leaving Gemini 2.5 Pro

Google's choice, 3.8 Flash, is a reasonable default for most 2.5 Pro work, and section 6 showed it is cost-neutral to cheaper for most shapes of request until you account for extra reasoning. Its stated strengths match what people used 2.5 Pro for: "long-horizon software engineering, autonomous agents, and complex enterprise workflows" - Gemini 3.8 Flash model page. The decision points are latency and quality floor. For a user-facing chat feature where 2.5 Pro was chosen for answer quality, try 3.8 Flash at low thinking first and step up only where your test set shows a gap. For agents and coding tasks, start at the default medium.

If your test set shows 3.8 Flash falling short on the hardest tasks, the Pro-tier option inside Google is Gemini 4 Argon, at a price that from December 1 is 3.2 times 2.5 Pro's input rate and twice its output rate. Argon also changes the API surface again: Google's Argon guide says explicit caching "is not supported on Gemini 4 Argon", that implicit caching applies to prompts of at least 4,096 tokens with a 95% discount on hits, and that sampling parameters are ignored - What's new in Gemini 4 Argon. There is no free tier. A pattern that often works is to route only the hard fraction of requests to Argon and everything else to 3.8 Flash, which keeps the average cost near 2.5 Pro's.

Avoid Gemini 3.1 Pro Preview for production work you cannot move on short notice. Google's models page says preview models "will be deprecated with at least 2 weeks notice" - Gemini models overview. That is a shorter promise than the one that just gave you 29 days.

If you are leaving Gemini 2.5 Flash

Google's choice, 3.5 Flash-Lite, is the natural fit for the jobs that made 2.5 Flash popular in the first place: high-volume extraction, classification, tagging, translation and routing, at the same price. Google describes it as "optimized for high-volume, latency-sensitive tasks like translation and classification as well as supporting agentic workflows" in its model card, and its benchmarks against the previous Flash-Lite are strong: 54.2% on SWE-Bench Pro against 38.3%, and 74.0% on OSWorld-Verified against 54.3% - Gemini 3.5 Flash-Lite model card. Run it at the default minimal for simple tasks and test refusals if your content is sensitive.

Where 2.5 Flash was doing harder work, such as multi-step reasoning, tool loops, or code generation, the tracking issue in llm-exe makes the case that gemini-3.8-flash "is probably a better suggestion than Google's own 3.5-flash-lite" because it keeps users on the same tier - llm-exe issue #935. The cost of that choice is real (section 6 put it at more than three and a half times per request from January), so there is a middle path worth testing first: 3.5 Flash-Lite at medium or high thinking, which Google itself recommends for "autonomous subagents with tool calls, code execution, or multi-step reasoning" - What's new in Gemini 3.6 Flash and 3.5 Flash-Lite. Only move a workload to 3.8 Flash when your tests show Flash-Lite at a higher thinking level is not enough.

The diagram summarizes a starting point for each common job. Treat it as a hypothesis to test, not a rule.

Should you leave Gemini altogether?

A forced migration is the cheapest moment there will ever be to reconsider your provider, and the reasoning is simple. The expensive part of switching models is not the code change; it is the evaluation: building a test set, running it, reading the differences, fixing prompts. This month you have to pay that cost anyway to move between two Gemini models. Running the same test set against a model from another lab adds a few hours, not a project. Whether the answer is to stay is a separate question, and for many teams it will be: Google's Flash and Flash-Lite prices are hard to beat, Search grounding and long video understanding are distinctive, and staying inside one API keeps the migration small.

If you do look elsewhere, the comparison is easier than it used to be. Our head-to-head of Claude Sonnet 5.5 and GPT-6.1 Sol covers the mid-to-upper tier, and if you have a ChatGPT Pro or Business plan, up to $500 a month of OpenAI API credits can pay for the test runs. Open-weight models are the other direction: through Vercel's AI Gateway in September, open-weight models processed "more than seven in 10 tokens" but took "nearly one in four" gateway dollars, and DeepSeek alone carried 58% of tokens for 6.6% of spend - The Register. For high-volume extraction work, the kind 2.5 Flash did, that is a serious alternative, and our guide to the best open-weight models to self-host covers the trade-offs of running one yourself.

Keep in mind that every lab retires models. Claude Sonnet 4.5 retires on November 30, the same weekend as this reroute, and OpenAI's original GPT-5 and o3 snapshots shut down on December 11. Our walkthroughs of OpenAI's October model shutdowns and of the Claude 5.5 API migration show that changing labs trades one deprecation schedule for another. What you can choose is how well your product absorbs them, which is the subject of section 11.

8. Find Every Call Before Google Moves It for You

You cannot migrate a call you do not know about, and model IDs hide in more places than source code. The goal of this step is a complete list of every place your product, its dependencies and its vendors send a request to gemini-2.5-pro or gemini-2.5-flash, with the job each call does.

Search the code, the config and the data

Begin with a search that finds the two affected IDs without the unaffected 2.5 variants (-lite, -image, -preview-tts). This ripgrep command matches gemini-2.5-pro and gemini-2.5-flash in any form, including models/gemini-2.5-pro resource names and google/gemini-2.5-flash gateway IDs, while skipping names that continue with a hyphen:

rg -n -P 'gemini-2\.5-(pro|flash)(?![-\w])' --hidden -g '!node_modules' -g '!.git' .

Run it across every repository, not only the main application: infrastructure code, scripts, notebooks, test fixtures, CI workflows and documentation all carry model strings. Then search the places a code search cannot see. Environment variables and secret managers often hold the model name for a deployment. Feature-flag and remote-config services (Firebase Remote Config is a common one for mobile apps) can override it at runtime. Databases frequently store a model choice per user, per workspace, per agent or per prompt template, and those rows will keep requesting 2.5 long after the code default has changed. A query along the lines of WHERE model LIKE 'gemini-2.5-%' against each table that stores a model setting is the database equivalent of the search above.

Also check for the floating alias. If any of your code calls gemini-flash-latest, it is already on Google's rolling pointer, which "will get hot-swapped with every new release" with "a 2-week notice" by email - Gemini models overview. That is not affected by this reroute, but it is the same kind of risk on a shorter fuse, and it belongs in the same inventory.

Search the dependencies and the vendors

Code you did not write can call Gemini too. Check the configuration of every framework that wraps a model (LangChain, LlamaIndex, the Vercel AI SDK, agent frameworks), every low-code automation tool your team uses (workflow builders often store the model in each node), and every SaaS product that runs AI on your data with a model you chose in its settings. For tools where the vendor picks the model, ask them directly what they will run after December 1; a vendor that does not know is telling you something useful.

Measure what is actually called

A static search tells you what could run. Usage data tells you what does. The Usage page in Google AI Studio shows each project's API usage, grouped by key - Gemini API keys. For the request-level picture, including which model each call named, Gemini's Logs and Datasets feature can store your API calls; note that since October 26, new projects using generateContent on the paid tier "now store requests by default (store=true)", while existing projects keep their current setting - Gemini API release notes. That default matters if you create a new project for the migration and your data policy does not allow request logging; you can opt out per request with store=false or in the Logs and Datasets settings.

The single most useful habit from this whole guide is the next one: log which model actually answered. Every generateContent response carries a modelVersion field, which Google's API reference defines as "the model version used to generate the response" - Gemini generateContent reference. Log it next to the model you requested, and alert when the two differ. Google does not document what modelVersion a rerouted 2.5 request will report, so do not rely on it to confirm the reroute; rely on it to catch every future one, including reroutes that arrive without a changelog entry you happened to read.

9. The Code Changes, Before and After

The examples below use the Google GenAI SDK for Python, the most common way to call the Gemini Developer API, and show the minimal changes: a new model string plus the parameter fixes from section 4. Google's own migration material is written for its newer Interactions API, and it ships coding-agent skills that automate a migration (its 3.8 Flash guide suggests running /gemini-api-dev migrate my app to Gemini 3.8 Flash in an agent that supports skills) - What's new in Gemini 3.8 Flash. Those tools also move you onto the Interactions API, which is a larger change than this deadline requires. The generateContent path keeps working on Gemini 3 models; Google's checklists include steps that apply "only if using generateContent API", so a minimal migration can stay where it is and adopt the Interactions API later, deliberately.

A structured extraction call, from 2.5 Flash to 3.5 Flash-Lite

This is a typical 2.5 Flash call: it prefills a { to force JSON, sets temperature=0 for repeatability and switches thinking off with a zero budget. On December 1 the prefill returns a 400, the temperature is ignored and the zero budget cannot fully switch thinking off.

# Before: written for gemini-2.5-flash
response = client.models.generate_content(
    model="gemini-2.5-flash",
    contents= [
        types.Content(role="user", parts= [types.Part(text=invoice_text)]),
        types.Content(role="model", parts= [types.Part(text="{")]),  # prefill: HTTP 400 on Gemini 3
    ],
    config=types.GenerateContentConfig(
        temperature=0,  # ignored on Gemini 3.5 Flash-Lite and later
        thinking_config=types.ThinkingConfig(thinking_budget=0),
    ),
)
invoice = json.loads("{" + response.text)

The replacement asks for the shape instead of starting it, with a Pydantic schema that the API enforces, and uses the named thinking level. It also logs the model that answered.

# After: written for gemini-3.5-flash-lite
from pydantic import BaseModel
from google import genai
from google.genai import types

class Invoice(BaseModel):
    vendor: str
    total: float
    currency: str
    due_date: str

client = genai.Client()

response = client.models.generate_content(
    model="gemini-3.5-flash-lite",
    contents=invoice_text,
    config=types.GenerateContentConfig(
        system_instruction="Extract the invoice fields. Use an empty string for any field that is missing.",
        response_mime_type="application/json",
        response_schema=Invoice,
        thinking_config=types.ThinkingConfig(thinking_level="minimal"),
    ),
)
invoice = Invoice.model_validate_json(response.text)
logger.info("model requested=%s served=%s", "gemini-3.5-flash-lite", response.model_version)

A tool loop, from 2.5 Pro to 3.8 Flash

The second pattern is the agent loop that breaks on missing thought signatures. The bug is usually in how history is stored: the code keeps only the function name and arguments and rebuilds a fresh Content object from them, which drops the signature.

# Before: rebuilds the model's turn from stored fields, losing the thought signature
call = response.candidates [0].content.parts [0].function_call
db.save_step(name=call.name, args=dict(call.args))
history.append(types.Content(role="model", parts= [
    types.Part(function_call=types.FunctionCall(name=call.name, args=call.args)),
]))

The fix is to keep the model's own Content object, every part and signature included, and to answer each call with a FunctionResponse that carries the call's id and name. The SDK's types are Pydantic models whose bytes fields serialize to base64, so a whole turn can be stored as JSON and restored exactly.

# After: keep the model's turn whole, signatures included
model_turn = response.candidates [0].content
history.append(model_turn)
db.save_turn(model_turn.model_dump_json())  # restore with types.Content.model_validate_json(...)

for part in model_turn.parts:
    if part.function_call:
        result = run_tool(part.function_call.name, part.function_call.args)
        history.append(types.Content(role="user", parts= [
            types.Part(function_response=types.FunctionResponse(
                id=part.function_call.id,
                name=part.function_call.name,
                response={"result": result},
            )),
        ]))

response = client.models.generate_content(
    model="gemini-3.8-flash",
    contents=history,
    config=types.GenerateContentConfig(
        tools=tools,
        thinking_config=types.ThinkingConfig(thinking_level="medium"),
    ),
)

Google's function-calling guide says "the SDKs automatically handle thought signatures for you", which holds as long as you pass the SDK's own Content objects back, as above - Gemini function calling. If you would rather not manage history at all, the SDK's chat helper (client.chats.create(model="gemini-3.8-flash")) keeps it for you, and the Interactions API in stateful mode keeps it on Google's side, where signatures "are handled entirely on the server side."

The same change in JavaScript

In the JavaScript SDK the configuration is camel-cased, and the response exposes the same field for logging which model answered.

import { GoogleGenAI } from "@google/genai";

const ai = new GoogleGenAI({});

const response = await ai.models.generateContent({
  model: "gemini-3.8-flash",
  contents: prompt,
  config: {
    systemInstruction: "Answer in plain language, in at most three short paragraphs.",
    thinkingConfig: { thinkingLevel: "low" },
  },
});

console.log(response.text);
console.log("served by", response.modelVersion);

A shadow test you can run this week

Code changes are the easy part. The part that protects your users is comparing old and new on real traffic, and it can only be done while 2.5 still answers. The simplest version takes a few hundred recent production requests per workload, sends each to both the current 2.5 model and the candidate replacement, and stores both answers side by side with their token counts and latency. Score the pairs with whatever your product already uses to judge quality: exact match for extraction, a rubric or a second model for open-ended text, the success of the downstream action for agents. The scores tell you which workloads can move as they are, which need a different thinking level, and which need a different model. After December 1 there is no "old" side left to compare against.

10. A 23-Day Migration Runbook

From November 8 to December 1 there are 23 days, and the same weeks carry several other deadlines that may compete for the same engineers. The timeline puts them in order.

The dates come from the three labs' deprecation pages and Google's pricing page; OpenAI's Agent Builder shutdown and the December 11 removal of the original GPT-5 and o3 snapshots are on OpenAI's list - OpenAI deprecations. With that calendar in mind, the work splits naturally into four stages.

Week one (Nov 8 to 14). Inventory and decide. Run the searches from section 8 and produce one list: every call site, the model it uses, the surface it calls (Developer API or Cloud), the job it does, and its monthly volume and cost. Check Cloud traffic first, because on that surface 2.5 has been retired since October 20 and anything still configured for it is already failing or has silently moved to a fallback. For each job, pick a first candidate from section 7. Build a test set per job from recent production requests.

Week two (Nov 15 to 21). Fix and compare. Make the code changes from sections 4 and 9 behind a configuration switch you can flip per workload, and run the shadow comparison from section 9 against the live 2.5 models. Measure cost per request at January prices, not December's, and include grounding searches if you use them. For any workload where the candidate falls short, try the next option: a higher thinking level first, a different model second. If you run on Google Cloud and planned to use 3.6 Flash anywhere, change that plan before November 19.

Week three (Nov 22 to 28). Roll out. Move workloads one at a time, starting with the ones where the comparison was clearest: a small share of traffic first, then half, then all of it. Watch error rates, latency, cost per request and your product's own quality signals at each step. Turn on the model mismatch alert from section 8. Recreate explicit caches on the new models and make sure no batch job submitted on a 2.5 ID will still be running on December 1.

Nov 29 to Dec 1. Verify and hold. Search one more time for any remaining 2.5 Pro or 2.5 Flash calls, including database rows and vendor settings. Pause non-essential changes over the weekend. On December 1, watch for 400 errors on the paths you did not migrate, check that your modelVersion logs show the models you expect, and compare spend with your projections. Then put January 1 in the calendar: that is when 3.8 Flash's price doubles, and when the real cost of the migration becomes visible.

A smaller team can compress this. The minimum responsible version is: find every call, change every string to an explicit successor, fix prefills and history storage, run a few dozen real requests per workload through the new model and read the answers. That fits in an afternoon for a simple product, and it still beats letting Google make the change on December 1.

11. Build So the Next Reroute Is a Non-Event

This deadline will pass, and another will follow; rerouting is now how Google retires Gemini models, and the other labs retire theirs on their own schedules. The lasting fix is not this migration but the design that makes the next one boring. Five habits do most of the work.

Name models by purpose. Keep the model choice in one place. When the string gemini-2.5-flash appears in forty files, a migration is a search-and-replace across forty files and a hope that nothing was missed. When every call asks for a purpose ("extraction", "agent", "chat") and one configuration maps each purpose to a model, a migration is a one-line change per purpose, reviewable in one diff and reversible in one revert. The same structure lets you run different models for different jobs, which section 7 showed is usually the right answer anyway.

Log requested and served. The modelVersion field turns a silent reroute into a visible event. A dashboard of requested versus served models, with an alert on any mismatch, would have shown every Gemini reroute this autumn on the day it happened.

Keep a test set. Run it on every model change. The shadow test from section 9 is worth keeping after this migration. A few hundred real requests per job, with a scoring method, turns "is the new model good enough?" from a debate into a number, and makes the next migration a matter of hours.

Store native history. Keep conversation history in the provider's own format. Agents that store the model's raw response parts, signatures and all, survive changes in validation rules that break agents which store a simplified copy. If you need a provider-neutral format for analytics, keep it alongside the raw one, not instead of it.

Avoid removable knobs. Do not depend on controls the vendor can take away. Prefills and temperature=0 were convenient ways to control output, and both were taken away by an API change. Schemas and explicit instructions are the controls that newer models are designed around, and they transfer between providers.

Behind those habits is a broader point about control. When an AI lab can change the model behind your product with a month's notice and no error, the most valuable property of your architecture is that the choice of model stays yours: that you decide what runs, when it changes and how you know. That is not immunity from a lab's decisions (nobody has that), but it is the difference between absorbing a change and discovering one.

Some platforms build this in at the level of the product. One concrete case is Founden, the platform publishing this guide. Its model policy file keys choices by model family rather than by version, and its list of retired names maps gemini-2-5-pro and gemini-2-5-flash onto Google's Pro and Flash family pointers, so a stored choice of either resolves to that family's newest release and the user is told which model actually ran; the catalog those pointers resolve against is regenerated from OpenRouter's and each vendor's own model lists every six hours. The pattern is not specific to any platform. A purpose-to-model map, a family pointer for each line, and a log line that names the substitute are a design any team can build into its own code in an afternoon, and our guide to pricing an AI product against token costs covers the commercial side of the same discipline: knowing what each job costs so a model change never surprises your margins.

12. Conclusion: The Window That Closes on December 1

Google's reroute is designed to be painless, and for an app nobody maintains it probably will be. For a product people depend on, it is a model change you did not review, landing on a date you did not choose, with API rules your code was not written for. Prefills will fail. Agents that drop thought signatures will fail. Temperature settings will stop doing anything. A Pro-tier workload will be answered by a Flash model that thinks longer, a mid-tier Flash workload by a Flash-Lite model that by default barely thinks, grounding will be billed per search instead of per prompt, and the price of the Pro replacement doubles on January 1.

None of that is a reason to panic, and most of it is a reason to act now rather than later. The work is well defined: find every call, fix the breaking changes, choose a replacement per job, and test it against the old model while the old model still answers. That last condition is the real deadline. On December 1 the comparison disappears, because there is nothing left to compare against, and every difference you did not measure becomes a difference your users discover for you.

Do the migration on your terms, before the 1st. Then make the next one a configuration change.

This guide reflects Google's Gemini API deprecation, pricing and model pages, Google Cloud's model lifecycle page and the other labs' deprecation pages as of November 8, 2026. Prices, dates and API rules in this area change often, so verify current details on the linked pages before you migrate.

What this article rests on

Every model figure linked above is read from its record, re-read from OpenRouter's model feed every 6 hours, so the figures on this page are current even where the prose around them is older. Prices are OpenRouter's listed price per million tokens: for a lab's closed models that is the lab's own list price, and for an open-weight model it is the price of the host OpenRouter routes to by default, which can differ from the lab's own API and from other hosts.

• Gemini 3.5 Flash Lite (Google): $0.30 in and $2.50 out per million tokens, cached input $0.03, a 1M token window, listed 21 July 2026.
• Claude Sonnet 5.5 (Anthropic): $2 in and $10 out per million tokens, cached input $0.10, a 1M token window, listed 28 September 2026.
• GPT-6.1 Terra (OpenAI): $1 in and $5 out per million tokens, cached input $0.05, a 1.05M token window, listed 26 October 2026.

In this topic: AI models

• Anthropic S-1: What Claude Builders Should Change (2026)
• OpenAI Dots vs Gemini Agent vs Grok Bot: Which to Hire 2026
• Claude Sonnet 5.5 vs GPT-6.1 Sol: Which to Build On (2026)
• Gemini 4 Argon Pricing: $2/$10 Now, Doubles Dec 1 (2026)
• Claude Haiku 5.5: 75% Cheaper Than 4.5, Takes On GPT-6 Luna
• Personal Sovereign AI: Own Your AI in 2026
• Best Open-Weight LLM to Self-Host in 2026
• DeepSeek V4.1 Flash: Frontier AI for Pennies 2026

Which AI model should you build on? Every guide on it

Data behind this topic: AI model prices, context windows and release dates.