Gemini 3.7 Flash duplica su precio, pero un razonamiento más alto aún puede costar menos
Los precios de Gemini 3.7 Flash subirán en enero de 2027, mientras que el nivel de razonamiento más barato sigue dependiendo de la aceptación, los reintentos, la latencia y el coste alternativo.
Google ha puesto Gemini 3.7 Flash a disposición general con tres niveles de razonamiento—low, medium y high—que intercambian uso de tokens y latencia por comportamientos de razonamiento distintos. También ha puesto el modelo bajo un reloj de precios. Las tarifas estándar globales de la API son de 0,75 por millón de tokens de salida hasta el 31 de diciembre de 2026; después se duplican el 1 de enero.
Eso no hace que low sea necesariamente la opción barata ni que high sea la cara. La comparación útil es el gasto total dividido por las tareas aceptadas, después de contar los intentos rechazados, los reintentos, el trabajo alternativo y el tiempo transcurrido. Un nivel que cuesta más por llamada puede costar menos por resultado utilizable si supera con mayor frecuencia la misma prueba externa de aceptación.
La calculadora de abajo aplica los dos periodos de precios publicados por Google a las mediciones de la carga de trabajo de un lector. Sus valores predeterminados son ficticios y no representan un benchmark de Gemini.
El precio se duplica; la decisión no se simplifica
La guía para desarrolladores de Gemini 3.7 Flash de Google presenta gemini-3.7-flash como un modelo listo para producción, con una ventana de contexto de un millón de tokens, un máximo de salida de 64.000 tokens y medium como nivel de razonamiento predeterminado. Google describe low como un ajuste orientado a la latencia, medium como el valor general predeterminado y high como la opción para razonamientos más difíciles y uso de herramientas, con mayor consumo y coste de tokens.
Esas descripciones son hipótesis iniciales, no una política de enrutamiento. «Difícil» no es un campo de la API, y una respuesta segura no es necesariamente una respuesta aceptada. El equipo aún tiene que definir el éxito fuera del modelo: por ejemplo, que las pruebas pasen, que un esquema obligatorio sea válido, que las citas respalden cada afirmación material o que se iguale una respuesta de referencia aprobada por una persona.
La tarjeta de tarifas de Google Cloud hace explícito el cambio de coste fechado para el servicio global estándar:
| Periodo de precios | Entrada por 1 M de tokens | Salida de texto y razonamiento por 1 M de tokens |
|---|---|---|
| Hasta el 31 de diciembre de 2026 | $0.75 | $3.75 |
| Desde el 1 de enero de 2027 | $1.50 | $7.50 |
La misma página enumera tarifas separadas para servicios no globales, entrada en caché, prioridad y flex/lote. La calculadora excluye intencionadamente esas variantes para no mezclar silenciosamente servicios distintos. También trata juntos los tokens de salida y los tokens de razonamiento facturados, de acuerdo con la categoría de precios de Google.
El coste por tarea aceptada cambia el ganador aparente
Ejecuta un conjunto de tareas congelado en cada nivel de razonamiento y después introduce los promedios agregados o por intento. «Intentos» incluye reintentos; «tareas aceptadas» cuenta solo los resultados que superaron la regla escrita antes de las pruebas. El coste alternativo puede representar otra llamada al modelo, una ruta de recuperación determinista o un gasto de reparación estimado por separado, pero se debe usar la misma definición para los tres niveles.
Calculadora de carga de trabajo
Compara niveles de razonamiento por trabajo aceptado
Sustituye los valores ficticios por mediciones del mismo conjunto de tareas congelado. Los tokens de salida deben incluir los tokens de razonamiento facturados. La latencia se trata como tiempo transcurrido en serie; la calculadora no modela la concurrencia.
| Razonamiento | Aceptadas / intentos | Carga de rechazos | API actual / aceptada | API de enero / aceptada | API actual + alternativa / aceptada | Minutos en serie / aceptada |
|---|---|---|---|---|---|---|
| Bajo | ||||||
| Medio | ||||||
| Alto |
Incluye: tarifas globales estándar de entrada y salida de texto. Excluye: entrada en caché, regiones no globales, servicios prioritarios o flexibles/por lotes, herramientas, almacenamiento, redes, impuestos, tiempo del personal y descuentos específicos del proveedor.
El cálculo estático es:
API cost per attempt =
(input tokens × input rate + output-and-reasoning tokens × output rate)
/ 1,000,000
API cost per accepted task =
(API cost per attempt × all attempts) / accepted tasks
Effective cost per accepted task =
(total API cost + rejected attempts × fallback cost) / accepted tasks
Serial minutes per accepted task =
(minutes per attempt × all attempts) / accepted tasksCon los valores predeterminados ficticios, low produce 78 tareas aceptadas de 100 intentos, medium produce 88 y high produce 93. Los costes actuales solo de API resultantes son aproximadamente 0,00673 y 0,01129 por cada intento rechazado, los totales pasan a ser aproximadamente 0,02083 y 0,01505 $. En esa carga de trabajo inventada, medium gana por poco en coste efectivo aunque low tenga la factura de tokens más pequeña y high acepte más trabajo.
Ese resultado no aconseja elegir medium. Muestra por qué el precio de los tokens, la aceptación y el gasto de recuperación deben formar parte del mismo cálculo.
Los benchmarks independientes ayudan a elegir pruebas, no ganadores
Artificial Analysis probó los tres niveles de razonamiento e informó de puntuaciones distintas del índice de inteligencia, tiempo por tarea, velocidad de salida y coste por tarea. Su configuración high obtuvo una puntuación superior a medium y low en ese conjunto, mientras que medium usó menos dinero por tarea del índice que high con la tarifa introductoria.
Esos resultados son evidencia útil de que el control cambia el comportamiento observable. No proporcionan las tasas de aceptación ni los recuentos de tokens del producto de un lector. Artificial Analysis usa su propia mezcla de benchmarks, pesos, harnesses y graders. Un flujo de respuestas de soporte, un agente de reparación de código, un extractor de documentos y un sistema de inspección multimodal pueden invertir el orden porque fallan de formas distintas.
La model card de Gemini 3.7 Flash de Google marca un límite similar. Presenta evaluaciones de razonamiento, programación, uso de herramientas por agentes, tareas multimodales, rendimiento multilingüe y contexto largo, e identifica el modelo como adecuado para varios casos de uso generales. Una tabla de benchmarks sirve para apoyar un plan de pruebas; no establece la aptitud para producción de una carga de trabajo no probada.
El nivel de razonamiento cambia tanto la calidad como la factura
En la primera comparación, cambia solo thinking_level. Mantén fijos el ID exacto del modelo, los prompts, los fixtures, las definiciones de herramientas, el contexto, la salida máxima, la regla de reintentos, la región, la concurrencia, el tiempo de espera y el grader de aceptación. Registra el uso comunicado por la API en lugar de estimar todos los niveles con un tokenizador genérico.
Usa tareas extraídas del trabajo real, incluidos casos normales y fallos costosos. Ejecuta los niveles en orden aleatorio o alterno para que una breve ralentización del proveedor no afecte únicamente a un candidato. Publica los recuentos brutos de aceptados e intentos cuando la muestra sea pequeña; un porcentaje sin denominador oculta la incertidumbre.
La latencia necesita la misma disciplina. La calculadora informa de los minutos en serie por tarea aceptada porque se pueden auditar a partir de cinco entradas. No predice un sistema concurrente. Registra al menos por separado la latencia mediana y la de cola, porque un nivel de razonamiento puede parecer eficiente en promedio y aun así incumplir el plazo p95 del producto.
El análisis de costes de Grok 4.6 explica el mismo problema del denominador entre modelos. La guía general de evaluación de IA explica por qué la métrica de éxito elegida determina el producto.
El punto de equilibrio debe sobrevivir a la factura
Para cada nivel de razonamiento, conserva cuatro columnas de decisión separadas:
- coste de API por tarea aceptada;
- coste efectivo después del fallback definido;
- tareas aceptadas por minuto transcurrido; y
- minutos de revisión o reparación humana por tarea aceptada.
Después, elige el nivel que cumpla las puertas de calidad y latencia del producto al menor coste relevante. Si ningún nivel supera la puerta, la respuesta no es automáticamente «usar high». Puede que tengan que cambiar el prompt, las herramientas, la descomposición de tareas, el modelo o el fallback.
Vuelve a calcularlo antes del 1 de enero de 2027. El coste solo de API se duplicará según el calendario global estándar documentado actualmente, pero el coste efectivo puede aumentar menos de un 100 % cuando dominen los gastos de fallback o del personal. Por el contrario, un flujo con un gasto de recuperación insignificante notará casi todo el cambio de tarifas.
No uses esta calculadora simplificada para pronosticar una factura hasta añadir los tokens en caché, el modo de servicio, la región, las herramientas, los cargos de red, los límites de velocidad, los errores, los descuentos, los impuestos y la concurrencia del despliegue real. Google también puede cambiar los precios o la disponibilidad. Conserva la URL de la tarjeta de tarifas y la marca de tiempo de verificación con cada decisión.
El cambio de enero es un plazo útil porque impide que un precio promocional se convierta en una suposición arquitectónica inadvertida. El resultado duradero no es un nivel de razonamiento favorito, sino una carga de trabajo congelada, una regla externa de aprobación y suficiente evidencia de facturación y fallos para repetir la decisión cuando cambien el modelo o el precio.