Google je opustil dva polža Gemini Flash API in samodejno usmerja promet od vsakega starega imena k novejšemu nadomestnemu, kar ustvarja na videz majhno spremembo kataloga modela z večjimi posledicami za prehode, analitiko in poročanje o strankah.

V skladu z Google Gemini API opombami ob izdaji z dne 8. oktobra 2026 je gemini-3.7-flash zastarel in nadomeščen z gemini-3.8-flash. Zahteve, poslane zastarelemu polžu 3.7 Flash, so samodejno preusmerjene na 3.8 Flash. Google je prav tako opustil gemini-3.5-flash in ga nadomestil z gemini-3.6-flash in enakim samodejnim preusmerjanjem.

Podjetje je prav tako opustilo deep-research-pro-preview-12-2025 in pravi, da se bo agent Deep Research zaprl 23. oktobra 2026 s prehodnimi potmi na novejše agente Deep Research. To daje ekipam kratko okno za prepoznavanje produkcijske uporabe, spreminjanje pripetih ID-jev in preverjanje izhodnega vedenja, preden stara končna točka predogleda izgine.

Kaj se je spremenilo v Gemini API

Takojšnja operativna sprememba je enostavna: zahteva lahko poimenuje en model, medtem ko Google služi drugemu. To ni isto kot razvijalec, ki namerno ureja aplikacijo od gemini-3.7-flash do gemini-3.8-flash. Gre za zamenjavo na strani ponudnika.

Pri preprostih aplikacijah je razlika morda nevidna, če odgovori ostanejo sprejemljivi. Za ekipe, ki izvajajo evalvacije, analitiko, obrnjeno k strankam, regulirane poteke dela ali dodeljevanje stroškov, je pomembno. Vnos v dnevnik, ki beleži samo zahtevani model, lahko povzroči, da je videti, kot da zastareli model še vedno obravnava promet. Nadzorna plošča, ki beleži samo postreženi model, lahko prikrije dejstvo, da kupci še vedno kličejo starega polža. Oba pogleda sta nepopolna.

Tukaj postanejo vzdevki modelov AI več kot udobje za razvijalce. Prehodi morajo razlikovati vsaj tri primere: stabilen vzdevek stranke, ki ga ustvari platforma, vzdevek ponudnika, ki namerno plava, in pot opustitve ponudnika, ki tiho preslika stari ID javnega modela v novega. Obravnavanje vseh treh kot istega polja ustvari dvoumno analitiko.

Zakaj je samodejno preusmerjanje koristno, a tvegano

Samodejna preusmeritev zmanjša takojšnje zlome. Če je stranka trdo kodirala gemini-3.7-flash, lahko nadomestna pot Google še naprej izvaja zahteve, medtem ko ekipa posodablja konfiguracijo. To je praktična izbira neprekinjenosti storitev, zlasti za aplikacije, kjer so ID-ji modelov razporejeni po skriptih, partnerskih integracijah, pozivih ali nastavitvah strank.

Kompromis je izguba eksplicitnega nadzora. Zamenjava modela lahko spremeni zakasnitev, izhodni slog, varnostno vedenje, vzorce uporabe orodja ali zanesljivost robnega primera, tudi če je klic API še vedno uspešen. Razvijalci morda ne bodo opazili spremembe, dokler se ocena ne spremeni, se poziv ne obnaša drugače ali stranka vpraša, zakaj se prijavljena uporaba ne ujema več z dokumentacijo.

Tveganje je večje pri platformah, ki izpostavljajo Google modele prek večmodelnega API prehoda za ekipe. Ti izdelki sedijo med ponudnikom in končnim uporabnikom, zato se morajo odločiti, koliko ponudnikovega usmerjevalnega vedenja bo prikazano. Prehod, ki preprosto posreduje starega polža in nastali klic zaračuna kot običajno, lahko ohrani združljivost, vendar ekipam za podporo in finance pusti šibko revizijsko sled.

Kateri prehodi in platforme preprodajalcev morajo beležiti

Najčistejši vzorec je shranjevanje zahtevanega modela, razrešenega modela ponudnika in pravila vzdevka, ki je povzročilo razrešitev. Za spremembo Gemini Flash to pomeni, da bi zapis o uporabi moral pokazati, da je stranka zahtevala gemini-3.7-flash, Google postregla gemini-3.8-flash, razlog pa je bila preusmeritev opustitve Google in ne nadomestno pravilo, ki ga določi stranka.

Ta razlika vpliva na podporo pri zaračunavanju, načrtovanje selitve in zaupanje v izdelek. Če stranka vpraša, ali njihova aplikacija še vedno uporablja zastarel model, odgovor ne bi smel zahtevati ročne arheologije dnevnikov. Če mora preprodajalec obvestiti nadaljnje račune, mora imeti možnost segmentiranja po zahtevanem podedovanem polžu. Če začne notranji paket za vrednotenje odpovedovati, bi morali imeti inženirji možnost primerjati rezultate pred in po spremembi streženega modela, ne da bi ugibali, kdaj se je promet premaknil.

Pri izdelkih v slogu Model Gate je praktično delo analitika uporabe in poročanje strank. Nadzorna plošča za analitiko uporabe bi morala preprečiti strnitev zahtevanega in postreženega modela v eno oznako. Zastareli ID-ji morajo biti dovolj vidni, da lahko lastniki računov pospešijo selitve, preden se podpora ponudnika konča.

Zaustavitev agenta Deep Research doda drugo vrsto roka. Za razliko od preusmeritve Flash, Google pravi, da se bo deep-research-pro-preview-12-2025 zaustavil 23. oktobra 2026. Ekipe, ki uporabljajo tega agenta za predogled, se morajo preseliti, namesto da bi se zanašale na neomejeno usmerjanje združljivosti. Ker so delovni tokovi Deep Research morda vdelani v dolgotrajnejše raziskovalne ali avtomatizacijske napeljave, mora preverjanje selitve vključevati pozive, predpostavke orodij, izhodne formate in morebitne sezname dovoljenih shranjenih modelov.

Kaj ostaja negotovo

Opombe ob izdaji

Google identificirajo zastarele polže, zamenjave in vedenje pri preusmerjanju, vendar ne rešijo vseh operativnih vprašanj za spodnje platforme. Opombe ne zagotavljajo široke vedenjske primerjave med starim in nadomestnim modelom Flash v navedenem vnosu v dnevnik sprememb. Prav tako ne navedejo datuma zaustavitve za zastarele polže Flash na enak način kot za agenta za predogled Deep Research.

To pušča ekipe pred znano težavo API-upravljanja: združljivost se lahko zaenkrat nadaljuje, vendar je stabilno stanje še vedno migracija. Razvijalci bi morali posodobiti eksplicitne izbire modelov, znova zagnati kritične ocene glede na nadomestne ID-je in zagotoviti, da dnevniki ohranijo dovolj podrobnosti za razlago, kaj se je zgodilo med prehodom.

Širša lekcija je, da ID-ji modelov niso več preprosta imena izdelkov. Lahko so stabilne izdaje, premikajoči se vzdevki, združljivostni podstavki ali pasti zastaranja. Prehodi, ki želijo strankam zagotoviti zanesljiv nadzor, potrebujejo podatkovni model, ki lahko neposredno predstavi te razlike.