El 21 de julio Google presentó Gemini 3.6 Flash junto a 3.5 Flash-Lite y 3.5 Flash Cyber. El titular no es "otro modelo más": es que el coste por tarea agéntica baja de forma notable. Si tienes features de IA en producción —o a punto de entrar—, esto toca directamente tu factura y tu decisión de qué modelo enrutar a cada caso. Nuestra lectura, sin hype, y para quién sí y para quién no.

Qué ha pasado

El 21 de julio de 2026, Google anunció tres modelos nuevos en el tier Flash. El relevante para la mayoría es Gemini 3.6 Flash, que Google posiciona como "modelo de trabajo" (mejor código, tareas de conocimiento y multimodal) con un precio de 1,50 $/1M tokens de entrada y 7,50 $/1M de salida, frente a los 9,00 $ de salida del anterior 3.5 Flash.

La parte interesante no es solo el precio de lista. Según el Artificial Analysis Index, 3.6 Flash consume un 17 % menos de tokens de salida que 3.5 Flash para el mismo trabajo, y en algún benchmark de código (DeepSWE) el ahorro llega al 65 %. Como en las cargas agénticas pagas por cada paso de razonamiento y cada llamada a herramienta, menos tokens por tarea multiplica el efecto del precio más bajo. Mantiene ventana de 1M de contexto, 64k de salida, entrada multimodal nativa, controles de "thinking" y Computer Use integrado.

Google acompañó el lanzamiento con 3.5 Flash-Lite (0,30 $/2,50 $ por 1M, para alto volumen y latencia mínima) y 3.5 Flash Cyber, afinado para encontrar y corregir vulnerabilidades a menor coste por token que los modelos grandes. Fuente primaria: el blog oficial de Google.

Qué implica para tu producto

Traducido a decisiones de producto y presupuesto:

  • Si operas agentes o RAG en producción, tu coste unitario baja sin tocar código. Un flujo agéntico que hoy resuelve una tarea en, pongamos, 12k tokens de salida repartidos en varios pasos se abarata por dos vías a la vez: precio por token más bajo y menos tokens para llegar al mismo resultado. En volumen, ahí es donde está el dinero, no en la demo.
  • El coste deja de ser la excusa para no meter IA. Muchas features que "no salían" a precio de modelo grande empiezan a cuadrar en un tier Flash barato. Casos de clasificación, extracción, resúmenes o enrutado de soporte son los primeros candidatos.
  • Más presión para tener una estrategia de model routing. Un solo modelo para todo es cómodo y caro. Lo sensato es una política por caso de uso: Flash-Lite para alto volumen y baja complejidad, Flash 3.6 como caballo de batalla, y reservar el modelo grande (o el razonamiento profundo) solo para lo que de verdad lo necesita.

Dónde NO nos precipitaríamos

Aquí es donde tu equipo se ahorra sustos:

  • No migres tu tráfico de golpe. Un modelo más barato con menos pasos de razonamiento cambia el comportamiento en los casos límite. Antes de mover producción, pasa tus evals y tu dataset real; el ahorro no vale nada si sube la tasa de error en el 5 % de casos que importan.
  • No uses Flash para lo que pide profundidad. Razonamiento multi-hop complejo, decisiones con riesgo legal o financiero, o generación donde el matiz cuesta dinero: ahí el tier grande sigue ganando. El Flash es un caballo de batalla, no un sustituto universal.
  • No confundas benchmark con tu caso. Un 65 % de ahorro en DeepSWE no es tu 65 %. Mide en tu carga real antes de prometer números a negocio.
  • Cuidado con acoplarte a un solo proveedor. Si abstraes el acceso al modelo detrás de un gateway, cambiar de modelo (o de vendor) es una variable de configuración, no un proyecto. Es la diferencia entre aprovechar cada bajada de precio y quedarte atado.

Nuestra recomendación

Para la mayoría de equipos con IA en producción, 3.6 Flash es una actualización que sí merece la pena evaluar esta semana: mismo API, menos coste, menos tokens. Pero "evaluar" no es "migrar a ciegas". El orden que seguimos con un cliente sería: (1) identificar qué llamadas son de alto volumen y baja complejidad, (2) probar Flash-Lite o 3.6 Flash contra esas rutas con evals reales, (3) mantener el modelo grande donde el coste del error supera el ahorro, y (4) dejarlo todo detrás de una capa de enrutado para que la próxima bajada de precio sea un cambio de config, no una refactorización.

Si estás decidiendo dónde encaja cada modelo en tu arquitectura de IA —o si el coste de tus agentes se te está yendo de las manos—, es exactamente el tipo de decisión que ayudamos a tomar en integración de IA. Y si aún estás montando las piezas, tenemos escrito cuándo tiene sentido (y cuándo no) usar MCP en producción y cómo encaja RAG en todo esto.