Coste de Gemini 3.7 Flash: tareas entre 2.5 y 8x más baratas

Gemini 3.7 Flash factura las mismas tareas entre 2.5x y 8x más baratas que Gemini 3.6 Flash, y solo la mitad de la diferencia procede de la rebaja anunciada. La tarifa de lanzamiento, $0.75 por millón de tokens de entrada y $3.75 por millón de tokens de salida, es un 50% inferior a la de 3.6. En nuestras mediciones, el mismo prompt de 6.9K tokens costó exactamente la mitad ($0.00529 frente a $0.01057). La otra mitad pasa más desapercibida: gemini-3.7-flash consumió entre un 26% y un 77% menos de tokens de thinking que 3.6 en las mismas cuatro tareas. Probamos el modelo dos días después de su lanzamiento: las tarifas, el control de thinking —una posición ha desaparecido—, las incompatibilidades que avisa la documentación de Google y las que minimiza, además de la continuidad de la caché, el contexto y el tokenizer.

TL;DR

• La tarifa de lanzamiento de $0.75/$3.75 estará vigente hasta el 31 de diciembre de 2026; después subirá a $1.50/$7.50. El mismo prompt costó exactamente la mitad que en 3.6 según nuestras mediciones.
• El thinking predeterminado bajó entre un 26% y un 77% frente a 3.6 (144 frente a 384 tokens en una tarea de 5 pasos), por lo que el coste por tarea cae entre 2.5x y 8x, no solo 2x.
• Ya no se puede desactivar: todas las variantes para apagarlo devuelven un 400 (“Thinking level is unsupported”); low es ahora el mínimo.
• En un bucle de herramientas de dos turnos, 3.7 redujo a la mitad la deliberación del turno que procesa el resultado de la herramienta (32 frente a 61 tokens); rechazar una pregunta sin respuesta costó unos 500 tokens en ambos modelos.

¿Cuánto cuesta realmente Gemini 3.7 Flash?

La mitad que 3.6 hasta el 31 de diciembre de 2026 y, en todas las tareas medidas, menos de la mitad de sus tokens. Google ha fijado el precio de lanzamiento en $0.75 por millón de tokens de entrada y $3.75 por millón de tokens de salida. A partir del 1 de enero de 2027 volverá a $1.50/$7.50, exactamente la misma tarifa que 3.6. Las lecturas de caché cuestan $0.075 por millón, un 10% de la tarifa inicial de entrada. Nuestras mediciones coinciden: el mismo prompt de 6.9K tokens costó $0.0052875 en 3.7 y $0.0105675 en 3.6, justo la mitad.

El mayor ahorro viene de lo que el modelo deja de consumir. Ejecutamos tareas idénticas con un salt, tres veces cada una. Estos son la mediana de tokens de razonamiento y el coste de salida resultante:

Google afirma en el lanzamiento que 3.7 “razona con más detenimiento”; en nuestras tareas, eso significa usar menos tokens, no más. Ambos modelos mantuvieron una precisión de 3/3 en todos los casos. Al combinar la tarifa reducida a la mitad con un consumo de thinking igual o inferior a la mitad, el coste real por tarea baja entre un 61% y un 88%, antes de aplicar la caché. Hay una salvedad: al presupuestar, hay que contar con la vuelta a la tarifa anterior el 1 de enero, igual que ocurrió con el precio de lanzamiento de Sonnet 5.

Hay un tipo de tarea que no sigue esta tendencia y que casi nadie contempla en sus presupuestos: rechazar una solicitud. Preguntamos por cinco entidades inventadas —una empresa, un instituto, la carta fundacional de una localidad, una aleación y un premio—. Ambos modelos rechazaron las cinco consultas y consumieron más thinking que en cualquier otra tarea medida: una mediana de 511 tokens de razonamiento en 3.7 y 494 en 3.6. Responder “no hay constancia de esto” costó 3.5x más thinking que resolver la cadena aritmética de 5 pasos. Los pipelines con recuperación aumentada que encuentran datos ausentes con frecuencia pagan este coste en cada fallo. Es el único caso donde desaparece la mejora de eficiencia de 3.7. También aporta un dato frente a una preocupación de la primera semana: algunos análisis señalaron una mayor tasa de alucinaciones en 3.7, pero ante las preguntas sobre entidades inventadas respondió con cautela en 5 de 5 casos, igual que 3.6.

¿Qué controles de thinking siguen funcionando en 3.7?

Hay tres posiciones y ninguna permite desactivarlo, tal como indica la documentación: low, medium —el valor predeterminado— y high. La documentación no aclara que las vías de escape de 3.6 han dejado de funcionar. Todas las variantes que enviamos para apagarlo, reasoning_effort: "none", "minimal", thinking_budget: 0, thinking: {"type": "disabled"}, enable_thinking: false, devolvieron el mismo 400 del upstream: “Thinking level is unsupported: THINKING_LEVEL_MINIMAL”. Una segunda ruta de solicitud independiente lo expresa con más claridad: “Reasoning is mandatory for this endpoint and cannot be disabled”. Por tanto, la restricción viene del modelo, no de la capa de traducción de un cliente. En 3.6-flash, medido en el mismo lote, none y minimal siguen eliminando el consumo. La gama Flash adopta así la política del nivel pro: el thinking no se puede desactivar y 3.6 es ahora el último Flash que lo permite.

Estos son los resultados del control disponible en la tarea de 5 pasos (mediana de 3 ejecuciones, todas correctas 3/3):

Dos observaciones prácticas. Confirmamos que el valor predeterminado es medium: las ejecuciones sin configuración consumieron 154 tokens, prácticamente lo mismo que las 147 de la variante con medium explícito. Además, thinking_budget está realmente obsoleto: todos los valores distintos de cero que enviamos —de 16 a 1,024— se aceptaron y consumieron los mismos 135-138 tokens, sin efecto alguno. En 3.6, los presupuestos pequeños todavía desactivan el thinking y los más grandes actúan como límites. Si una integración con 3.6 controla el coste mediante presupuestos, en 3.7 debe elegir uno de los niveles; no hay más controles. Para comparar qué controles funcionan en cada proveedor, consulte nuestra matriz de controles de thinking.

¿Cuánto cuesta por paso la propuesta para agentes?

La selección de herramientas no ha cambiado respecto a 3.6; lo que se ha abaratado es la deliberación entre pasos. Ejecutamos un bucle de dos turnos con dos funciones —consultar un incidente y reiniciar el servicio indicado—, con tres ejecuciones por modelo:

Ambos modelos eligieron primero get_incident y después restart_service, con 3/3 aciertos y el mismo número de tokens de prompt. La diferencia aparece en el segundo turno: 3.7 razona aproximadamente la mitad antes de decidir la siguiente llamada. Ese es el paso que un agente repite. Un bucle de 20 pasos con estas medianas factura unos $0.0043 de salida en 3.7 frente a $0.0131 en 3.6. La proporción se mantiene tras el cambio de precio de enero porque depende de los tokens, no de las tarifas. Este es el motivo por el que Google presenta la mejora en benchmarks de agentes como un ahorro: menos tokens de deliberación por salto, multiplicados por muchos saltos.

La posición del modelo frente a sus rivales depende del benchmark y conviene revisarla antes de migrar un agente de programación. Comparativas independientes sitúan a 3.7 Flash por delante en FrontierCode (43.6% frente al 42.7% de Sonnet 5) y cerca de triplicar a Sonnet 5 en AutomationBench. En cambio, GPT-5.6 Terra lidera Terminal-bench y Sonnet 5 encabeza la prueba de tareas de escritorio, según esa misma comparativa y la cobertura de la semana de lanzamiento. En coste mínimo, la ventaja de 3.7 es clara.

¿Qué se rompe al migrar desde 3.6?

Hay dos errores 400 claros y varios fallos más discretos de lo que sugiere la documentación. La nota de migración de Google indica que deben eliminarse temperature, top_p, top_k, candidate_count y los turnos del modelo con contenido precargado. Esto es lo que medimos:

La validación es asimétrica. El control de thinking falla de forma explícita: un nivel no compatible devuelve un 400 que incluye el valor. En cambio, los parámetros de sampling y los límites de salida aceptan cualquier valor sin avisar. Si una librería cliente establece temperature por defecto, hoy no se rompe nada. Si precarga turnos del assistant para guiar la salida, ya estaba fallando antes de la migración.

¿Se mantienen la caché, el contexto y el tokenizer?

Sí, salvo por un aumento de la latencia. La caché implícita acierta con el mismo patrón que en 3.6: en la segunda llamada de un prompt idéntico se sirvieron 4,076 de 6,905 tokens desde caché, lo que redujo el coste de la llamada un 52%. Las lecturas cuestan un 10% de la tarifa inicial de entrada. Pero la caché tarda más en estar disponible: 3.6 devolvió un hit 4 segundos después de la llamada inicial; 3.7 no devolvió ninguno a los 4 segundos y sí lo hizo a los 30. El tráfico duplicado enviado con poca separación llega antes de que la caché esté lista. La economía de las escrituras no cambia en los demás aspectos.

El modelo aceptó 708,912 tokens de entrada en una sola llamada y respondió correctamente a una pregunta de tipo needle, lo que encaja con el contexto anunciado de 1M y con la ausencia de un tramo de precio específico para contexto largo. El tokenizer de texto produce resultados idénticos byte a byte en cuatro generaciones: gemini-3.1-pro-preview, 3.5-flash, 3.6 y 3.7 contaron 50 tokens para el mismo corpus mixto de inglés, chino y código. Por tanto, los presupuestos de tokens se pueden trasladar sin cambios. Las imágenes siguen facturando 1,089 tokens fijos para cualquier tamaño en toda la gama Gemini que medimos. Ninguna generación devuelve el texto de razonamiento: reasoning_content llegó vacío en todas las llamadas. El thinking se factura, pero sigue sin ser visible en ambos modelos, una queja recurrente en los hilos de la semana de lanzamiento. La salida estructurada se mantiene: json_schema estricto devolvió JSON válido y correcto en 3/3 ejecuciones, y reasoning_effort: "low" redujo a cero el thinking de la extracción, la misma zona segura para tareas de un solo paso que detectamos en toda nuestra matriz de controles.

Preguntas frecuentes

¿Cuánto cuesta la API de Gemini 3.7 Flash?

$0.75 por millón de tokens de entrada y $3.75 por millón de tokens de salida como tarifa de lanzamiento hasta el 31 de diciembre de 2026. A partir del 1 de enero de 2027 volverá a $1.50/$7.50, la misma tarifa que Gemini 3.6 Flash. Las lecturas de caché cuestan $0.075 por millón. Con prompts idénticos, nuestras mediciones facturaron exactamente la mitad en 3.7 que en 3.6.

¿Se puede desactivar el thinking en Gemini 3.7 Flash?

No. Todas las variantes para desactivarlo devuelven un 400 (“Thinking level is unsupported”). El control admite low, medium —el valor predeterminado— y high; incluso low consumió 133 tokens de razonamiento en nuestra tarea de 5 pasos. Gemini 3.6 Flash sigue siendo el Flash más reciente donde funciona reasoning_effort: "none", con la tarifa que tendrá 3.7 tras el periodo inicial.

¿Gemini 3.7 Flash es realmente más barato por solicitud que 3.6?

Sí, y el ahorro supera el 50% anunciado: también consume entre un 26% y un 77% menos de thinking en las mismas tareas. En nuestras mediciones, el coste por tarea cayó entre un 61% y un 88% —un problema verbal de 2 saltos pasó de $0.0020 a $0.0002—. Después del 31 de diciembre las tarifas volverán a igualarse y solo se mantendrá el ahorro de thinking.

¿El código escrito para Gemini 3.6 Flash funciona con 3.7?

En su mayoría. Los parámetros de sampling (temperature, top_p, top_k) siguen aceptándose pese a figurar en la lista de elementos eliminados de la documentación, y los valores excesivos de max_tokens se limitan sin avisar. Hay dos incompatibilidades claras: los turnos precargados del assistant devuelven un 400 —como ya ocurría en 3.6— y cualquier intento de desactivar el thinking ahora devuelve un 400. El control de costes debe pasar de thinking_budget a los tres niveles disponibles.

Mediciones realizadas el 2026-08-15 mediante el gateway de Synthorai, dos días después del lanzamiento: matriz de niveles y apagado (7 valores de esfuerzo, 5 presupuestos, 2 parámetros de apagado, n=3, con gemini-3.6-flash ejecutado de nuevo en el mismo lote para cada comparación), análisis del coste de razonamiento en cuatro tareas, salida estructurada con JSON estricto, pruebas de parámetros obsoletos, aceptación del límite de salida y de un contexto de 708K, pares de caché implícita con dos tiempos de espera, comparación del tokenizer con un corpus fijo en cuatro generaciones de Gemini, bucle de llamada a funciones de dos turnos (n=3 por modelo) y prueba de rechazo con cinco preguntas sobre entidades inventadas. Los importes por tarea se calcularon aplicando la tarifa de salida actual de cada modelo a los tokens de completion medidos. Dos afirmaciones se verificaron en una segunda ruta de solicitud independiente: la aceptación de valores excesivos de max_tokens y la imposibilidad de desactivar el thinking. Los precios y las fechas de lanzamiento son los publicados por Google; el comportamiento puede cambiar a medida que avance el despliegue.

← Volver al blog