On 8 October Google deprecated gemini-3.7-flash, a stable model it released on 13 August, and gemini-3.5-flash from 19 May. Neither has a shutdown date. Every request to either ID is now answered by its successor, 3.8 Flash and 3.6 Flash.
Nothing on the request path says so. Both IDs still appear in the model list, the model metadata endpoint returns the old version string, and the call returns 200. The one place the swap shows is the modelVersion field of the response, which names the model that actually ran.
Vertex AI treats the same model differently. There, 3.7 Flash has a fixed retirement date of 28 January 2027 and the docs tell you to upgrade, with no routing mentioned. On the Gemini API a stable ID is a pointer Google can move, so log what comes back.
What changed on Wednesday
The Gemini API changelog entry for 8 October is short. gemini-3.7-flash "is deprecated and has been replaced by gemini-3.8-flash." Then: "All requests to gemini-3.7-flash are automatically routed to gemini-3.8-flash." Update your model string. The same entry says the same thing about gemini-3.5-flash and gemini-3.6-flash.
The deprecations page lists both retired IDs with "No shutdown date announced." That page defines a deprecation as "the announcement that we no longer provide support for a model, and that it will be shut down in the near future," and a shutdown as the point where the endpoint "is no longer available." Routing is a third state the page never defines. The endpoint is available. The model behind it is gone.
The timeline is short. 3.7 Flash went GA on 13 August as "our most intelligent workhorse model yet for coding and agents," at an introductory price through 31 December. 3.8 Flash went GA on 2 September, 20 days later. On 8 October, 56 days after launch, 3.7 Flash was deprecated and its traffic moved. 3.5 Flash lasted 142 days, and for part of that time it was the model behind gemini-flash-latest.
What the API says if you ask it
I sent a handful of requests this morning with an ordinary API key.
GET /v1beta/models/gemini-3.7-flash returns a normal model object: version 3.7-flash-08-2026, a 1,048,576-token input limit, 65,536 output, thinking enabled. No status, no retirement time, no message. gemini-3.5-flash looks the same with version 3.5-flash-05-2026. The model list shows 3.5, 3.6, 3.7 and 3.8 Flash side by side as ordinary entries.
generateContent on gemini-3.7-flash returns 200 and a body whose modelVersion reads gemini-3.8-flash. The same call on gemini-3.5-flash comes back with gemini-3.6-flash. The API reference defines modelVersion as "the model version used to generate the response," and here it is doing exactly that job. The ID you sent is not the model you got.
The response schema has a field built for this moment. modelStatus carries a modelStage, a retirementTime and a message, and the stage enum runs from STABLE through LEGACY ("on the path to deprecation in near future") to DEPRECATED and RETIRED, both described as models that "cannot be used." It was absent from both responses. And the enum's own definition of a deprecated model is one that cannot be used, which is the opposite of what happened to 3.7 Flash.
What "stable" promised
Google's models page explains the naming scheme. A stable ID "points to a specific stable model. Stable models usually don't change. Most production apps should use a specific stable model." Preview models get "at least 2 weeks notice" before deprecation. gemini-3.7-flash was a stable ID, and the changelog entry that announced its deprecation also announced that the routing was already live.
"Usually" is carrying the weight. Nothing in the docs is false. A stable model didn't change, it was replaced, and the ID that pointed at it now points at something else. For anyone who pinned the ID because the docs told them to, that distinction is academic.
The two model pages don't help you tell them apart either. 3.7 Flash and 3.8 Flash list the same token limits, the same three thinking levels with minimal returning an error, the same tool support and the same unsupported modalities. The spec sheets are identical. What differs is the weights, which is the part you were pinning.
Price and quota
For the 3.7 to 3.8 pair, the bill doesn't move. 3.7 Flash launched at an introductory $0.75 per million input tokens and $3.75 output, and 3.8 Flash carries the same rate through 31 December, after which it doubles to $1.50 and $7.50. The routing changes the model and not the invoice, for now.
3.5 Flash goes the other direction. Google's pricing page no longer has a row for it, so the rate you pay is whatever 3.6 Flash costs, $0.75 and $3.75. Pricing aggregators had 3.5 Flash at $1.50 in and $9.00 out. The maintainer of an open-source AI gateway merged a change on Friday to price both retired IDs as their replacements, because Google's page had stopped listing them and the gateway's model check had started flagging them as missing. The rate limits page lists only the replacements too.
Vertex AI is a different surface
Vertex AI's page for Gemini 3.7 Flash says it "will be retired on January 28, 2027. Upgrade to Gemini 3.8 Flash to avoid service disruptions." The Vertex lifecycle page puts 3.7 Flash in its shorter-term group, where "a model remains active until we announce its retirement date," and promises at least 45 days once a date is set. 3.5 Flash sits in the 12-month group with a retirement of 19 May 2027 or later.
Nothing on the Vertex pages mentions routing. I can't test Vertex from here, so I'll say only what the docs say: a fixed date and an instruction to upgrade, which is the ordinary deprecation contract. The same model ID on the Gemini API got no date and a silent redirect. If you run the same code against both, the two paths have been serving different models since Wednesday.
Someone's evals already moved
A developer running a video transcription pipeline on 3.7 Flash opened a P1 issue on Friday. They had benchmarked 3.8 Flash on 19 September and not adopted it, calling the result "close to a tie," with one of three runs returning only part of the task. After the redirect, two severe quality flags appeared in about 20 transcripts: a 22-minute video reduced to three dialogue entries, and a 30-minute podcast chunk that returned zero output tokens. They call that weak evidence, which is fair. Their fix is the right one: switch the default, persist the served modelVersion in every output's metadata, and re-baseline the failure rate on the model that is actually running.
That last step is the one most pipelines skip. Their A/B test had 3.7 Flash at zero severe flags in twelve runs. Whatever the number is on 3.8 Flash, it has been the production number since Wednesday, and the pinned ID in the config file says otherwise.
What to do with this
Search your code and config for gemini-3.7-flash and gemini-3.5-flash and change them. The route works today and has no announced end, which is not the same as a commitment.
Log modelVersion from every Gemini response and compare it to the ID you sent. One line of code, and it would have paged you on Wednesday. It is also the only signal available, since the model endpoint and the model list don't carry one.
If a pipeline was pinned to 3.7 Flash because it was evaluated there, it has been running on 3.8 Flash unevaluated for two days. Re-run the eval. The transcription developer found a difference in twenty samples. You may find none, but you don't know yet.
Treat the stable tier the way the docs describe it. "Usually don't change" is a reasonable promise from a provider that shipped four stable Flash models between 19 May and 2 September. It is not a pin.