Google har forældet to Gemini Flash API-slugs og dirigerer automatisk trafik fra hvert gammelt navn til en nyere erstatning, hvilket skaber en lille modelkatalogændring med større konsekvenser for gateways, analyser og kunderapportering.

Ifølge Googles Gemini API release notes dateret 8. oktober 2026, er gemini-3.7-flash forældet og erstattet af gemini-3.8-flash. Anmodninger sendt til den forældede 3.7 Flash-slug bliver automatisk dirigeret til 3.8 Flash. Google udfasede også gemini-3.5-flash og erstattede det med gemini-3.6-flash og den samme automatiske omdirigeringsadfærd.

Virksomheden udfasede også deep-research-pro-preview-12-2025 og siger, at Deep Research-agenten vil lukke ned den 23. oktober 2026 med migreringsstier til nyere Deep Research-agenter. Det giver teams et kort vindue til at identificere produktionsbrug, ændre fastgjorte id'er og bekræfte outputadfærd, før det gamle eksempelslutpunkt forsvinder.

Hvad ændrede sig i Gemini API

Den øjeblikkelige driftsændring er ligetil: En anmodning kan navngive én model, mens Google tjener en anden. Det er ikke det samme som en udvikler, der bevidst redigerer en applikation fra gemini-3.7-flash til gemini-3.8-flash. Det er substitution på udbydersiden.

For simple applikationer kan forskellen være usynlig, hvis svar forbliver acceptable. For teams, der kører evalueringer, kundevendte analyser, regulerede arbejdsgange eller omkostningstilskrivning, er det vigtigt. En logpost, der kun registrerer den anmodede model, kan få det til at se ud, som om en forældet model stadig håndterer trafik. Et dashboard, der kun registrerer den betjente model, kan skjule det faktum, at kunderne stadig kalder en gammel snegl. Begge visninger er ufuldstændige.

Det er her, AI-modelaliaser bliver mere end udviklerbekvemmelighed. Gateways skal skelne mellem mindst tre tilfælde: et stabilt kundealias, der er oprettet af platformen, et udbyderalias, der med vilje flyder, og en udbyder-afskrivningsrute, der i det stille kortlægger et gammelt offentligt model-id til et nyt. At behandle alle tre som det samme felt skaber tvetydige analyser.

Hvorfor er automatisk omdirigering nyttig, men risikabel

Automatisk omdirigering reducerer øjeblikkelig brud. Hvis en kunde har hardkodet gemini-3.7-flash, kan Googles erstatningsrute holde anmodninger kørende, mens teamet opdaterer konfigurationen. Det er et praktisk valg af servicekontinuitet, især for applikationer, hvor model-id'er er fordelt på tværs af scripts, partnerintegrationer, prompter eller kundeindstillinger.

Afvejningen er tab af eksplicit kontrol. En modeludskiftning kan ændre latens, outputstil, sikkerhedsadfærd, værktøjsbrugsmønstre eller edge-case-pålidelighed, selv når API-kaldet stadig lykkes. Udviklere bemærker muligvis ikke ændringen, før en evaluering afviger, en prompt opfører sig anderledes, eller en kunde spørger, hvorfor rapporteret brug ikke længere matcher dokumentationen.

Risikoen er højere for platforme, der eksponerer Google modeller gennem en multimodel API-gateway for teams. Disse produkter sidder mellem udbyderen og slutbrugeren, så de skal beslutte, hvor meget af udbyderens routingadfærd, der skal vises. En gateway, der blot videresender den gamle slug og fakturerer det resulterende opkald som sædvanligt, kan bevare kompatibiliteten, men den efterlader support- og økonomiteams med et svagt revisionsspor.

Hvilke gateways og forhandlerplatforme skal registrere

Det reneste mønster er at gemme den anmodede model, den løste udbydermodel og den aliasregel, der forårsagede opløsningen. For Gemini Flash-ændringen betyder det, at en brugspost skal kunne vise, at kunden anmodede om gemini-3.7-flash, Google serverede gemini-3.8-flash, og årsagen var Googles udfasningsomdirigering snarere end en kundedefineret reserveregel.

Denne skelnen påvirker faktureringssupport, migrationsplanlægning og produkttillid. Hvis en kunde spørger, om deres applikation stadig bruger en forældet model, bør svaret ikke kræve manuel log arkæologi. Hvis en forhandler skal underrette downstream-konti, bør den kunne segmentere efter anmodet ældre slug. Hvis en intern evalueringspakke begynder at svigte, bør teknikere være i stand til at sammenligne resultater før og efter ændringen af den viste model uden at gætte, hvornår trafikken flyttede sig.

For produkter i Model Gatestil er det praktiske arbejde i brugsanalyse og kunderapportering. Et usage analytics dashboard bør undgå at skjule den anmodede og viste model til én etiket. Det bør også gøre forældede id'er synlige nok til, at kontoejere kan skubbe migreringer, før udbydersupport slutter.

Lukningen af Deep Research-agenten tilføjer en anden form for deadline. I modsætning til en Flash-omdirigering siger Google, at deep-research-pro-preview-12-2025 lukker ned den 23. oktober 2026. Teams, der bruger denne forhåndsvisningsagent, skal migrere i stedet for at stole på ubestemt kompatibilitetsrouting. Da Deep Research-arbejdsgange kan være indlejret i længerevarende forsknings- eller automatiseringspipelines, bør migreringstjekket omfatte prompter, værktøjsantagelser, outputformater og eventuelle gemte modeltilladelseslister.

Hvad er fortsat usikkert

Googles udgivelsesbemærkninger identificerer de forældede slugs, udskiftninger og omdirigeringsadfærd, men de løser ikke alle driftsspørgsmål for downstream-platforme. Noterne giver ikke en bred adfærdsmæssig sammenligning mellem den gamle og den nye Flash-model i den citerede ændringslogpost. De angiver heller ikke en nedlukningsdato for de forældede Flash-slugs på samme måde, som de gør for forhåndsvisningsagenten Deep Research.

Det efterlader teams med et velkendt API-administrationsproblem: kompatibiliteten fortsætter muligvis indtil videre, men den stabile tilstand er stadig migrering. Udviklere bør opdatere eksplicitte modelvalg, køre kritiske evalueringer igen mod erstatnings-id'erne og sørge for, at logfiler bevarer nok detaljer til at forklare, hvad der skete under overgangen.

Den bredere lektie er, at model-id'er ikke længere er simple produktnavne. De kan være stabile udgivelser, bevægelige aliaser, kompatibilitets-shims eller udskrivningsfælder. Gateways, der ønsker at give kunderne pålidelig kontrol, har brug for en datamodel, der kan repræsentere disse forskelle direkte.