Google отхвърли два Gemini Flash API плуга и автоматично насочва трафика от всяко старо име към по-ново заместващо, създавайки малка на вид промяна в каталога на модела с по-големи последствия за шлюзове, анализи и отчитане на клиенти.

Съгласно Google Gemini API бележки по изданието от 8 октомври 2026 г., gemini-3.7-flash е отхвърлен и заменен с gemini-3.8-flash. Заявките, изпратени до остарелия 3.7 Flash slug, автоматично се насочват към 3.8 Flash. Google също оттегли gemini-3.5-flash, заменяйки го с gemini-3.6-flash и същото автоматично пренасочване.

Компанията също така отхвърли deep-research-pro-preview-12-2025 и казва, че агентът Deep Research ще се затвори на 23 октомври 2026 г. с пътища за миграция към по-нови агенти Deep Research. Това дава на екипите кратък прозорец за идентифициране на производствената употреба, промяна на фиксираните идентификатори и проверка на поведението на изхода, преди старата крайна точка за визуализация да изчезне.

Какво се промени в Gemini API

Незабавната оперативна промяна е проста: една заявка може да назове един модел, докато Google обслужва друг. Това не е същото като програмист, който умишлено редактира приложение от gemini-3.7-flash на gemini-3.8-flash. Това е заместване от страна на доставчика.

За прости приложения разликата може да е невидима, ако отговорите останат приемливи. За екипи, изпълняващи оценки, анализи, насочени към клиента, регулирани работни потоци или разпределяне на разходите, това има значение. Запис в регистрационния файл, който записва само заявения модел, може да изглежда така, сякаш отхвърлен модел все още обработва трафик. Табло, което записва само обслужвания модел, може да скрие факта, че клиентите все още се обаждат на стар плужек. И двата изгледа са непълни.

Тук псевдонимите на AI модели стават нещо повече от удобство за разработчици. Шлюзовете трябва да разграничат най-малко три случая: стабилен клиентски псевдоним, създаден от платформата, псевдоним на доставчик, който умишлено плава, и маршрут за отмяна на доставчика, който тихо картографира стар публичен идентификатор на модел към нов. Третирането на трите като едно и също поле създава двусмислен анализ.

Защо автоматичното пренасочване е полезно, но рисковано

Автоматичното пренасочване намалява незабавното счупване. Ако клиент е кодирал твърдо gemini-3.7-flash, заместващият маршрут на Google може да поддържа изпълнението на заявките, докато екипът актуализира конфигурацията. Това е практичен избор за непрекъснатост на услугата, особено за приложения, където идентификаторите на модела са разпределени между скриптове, партньорски интеграции, подкани или клиентски настройки.

Компромисът е загуба на явен контрол. Замяната на модела може да промени латентността, стила на изхода, поведението на безопасността, моделите на използване на инструментите или надеждността на крайния случай, дори когато извикването API все още е успешно. Разработчиците може да не забележат промяната, докато оценката не се промени, подканата не се държи по различен начин или клиентът не попита защо отчетената употреба вече не съответства на документацията.

Рискът е по-висок за платформи, които излагат Google модели през мултимоделен API шлюз за екипи. Тези продукти стоят между доставчика и крайния потребител, така че те трябва да решат каква част от маршрутизиращото поведение на доставчика да изплува. Шлюз, който просто препраща стария охлюв и таксува произтичащото обаждане както обикновено, може да запази съвместимостта, но оставя екипите за поддръжка и финанси със слаба одитна пътека.

Какви портали и платформи за дистрибутори трябва да записват

Най-чистият модел е да се съхрани исканият модел, разрешеният модел на доставчика и правилото за псевдоним, което е причинило разрешаването. За промяната на Gemini Flash това означава, че записът за използване трябва да може да показва, че клиентът е поискал gemini-3.7-flash, Google е обслужил gemini-3.8-flash и причината е пренасочването на оттеглянето на Google, а не дефинирано от клиента резервно правило.

Това разграничение засяга поддръжката при таксуване, планирането на миграция и доверието на продукта. Ако клиент попита дали неговото приложение все още използва остарял модел, отговорът не трябва да изисква ръчна археология на журнала. Ако дистрибутор трябва да уведоми акаунти надолу по веригата, той трябва да може да сегментира по заявен наследен охлюв. Ако вътрешен пакет за оценка започне да се проваля, инженерите трябва да могат да сравняват резултатите преди и след промяната на сервирания модел, без да гадаят кога трафикът е преместен.

За продукти в стил Model Gate практическата работа е в анализа на употребата и отчитането на клиентите. таблото за анализ на използването трябва да избягва свиването на заявения и обслужван модел в един етикет. Освен това трябва да направи оттеглените идентификатори достатъчно видими, за да могат собствениците на акаунти да настояват за миграции, преди поддръжката от доставчика да приключи.

Изключването на агента Deep Research добавя втори вид краен срок. За разлика от пренасочването на Flash, Google казва, че deep-research-pro-preview-12-2025 ще се изключи на 23 октомври 2026 г. Екипите, използващи този агент за предварителен преглед, трябва да мигрират, вместо да разчитат на неопределено маршрутизиране за съвместимост. Тъй като работните потоци на Deep Research могат да бъдат вградени в по-продължителни изследвания или конвейери за автоматизация, проверката на миграцията трябва да включва подкани, предположения за инструменти, изходни формати и всякакви съхранени списъци с разрешени модели.

Какво остава несигурно

Бележките по изданието на

Google идентифицират отхвърлените охлюви, замени и поведение при пренасочване, но те не решават всеки оперативен въпрос за платформи надолу по веригата. Бележките не предоставят широко сравнение на поведението между стария и заместващия Flash модел в цитирания запис в регистъра на промените. Те също така не посочват дата на спиране за остарелите Flash модули по същия начин, по който правят за агента за предварителен преглед на Deep Research.

Това оставя екипите с познат проблем с API-управление: съвместимостта може да продължи засега, но стабилното състояние все още е миграция. Разработчиците трябва да актуализират изричните селекции на модела, да изпълнят повторно критичните оценки спрямо заместващите идентификатори и да се уверят, че регистрационните файлове запазват достатъчно подробности, за да обяснят какво се е случило по време на прехода.

По-широкият урок е, че идентификаторите на модела вече не са прости имена на продукти. Те могат да бъдат стабилни издания, подвижни псевдоними, подложки за съвместимост или прихващания за отхвърляне. Шлюзовете, които искат да дадат на клиентите надежден контрол, се нуждаят от модел на данни, който може да представи тези разлики директно.