Obsolescencia de Gemini 2.5: lista de verificación antes de la redirección automática del 1 de diciembre

La obsolescencia de Gemini 2.5 entra en vigor el 1 de diciembre de 2026. En esa fecha, las llamadas a gemini-2.5-pro y gemini-2.5-flash empiezan a redirigirse automáticamente a otros modelos. La mayoría de las solicitudes seguirán funcionando, y esa es precisamente la razón para revisarlas ahora.

Esta guía explica lo que Google anunció, el impacto en la factura, los parámetros que hay que reescribir y cómo decidir, por carga de trabajo, si aceptar la redirección o fijar un modelo de forma deliberada. Si usas Gemini en Vertex AI, lee primero esa sección. Su fecha de retirada ya pasó.

Qué anunció Google y qué cambia realmente el 1 de diciembre

Las notas de la versión de la API de Gemini, publicadas el 2 de noviembre de 2026, indican que las llamadas a gemini-2.5-pro se redirigirán automáticamente a gemini-3.8-flash y que las llamadas a gemini-2.5-flash se redirigirán a gemini-3.5-flash-lite. Las notas fijan el 1 de diciembre de 2026 como la fecha en que comienza la redirección. A partir de ese día, cualquier solicitud a la API que siga nombrando alguno de esos modelos será respondida por un modelo distinto y más reciente, y se cobrará a los precios de ese modelo.

El alcance es más reducido de lo que sugiere el titular. La página de obsolescencias de Gemini indica que gemini-2.5-flash-lite no está obsoleto y sigue disponible hasta nuevo aviso. Solo se ven afectados dos ID de modelo.

El problema práctico es que, por lo general, nada devuelve un error. Que otro modelo responda en silencio puede pasar inadvertido.

Por qué una redirección silenciosa es más arriesgada que un error

Desde el punto de vista de Google, redirigir es una opción predeterminada sensata, porque los equipos que no vean el aviso siguen en línea. También significa que la calidad de la salida, la latencia, el uso de tokens y el costo pueden cambiar aunque nadie del lado del cliente haya tocado el código.

Los mantenedores de la biblioteca de código abierto llm-exe plantearon esto en una incidencia de GitHub: las llamadas siguen funcionando, pero los usuarios de gemini-2.5-pro reciben un modelo de nivel Flash sin ninguna advertencia. Lo describen como una verdadera reducción de capacidades y dicen que es "peor que un 404 porque nadie lo notará".

Google ha dejado algunas preguntas abiertas. Su aviso no explica por qué 2.5 Pro se asigna a un modelo Flash en lugar de a un nivel superior, ni aclara si los clientes pueden excluirse de la redirección automática.

Sugerimos tratar la transición como un cambio de modelo que tu equipo no eligió y revisarla como una actualización planificada, con una pasada de evaluación, una comprobación de costos y la aprobación de un responsable.

El panorama de costos: más barato en diciembre, distinto desde enero de 2027

La publicación de lanzamiento de Gemini 3.8 Flash de Google indica un precio introductorio de $0.75 por 1M de tokens de entrada y $3.75 por 1M de tokens de salida hasta el 31 de diciembre de 2026. Gemini 2.5 Pro cuesta $1.25 y $10.00 en prompts de hasta 200,000 tokens. Desde el 1 de enero de 2027, las tarifas de 3.8 Flash se duplican a $1.50 y $7.50. Con esas tarifas, la entrada cuesta más que en 2.5 Pro, aunque la salida sigue siendo más barata.

Dos cargas de trabajo ilustrativas

Un análisis de terceros de Data Studios desarrolla dos cargas de trabajo de ejemplo. No son benchmarks ni mediciones de Optijara.

En el ejemplo del asistente de soporte, la factura mensual baja de $9,300 a $4,500 en diciembre y luego vuelve a subir a $9,000 desde enero de 2027. Los volúmenes de tokens detrás de esos totales están en el análisis de Data Studios, así que revísalos allí antes de compararlos con tu propio tráfico.

La fila de documentos largos enumera sus supuestos, de modo que puedes recalcularla a partir de la tabla de precios. Resulta en $810 en 2.5 Pro porque cada prompt cae en la franja más cara de contexto largo. En 3.8 Flash cuesta $240 en diciembre y $480 desde enero, porque 3.8 Flash no tiene recargo por contexto largo.

El conteo de tokens importa más que el precio por token

La publicación de lanzamiento de Google indica que 3.8 Flash podría usar más tokens para maximizar el rendimiento, especialmente en niveles de esfuerzo más altos. Un volumen mayor puede absorber parte o la totalidad de un precio por token más bajo. Mide los conteos reales de tokens en tu propio tráfico antes de fiarte de cualquier hoja de cálculo, incluidos los ejemplos anteriores.

Cambios de parámetros que rompen o alteran el comportamiento en silencio

thinking_budget pasa a ser thinking_level

Los modelos Gemini 3.x usan thinking_level en lugar de thinking_budget. Gemini 3.8 Flash acepta los niveles low, medium y high, y la documentación del modelo 3.8 Flash de Google indica que minimal devuelve un error. Confirma la redacción actual en el registro de cambios de la API de Gemini y en la página del modelo.

Este es uno de los pocos puntos en los que una solicitud redirigida puede fallar directamente, así que revisa cualquier código, configuración o wrapper que establezca o asigne minimal. También sugerimos probar cómo se comporta un valor residual de thinking_budget en una solicitud redirigida.

Los parámetros de muestreo van de salida

La guía de migración de Google indica a los desarrolladores que eliminen temperature, top_p y top_k. Estos parámetros están obsoletos, hoy se ignoran y devolverán HTTP 400 en generaciones futuras. Elimina también candidate_count, ya que Gemini 3 y posteriores no lo admiten. Consulta el registro de cambios de la API de Gemini y la página de obsolescencias antes de tocar el código.

Esto no afecta solo a la redirección. La documentación de la API de Gemini de Google confirma que estos parámetros de muestreo se ignoran en Gemini 3.6 Flash, Gemini 3.5 Flash-Lite y Gemini 3.5 Flash Cyber. Si llamas a esos modelos, es posible que algunos de tus ajustes ya no estén haciendo nada. Un flujo de trabajo que dependía de una temperatura baja para obtener resultados consistentes ha perdido ese control, así que prueba la consistencia directamente.

La ruta de 2.5 Flash a 3.5 Flash-Lite

Sugerimos separar lo que está documentado en esta ruta de lo que tu equipo aún necesita probar o consultar.

• Conocido: límites de salida. Gemini 3.5 Flash-Lite, el reemplazo de 2.5 Flash, tiene una ventana de contexto de 1M de tokens y admite hasta 64,000 tokens de salida. Comprueba que tus ajustes de salida máxima y tu lógica de fragmentación encajen.
• Conocido: parámetros de muestreo. Ya se ignoran en 3.5 Flash-Lite, como se indicó arriba.
• Por probar: niveles de razonamiento. Sugerimos probar cada valor de thinking_level que pienses enviar, incluido minimal.
• Por consultar: costo. Sugerimos calcular el precio de esta ruta a partir de las tarifas vigentes publicadas por Google.

Llamadas a herramientas y funciones

Las llamadas a herramientas necesitan su propia pasada de pruebas. Sugerimos volver a probar de extremo a extremo cada flujo de llamadas a herramientas contra el modelo de destino, cubriendo la selección de herramientas, el formato de los argumentos, el estado entre turnos y el manejo de errores. Algunos equipos pueden considerar más seguro tratar el comportamiento anterior como no verificado hasta que esas pruebas se superen.

Guía práctica: lista de siete pasos para migrar desde Gemini 2.5

Sugerimos asignar a cada paso un responsable y una fecha objetivo antes de la transición.

• [ ] Paso 1, inventario. Busca gemini-2.5-pro y gemini-2.5-flash en código, configuración, variables de entorno, plantillas de infraestructura y wrappers de SDK, incluidos los valores predeterminados dentro de bibliotecas de terceros y frameworks de agentes. Excluye gemini-2.5-flash-lite.
• [ ] Paso 2, clasificación. Etiqueta cada llamada según su riesgo de negocio (de cara al cliente, con mucho razonamiento, con llamadas a herramientas, por lotes, de contexto largo) y asigna un responsable.
• [ ] Paso 3, reescritura de parámetros. Reemplaza thinking_budget por thinking_level (low, medium o high; sin minimal en 3.8 Flash). Prueba cada nivel en 3.5 Flash-Lite. Elimina temperature, top_p, top_k y candidate_count.
• [ ] Paso 4, nuevas pruebas. Ejecuta un conjunto de evaluación fijo y tus flujos de llamadas a herramientas contra el modelo de destino, comparando calidad, latencia y uso de tokens con una línea base del modelo actual.
• [ ] Paso 5, modelo de costos. Calcula el precio del uso de tokens medido por cada ruta.
• [ ] Cargas de trabajo de 2.5 Pro: con las tarifas de 3.8 Flash de diciembre de 2026 y luego con las de enero de 2027.
• [ ] Antiguas cargas de trabajo de Flash: sugerimos calcular su precio a partir de las tarifas vigentes publicadas por Google para el modelo de destino.
• [ ] Paso 6, decisión. Fija cada carga de trabajo a un ID de modelo explícito, o deja por escrito que aceptas el destino de la redirección.
• [ ] Paso 7, monitoreo después del 1 de diciembre. Registra el ID de modelo solicitado y cualquier metadato de modelo o versión que devuelva la respuesta, y configura una alerta cuando difieran. El ID solicitado por sí solo no revelará una redirección. Haz seguimiento de los tokens y el gasto, y vigila el almacenamiento en caché, ya que Google no ha documentado cómo se comportan las respuestas o las cachés con la redirección.

Para el paso 7, las trazas por solicitud que registran el modelo solicitado, el modelo informado, los conteos de tokens y la latencia hacen visible la deriva rápidamente. Nuestra guía práctica de trazado GenAI con OpenTelemetry puede ser un punto de partida útil para este tipo de trazado.

Fijar a propósito o aceptar la redirección: la revisión de tres diales

Llamamos a nuestro marco para esta decisión la revisión de tres diales. Puntúa cada carga de trabajo como baja, media o alta en cada dial.

• Riesgo. ¿Quién ve la salida y qué ocurre cuando es incorrecta? Las respuestas de cara al cliente, el contenido regulado y las llamadas a herramientas que modifican datos puntúan alto.
• Dependencia del razonamiento. ¿Elegiste 2.5 Pro por su razonamiento de varios pasos, o simplemente se convirtió en el valor predeterminado?
• Sensibilidad al costo. ¿Qué parte de tu gasto en Gemini genera esta carga de trabajo y a qué velocidad crece?

Si el riesgo o la dependencia del razonamiento son altos, sugerimos probar primero y fijar explícitamente el modelo que supere las pruebas. Si ambos son bajos y la sensibilidad al costo es alta, aceptar el destino de la redirección es razonable, pero fíjalo explícitamente de todos modos. Las puntuaciones mixtas pasan a evaluación, con los precios de enero como criterio de desempate. Las cargas de trabajo de contexto largo merecen una mirada atenta, ya que el ejemplo ilustrativo anterior sigue mostrando ahorros después del cambio de enero.

La publicación de lanzamiento de Google también indica que, cuando la eficiencia de cómputo es la principal limitación, los desarrolladores pueden usar niveles de esfuerzo más bajos o seguir usando Gemini 3.7 Flash, que sigue plenamente admitido para cargas de trabajo que priorizan la eficiencia. Si la eficiencia es tu principal limitación, sugerimos incluir ese modelo en tu evaluación como opción de fijación.

Google informa una puntuación de 54.9% para 3.8 Flash en HLE-Verified. Es un contexto informado por el proveedor, no una prueba de que el modelo se adapte a tu tarea. Sugerimos dejar que decida tu propio conjunto de evaluación, y nuestro artículo sobre por qué las puntuaciones de benchmarks necesitan protocolos ofrece más lectura sobre cómo ponderar las cifras destacadas.

Sugerimos fijar de forma explícita incluso cuando elijas el modelo que la redirección habría seleccionado. Fijar un modelo puede convertir un valor predeterminado del proveedor en una decisión documentada que tu equipo puede revisar a medida que cambien los precios. Si el tráfico pasa por un gateway, considera imponer la fijación explícita de modelos en la capa del gateway para que un valor predeterminado perdido en un servicio no pueda saltársela.

Vertex AI: la fecha de retirada ya pasó

La tabla del ciclo de vida de Vertex indica el 20 de octubre de 2026 como fecha de retirada tanto de gemini-2.5-pro como de gemini-2.5-flash. Esa fecha ya quedó atrás. Las llamadas de Vertex AI que siguen nombrando alguno de esos modelos pueden estar fallando ya o siendo atendidas por otro modelo, así que revisa esta semana los registros y las tasas de error de esos ID antes de pasar a la API para desarrolladores.

Vertex AI documenta los ciclos de vida de los modelos por separado de la API para desarrolladores de Gemini. Google indica que, cuando programa la retirada de un modelo allí, publica una fecha fija que te da al menos 45 días para migrar. Los reemplazos sugeridos también difieren: gemini-3.8-flash o gemini-3.5-flash para Pro, y gemini-3.8-flash o gemini-3.5-flash-lite para Flash. El aviso de redirección de Google no dice cómo se aplica a Vertex AI el cambio del 1 de diciembre. Si usas ambas superficies, revisa cada una según sus propias condiciones.

Errores comunes de los equipos en esta migración

• Capturar la línea base demasiado tarde. Después del 1 de diciembre, una llamada a la API de Gemini a gemini-2.5-pro ya no llega a 2.5 Pro.
• Pasar por alto valores predeterminados en CI y fixtures de prueba. Sugerimos revisar fixtures, mocks, pruebas de humo y configuraciones de staging en busca de ID de modelo codificados de forma fija.
• Dejar cachés y evaluaciones indexadas por ID antiguos. Todo lo que se indexa por la cadena del modelo puede mezclar resultados antiguos y redirigidos bajo una misma etiqueta. Vuelve a indexarlo o marca la fecha de la transición.
• Ajustar alertas de presupuesto durante diciembre. Los umbrales definidos con el gasto de diciembre subestimarán enero, cuando las tarifas de 3.8 Flash se duplican.
• Migrar las llamadas equivocadas o pasar por alto las ocultas. gemini-2.5-flash-lite no está obsoleto, y los ID afectados pueden esconderse dentro de wrappers de terceros que la búsqueda en tu repositorio no encontrará.

Advertencias y preguntas abiertas

Google no ha dicho si las respuestas mostrarán que una solicitud redirigida fue atendida por el modelo de reemplazo. Tampoco ha dicho qué ocurre con las cachés de contexto explícitas creadas en modelos Gemini 2.5, y no hay ninguna opción de exclusión declarada.

Los escenarios de costos de este artículo proceden de un análisis de terceros que usa cargas de trabajo ilustrativas. Tu combinación de tráfico, la longitud de tus prompts y tus ajustes de esfuerzo producirán cifras diferentes. Las cifras de benchmarks son informadas por el proveedor. Los precios y la documentación pueden cambiar, así que sugerimos volver a consultar el registro de cambios oficial y las páginas de obsolescencias antes de actuar.

Si te vendría bien una segunda opinión, Optijara puede realizar una auditoría de migración de tus llamadas a Gemini o ayudarte a construir la línea base de evaluación con la que harás las comparaciones.