Gemini 3.6 Flash: el dial de thinking que mueve el coste 30x

Gemini 3.6 Flash cobra los tokens de razonamiento además de la respuesta, y puedes controlar cuánto gasta en cada petición. En la misma tarea de redacción de 120 palabras, la configuración predeterminada facturó $0.03316 y minimal, $0.00110: una diferencia de 30x con resultados que un lector no podría distinguir. Este ajuste es la decisión de costes más importante al usar el modelo, pero tiene un riesgo claro. Gemini 3.6 Flash alcanzó la disponibilidad general el 2026-07-21, con un precio de $1.50 por millón de tokens de entrada y $7.50 por millón de tokens de salida, frente a los $9 de salida de 3.5 Flash. Se lanzó junto con Gemini 3.5 Flash-Lite y 3.5 Flash Cyber, optimizado para seguridad. En este artículo medimos los dos niveles de uso general: 3.6 Flash y Flash-Lite.

TL;DR

• reasoning_effort: "minimal" redujo el coste por llamada entre un 91% y un 97% respecto a la configuración predeterminada. En una tarea de 120 palabras, la diferencia fue de 30x. No afectó a las tareas de un solo paso, salida estructurada ni llamadas a herramientas, pero hizo caer el resultado en matemáticas de varios pasos de 3/3 a 0/3.
• La afirmación de Google sobre un «17% menos de tokens de salida» depende de la carga: nuestras tareas con mucho razonamiento consumieron un 19% menos y costaron un 32% menos; nuestra suite de agentes consumió un 9% más y costó un 6% menos.
• La ventana de contexto de 1M es real: el modelo recordó una aguja situada a 972K tokens. El prompt caching también coincide exactamente con el mínimo publicado por Google de 4,096 tokens. Las especificaciones se cumplen, a diferencia de algunos modelos con «1M de contexto» que no llegan a lo anunciado.

Todas las mediciones siguientes se realizaron el 2026-07-24 a través del gateway de Synthorai. Añadimos variaciones aleatorias a los prompts repetidos para evitar las cachés, y cada cifra está respaldada por registros de uso sin procesar.

¿Cuánto cuesta cada tarea con Gemini 3.6 Flash y la configuración predeterminada?

El razonamiento domina la factura de salida y se cobra aunque no puedas verlo. Con el esfuerzo predeterminado, el modelo usa muchos más tokens para razonar que para responder. Esos tokens de razonamiento se facturan a la tarifa completa de salida de $7.50/M:

Este es el patrón que hay que tener presente: una respuesta factual de dos tokens generó 69 tokens de razonamiento, mientras que el párrafo de 120 palabras gastó 30x más tokens en razonar que en escribir. Los tokens de razonamiento aparecen desglosados en completion_tokens_details.reasoning_tokens, por lo que puedes consultar la cantidad, pero nunca el contenido. Gemini no devuelve ningún resumen ni traza del razonamiento. Es el extremo más cerrado de los modelos que analizamos en nuestro estudio sobre la anatomía del consumo de tokens, donde Kimi K3 devuelve toda su cadena de pensamiento y GPT-5.6 ofrece un resumen. En la siguiente sección veremos cómo reducir este gasto.

¿Qué hace realmente el control de razonamiento?

Es un mecanismo real y progresivo para controlar el coste. En la mayoría de las tareas, el ahorro sale prácticamente gratis. Al establecer reasoning_effort o el parámetro nativo thinking_config.thinking_level en minimal, los tokens de razonamiento bajaron a cero y el coste por tarea se redujo entre un 91% y un 97%:

El control funciona y acepta los valores minimal, low, medium (predeterminado) y high. En nuestras pruebas, cada nivel aumentó progresivamente el razonamiento: minimal, 0 tokens; low, ~180; medium, ~530; high, ~650. minimal no permite razonar, y la aritmética de varios pasos sí lo necesita. Al obligar al modelo a responder de forma breve al problema de lápices y bolsas, falló las tres veces, con respuestas incorrectas distintas y no por un único error sistemático. En tareas de recuperación, clasificación, formato y preguntas de un solo paso, minimal mantuvo la precisión y redujo la factura en un orden de magnitud.

La regla práctica coincide con lo que observamos en Kimi K3: minimal es una opción predeterminada razonable para extracción, consultas y formato, pero resulta peligroso en cualquier tarea que necesite pasos intermedios. Configúralo por ruta, no de forma global, y comprueba la precisión con tus propias tareas antes de desplegarlo en cargas con mucho razonamiento.

Dos patrones habituales en producción a gran escala lo dejan claro: tanto la salida estructurada como las llamadas a funciones consumen razonamiento con la configuración predeterminada, y ambas pueden ejecutarse de forma segura con minimal. Una extracción restringida por esquema (response_format con un esquema JSON) facturó 337 tokens de razonamiento con la configuración predeterminada y devolvió JSON válido. Con minimal, no facturó ningún token de razonamiento, siguió devolviendo JSON válido conforme al esquema y costó 9x menos. En una llamada a función ocurrió lo mismo: 74 tokens de razonamiento y una llamada correcta a get_weather(city) con la configuración predeterminada, frente a cero tokens de razonamiento y la misma llamada correcta con minimal, por un coste 4x menor. Son tareas de un solo paso presentadas como «estructuradas». El modelo no necesita razonar para rellenar un campo que se le ha indicado explícitamente. Si tu tráfico consiste en extracción o enrutamiento de herramientas, minimal ofrece un ahorro casi gratuito.

¿Se cumple la afirmación del «17% menos de tokens de salida»?

Depende de la carga, y la diferencia entre casos resulta reveladora. En su lanzamiento, Google presentó 3.6 Flash como un modelo que consume aproximadamente un 17% menos de tokens de salida que 3.5 Flash en el Artificial Analysis Index, y hasta un 65% menos en evaluaciones concretas de agentes. Probamos ambos modelos en dos bancos de pruebas propios y obtuvimos resultados opuestos:

En las tareas cortas con mucho razonamiento, no solo reproducimos la afirmación, sino que mejoramos la cifra principal: el total de tokens de salida bajó un 19%, cerca del 17% de Google. La reducción procedió casi por completo del razonamiento, no de la respuesta. En una repetición emparejada con ambos modelos, la respuesta visible se redujo solo un 4%, mientras que el razonamiento cayó un 19%. El descenso se concentró en las tareas matemáticas y de redacción, donde 3.6 llega al mismo resultado con menos deliberación. Ese es el mecanismo que explica el benchmark: en cargas que dependen mucho del presupuesto de razonamiento, 3.6 es realmente más eficiente para obtener la misma respuesta.

En tráfico de agentes y varios turnos, el resultado se invierte: 3.6 consumió alrededor de un 9% más de tokens de salida que 3.5 en toda la suite. La mejora de eficiencia se concentra en la fase de razonamiento, mientras que los bucles de agentes dedican proporcionalmente menos presupuesto a esa fase. Hay menos margen de ahorro y terminan pesando más los turnos ligeramente más largos de 3.6. Aun así, la factura baja en ambos casos, aunque por motivos distintos. Las tareas con mucho razonamiento ahorran tanto en tokens como por la reducción de tarifa de $9→$7.50, con un coste un 32% menor. En el tráfico de agentes, el ahorro procede únicamente del precio y ronda el 6%. El «17% menos de tokens de salida» se cumple cuando el razonamiento domina la salida y se invierte cuando no es así. Mide tu propia combinación de cargas en lugar de asumir que la cifra general se aplicará a todas. Además, el control de la sección anterior tiene mucho más impacto que el cambio de versión.

¿Es real la ventana de contexto de 1M?

Sí, y cuando se supera falla de forma explícita. Colocamos una aguja al principio de prompts cada vez más grandes. El modelo seguía recuperándola correctamente con 972K tokens de entrada. Al superar el límite, devolvió claramente 400 input token count exceeds the maximum en lugar de descartar contenido sin avisar. No todos los modelos del mercado que anuncian «1M de contexto» ofrecen realmente esa ventana. Si vas a reproducir la prueba, rellena el prompt con texto variado y formado por oraciones. Un prompt construido repitiendo un único token hizo que el modelo generara texto incoherente mucho antes de alcanzar el límite.

El prompt caching es automático y cumple la especificación en la cifra importante. Google documenta un mínimo de 4,096 tokens para la caché de contexto en los modelos Flash, y nuestras pruebas dieron exactamente ese resultado: los prefijos de hasta ~2.1K tokens nunca entraron en caché; los aciertos empezaron alrededor de 4.1K tokens; y en cada acierto quedaron sin cachear aproximadamente los últimos 2.1K, tras un calentamiento de entre 5 y 8 llamadas. Las lecturas de entrada desde caché cuestan $0.15/M, un descuento de 10x respecto a la tarifa de $1.50 para entrada nueva. En este caso, las cifras publicadas son fiables: a diferencia de algunos modelos que hemos medido y cuyas especificaciones exageran lo que realmente ofrece el endpoint, tanto el mínimo de caché como la ventana de 1M de Gemini 3.6 Flash funcionan como indica la documentación. La caché solo compensa con prefijos realmente largos y estables. Los niveles Flash solo admiten caché automática o implícita, no la API explícita de contenido en caché. Por tanto, no puedes fijar manualmente un documento grande y reutilizarlo por debajo del mínimo.

¿Qué papel ocupa Gemini 3.5 Flash-Lite?

Flash-Lite es el nivel de coste predecible. Nunca consume tokens de razonamiento de forma oculta, por lo que la factura crece en proporción directa a la salida visible. En el mismo problema matemático de varios pasos, Flash-Lite facturó $0.00057 frente a los $0.00368 de 3.6 Flash con la configuración predeterminada: aproximadamente 6x menos. Además, desarrolló la respuesta de forma visible en lugar de hacerlo en un campo de razonamiento oculto. Con un precio de $0.30/M para entrada y $2.50/M para salida, es la opción predeterminada adecuada para tareas de un solo paso, sensibles a la latencia y con mucho volumen. Pasa a 3.6 Flash cuando la tarea necesite el razonamiento que permite añadir el control. El tokenizer no ha cambiado entre los tres modelos nuevos ni respecto a Gemini 2.5 Flash: obtuvimos recuentos idénticos de tokens en inglés, chino, japonés, coreano y Python en todas las generaciones analizadas. Los presupuestos por idioma definidos para 2.5 pueden aplicarse a 3.6 sin establecer una nueva línea base.

Preguntas frecuentes

¿Se puede desactivar por completo el razonamiento en Gemini 3.6 Flash?

reasoning_effort: "minimal" o thinking_level: "minimal" redujeron los tokens de razonamiento a cero en nuestras pruebas y representan el nivel mínimo del control. Los niveles admitidos son minimal, low, medium y high. No existe un estado independiente de «desactivado», y los intentos de deshabilitar el razonamiento por completo son rechazados en origen. minimal es el valor más bajo posible y resulta suficiente para tareas de un solo paso.

¿Por qué mi factura de Gemini es mayor de lo que sugiere la respuesta visible?

Porque los tokens de razonamiento se facturan a la tarifa completa de salida y no forman parte del texto que recibes. Una respuesta de dos tokens puede incluir desde decenas hasta miles de tokens de razonamiento facturados. Consulta completion_tokens_details.reasoning_tokens o calcula total_tokens − prompt − completion para conocer el cargo real de salida. Reduce el nivel cuando la tarea lo permita.

¿Gemini 3.6 Flash o Claude Haiku 4.5?

Ocupan el mismo segmento de modelos rápidos y tienen precios similares. La elección depende de la carga, no hay un único ganador. Desde el punto de vista del coste, el control de razonamiento de 3.6 Flash marca la diferencia: minimal reduce su coste en un orden de magnitud para tráfico de un solo paso, mientras que la configuración predeterminada consume razonamiento que Haiku 4.5, con un precio de $1/$5, no utiliza. Los benchmarks publicados sitúan a Haiku 4.5 por delante en tareas de programación complejas, mientras que 3.6 Flash lidera en matemáticas y precio bruto por token. Elige según la composición de tu tráfico y mide ambos con tus propias tareas antes de tomar una decisión.

¿Gemini 3.6 Flash es más barato que 3.5 Flash?

Sí, en todas las cargas que medimos, aunque el ahorro depende del tipo de tarea. La salida bajó de $9/M a $7.50/M. En tareas cortas con mucho razonamiento, 3.6 también consumió menos tokens de salida, por lo que el coste se redujo aproximadamente un 32%. En tráfico de agentes consumió algo más de tokens, y el ahorro procedió únicamente de la reducción de tarifa: alrededor de un 6%. Es más barato en ambos casos. Migra y vuelve a medir tu propia combinación de cargas. Para ver el desglose del coste por token entre distintas familias, consulta nuestro estudio sobre la anatomía del consumo de tokens.

Mediciones realizadas el 2026-07-24 con gemini-3.6-flash, gemini-3.5-flash y gemini-3.5-flash-lite a través del gateway de Synthorai. Los recuentos de tokens de la matriz de tareas y la suite de agentes proceden de registros de uso por llamada. Los resultados del control de esfuerzo proceden de una ablación con cinco tareas y variaciones aleatorias (n=3 por celda). Las pruebas de contexto y caché se realizaron mediante recuperación de agujas y barridos de prefijos. Los recuentos de precisión solo incluyen tareas con una única respuesta verificable. Los precios y el comportamiento pueden cambiar; compruébalos con tus propios registros de uso.

← Volver al blog