Google a retras două Gemini Flash API slug-uri și direcționează automat traficul de la fiecare nume vechi către un înlocuitor mai nou, creând o modificare a catalogului de modele cu aspect mic, cu consecințe mai mari pentru gateway-uri, analize și raportare pentru clienți.

Conform notelor de lansare ale lui Google Gemini API din 8 octombrie 2026, gemini-3.7-flash este depreciat și înlocuit cu gemini-3.8-flash. Solicitările trimise către slug-ul Flash 3.7 depreciat sunt direcționate automat către 3.8 Flash. Google a depreciat și gemini-3.5-flash, înlocuindu-l cu gemini-3.6-flash și același comportament de redirecționare automată.

Compania a retras și deep-research-pro-preview-12-2025 și spune că agentul Deep Research se va închide pe 23 octombrie 2026, cu căi de migrare către agenți Deep Research mai noi. Acest lucru oferă echipelor o fereastră scurtă pentru a identifica utilizarea în producție, pentru a modifica ID-urile fixate și pentru a verifica comportamentul de ieșire înainte ca vechiul punct final de previzualizare să dispară.

Ce s-a schimbat în Gemini API

Schimbarea operațională imediată este simplă: o solicitare poate denumi un model în timp ce Google deservește altul. Acesta nu este același lucru cu un dezvoltator care editează în mod deliberat o aplicație de la gemini-3.7-flash la gemini-3.8-flash. Este o înlocuire la nivelul furnizorului.

Pentru aplicații simple, diferența poate fi invizibilă dacă răspunsurile rămân acceptabile. Pentru echipele care efectuează evaluări, analize orientate către clienți, fluxuri de lucru reglementate sau atribuirea costurilor, contează. O intrare de jurnal care înregistrează numai modelul solicitat poate face să pară ca și cum un model învechit încă gestionează traficul. Un tablou de bord care înregistrează doar modelul deservit poate ascunde faptul că clienții încă apelează la un melc vechi. Ambele vizualizări sunt incomplete.

Aici aliasele modelului AI devin mai mult decât comoditatea pentru dezvoltatori. Gateway-urile trebuie să distingă cel puțin trei cazuri: un alias de client stabil creat de platformă, un alias de furnizor care plutește în mod intenționat și o rută de depreciere a furnizorului care mapează în tăcere un ID de model public vechi cu unul nou. Tratându-le pe toate trei ca pe același câmp, se creează analize ambigue.

De ce este utilă, dar riscantă redirecționarea automată

Redirecționarea automată reduce ruperea imediată. Dacă un client a codificat gemini-3.7-flash, ruta de înlocuire a lui Google poate menține cererile în curs în timp ce echipa actualizează configurația. Aceasta este o alegere practică de continuitate a serviciilor, în special pentru aplicațiile în care ID-urile modelului sunt distribuite prin scripturi, integrări de parteneri, solicitări sau setări ale clienților.

Compartimentul este pierderea controlului explicit. O înlocuire a modelului poate schimba latența, stilul de ieșire, comportamentul de siguranță, modelele de utilizare a instrumentelor sau fiabilitatea carcasei marginale, chiar și atunci când apelul API încă reușește. Este posibil ca dezvoltatorii să nu observe schimbarea până când o evaluare nu se schimbă, un prompt se comportă diferit sau un client întreabă de ce utilizarea raportată nu mai corespunde documentației.

Riscul este mai mare pentru platformele care expun Google modele printr-o gateway multi-model API pentru echipe. Aceste produse se află între furnizor și utilizatorul final, așa că trebuie să decidă cât de mult va apărea din comportamentul de rutare al furnizorului. Un gateway care pur și simplu redirecționează vechiul slug și facturează apelul rezultat ca de obicei poate păstra compatibilitatea, dar lasă echipelor de asistență și finanțare cu o pistă de audit slabă.

Ce gateway-uri și platforme de reseller ar trebui să înregistreze

Cel mai curat model este de a stoca modelul solicitat, modelul furnizorului rezolvat și regula de alias care a determinat rezoluția. Pentru modificarea Gemini Flash, aceasta înseamnă că o înregistrare de utilizare ar trebui să poată arăta că clientul a solicitat gemini-3.7-flash, Google a servit gemini-3.8-flash, iar motivul a fost redirecționarea deprecierii lui Google, mai degrabă decât o regulă de rezervă definită de client.

Această distincție afectează suportul pentru facturare, planificarea migrației și încrederea în produs. Dacă un client întreabă dacă aplicația sa folosește în continuare un model depreciat, răspunsul nu ar trebui să necesite arheologie manuală a jurnalului. Dacă un revânzător trebuie să notifice conturile din aval, ar trebui să poată segmenta după slug moștenit solicitat. Dacă o suită de evaluare internă începe să eșueze, inginerii ar trebui să poată compara rezultatele înainte și după schimbarea modelului difuzat fără a ghici când s-a mutat traficul.

Pentru produsele în stil Model Gate, munca practică este în analiza utilizării și raportarea clienților. Un tablou de bord de analiză a utilizării ar trebui să evite restrângerea modelului solicitat și difuzat într-o singură etichetă. De asemenea, ar trebui să facă ca ID-urile învechite să fie suficient de vizibile pentru ca proprietarii de cont să împingă migrarea înainte ca asistența furnizorului să se încheie.

Închiderea agentului Deep Research adaugă un al doilea tip de termen limită. Spre deosebire de o redirecționare Flash, Google spune că deep-research-pro-preview-12-2025 se va închide pe 23 octombrie 2026. Echipele care folosesc acel agent de previzualizare trebuie să migreze mai degrabă decât să se bazeze pe rutarea de compatibilitate nedefinită. Deoarece fluxurile de lucru Deep Research pot fi încorporate în conductele de cercetare sau de automatizare de lungă durată, verificarea migrației ar trebui să includă solicitări, ipoteze pentru instrumente, formate de ieșire și orice liste de modele permise stocate.

Ce rămâne nesigur

Notele de lansare ale

Google identifică slug-urile, înlocuirile și comportamentul de redirecționare învechite, dar nu rezolvă toate întrebările operaționale pentru platformele din aval. Notele nu oferă o comparație amplă de comportament între modelele Flash vechi și cele de înlocuire din intrarea din jurnalul de modificări citată. De asemenea, nu precizează o dată de închidere pentru slug-urile Flash depreciate în același mod în care o fac pentru agentul de previzualizare Deep Research.

Asta lasă echipele cu o problemă familiară de API-management: compatibilitatea poate continua pentru moment, dar starea stabilă este încă migrarea. Dezvoltatorii ar trebui să actualizeze selecțiile explicite de model, să ruleze din nou evaluările critice cu ID-urile înlocuitoare și să se asigure că jurnalele păstrează suficiente detalii pentru a explica ce s-a întâmplat în timpul tranziției.

Lecția mai largă este că ID-urile de model nu mai sunt simple nume de produse. Acestea pot fi versiuni stabile, aliasuri în mișcare, shim-uri de compatibilitate sau capcane de depreciere. Gateway-urile care doresc să ofere clienților un control fiabil au nevoie de un model de date care să reprezinte direct aceste diferențe.