Si tu app llama a gemini-2.5-pro o gemini-2.5-flash a través de Firebase AI Logic sobre la Gemini Developer API, el 1 de diciembre de 2026 esas peticiones pasan a ejecutarse en modelos Gemini 3.x sin que toques una línea de código. La llamada seguirá funcionando. El modelo que responde por debajo, no: cambia el precio, cambian algunos parámetros y cambia el comportamiento. Esto es lo que hay que mirar antes del día 1.
Qué ha cambiado y desde cuándo
Google lo publicó en las release notes de Firebase el 2 de noviembre. A partir del 1 de diciembre de 2026, en la Gemini Developer API (Google AI), el enrutado automático queda así:
gemini-2.5-pro→gemini-3.8-flashgemini-2.5-flash→gemini-3.5-flash-litegemini-2.5-flash-lite→ sin cambios previstos
En Agent Platform (la antigua ruta Vertex AI) los modelos 2.5 de uso general se retiraron antes, el 20 de octubre. Así que si usas esa vía, esto no es un aviso: ya pasó.
El patrón es el de siempre con los modelos gestionados: no hay apagón que te rompa la build, hay sustitución silenciosa. Tu código pide 2.5 y recibe una respuesta de un 3.x. La recomendación oficial de Google es fijar un modelo nuevo de forma explícita y probarlo antes del 1 de diciembre. Nosotros firmamos esa recomendación, y añadimos el porqué.
Por qué un reemplazo "equivalente" no lo es
El enrutado no es un intercambio uno a uno. Las dos sustituciones cruzan de categoría, y cada una en una dirección distinta.
gemini-2.5-pro era el modelo pesado de la gama 2.5, el que reservabas para razonamiento largo. Su destino, gemini-3.8-flash, es un modelo flash: Google lo vende como rendimiento de frontera a precio de flash, y para muchos casos lo será. Pero es otra familia de latencia y otra forma de responder. Si tenías prompts afinados contra el 2.5-pro, no asumas que caen igual.
gemini-2.5-flash baja un peldaño: su destino es gemini-3.5-flash-lite, el modelo de alto volumen y coste bajo. Para clasificar, enrutar intenciones o resumir barato, suficiente. Para extracción estructurada con casos límite o para clasificación donde el borde importa, un flash-lite no es un flash: ahí es donde se te van a colar las regresiones, y no en el camino feliz de tus pruebas.
La facturación pasa a las tarifas de los modelos nuevos. En el caso de 2.5-pro a 3.8-flash lo normal es que pagues menos, que es justo el argumento de venta. En el de 2.5-flash a 3.5-flash-lite cambia la base de cálculo y conviene rehacer el número con tu volumen real, no con el de la demo.
Dos cambios que pueden romperte llamadas
Más allá de la calidad, hay dos diferencias de comportamiento que te pueden dejar llamadas caídas o facturas infladas el 1 de diciembre sin previo aviso.
La primera: gemini-3.8-flash rechaza frequencyPenalty, presencePenalty y candidateCount. No los ignora, devuelve un 400. Si tu capa de generación pasa cualquiera de esos tres parámetros contra 2.5-pro, hoy funciona y el 1 de diciembre empieza a fallar en seco. Es la parte buena dentro de la mala: una caída así se ve enseguida y se arregla en diez minutos auditando los payloads que construyes.
La segunda: los modelos destino no permiten desactivar el razonamiento con thinkingBudget: 0. Si apoyabas la velocidad y el coste de tus llamadas a 2.5-flash en que el "thinking" estuviera apagado, al enrutar a 3.5-flash-lite el modelo piensa, y pensar son tokens, latencia y a veces una respuesta con otra forma. Revisa las llamadas donde la rapidez y el determinismo mandaban por encima de la calidad del razonamiento.
Qué haríamos nosotros
No dejaríamos el enrutado automático decidiendo en producción. El 1 de diciembre no es un plazo para migrar con prisa; es la fecha a partir de la cual, si no has elegido tú, elige Google por ti. Lo que haríamos, con un cliente, en este orden:
- Fijar el modelo de forma explícita. Deja de pedir
gemini-2.5-proogemini-2.5-flashpor nombre y pasa a nombrar el 3.x que hayas validado. Así controlas tú cuándo cambias de modelo, no el calendario de Google. Es la misma lógica que aplicamos para no perseguir cada release de modelo. - Auditar los payloads. Busca en tu código los tres parámetros que ahora dan 400 y los sitios donde fuerzas
thinkingBudget: 0. Son dos greps. - Pasar tus evals, no probar a ojo. Si tienes un set de evaluación, córrelo contra el modelo destino antes del día 1. Si no lo tienes, esta es una razón más para montarlo: cambiar de modelo a ciegas es fiarte de la demo en vez de los datos.
- Decidir modelo por tarea. 3.8-flash para lo que antes iba a 2.5-pro quizá te sobre o quizá te falte; 3.5-flash-lite para lo que iba a 2.5-flash puede bastar o puede quedarse corto. No hay un reemplazo único correcto para toda la app.
Si llamas a los modelos desde el cliente y no desde un backend propio, este también es el momento de mirar cómo tienes montada la capa: un gateway de LLM delante convierte un cambio como este en una línea de configuración en vez de un despliegue de app.
A quién afecta y a quién no
Te afecta si tu app llama a gemini-2.5-pro o gemini-2.5-flash por nombre a través de Firebase AI Logic sobre la Gemini Developer API, y más aún si pasas los parámetros con penalización o apagas el thinking.
No te afecta, o casi, si ya fijas modelos 3.x, si solo usas gemini-2.5-flash-lite (que de momento se queda), o si tu integración es tan sencilla que un cambio de modelo no mueve tu métrica de calidad. Y si ibas por Agent Platform con los 2.5, el tren salió el 20 de octubre: ahí toca mirar qué se rompió, no qué prevenir.
En Dribba integramos Gemini en apps Flutter y backends en Go, y un plazo así lo tratamos como mantenimiento, no como urgencia: se mira con tiempo y se decide por tarea. Si tienes una app con Firebase AI Logic y no sabes dónde estás expuesto, te ayudamos a hacer el repaso antes del 1 de diciembre.
