Google has deprecated two Gemini Flash API slugs and is automatically routing traffic from each old name to a newer replacement, creating a small-looking model catalog change with larger consequences for gateways, analytics and customer reporting.
According to Google’s Gemini API release notes dated October 8, 2026, gemini-3.7-flash is deprecated and replaced by gemini-3.8-flash. Requests sent to the deprecated 3.7 Flash slug are automatically routed to 3.8 Flash. Google also deprecated gemini-3.5-flash, replacing it with gemini-3.6-flash and the same automatic rerouting behavior.
The company also deprecated deep-research-pro-preview-12-2025 and says that Deep Research agent will shut down on October 23, 2026, with migration paths to newer Deep Research agents. That gives teams a short window to identify production use, change pinned IDs and verify output behavior before the old preview endpoint disappears.
What changed in the Gemini API
The immediate operational change is straightforward: a request can name one model while Google serves another. That is not the same thing as a developer deliberately editing an application from gemini-3.7-flash to gemini-3.8-flash. It is provider-side substitution.
For simple applications, the difference may be invisible if responses remain acceptable. For teams running evals, customer-facing analytics, regulated workflows or cost attribution, it matters. A log entry that records only the requested model can make it look as though a deprecated model is still handling traffic. A dashboard that records only the served model can hide the fact that customers are still calling an old slug. Both views are incomplete.
This is where AI model aliases become more than developer convenience. Gateways need to distinguish at least three cases: a stable customer alias created by the platform, a provider alias that intentionally floats, and a provider deprecation route that silently maps an old public model ID to a new one. Treating all three as the same field creates ambiguous analytics.
Why automatic rerouting is useful but risky
Automatic rerouting reduces immediate breakage. If a customer has hard-coded gemini-3.7-flash, Google’s replacement route can keep requests running while the team updates configuration. That is a practical service-continuity choice, especially for applications where model IDs are distributed across scripts, partner integrations, prompts or customer settings.
The tradeoff is loss of explicit control. A model replacement can change latency, output style, safety behavior, tool-use patterns or edge-case reliability even when the API call still succeeds. Developers may not notice the change until an evaluation drifts, a prompt behaves differently or a customer asks why reported usage no longer matches documentation.
The risk is higher for platforms that expose Google models through a multi-model API gateway for teams. Those products sit between the provider and the end user, so they have to decide how much of the provider’s routing behavior to surface. A gateway that simply forwards the old slug and bills the resulting call as usual may preserve compatibility, but it leaves support and finance teams with a weak audit trail.
What gateways and reseller platforms should record
The cleanest pattern is to store the requested model, the resolved provider model and the alias rule that caused the resolution. For the Gemini Flash change, that means a usage record should be able to show that the customer requested gemini-3.7-flash, Google served gemini-3.8-flash, and the reason was Google’s deprecation reroute rather than a customer-defined fallback rule.
That distinction affects billing support, migration planning and product trust. If a customer asks whether their application is still using a deprecated model, the answer should not require manual log archaeology. If a reseller needs to notify downstream accounts, it should be able to segment by requested legacy slug. If an internal eval suite begins failing, engineers should be able to compare results before and after the served-model change without guessing when traffic moved.
For Model Gate-style products, the practical work is in usage analytics and customer reporting. A usage analytics dashboard should avoid collapsing requested and served model into one label. It should also make deprecated IDs visible enough for account owners to push migrations before provider support ends.
The Deep Research agent shutdown adds a second kind of deadline. Unlike a Flash reroute, Google says deep-research-pro-preview-12-2025 will shut down on October 23, 2026. Teams using that preview agent need to migrate rather than rely on indefinite compatibility routing. Because Deep Research workflows may be embedded in longer-running research or automation pipelines, the migration check should include prompts, tool assumptions, output formats and any stored model allowlists.
What remains uncertain
Google’s release notes identify the deprecated slugs, replacements and rerouting behavior, but they do not settle every operational question for downstream platforms. The notes do not provide a broad behavioral comparison between the old and replacement Flash models in the cited changelog entry. They also do not state a shutdown date for the deprecated Flash slugs in the same way they do for the Deep Research preview agent.
That leaves teams with a familiar API-management problem: compatibility may continue for now, but the stable state is still migration. Developers should update explicit model selections, rerun critical evals against the replacement IDs and make sure logs retain enough detail to explain what happened during the transition.
The broader lesson is that model IDs are no longer simple product names. They can be stable releases, moving aliases, compatibility shims or deprecation traps. Gateways that want to give customers reliable control need a data model that can represent those differences directly.