Gemini 3.5 Flash: qué cambia de verdad para desarrolladores

Si llevas un tiempo usando Gemini en producción, o simplemente probando modelos de Google para evaluar su encaje en un producto, el anuncio de Gemini 3.5 Flash merece más atención de la que suele recibir un lanzamiento de modelo nuevo. No porque sea un salto revolucionario de los que "resuelven todos los problemas de la IA" (aunque el modelo ha mejorado sustancialmente), sino porque cambia algo un poco más sutil y más importante: el enfoque del modelo.

Google lleva meses consolidando la familia Gemini 3, y con 3.5 Flash deja bastante claro su objetivo. La gama Flash ya no es solo la vía rápida para prompts sueltos y tareas sencillas (que también). Esta nueva versión pasa a ser una pieza importante dentro de arquitecturas que necesitan razonamiento ajustable, ejecución multipaso y coherencia en workflows agénticos.

Si estás construyendo algo que va más allá de "mando un texto, recibo un texto", aquí hay bastante donde rascar. Vamos a verlo...

Novedades funcionales y técnicas: qué trae Gemini 3.5 Flash

La forma más directa de presentar este modelo es con los datos sobre la mesa. Google lo posiciona como el Flash con mayor capacidad agéntica y de escritura de código que ha lanzado hasta la fecha, y los benchmarks acompañan esa afirmación en los casos que importan para el trabajo real.

Antes de entrar en comparativas, los datos técnicos base:

• Contexto de entrada: 1.048.576 tókenes. Entrada multimodal (texto, imagen, audio, vídeo y PDF)
• Longitud máxima de la salida: 65.536 tókenes. Solo texto.
• Corte de conocimiento: enero de 2026.
• Capacidades desde la API: llamada a funciones, salidas estructuradas, grounding basado en búsquedas (Con Google Search y Google Maps), ejecución de código, cacheado implícito y explícito, batch API, y contexto basado en URL. Lo que todavía no tiene: Computer Use, generación de imagen, Live API y Content Credentials (C2PA).

Cambios de comportamiento respecto Gemini 3 Flash preview

Si estabas usando la versión preview, hay dos cambios de comportamiento que debes conocer.

El primero es el razonamiento dinámico activado por defecto: ya no tienes que habilitar el modo thinking expresamente. El modelo lo aplica de forma adaptativa según la tarea, con thinking_level como manera de controlar su intensidad (minimal, low, medium, high) y medium como valor por defecto.

El segundo es la preservación automática de thought signatures entre turnos, que permite que el modelo mantenga el hilo de razonamiento a lo largo de un flujo multipaso sin tener que reconstruirlo desde cero en cada llamada. Esto es una característica muy interesante.

Google ha coordinado la optimización de este nuevo modelo para workflows agénticos para tenerlo disponible en su nueva característica Managed Agents en la Gemini API, y con todas las novedades de su asistente de código Antigravity. Gracias a ello, Gemini 3.5 Flash permite lanzar un agente completo con una sola llamada: el agente razona, llama a herramientas y ejecuta código en un entorno Linux aislado con estado persistente entre llamadas. Ese entorno persistente es importante porque cambia la forma de diseñar flujos: ya no tienes que gestionar tú el estado entre pasos, el modelo puede retomarlo automáticamente.

Gemini 3.5 Flash frente a Gemini 3.1 Pro

La propia Google ha elegido su modelo estrella hasta ahora, Gemini 3.1 Pro, para hacer la comparación con el nuevo Flash a la hora de presentar el modelo. Y esto no es por casualidad: querían llamar la atención. Y es que Gemini 3.5 Flash supera a 3.1 Pro en muchos benchmarks, en especial los que modelan trabajo agéntico real. Al mismo tiempo se ejecuta hasta 4 veces más rápido y a menos de la mitad del coste de 3.2 Pro 😱

Los números en programación y uso de herramientas son los más llamativos. Por ejemplo:

• En Terminal-Bench 2.1, que evalúa ejecución de código en terminal con múltiples pasos, 3.5 Flash alcanza un 76.2% frente al 70.3% del Pro.
• En MCP Atlas, que evalúa uso de herramientas en entornos agénticos, la diferencia es de 83.6% frente a 78.2%.
• Y en Finance Agent v2, que simula tareas de análisis financiero con documentos largos y múltiples herramientas, la diferencia es de 14.9 puntos porcentuales: 57.9% frente a 43.0%.
• En GDPval-AA, un índice Elo de valor económico real, la ventaja es de 342 puntos.

Donde 3.1 Pro mantiene todavía la delantera es en los benchmarks de razonamiento abstracto y conocimiento paramétrico puro:

• En Humanity's Last Exam, Gemini 3.5 Flash obtiene un 40.2% frente al 44.4% del Pro.
• En ARC-AGI-2, que evalúa resolución de patrones lógicos nuevos, la diferencia es de 72.1% frente a 77.1%.
• También hay una ventaja importante en las tareas de recuperación de contexto denso a 128k tókenes: 77.3% frente a 84.9% del Pro en el benchmark MRCR v2. Eso sí, en contextos de 1M de tókenes la diferencia prácticamente desaparece, con 26.6% frente a 26.3%.

La tabla de benchmarks completa publicada por Google es la siguiente:

Lo que se desprende de estos datos es que no estamos ante un modelo universalmente superior, sino ante uno que está optimizado para un tipo concreto de trabajo. Aunque mejora a lo bestia respecto a la versión 2.5 tanto de Flash como de Pro.

Si tu caso de uso es un agente que tiene que ejecutar tareas multipaso con herramientas, procesar documentos largos con razonamiento aplicado o iterar sobre código, 3.5 Flash es el candidato más sólido ahora mismo.

Si tu caso de uso se parece más a "resolver un problema difícil en una sola respuesta larga", 3.1 Pro sigue siendo mejor opción, y 3.5 Pro, anunciado para el mes que viene, aún mejorará los resultados en estas tareas.

En cuanto al precio, Gemini 3.5 Flash cuesta $1.50 por millón de tókenes de entrada y $9.00 por 1M de tókenes de salida, frente a los $2.50 y $15.00 del Pro. Una diferencia sustancial para las ventajas que tiene. Los prompts cacheados se queda en tan solo $0.15, lo que supone un descuento del 90% que tiene un impacto muy directo en flujos agénticos con system prompts largos y muchas llamadas encadenadas.

Cuándo usar Gemini 3.5 Flash: casos de uso recomendados

Como siempre, los benchmarks nos sirven un poco para ver la idea general, pero solo la práctica y la prueba y error nos dirán cuál es de verdad el mejor para nuestro caso de uso. De todos modos, sí que hay algunas reglas generales que nos ayudarán a elegir 3.5 Flash frente a otras opciones del catálogo de modelos de Google.

La regla básica es esta: si el trabajo implica múltiples pasos, herramientas, contexto que se acumula o código que itera, 3.5 Flash es el punto de partida más razonable. Si el trabajo es una consulta técnica densa con respuesta en un solo turno, vale la pena evaluar si 3.1 Pro o el futuro 3.5 Pro son más adecuados.

Casos donde 3.5 Flash encaja bien:

• Agentes con uso de herramientas en tareas con varios pasos: cualquier flujo donde el modelo tiene que planificar, llamar a herramientas externas, evaluar el resultado y decidir el siguiente paso encaja a la perfección con este modelo. Ayer mismo, tras su lanzamiento, tuve la oportunidad de probarlo en un caso real relativamente sencillo, pero con estas características y me generó resultados comparables a los que me suele generar Claude Sonnet 4.6.
• Código asistido con contexto largo: revisión y modificación de bases de código extensas, generación de código incremental sobre un contexto que ya contiene archivos, test o decisiones anteriores.
• Procesamiento de documentos grandes con razonamiento aplicado: análisis de contratos, informes financieros, documentación técnica o datasets donde el modelo no solo extrae texto sino que razona sobre él.
• Orquestación de subagentes en paralelo: workflows donde el modelo coordina varios agentes especializados trabajando en paralelo. Google lo ha demostrado con 64 variaciones fractales simultáneas, diseño y construcción de una ciudad virtual, y preparación de formularios fiscales de varias semanas comprimida en tiempo real. Siendo el modelo por defecto para Antigravity es de esperar que se comporte de maravilla en este tipo de tareas.
• Pipelines de alto volumen con caching: cualquier sistema que reutiliza prompts del sistema (sobre todo si son largos) o contexto base entre muchas llamadas es un gran candidato para usar el modelo, sobre todo porque cachea automáticamente los prompts y nos ahorra un montón de dinero. Con el input cacheado a $0.15 por millón de tókenes, el descuento del 90% sobre la entrada estándar cambia bastante la ecuación de coste para aplicaciones con muchas llamadas y prompts de sistema largos.

¿Dónde conviene evaluar otros modelos como alternativa?: pues en tareas que requieren conocimiento muy específico y poco frecuente, razonamiento abstracto puro sin herramientas, o recuperación precisa en ventanas de 128k tókenes con mucha información crítica. Ahí 3.1 Pro sigue siendo la apuesta más fiable mientras no llega 3.5 Pro.

Qué revisar antes de migrar

Si ya tienes una integración con Gemini 2.5 Flash o con Gemini 3 Flash Preview, la migración no debería hacerse sin una revisión mínima. Hay tres zonas donde las diferencias se notan más.

1. El control de razonamiento. Si dependías de thinking_budget o de un comportamiento implícito del modelo respecto a cuánto "pensaba", ahora tienes que trasladar eso a thinking_level. El cambio del default a medium puede mover la aguja en latencia y coste sin que hayas cambiado nada más en tu código. Merece la pena medir antes y después con tus casos de uso reales, no con benchmarks genéricos.
2. Las herramientas y los schemas. Si usas llamada a funciones, salida estructurada (response_schema) o combined tool use, testea tus integraciones existentes contra el nuevo modelo con casos límite. El function calling más estricto suele ser una mejora, pero si tienes esquemas con ambigüedades o prompts de sistema que dependían de cierta permisividad del modelo anterior, pueden aparecer comportamientos inesperados. No muchos, pero los suficientes para que valga la pena el ciclo de pruebas.
3. Los prompts de sistema en flujos agénticos. Los prompts que funcionan bien para un modelo con nivel de razonamiento bajo no siempre escalan igual a medium o high. A mayor nivel de pensamiento, el modelo tiene más espacio para interpretar la instrucción y a veces eso descubre ambigüedades que antes pasaban inadvertidas porque el modelo simplemente no las procesaba. Si tus prompts de sistema son muy cortos o asumen que el modelo no va a razonar mucho sobre ellos, conviene revisarlos.
4. Y por supuesto las pruebas habituales de regresión que deberías hacer cuando cambias cualquier modelo, ya que a veces pequeños cambios hacen que cualquier modelo autoregresivo y no determinista haga "cosas raras".

Conclusiones

Si utilizas modelos de lenguaje de Google, para la mayoría de casos nuevos, Gemini 3.5 Flash es el punto de partida más razonable a día de hoy.

Pero, el ritmo al que los modelos de los grandes jugadores avanzan hoy en día, hace que cualquier elección de modelo o stack que hagas hoy tenga fecha de caducidad. Lo que importa no es tanto qué modelo eliges sino cómo diseñas tu aplicación para que no sea rehén en el futuro de esa decisión.

Aún así, 3.5 Flash es un buen ejemplo de hacia dónde van los tiros ahora mismo en este mundo: modelos más pequeños que superan a los grandes de hace unos pocos meses en los casos que más interesan a los equipos de producto, con APIs más controlables y costes que hacen viables cosas que antes solo eran teóricas.

Si tienes que quedarte con una idea, que sea esta: la ventaja competitiva ya no está en tener acceso al modelo más potente, sino en saber combinarlo bien con herramientas, contexto y arquitectura.

Eso no cambia con cada nuevo lanzamiento. Al contrario, cada nuevo lanzamiento lo confirma.