Google wycofało dwa moduły Gemini Flash API i automatycznie kieruje ruch z każdej starej nazwy do nowszej wersji, tworząc niewielką zmianę w katalogu modeli z większymi konsekwencjami dla bramek, analiz i raportowania klientów.

Zgodnie z informacjami o wersji Google Gemini API z dnia 8 października 2026 r., wersja gemini-3.7-flash jest przestarzała i zastąpiona przez gemini-3.8-flash. Żądania wysyłane do przestarzałej wersji 3.7 Flash są automatycznie kierowane do wersji 3.8 Flash. Google również uznano za przestarzały gemini-3.5-flash, zastępując go gemini-3.6-flash i zachowując to samo zachowanie automatycznego przekierowywania.

Firma również wycofała deep-research-pro-preview-12-2025 i twierdzi, że agent Deep Research zostanie zamknięty 23 października 2026 r., ze ścieżkami migracji do nowszych agentów Deep Research. Daje to zespołom krótkie okno na identyfikację zastosowań produkcyjnych, zmianę przypiętych identyfikatorów i sprawdzenie zachowania danych wyjściowych, zanim zniknie stary punkt końcowy wersji zapoznawczej.

Co się zmieniło w Gemini API

Natychmiastowa zmiana operacyjna jest prosta: żądanie może nazwać jeden model, a Google obsługuje inny. To nie to samo, co programista celowo edytujący aplikację od gemini-3.7-flash do gemini-3.8-flash. Jest to substytucja po stronie dostawcy.

W przypadku prostych zastosowań różnica może być niewidoczna, jeśli odpowiedzi pozostaną akceptowalne. Ma to znaczenie dla zespołów przeprowadzających oceny, analizy skierowane do klientów, regulowane przepływy pracy lub atrybucję kosztów. Wpis dziennika rejestrujący tylko żądany model może sprawiać wrażenie, jakby przestarzały model nadal obsługiwał ruch. Dashboard rejestrujący tylko obsługiwany model może ukryć fakt, że klienci wciąż dzwonią do starego ślimaka. Obydwa widoki są niekompletne.

W tym miejscu aliasy modeli AI stają się czymś więcej niż tylko wygodą dla programistów. Bramy muszą rozróżnić co najmniej trzy przypadki: stabilny alias klienta utworzony przez platformę, alias dostawcy, który jest celowo pływający, oraz trasę wycofania dostawcy, która po cichu mapuje stary identyfikator modelu publicznego na nowy. Traktowanie wszystkich trzech jako tego samego pola prowadzi do niejednoznacznych analiz.

Dlaczego automatyczne przekierowywanie jest przydatne, ale ryzykowne

Automatyczne przekierowanie ogranicza natychmiastowe awarie. Jeśli klient ma zakodowany na stałe gemini-3.7-flash, trasa zastępcza Google może utrzymać realizację żądań, podczas gdy zespół aktualizuje konfigurację. Jest to praktyczny wybór zapewniający ciągłość usług, szczególnie w przypadku aplikacji, w których identyfikatory modeli są rozproszone w skryptach, integracjach partnerów, podpowiedziach lub ustawieniach klienta.

Kompromisem jest utrata wyraźnej kontroli. Zastąpienie modelu może zmienić opóźnienie, styl wyników, zachowanie bezpieczeństwa, wzorce użycia narzędzi lub niezawodność przypadków brzegowych, nawet jeśli wywołanie API nadal się powiedzie. Programiści mogą nie zauważyć zmiany, dopóki ocena nie ulegnie zmianie, monit nie zachowa się inaczej lub klient nie zapyta, dlaczego zgłoszone użycie nie jest już zgodne z dokumentacją.

Ryzyko jest wyższe w przypadku platform udostępniających Google modele za pośrednictwem bramy wielomodelowej API dla zespołów. Produkty te leżą pomiędzy dostawcą a użytkownikiem końcowym, więc to oni muszą zdecydować, jaka część zachowań dostawcy w zakresie routingu ma zostać ujawniona. Brama, która po prostu przekazuje stary komunikat i jak zwykle wystawia rachunki za wynikowe połączenie, może zachować kompatybilność, ale pozostawia zespołom wsparcia i finansów słabą ścieżkę audytu.

Jakie bramy i platformy sprzedawców powinny rejestrować

Najczystszy wzorzec polega na przechowywaniu żądanego modelu, rozpoznanego modelu dostawcy i reguły aliasu, która spowodowała rozwiązanie. W przypadku zmiany Flash Gemini oznacza to, że zapis użycia powinien być w stanie wykazać, że klient zażądał gemini-3.7-flash, Google został obsłużony gemini-3.8-flash, a powodem było przekierowanie wycofania Google, a nie zdefiniowana przez klienta reguła awaryjna.

To rozróżnienie wpływa na obsługę rozliczeń, planowanie migracji i zaufanie do produktów. Jeśli klient zapyta, czy jego aplikacja nadal korzysta z przestarzałego modelu, odpowiedź nie powinna wymagać ręcznej archeologii dzienników. Jeśli odsprzedawca musi powiadomić dalsze konta, powinien mieć możliwość segmentacji według żądanego starszego ślimaka. Jeśli wewnętrzny zestaw ewaluacyjny zacznie zawodzić, inżynierowie powinni móc porównać wyniki przed i po zmianie obsługiwanego modelu, nie zgadując, kiedy przeniósł się ruch.

W przypadku produktów w stylu Model Gate praktyczna praca polega na analizie użytkowania i raportowaniu klientów. Panel analityczny użycia powinien unikać zwijania żądanego i udostępnianego modelu w jedną etykietę. Powinno także sprawić, że przestarzałe identyfikatory będą wystarczająco widoczne, aby właściciele kont mogli przesyłać migracje przed zakończeniem wsparcia dostawcy.

Zamknięcie agenta Deep Research dodaje drugi rodzaj terminu ostatecznego. W przeciwieństwie do przekierowania Flash, Google mówi, że deep-research-pro-preview-12-2025 zostanie zamknięty 23 października 2026 r. Zespoły korzystające z tego agenta w wersji zapoznawczej muszą przeprowadzić migrację, a nie polegać na routingu o nieokreślonej zgodności. Ponieważ przepływy pracy Deep Research mogą być osadzone w dłuższych procesach badawczych lub automatyzacyjnych, kontrola migracji powinna obejmować podpowiedzi, założenia narzędzi, formaty wyjściowe i wszelkie listy dozwolonych przechowywanych modeli.

Co pozostaje niepewne

Informacje o wersji

Google identyfikują przestarzałe ślimaki, zamienniki i zachowanie związane z przekierowywaniem, ale nie rozstrzygają wszystkich kwestii operacyjnych dla platform niższego szczebla. Uwagi nie zapewniają szerokiego porównania behawioralnego pomiędzy starymi i zastępczymi modelami Flash w cytowanym wpisie dziennika zmian. Nie podają też daty zamknięcia przestarzałych ślimaków Flash w taki sam sposób, jak w przypadku agenta Deep Research w wersji zapoznawczej.

To stawia zespoły przed znanym API problemem z zarządzaniem: zgodność może na razie być zachowana, ale stan stabilny to nadal migracja. Programiści powinni zaktualizować jawnie wybrane modele, ponownie przeprowadzić krytyczne oceny względem identyfikatorów zastępczych i upewnić się, że dzienniki zawierają wystarczająco dużo szczegółów, aby wyjaśnić, co wydarzyło się podczas przejścia.

Szerszy wniosek jest taki, że identyfikatory modeli nie są już prostymi nazwami produktów. Mogą to być wydania stabilne, ruchome aliasy, podkładki kompatybilności lub pułapki przestarzałe. Bramy, które chcą zapewnić klientom niezawodną kontrolę, potrzebują modelu danych, który będzie w stanie bezpośrednio przedstawić te różnice.