Google ha dejado obsoletos dos slugs Gemini Flash API y está enrutando automáticamente el tráfico de cada nombre antiguo a un reemplazo más nuevo, creando un cambio de catálogo de modelo de apariencia pequeña con mayores consecuencias para las puertas de enlace, los análisis y los informes de clientes.
Según las notas de la versión Gemini API de Google con fecha del 8 de octubre de 2026, gemini-3.7-flash está obsoleto y reemplazado por gemini-3.8-flash. Las solicitudes enviadas al obsoleto Flash 3.7 se enrutan automáticamente a 3.8 Flash. Google también dejó obsoleto a gemini-3.5-flash, reemplazándolo con gemini-3.6-flash y el mismo comportamiento de redireccionamiento automático.
La empresa también dejó obsoleto deep-research-pro-preview-12-2025 y dice que el agente de Deep Research cerrará el 23 de octubre de 2026, con rutas de migración a agentes de Deep Research más nuevos. Esto brinda a los equipos una breve ventana para identificar el uso de producción, cambiar los ID fijados y verificar el comportamiento de salida antes de que desaparezca el punto final de vista previa anterior.
Qué cambió en el Gemini API
El cambio operativo inmediato es sencillo: una solicitud puede nombrar un modelo mientras Google atiende a otro. Eso no es lo mismo que un desarrollador edite deliberadamente una aplicación del gemini-3.7-flash al gemini-3.8-flash. Es una sustitución del lado del proveedor.
Para aplicaciones simples, la diferencia puede ser invisible si las respuestas siguen siendo aceptables. Para los equipos que ejecutan evaluaciones, análisis de cara al cliente, flujos de trabajo regulados o atribución de costos, es importante. Una entrada de registro que registre solo el modelo solicitado puede hacer que parezca que un modelo obsoleto todavía está manejando tráfico. Un panel que registre solo el modelo servido puede ocultar el hecho de que los clientes siguen llamando a un viejo slug. Ambas vistas están incompletas.
Aquí es donde los alias de modelos de IA se vuelven más que una conveniencia para los desarrolladores. Las puertas de enlace deben distinguir al menos tres casos: un alias de cliente estable creado por la plataforma, un alias de proveedor que flota intencionalmente y una ruta de desaprobación de proveedor que asigna silenciosamente una ID de modelo público antiguo a una nueva. Tratar los tres como el mismo campo crea análisis ambiguos.
Por qué el redireccionamiento automático es útil pero arriesgado
El desvío automático reduce la rotura inmediata. Si un cliente ha codificado gemini-3.7-flash, la ruta de reemplazo de Google puede mantener las solicitudes en ejecución mientras el equipo actualiza la configuración. Se trata de una opción práctica para la continuidad del servicio, especialmente para aplicaciones en las que los ID de modelo se distribuyen entre scripts, integraciones de socios, indicaciones o configuraciones de cliente.
La desventaja es la pérdida de control explícito. Un reemplazo de modelo puede cambiar la latencia, el estilo de salida, el comportamiento de seguridad, los patrones de uso de herramientas o la confiabilidad de los casos extremos incluso cuando la llamada API todavía tiene éxito. Es posible que los desarrolladores no noten el cambio hasta que una evaluación cambie, un mensaje se comporte de manera diferente o un cliente pregunte por qué el uso informado ya no coincide con la documentación.
El riesgo es mayor para las plataformas que exponen Google modelos a través de una puerta de enlace multimodelo API para equipos. Esos productos se encuentran entre el proveedor y el usuario final, por lo que tienen que decidir qué parte del comportamiento de enrutamiento del proveedor sale a la luz. Una puerta de enlace que simplemente reenvía el antiguo slug y factura la llamada resultante como de costumbre puede preservar la compatibilidad, pero deja a los equipos de soporte y finanzas con un registro de auditoría débil.
Qué pasarelas y plataformas de revendedores deben registrar
El patrón más limpio es almacenar el modelo solicitado, el modelo de proveedor resuelto y la regla de alias que provocó la resolución. Para el cambio de Flash Gemini, eso significa que un registro de uso debe poder mostrar que el cliente solicitó gemini-3.7-flash, Google sirvió gemini-3.8-flash y el motivo fue la redirección de obsolescencia de Google en lugar de una regla alternativa definida por el cliente.
Esa distinción afecta el soporte de facturación, la planificación de la migración y la confianza en el producto. Si un cliente pregunta si su aplicación todavía utiliza un modelo obsoleto, la respuesta no debería requerir una arqueología de registros manual. Si un revendedor necesita notificar a las cuentas posteriores, debería poder segmentar según el slug heredado solicitado. Si un conjunto de evaluaciones internas comienza a fallar, los ingenieros deberían poder comparar los resultados antes y después del cambio del modelo servido sin adivinar cuándo se movió el tráfico.
Para los productos del estilo Model Gate, el trabajo práctico consiste en análisis de uso e informes de clientes. Un panel de análisis de uso debe evitar colapsar el modelo solicitado y servido en una sola etiqueta. También debería hacer que los ID obsoletos sean lo suficientemente visibles para que los propietarios de cuentas puedan impulsar las migraciones antes de que finalice el soporte del proveedor.
El cierre del agente de Deep Research añade un segundo tipo de fecha límite. A diferencia de un redireccionamiento de Flash, Google dice que deep-research-pro-preview-12-2025 se cerrará el 23 de octubre de 2026. Los equipos que utilizan ese agente de vista previa deben migrar en lugar de depender de un enrutamiento de compatibilidad indefinido. Debido a que los flujos de trabajo de Deep Research pueden estar integrados en procesos de investigación o automatización de mayor duración, la verificación de la migración debe incluir indicaciones, suposiciones de herramientas, formatos de salida y cualquier lista de modelos permitidos almacenados.
Lo que sigue siendo incierto
Las notas de la versión deGoogle identifican los slugs, los reemplazos y el comportamiento de redireccionamiento obsoletos, pero no resuelven todas las cuestiones operativas para las plataformas posteriores. Las notas no proporcionan una comparación amplia de comportamiento entre los modelos Flash antiguos y de reemplazo en la entrada del registro de cambios citada. Tampoco indican una fecha de cierre para los slugs Flash obsoletos de la misma manera que lo hacen para el agente de vista previa de Deep Research.
Esto deja a los equipos con un API problema familiar de administración: la compatibilidad puede continuar por ahora, pero el estado estable sigue siendo la migración. Los desarrolladores deben actualizar las selecciones de modelos explícitas, volver a ejecutar evaluaciones críticas con los ID de reemplazo y asegurarse de que los registros conserven suficientes detalles para explicar lo que sucedió durante la transición.
La lección más amplia es que los ID de modelo ya no son simples nombres de productos. Pueden ser versiones estables, alias móviles, correcciones de compatibilidad o trampas de desaprobación. Las puertas de enlace que quieran ofrecer a los clientes un control fiable necesitan un modelo de datos que pueda representar esas diferencias directamente.