A

Google két Gemini Flash API sluget elavult, és automatikusan átirányítja a forgalmat minden régi névről egy újabb cserére, így egy kis megjelenésű modellkatalógus-módosítást hoz létre, ami nagyobb következményekkel jár az átjárókra, az elemzésekre és az ügyféljelentésekre nézve.

A Google Gemini API kiadási megjegyzései szerint, 2026. október 8-án, a gemini-3.7-flash elavult, helyette a gemini-3.8-flash. Az elavult 3.7-es Flash-slug-nak küldött kérések automatikusan a 3.8-as Flash-be kerülnek. Google szintén elavult gemini-3.5-flash, helyette gemini-3.6-flash és ugyanaz az automatikus átirányítási viselkedés.

A vállalat szintén elavult deep-research-pro-preview-12-2025, és azt állítja, hogy a Deep Research ügynök 2026. október 23-án leáll, és áttér az újabb Deep Research ügynökökhöz. Ez egy rövid időtartamot biztosít a csapatoknak az éles felhasználás azonosítására, a rögzített azonosítók módosítására és a kimeneti viselkedés ellenőrzésére, mielőtt a régi előnézeti végpont eltűnne.

Mi változott a Gemini API

Az azonnali működési változás egyértelmű: egy kérés egy modellt nevezhet meg, míg a Google egy másik modellt szolgál ki. Ez nem ugyanaz, mint egy fejlesztő szándékosan szerkeszteni egy alkalmazást gemini-3.7-flash-ről gemini-3.8-flash-re. Ez egy szolgáltató oldali helyettesítés.

Egyszerű alkalmazások esetén a különbség láthatatlan lehet, ha a válaszok elfogadhatóak maradnak. Az értékeléseket, az ügyfelek felé irányuló elemzéseket, a szabályozott munkafolyamatokat vagy a költség-hozzárendelést futtató csapatok számára ez számít. A csak a kért modellt rögzítő naplóbejegyzés azt a látszatot keltheti, mintha egy elavult modell továbbra is kezelné a forgalmat. A csak a kiszolgált modellt rögzítő irányítópult elrejti azt a tényt, hogy a vásárlók még mindig egy régi csigát hívnak. Mindkét nézet hiányos.

Ez az, ahol az AI modellálnevek többet jelentenek a fejlesztők kényelménél. Az átjáróknak legalább három esetet kell megkülönböztetniük: a platform által létrehozott stabil ügyfél-álnevet, a szándékosan lebegtetett szolgáltatói álnevet, valamint a szolgáltató megszüntetési útvonalát, amely csendesen leképezi a régi nyilvános modellazonosítót egy újra. Ha mindhárom mezőt ugyanazon mezőként kezeli, akkor kétértelmű elemzési eredmények születnek.

Miért hasznos, de kockázatos az automatikus átirányítás?

Az automatikus átirányítás csökkenti az azonnali törést. Ha egy ügyfél bekódolta a gemini-3.7-flash számot, akkor a Google csereútvonala továbbra is futni tudja a kéréseket, amíg a csapat frissíti a konfigurációt. Ez egy praktikus szolgáltatás-folytonossági választás, különösen azoknál az alkalmazásoknál, ahol a modellazonosítók szkriptek, partnerintegrációk, promptok vagy ügyfélbeállítások között vannak elosztva.

A kompromisszum az explicit kontroll elvesztése. A modellcsere megváltoztathatja a várakozási időt, a kimeneti stílust, a biztonsági viselkedést, a szerszámhasználati mintákat vagy az él-betét megbízhatóságát még akkor is, ha a API hívás továbbra is sikeres. Előfordulhat, hogy a fejlesztők nem veszik észre a változást addig, amíg az értékelés el nem mozdul, a felszólítás másképp nem viselkedik, vagy az ügyfél megkérdezi, hogy a bejelentett használat miért nem egyezik már a dokumentációval.

Nagyobb a kockázat azoknál a platformoknál, amelyek Google modellt tesznek közzé a többmodell API csapatok számára készült átjárón keresztül. Ezek a termékek a szolgáltató és a végfelhasználó között helyezkednek el, így nekik kell eldönteniük, hogy a szolgáltató útválasztási viselkedéséből mennyi kerüljön felszínre. Egy átjáró, amely egyszerűen továbbítja a régi csigát, és a szokásos módon kiszámlázza a létrejövő hívást, megőrizheti a kompatibilitást, de gyenge ellenőrzési nyomot hagy a támogatási és pénzügyi csapatok számára.

Milyen átjáróknak és viszonteladói platformoknak kell rögzíteniük

A legtisztább minta a kért modell, a feloldott szolgáltatói modell és a megoldást okozó álnév-szabály tárolása. A Gemini Flash módosításnál ez azt jelenti, hogy a használati rekordnak képesnek kell lennie arra, hogy kimutatja, hogy az ügyfél a gemini-3.7-flash, Google gemini-3.8-flash szolgáltatást kérte, és ennek oka a Google megszüntetésének átirányítása volt, nem pedig egy ügyfél által meghatározott tartalék szabály.

Ez a megkülönböztetés érinti a számlázási támogatást, a migráció tervezését és a termékmegbízhatóságot. Ha egy ügyfél megkérdezi, hogy az alkalmazása továbbra is elavult modellt használ-e, a válaszhoz nem szükséges manuális naplórégészet. Ha egy viszonteladónak értesítenie kell a későbbi fiókokat, akkor képesnek kell lennie a kért örökölt csigák alapján szegmentálni. Ha egy belső kiértékelési csomag kezd meghibásodni, a mérnököknek össze kell tudniuk hasonlítani a kiszolgált modellváltás előtti és utáni eredményeket anélkül, hogy találgatnák, mikor változott meg a forgalom.

A Model Gate-stílusú termékeknél a gyakorlati munka a használati elemzés és az ügyfelek jelentése. A használatelemzési irányítópultnak el kell kerülnie a kért és megjelenített modell egyetlen címkévé való összecsukását. Ezenkívül az elavult azonosítókat is elég láthatóvá kell tennie ahhoz, hogy a fióktulajdonosok a szolgáltatói támogatás megszűnése előtt megtegyék az áttelepítést.

A Deep Research ügynök leállítása egy második típusú határidőt ad hozzá. A Flash-átirányítással ellentétben a Google azt írja, hogy a deep-research-pro-preview-12-2025 2026. október 23-án leáll. Az ezt az előnézeti ügynököt használó csapatoknak migrálniuk kell, ahelyett, hogy a határozatlan idejű kompatibilitási útválasztásra hagyatkoznának. Mivel a Deep Research munkafolyamatok beágyazhatók hosszabb ideig tartó kutatási vagy automatizálási folyamatokba, az áttelepítési ellenőrzésnek tartalmaznia kell a promptokat, az eszközfeltevéseket, a kimeneti formátumokat és a tárolt modellek engedélyezési listáit.

Ami még bizonytalan

A

Google kiadási megjegyzései azonosítják az elavult csigákat, cseréket és átirányítási viselkedést, de nem oldanak meg minden működési kérdést a downstream platformokon. A megjegyzések nem nyújtanak átfogó viselkedési összehasonlítást a régi és a helyettesítő Flash-modellek között az idézett változásnapló-bejegyzésben. Ugyanúgy nem adnak meg leállási dátumot az elavult Flash-slugokhoz, mint a Deep Research előnézeti ügynökéhez.

Ez egy ismerős API-kezelési probléma elé hagyja a csapatokat: a kompatibilitás egyelőre folytatódhat, de a stabil állapot továbbra is a migráció. A fejlesztőknek frissíteniük kell az explicit modellválasztásokat, újra le kell futtatniuk a kritikus értékeléseket a helyettesítő azonosítókkal szemben, és gondoskodniuk kell arról, hogy a naplók elegendő részletet őrizzenek meg ahhoz, hogy elmagyarázzák, mi történt az átállás során.

A tágabb tanulság az, hogy a modellazonosítók már nem egyszerű terméknevek. Ezek lehetnek stabil kiadások, mozgó álnevek, kompatibilitási alátétek vagy elavult csapdák. Azoknak az átjáróknak, amelyek megbízható irányítást szeretnének biztosítani az ügyfeleknek, olyan adatmodellre van szükségük, amely közvetlenül képes reprezentálni ezeket a különbségeket.