Google har fasat ut två Gemini Flash API-sluggar och dirigerar automatiskt trafik från varje gammalt namn till en nyare ersättning, vilket skapar en liten modellkatalogändring med större konsekvenser för gateways, analyser och kundrapportering.

Enligt Googles Gemini API release notes daterad 8 oktober 2026 är gemini-3.7-flash utfasad och ersatt av gemini-3.8-flash. Förfrågningar som skickas till den föråldrade 3.7 Flash-sluggen dirigeras automatiskt till 3.8 Flash. Google fasade också ut gemini-3.5-flash och ersatte den med gemini-3.6-flash och samma automatiska omdirigeringsbeteende.

Företaget fasade också ut deep-research-pro-preview-12-2025 och säger att Deep Research-agenten kommer att stängas den 23 oktober 2026, med migreringsvägar till nyare Deep Research-agenter. Det ger teamen ett kort fönster för att identifiera produktionsanvändning, ändra fästa ID:n och verifiera utdatabeteende innan den gamla förhandsgranskningsslutpunkten försvinner.

Vad ändrades i Gemini API

Den omedelbara operativa förändringen är enkel: en begäran kan namnge en modell medan Google betjänar en annan. Det är inte samma sak som att en utvecklare medvetet redigerar en applikation från gemini-3.7-flash till gemini-3.8-flash. Det är ersättning på leverantörssidan.

För enkla applikationer kan skillnaden vara osynlig om svaren förblir acceptabla. För team som kör evaler, kundinriktad analys, reglerade arbetsflöden eller kostnadstillskrivning är det viktigt. En loggpost som endast registrerar den begärda modellen kan få det att se ut som om en föråldrad modell fortfarande hanterar trafik. En instrumentpanel som bara registrerar den serverade modellen kan dölja det faktum att kunder fortfarande ringer en gammal snigel. Båda vyerna är ofullständiga.

Det är här AI-modellalias blir mer än bekvämlighet för utvecklare. Gateways måste särskilja minst tre fall: ett stabilt kundalias skapat av plattformen, ett leverantörsalias som avsiktligt flyter, och en rutt för leverantörsavskrivning som tyst mappar ett gammalt offentligt modell-ID till ett nytt. Att behandla alla tre som samma fält skapar tvetydiga analyser.

Varför automatisk omdirigering är användbart men riskabelt

Automatisk omdirigering minskar omedelbart brott. Om en kund har hårdkodat gemini-3.7-flash, kan Googles ersättningsrutt hålla förfrågningar igång medan teamet uppdaterar konfigurationen. Det är ett praktiskt val för tjänstekontinuitet, särskilt för applikationer där modell-ID:n är fördelade över skript, partnerintegrationer, uppmaningar eller kundinställningar.

Kompromissen är förlust av explicit kontroll. En modellersättning kan ändra fördröjning, utmatningsstil, säkerhetsbeteende, verktygsanvändningsmönster eller tillförlitlighet i ytterkanter även när API-anropet fortfarande lyckas. Utvecklare kanske inte märker förändringen förrän en utvärdering avviker, en uppmaning beter sig annorlunda eller en kund frågar varför den rapporterade användningen inte längre matchar dokumentationen.

Risken är högre för plattformar som exponerar Google modeller genom en multi-model API gateway för team. Dessa produkter sitter mellan leverantören och slutanvändaren, så de måste bestämma hur mycket av leverantörens routingbeteende som ska dyka upp. En gateway som helt enkelt vidarebefordrar den gamla biten och fakturerar det resulterande samtalet som vanligt kan bevara kompatibiliteten, men den lämnar support- och ekonomiteam med ett svagt granskningsspår.

Vad ska gateways och återförsäljarplattformar registrera

Det renaste mönstret är att lagra den begärda modellen, den lösta leverantörsmodellen och aliasregeln som orsakade upplösningen. För Gemini Flash-ändringen betyder det att en användningspost ska kunna visa att kunden begärde gemini-3.7-flash, Google serverad gemini-3.8-flash, och anledningen var Googles utfasningsomdirigering snarare än en kunddefinierad reservregel.

Den skillnaden påverkar faktureringsstöd, migreringsplanering och produktförtroende. Om en kund frågar om deras applikation fortfarande använder en föråldrad modell, bör svaret inte kräva manuell loggarkeologi. Om en återförsäljare behöver meddela nedströmskonton bör den kunna segmentera efter efterfrågad äldre slug. Om en intern eval-svit börjar misslyckas bör ingenjörer kunna jämföra resultat före och efter bytet av servermodell utan att gissa när trafiken rörde sig.

För Model Gateprodukter är det praktiska arbetet i användningsanalys och kundrapportering. En användningsanalysinstrumentpanel bör undvika att komprimera den begärda och visade modellen till en etikett. Det bör också göra föråldrade ID:n tillräckligt synliga för kontoägare att driva migrering innan leverantörssupporten upphör.

Stängningen av Deep Research-agenten lägger till en andra typ av deadline. Till skillnad från en Flash-omdirigering säger Google att deep-research-pro-preview-12-2025 kommer att stängas av den 23 oktober 2026. Team som använder den förhandsgranskningsagenten måste migrera i stället för att förlita sig på kompatibilitetsrutt på obestämd tid. Eftersom Deep Research-arbetsflöden kan vara inbäddade i mer långvariga forsknings- eller automationspipelines, bör migreringskontrollen inkludera uppmaningar, verktygsantaganden, utdataformat och eventuella lagrade modellgodkännandelistor.

Vad är fortfarande osäkert

Googles versionsnoteringar identifierar de föråldrade slugs, ersättningar och omdirigeringsbeteende, men de löser inte alla driftsfrågor för nedströmsplattformar. Anteckningarna ger inte en bred beteendemässig jämförelse mellan den gamla och ersättningsmodellen av Flash i den citerade ändringsloggen. De anger inte heller ett avstängningsdatum för de utfasade Flash-slugarna på samma sätt som de gör för förhandsgranskningsagenten för Deep Research.

Det lämnar team med ett välbekant API-hanteringsproblem: kompatibiliteten kan fortsätta än så länge, men det stabila tillståndet är fortfarande migrering. Utvecklare bör uppdatera explicita modellval, köra om kritiska evaler mot ersättnings-ID:n och se till att loggarna har tillräckligt med detaljer för att förklara vad som hände under övergången.

Den bredare lärdomen är att modell-ID:n inte längre är enkla produktnamn. De kan vara stabila utgåvor, rörliga alias, kompatibilitetsshims eller utfasningsfällor. Gateways som vill ge kunderna pålitlig kontroll behöver en datamodell som kan representera dessa skillnader direkt.