Gemini 3.7 Flash llegó el 13 de agosto de 2026, apenas tres semanas después de 3.6 Flash, con una promesa concreta: mejorar la programación y los flujos agénticos complejos sin cambiar la familia de herramientas ni ampliar la ventana de contexto. Por eso, el cambio relevante no es “más funciones de API”, sino una mejor calidad de ejecución en tareas como depuración, resolución de issues, generación de aplicaciones web y automatizaciones de varios pasos. También hay un matiz importante de precio: la tarifa introductoria anunciada para 3.7 se aplicó también a 3.6 Flash, de modo que durante la promoción ambos modelos tienen el mismo precio por token en las superficies de Google documentadas actualmente.
Gemini 3.7 Flash vs. 3.6 Flash: qué cambió realmente
3.6 Flash se lanzó el 21 de julio de 2026 como un modelo de trabajo para agentes, con énfasis en eficiencia de tokens, programación, trabajo de conocimiento y tareas multimodales. 3.7 Flash conserva esa base, pero Google lo posiciona como su Flash más capaz para programación y agentes, con mejoras en ingeniería de software, desarrollo web y ejecución de workflows.
| Área | Gemini 3.6 Flash | Gemini 3.7 Flash | Lectura práctica |
|---|---|---|---|
| Programación y resolución de issues | Ya había mejorado la precisión y reducido loops frente a 3.5 Flash. | Google reporta 65,3% frente a 49,0% de 3.6 en DeepSWE v1.1, y 43,6% frente a 34,4% en FrontierCode 1.1 Main. | La mejora importa más cuando una respuesta incorrecta dispara otro ciclo de edición, prueba o herramienta. |
| Web e interfaz | Buen rendimiento general en programación y tareas multimodales. | Google reporta layouts más funcionales, apps más completas con menos prompts y Elo 1588 frente a 1538 en WebDev Arena. | Es un candidato más fuerte para generación desde mocks, revisión visual y tareas donde la fidelidad de diseño reduce retrabajo. |
| Documentos densos | También orientado a knowledge work y análisis multimodal. | En GDP.pdf, Google reporta 34,0% frente a 22,0%. | Puede ayudar a agentes que necesitan extraer, razonar y actuar sobre PDFs complejos, pero conviene validarlo con el tipo de documento real. |
| Automatización de workflows | Diseñado para ejecución agéntica y uso de herramientas. | En AutomationBench, 30,4% frente a 17,0%, además de una ejecución más disciplinada en planificación, instrucciones y tool calls según Google. | El beneficio esperado es menos supervisión, menos intentos y una mayor tasa de finalización de tareas con varios pasos. |
| Contexto y herramientas | 1.048.576 tokens de entrada, 65.536 de salida y herramientas como function calling, code execution, computer use, search grounding y URL context. | 1M de contexto, 64k de salida y la misma suite de herramientas integradas que 3.6. | No conviene elegir 3.7 esperando una herramienta nueva exclusiva. |
Estas cifras son benchmarks y mediciones publicadas por Google. Indican la dirección de la mejora, pero no garantizan la misma diferencia en un repositorio, agente, conjunto de herramientas o colección de prompts específicos.
Qué significa “mejor para programación” en la práctica
La mejora de 3.7 Flash es más relevante cuando el modelo debe mantener contexto técnico, modificar código existente y cerrar el ciclo de ejecución, no solo generar un snippet aislado. Google destaca depuración, resolución de issues, mayor precisión en el primer intento y código más cercano a producción.
- Bugs con reproducción y pruebas: pide al modelo que encuentre la causa, proponga el parche y ejecute o interprete la suite de tests. La métrica útil es cuántos casos llegan a una solución válida sin intervención humana.
- Refactors y migraciones: compara cambios innecesarios de archivos, regresiones y loops de corrección. 3.6 ya se lanzó con foco en reducir ediciones no deseadas; 3.7 intenta avanzar en ese punto.
- Aplicaciones web desde una referencia visual: 3.7 fue ajustado explícitamente para adherencia a mocks, screenshots y design systems. Evalúa funcionalidad y paridad visual, no solo si el código compila.
- Repositorios con varias herramientas: cuando el flujo incluye búsqueda, ejecución de código, lectura de archivos y funciones externas, una pequeña mejora por etapa puede cambiar mucho la tasa final de éxito.
Para agentes, el principal cambio es la ejecución — no una nueva lista de herramientas
La documentación de 3.7 Flash indica que utiliza la misma suite de herramientas integradas que 3.6. La diferencia declarada está en el comportamiento: adaptarse mejor a bloqueos, aclarar la intención cuando hace falta, seguir instrucciones con más fidelidad e invertir más esfuerzo en planificación de varios pasos y llamadas de herramientas. Esto importa porque el costo de un agente no es solo el precio de una respuesta; es la suma de tokens, tool calls, latencia, retries y posible intervención humana.
También existe una diferencia de configuración de razonamiento que conviene observar. 3.7 Flash admite los niveles low, medium y high, con medium por defecto. La documentación actual enumera 3.6 Flash con minimal, low, medium y high. Para un A/B justo, empieza con un nivel común como medium y luego prueba por separado los extremos de latencia o calidad.
Precio introductorio: mitad del precio original no significa mitad de 3.6 hoy
Cuando 3.6 Flash fue anunciado el 21 de julio, Google indicó un precio de US$ 1,50 por 1 millón de tokens de entrada y US$ 7,50 por 1 millón de tokens de salida. El 13 de agosto, 3.7 Flash se lanzó a US$ 0,75/1M de entrada y US$ 3,75/1M de salida, descrito como la mitad del costo original de 3.6.
Sin embargo, la documentación de migración actual añade un detalle decisivo: la nueva tarifa promocional también se aplicó a 3.6 Flash. Hasta el 31 de diciembre de 2026, 3.7 y 3.6 figuran con la misma tarifa introductoria en las superficies documentadas. Desde el 1 de enero de 2027, la tarifa estándar indicada es de US$ 1,50/1M de entrada y US$ 7,50/1M de salida.
En otras palabras, “la mitad del precio de 3.6” compara 3.7 con el precio original de lanzamiento de 3.6, no con una diferencia de precio actual entre ambos. Durante la promoción, el precio por token no desempata. La métrica relevante es el costo por tarea completada.
Una cuenta simple es: costo de tokens = (tokens de entrada ÷ 1.000.000 × tarifa de entrada) + (tokens de salida ÷ 1.000.000 × tarifa de salida). En agentes, añade costos de herramientas, infraestructura y repeticiones. Si 3.7 usa más razonamiento en un intento pero evita retries y tool calls adicionales, puede ser más barato por tarea; si el workload es simple y 3.6 ya acierta en el primer intento, la ventaja puede desaparecer.
Qué workloads tienen más probabilidades de beneficiarse de 3.7 Flash
- Ingeniería de software con feedback de ejecución: bugs, issues, tests, migraciones y refactors donde el resultado pueda verificarse objetivamente.
- Agentes de varios pasos: tareas con planificación, llamadas de funciones, investigación, lectura de documentos y recuperación ante errores intermedios.
- Desarrollo web guiado por diseño: generación de UI desde screenshot, mock o design system y auditoría de paridad entre implementación y referencia.
- Flujos con documentos complejos: informes, PDFs, tablas y contenido multimodal que termina en una acción o decisión estructurada.
- Procesos donde los retries son caros: cuando cada fallo dispara nuevas ejecuciones, herramientas o revisión humana, una mayor precisión inicial puede valer más que pequeñas diferencias de latencia.
Cuándo todavía tiene sentido mantener 3.6 Flash
3.6 Flash sigue en GA y no tiene una fecha de apagado anunciada. Si tu sistema ya cumple objetivos de calidad, latencia y costo, no hay una razón económica automática para migrar solo por la promoción, porque la tarifa introductoria quedó igualada. Mantener 3.6 puede ser racional mientras evalúas 3.7, especialmente en flujos simples, de alto volumen o muy optimizados.
Otro punto es el nivel minimal documentado para 3.6 y ausente en la lista actual de 3.7. Para workloads extremadamente sensibles a latencia y con poca exigencia de razonamiento, esto merece una prueba aparte en lugar de asumir que el modelo más nuevo será siempre la mejor opción.
Un conjunto de pruebas para elegir entre 3.7 y 3.6
No decidas por un único benchmark público. Usa tareas reales y ejecuta un A/B controlado.
- Congela el entorno: mismo commit, archivos, herramientas, permisos y prompt base.
- Usa un nivel de razonamiento comparable: empieza por medium, disponible en ambos.
- Separa categorías: bug fixing, refactor, generación de features, UI desde mock, workflow con herramientas y análisis de documentos.
- Repite las tareas: los modelos generativos varían entre ejecuciones; un solo intento puede ocultar regresiones o mejoras.
- Mide el éxito de extremo a extremo: test aprobado, issue resuelto, interfaz funcional, workflow completado o documento procesado correctamente.
- Registra eficiencia: tokens de entrada y salida, latencia total, tool calls, retries, errores de función e intervenciones humanas.
- Calcula costo por éxito: divide el costo total de las ejecuciones por la cantidad de tareas completadas dentro de tu criterio de calidad.
Si 3.7 aumenta la tasa de éxito y reduce loops lo suficiente para compensar cualquier consumo adicional de razonamiento, la migración tiene sentido. Si 3.6 ya resuelve el workload con poca variación, mantenerlo puede ser la opción más eficiente.
