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

Согласно примечаниям к выпуску Gemini API Google от 8 октября 2026 г., gemini-3.7-flash устарел и заменен на gemini-3.8-flash. Запросы, отправленные на устаревший фрагмент Flash 3.7, автоматически перенаправляются на Flash 3.8. 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. Это подмена на стороне провайдера.

Для простых приложений разница может быть незаметной, если ответы остаются приемлемыми. Это важно для команд, занимающихся оценками, аналитикой взаимодействия с клиентами, регулируемыми рабочими процессами или распределением затрат. Запись журнала, в которой записана только запрошенная модель, может создать впечатление, будто устаревшая модель все еще обрабатывает трафик. Панель мониторинга, записывающая только обслуживаемую модель, может скрыть тот факт, что клиенты все еще звонят по старой пуле. Оба представления являются неполными.

Здесь псевдонимы моделей ИИ становятся больше, чем просто удобством для разработчиков. Шлюзам необходимо различать как минимум три случая: стабильный псевдоним клиента, созданный платформой, псевдоним поставщика, который намеренно плавает, и маршрут прекращения поддержки поставщика, который автоматически сопоставляет старый общедоступный идентификатор модели с новым. Если рассматривать все три как одно и то же поле, аналитика будет неоднозначной.

Почему автоматическое изменение маршрута полезно, но рискованно

Автоматическое изменение маршрута снижает вероятность немедленных поломок. Если у клиента жестко запрограммирован номер 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 г. Командам, использующим этот агент предварительной версии, необходимо выполнить миграцию, а не полагаться на маршрутизацию с неопределенной совместимостью. Поскольку рабочие процессы глубокого исследования могут быть встроены в длительные исследования или конвейеры автоматизации, проверка миграции должна включать подсказки, предположения об инструментах, выходные форматы и любые разрешенные списки хранимых моделей.

Что остаётся неясным

В примечаниях к выпуску

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

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

Более общий урок заключается в том, что идентификаторы моделей больше не являются простыми названиями продуктов. Это могут быть стабильные выпуски, движущиеся псевдонимы, прокладки совместимости или ловушки устаревания. Шлюзам, которые хотят предоставить клиентам надежный контроль, необходима модель данных, которая может напрямую отражать эти различия.