Google har avviklet to Gemini Flash API-slugs og dirigerer automatisk trafikk fra hvert gamle navn til en nyere erstatning, og skaper en liten modellkatalogendring med større konsekvenser for gatewayer, analyser og kunderapportering.

I henhold til Googles Gemini API versjonsnotater datert 8. oktober 2026, er gemini-3.7-flash avviklet og erstattet av gemini-3.8-flash. Forespørsler sendt til den utdaterte 3.7 Flash-slugen blir automatisk rutet til 3.8 Flash. Google avviklet også gemini-3.5-flash, og erstattet den med gemini-3.6-flash og samme automatiske omdirigeringsatferd.

Selskapet avviklet også deep-research-pro-preview-12-2025 og sier at Deep Research-agenten vil legge ned 23. oktober 2026, med migreringsveier til nyere Deep Research-agenter. Det gir teamene et kort vindu for å identifisere produksjonsbruk, endre festede ID-er og bekrefte utdataatferd før det gamle forhåndsvisningsendepunktet forsvinner.

Hva endret seg i Gemini API

Den umiddelbare driftsendringen er enkel: En forespørsel kan gi én modell navn mens Google betjener en annen. Det er ikke det samme som at en utvikler bevisst redigerer en applikasjon fra gemini-3.7-flash til gemini-3.8-flash. Det er erstatning på leverandørsiden.

For enkle applikasjoner kan forskjellen være usynlig hvis svarene fortsatt er akseptable. For team som kjører evalueringer, kundevendt analyse, regulerte arbeidsflyter eller kostnadsattribusjon, er det viktig. En loggoppføring som bare registrerer den forespurte modellen kan få det til å se ut som om en utdatert modell fortsatt håndterer trafikk. Et dashbord som kun registrerer den serverte modellen kan skjule det faktum at kundene fortsatt kaller en gammel snegl. Begge visningene er ufullstendige.

Det er her AI-modellaliaser blir mer enn utviklervennlighet. Gatewayer må skille mellom minst tre tilfeller: et stabilt kundealias opprettet av plattformen, et leverandøralias som med hensikt flyter, og en leverandøravskrivningsrute som stille kartlegger en gammel offentlig modell-ID til en ny. Å behandle alle tre som samme felt skaper tvetydige analyser.

Hvorfor automatisk omdirigering er nyttig, men risikabelt

Automatisk omdirigering reduserer umiddelbar brudd. Hvis en kunde har hardkodet gemini-3.7-flash, kan Googles erstatningsrute fortsette å kjøre forespørsler mens teamet oppdaterer konfigurasjonen. Dette er et praktisk valg for tjenestekontinuitet, spesielt for applikasjoner der modell-ID-er er fordelt på tvers av skript, partnerintegrasjoner, forespørsler eller kundeinnstillinger.

Kompromissen er tap av eksplisitt kontroll. En modellerstatning kan endre ventetid, utdatastil, sikkerhetsatferd, verktøybruksmønstre eller edge-case-pålitelighet selv når API-kallet fortsatt lykkes. Utviklere legger kanskje ikke merke til endringen før en evaluering avviker, en forespørsel oppfører seg annerledes eller en kunde spør hvorfor rapportert bruk ikke lenger samsvarer med dokumentasjonen.

Risikoen er høyere for plattformer som eksponerer Google modeller gjennom en multi-model API gateway for team. Disse produktene sitter mellom leverandøren og sluttbrukeren, så de må bestemme hvor mye av leverandørens ruteadferd som skal vises. En gateway som ganske enkelt videresender den gamle sluggen og fakturerer det resulterende anropet som vanlig, kan bevare kompatibiliteten, men den etterlater støtte- og økonomiteam med et svakt revisjonsspor.

Hva gatewayer og forhandlerplattformer bør registrere

Det reneste mønsteret er å lagre den forespurte modellen, den løste leverandørmodellen og aliasregelen som forårsaket løsningen. For Gemini Flash-endringen betyr det at en brukspost skal kunne vise at kunden ba om gemini-3.7-flash, Google levert gemini-3.8-flash, og årsaken var Googles avviklingsomdirigering i stedet for en kundedefinert reserveregel.

Denne forskjellen påvirker faktureringsstøtte, migreringsplanlegging og produkttillit. Hvis en kunde spør om applikasjonen deres fortsatt bruker en utdatert modell, skal svaret ikke kreve manuell loggarkeologi. Hvis en forhandler trenger å varsle nedstrømskontoer, bør den kunne segmentere etter forespurt eldre slug. Hvis en intern evalueringspakke begynner å svikte, bør ingeniører kunne sammenligne resultater før og etter endringen av servert modell uten å gjette når trafikken beveget seg.

For produkter i Model Gatestil er det praktiske arbeidet i bruksanalyse og kunderapportering. Et oversiktspanel for bruksanalyse bør unngå å skjule den forespurte og leverte modellen til én etikett. Den bør også gjøre utdaterte IDer synlige nok til at kontoeiere kan pushe migreringer før leverandørstøtten avsluttes.

Nedleggelsen av Deep Research-agenten legger til en annen type frist. I motsetning til en Flash-omdirigering, sier Google at deep-research-pro-preview-12-2025 vil stenges 23. oktober 2026. Team som bruker den forhåndsvisningsagenten, må migrere i stedet for å stole på ubestemt kompatibilitetsruting. Fordi Deep Research-arbeidsflyter kan være innebygd i lengre løpende forsknings- eller automatiseringspipelines, bør migreringssjekken inkludere forespørsler, verktøyforutsetninger, utdataformater og eventuelle lagrede modelltillatelseslister.

Hva er fortsatt usikkert

Googles versjonsnotater identifiserer utdaterte slugs, erstatninger og omdirigeringsatferd, men de løser ikke alle driftsspørsmål for nedstrømsplattformer. Notatene gir ikke en bred atferdssammenligning mellom de gamle og erstattende Flash-modellene i den siterte endringsloggoppføringen. De oppgir heller ikke en avslutningsdato for de utdaterte Flash-sluggene på samme måte som for forhåndsvisningsagenten Deep Research.

Dette etterlater team med et kjent API-administrasjonsproblem: kompatibiliteten kan fortsette foreløpig, men den stabile tilstanden er fortsatt migrering. Utviklere bør oppdatere eksplisitte modellvalg, kjøre kritiske evalueringer på nytt mot erstatnings-ID-ene og sørge for at loggene har nok detaljer til å forklare hva som skjedde under overgangen.

Den bredere lærdommen er at modell-ID-er ikke lenger er enkle produktnavn. De kan være stabile utgivelser, bevegelige aliaser, kompatibilitetsshims eller avskrivningsfeller. Gatewayer som ønsker å gi kundene pålitelig kontroll, trenger en datamodell som kan representere disse forskjellene direkte.