Somewhere in your product there is a gemini-2.5-flash-lite call doing one small job a very large number of times. It decides whether an upload is spam, pulls four fields out of a document, picks which downstream service handles a request, or scores a piece of user content before it goes live. It is not the part of your product anyone demos. It is the part that runs on every request.
That model has been the cheapest credible option for over a year, which is exactly why the boring high-volume work ended up on it. Now Google has announced its retirement: the whole 2.5 series, Flash-Lite, Flash, and Pro, will be discontinued no earlier than October 16, 2026. The exact date gets set once Gemini 3 is generally available, with notice, on Google’s schedule. If you are on the Gemini Enterprise Agent Platform the date is already hard: migrate by October 20, 2026. And some teams report 2.5 Flash calls erroring ahead of any announced date.
So you are opening that code path either way, on a timeline someone else controls. The only real question is what you point it at.
The migration costs you an eval pass, not a price change
The token price is the small part of this. Cheap general-purpose tiers keep arriving from every provider and the per-token cost of a given level of capability keeps falling, so if you wait long enough the price sheet mostly takes care of itself.
What does not take care of itself is the work. To swap a model under a production workload you have to pull a test set together, run the new model against it, compare, find the cases where it behaves differently, fix the prompt, and ship it carefully. That is the actual cost of this deprecation, and you pay it in engineering time on Google’s schedule rather than yours.
That cost is fixed no matter where you land. Which makes the destination worth more thought than a find-and-replace on the model string.
For completeness, here is the price sheet you would be moving onto. The recommended replacement for gemini-2.5-flash-lite is gemini-3.1-flash-lite, and for gemini-2.5-flash it is gemini-3.6-flash. Paid tier, standard, per 1M tokens, as of July 29, 2026:
| Model | Input | Output | Cached input |
|---|---|---|---|
| gemini-2.5-flash-lite (retiring) | $0.10 | $0.40 | $0.01 |
| gemini-3.1-flash-lite (replacement) | $0.25 | $1.50 | $0.025 |
| gemini-2.5-flash (retiring) | $0.30 | $2.50 | $0.03 |
| gemini-3.6-flash (replacement) | $1.50 | $7.50 | $0.15 |
A classification service running 1B input and 100M output tokens a month goes from $140 to $400. Worth knowing before it turns up in an invoice review, and not the reason to read on. Batch mode, caching, and whatever the market does to these numbers between now and the shutdown all cut in the same direction, and none of it changes the argument below.
What a lateral move actually buys you
The default plan is to move to the next general-purpose model in the same family and get back to work. Fine. But be clear about what that gets you: the same kind of model, doing the same job, at roughly the same quality.
General-purpose models are built to be decent at everything, which means they are nobody’s best option at any one thing. On a clean benchmark task they look strong. On your task, with your messy real inputs and your edge cases and your particular definition of what counts as spam, they tend to land somewhere around 80%. Teams accept that number because the price was acceptable and because it is not obvious what else you would do.
Knowunity’s classifier was at 81% on Gemini 2.5 Flash-Lite. That is the number a general-purpose workhorse gets you, and it is the number a different general-purpose workhorse gets you too.
So you are about to spend a migration to stay there.
The workload worth reconsidering, not just re-qualifying
The reason this deprecation is annoying is also the reason it is an opening.
Look at what the Flash-Lite call is actually doing. It is one task repeated a million times. The inputs look the same every time and so do the outputs. And you can measure whether it is right, because “did this classifier label this document correctly” is a number, not a matter of taste.
That is a very specific profile, and it is nothing like the open-ended work a general-purpose model is priced and built for. You have been renting capability you do not use, and settling for general-purpose accuracy on a task where accuracy is measurable and worth money. A model trained on that one task does not have to make that trade.
What is distil labs
We are a platform that fine-tunes task-specific small language models automatically. Most people use us to swap the general-purpose LLM in their system for a smaller, purpose-built one: better quality on their task, around 80% lower cost, and lower latency. We take the production traces a team already collects, generate synthetic training data from them, train a small model that matches or beats frontier-model quality on the narrow task, and deploy it to an OpenAI-compatible endpoint. In practice it is the same swap you are already planning, pointed somewhere else.
How we train it
The loop is the same whether the task is classification or extraction.
You start with a plain-English description of the task and 20 to 100 seed examples. If you have production traces from the model you are about to lose, those are better than anything you could write by hand, and they need no labeling. We confirm the base model fails at the task, which sets the floor, and run a teacher model to set the ceiling, usually GPT-OSS-120B. The teacher generates roughly 10,000 in-domain synthetic examples. Rule-based validators filter those for length, format, schema, and novelty, so what reaches training is not just more teacher output but checked teacher output. We LoRA fine-tune the student for 4 epochs on the seed data plus the curated synthetic data, then evaluate on a held-out test set against both the teacher and the base model.
task description + your traces
|
v
teacher generates ~10,000 examples (GPT-OSS-120B)
|
v
validators filter: length, format, schema, novelty
|
v
LoRA fine-tune the student (4 epochs)
|
v
OpenAI-compatible endpointThe part that surprises people is that the student often beats its teacher. Two reasons: validation strips the teacher’s mistakes before the student ever sees them, and the student spends all of its capacity on one task instead of holding itself ready for every task.
This is also the answer to the obvious objection, which is that cheap general-purpose models keep getting better. They do. So do the small base models we start from, and the gap we are describing is not between an old model and a new one, it is between a model doing one job and a model doing everything. Across a 15-model, 9-task benchmark we kept finding the same thing: fine-tuning matters more than base model choice. A well-tuned 1B model can outperform a prompted 8B one.
On timing: setup is about 10 minutes of your time, the model is ready in a day, and teams are usually integrated in 1 to 3 days. The earliest possible shutdown is October 16, more than two months out, so this does not need to displace your roadmap to land ahead of it.
What this looked like on this exact swap
Knowunity, an education platform, ran classification on Gemini 2.5 Flash Lite at hundreds of millions of requests a month. They replaced it with a fine-tuned small model trained on their own data.
Classification accuracy went from 81% to 93%. Inference cost went down 68%.
The accuracy is the part worth sitting with. The cost saving is good, but 81% to 93% on a classifier running at that volume is a different product: fewer bad calls reaching users, fewer manual reviews, fewer complaints traced back to one silent mislabel. No general-purpose model in that price range was going to hand them those twelve points, because the ceiling was never about the price tier. It was about a model splitting its attention across every task instead of learning theirs.
These are production figures from their deployment rather than a controlled benchmark, so read them as one team’s outcome, not an error-barred result. The longer version, along with two other education platforms, is in our edtech case study.
Where this does not apply
A few things we would tell you on a call before you started.
A fine-tuned small model covers a bounded task. If your Flash-Lite call is a real open-ended fallback, catching whatever the rest of the system could not handle, then it has no fixed shape to train on and moving up the Gemini ladder is the right move.
If your task genuinely needs the extra general capability in gemini-3.1-flash-lite, paying for it is a reasonable decision and we would not argue with it. The lateral-move critique lands when the job is narrow, not when it is broad.
You need production traces or a few dozen examples. If you have neither, collecting them is the first job, and that is real work rather than a footnote.
Every migration needs an eval pass, and that includes ours. Quality is verified on a held-out test set, not assumed. Swapping a model string without an eval is how a quiet regression ships, whether the new string points at Google or at us.
And to be straight about the evidence: the Knowunity results are measured against the model being retired, not against gemini-3.1-flash-lite or any of the newer cheap tiers. We have not published a head-to-head against the replacement. When we run one we will publish it with the setup, as usual.
Owning the weights does not make deprecation risk disappear either. It does mean nobody retires your model on a date of their choosing, which is precisely the term Google has reserved for itself here.
Where to start
Find the gemini-2.5-flash-lite string in your codebase and look at what it does. If it is one narrow job running at volume, pull twenty examples of its inputs and outputs from your logs and start there. Training is free for two full runs and you keep the model, so what you get out of an afternoon is a working model and its eval report rather than a vendor conversation.
distil labs trains task-specific small language models that are cheaper and faster per request than general-purpose LLMs, with equal-or-better accuracy on bounded tasks. Docs · GitHub · Slack