Gemini 3.6 Flash: la palanca de razonamiento que mueve el coste 30x (medido)
Contenido
Gemini 3.6 Flash te cobra los tokens de razonamiento además de la respuesta, y cuántos gasta es una palanca que controlas en cada petición. En la misma tarea de redacción de 120 palabras, el ajuste por defecto facturó $0.03316 y el ajuste minimal facturó $0.00110: una diferencia de 30x para un resultado que un lector no distinguiría. Esa palanca es la decisión de coste más importante en este modelo, y trae consigo un filo peligroso. Gemini 3.6 Flash pasó a disponibilidad general el 2026-07-21 a $1.50 por millón de tokens de entrada y $7.50 por millón de salida, frente a los $9 de salida en 3.5 Flash. Salió junto a Gemini 3.5 Flash-Lite y una 3.5 Flash Cyber ajustada para seguridad; este artículo mide los dos niveles de propósito general, 3.6 Flash y Flash-Lite.
TL;DR
reasoning_effort: "minimal"redujo el coste por llamada un 91–97% frente al valor por defecto (una diferencia de 30x en una tarea de 120 palabras), gratis en trabajo de un solo paso, salida estructurada y tool calling, pero rompiendo la matemática multipaso 3/3 → 0/3.- El “17% menos tokens de salida” de Google depende de la carga de trabajo: nuestras tareas con mucho razonamiento salieron un 19% más ligeras (32% más baratas), y nuestra suite de agentes un 9% más pesada (6% más barata).
- El contexto de 1M es real (una aguja recuperada a 972K tokens) y el prompt caching coincide exactamente con el suelo de 4.096 tokens que Google publica, un encaje limpio con la spec, a diferencia de algunos modelos de “contexto de 1M” que se quedan cortos frente a lo que anuncian.
Todo lo que sigue se midió el 2026-07-24 a través del gateway de Synthorai, con prompts repetidos y saleados para saltarse las cachés; los registros de uso en bruto respaldan cada cifra.
¿Cuánto cuesta Gemini 3.6 Flash por tarea con los ajustes por defecto?
El razonamiento domina la factura de salida, y se cobra tanto si lo ves como si no. Con el effort por defecto, el modelo gasta muchos más tokens pensando que respondiendo, y esos tokens de razonamiento se facturan a la tarifa completa de salida de $7.50/M:
| Tarea | Tokens de respuesta | Tokens de razonamiento (facturados) | Coste por llamada |
|---|---|---|---|
| Frase factual de una línea | 2 | 69 | $0.00056 |
| Aritmética trivial | 3 | 167 | $0.00131 |
| Función de código pequeña | 29 | 379 | $0.00312 |
| Problema de enunciado multipaso | 4 | 472 | $0.00368 |
| Párrafo de 120 palabras | 139 | 4,274 | $0.03316 |
El patrón que conviene interiorizar es este: una respuesta factual de dos tokens arrastró igualmente 69 tokens de razonamiento, y el párrafo de 120 palabras gastó 30x más tokens pensando que escribiendo. Los tokens de razonamiento aparecen desglosados en completion_tokens_details.reasoning_tokens, así que puedes ver el recuento, pero nunca el contenido. Gemini no devuelve ningún resumen ni traza del razonamiento, el extremo más cerrado del espectro que mapeamos en nuestro estudio de anatomía del uso de tokens, donde Kimi K3 devuelve su cadena de pensamiento completa y GPT-5.6 un resumen. La siguiente sección trata de cómo bajar ese gasto.
¿Qué hace realmente el dial de razonamiento?
Es una palanca de coste real y monótona, y en la mayoría de los tipos de tarea es prácticamente dinero gratis. Poner reasoning_effort (o el nativo thinking_config.thinking_level) en minimal llevó los tokens de razonamiento a cero y recortó el coste entre un 91 y un 97% por tarea:
| Tarea | Coste por defecto | Coste minimal | Diferencia | Precisión por defecto → minimal |
|---|---|---|---|---|
| Respuesta factual de una línea | $0.00056 | $0.00005 | 12x | 3/3 → 3/3 |
| Aritmética trivial | $0.00131 | $0.00006 | 22x | 3/3 → 3/3 |
| Función de código pequeña | $0.00312 | $0.00028 | 11x | — |
| Problema de varios pasos | $0.00368 | $0.00014 | 26x | 3/3 → 0/3 |
| Párrafo de 120 palabras | $0.03316 | $0.00110 | 30x | — |
El dial funciona de verdad y los valores aceptados son minimal, low, medium (el valor por defecto) y high; cada escalón compró de forma monótona más razonamiento en nuestras pruebas (minimal 0 tokens, low ~180, medium ~530, high ~650). Lo único que minimal no puede hacer es pensar, y la aritmética de varios pasos lo necesita: obligado a responder de forma escueta al problema de los lápices y las bolsas, el modelo falló las tres veces, con respuestas erróneas dispersas en lugar de un único error sistemático. En recuperación, clasificación, formateo 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 vimos en Kimi K3: minimal es un valor por defecto razonable para extracción, consulta y formateo, y un tiro en el pie para cualquier cosa que requiera pasos intermedios. Configúralo por ruta, no globalmente, y comprueba la precisión en tus propias tareas antes de aplicarlo a una que dependa mucho del razonamiento.
Dos casos de producción de alto volumen lo dejan claro: tanto la salida estructurada como la llamada a funciones gastan razonamiento por defecto, y ambos son seguros de ejecutar en minimal. Una extracción con esquema (response_format con un JSON schema) facturó 337 tokens de razonamiento por defecto y devolvió JSON válido; en minimal facturó cero razonamiento, siguió devolviendo JSON válido que cumplía el esquema, y costó 9x menos. Una llamada a función se comportó igual: 74 tokens de razonamiento y una llamada get_weather(city) correcta por defecto, frente a cero razonamiento y la misma llamada correcta en minimal, 4x más barato. Son tareas de un solo paso disfrazadas de “estructuradas”, y el modelo no necesita razonar para rellenar un campo que ya se le ha indicado, así que si tu tráfico es extracción o enrutamiento de herramientas, minimal es casi dinero gratis.
¿Se sostiene la afirmación de “17% menos tokens de salida”?
Depende de la carga de trabajo, y el contraste es revelador. En su lanzamiento, Google posicionó a 3.6 Flash como capaz de gastar alrededor de un 17% menos de tokens de salida que 3.5 Flash en el Artificial Analysis Index (hasta un 65% en evals agénticas individuales). Pasamos ambos modelos por dos de nuestros propios bancos de pruebas y obtuvimos signos opuestos:
| Banco de pruebas | Tokens de salida 3.6 vs 3.5 | Coste 3.6 vs 3.5 |
|---|---|---|
| Matriz de tareas (cinco tareas cortas, intensivas en razonamiento) | −19% | −32% |
| Suite de agentes (bucle de herramientas, RAG, batch, chat largo) | +9% | −6% |
En las tareas cortas intensivas en razonamiento, la afirmación no solo se reprodujo, sino que superó su titular: la salida total cayó un 19%, cerca del 17% de Google, y provino casi por completo del pensamiento, no de la respuesta. Al desglosar los tokens de salida en una reejecución emparejada de ambos modelos, la respuesta visible se redujo solo un 4%, mientras que el razonamiento cayó un 19%, concentrado en las tareas de matemáticas y escritura donde 3.6 llega al mismo resultado con menos deliberación. Ese es el mecanismo detrás del benchmark: en trabajo que se apoya en el presupuesto de pensamiento, 3.6 es genuinamente más eficiente para la misma respuesta.
Con tráfico agéntico y de múltiples turnos, el signo se invierte: 3.6 gastó alrededor de un 9% más de salida que 3.5 en toda la suite. La ganancia de eficiencia vive en la fase de razonamiento, y los bucles de agente gastan proporcionalmente menos de su presupuesto ahí, así que hay menos que ahorrar y los turnos algo más largos de 3.6 acaban imponiéndose. En ambos casos la factura baja, porque los dos efectos se combinan de forma distinta: las tareas intensivas en razonamiento ahorran tanto en tokens como en la rebaja de tarifa de $9→$7.50 (−32%), mientras que el tráfico de agentes ahorra solo por precio (−6%). El resumen honesto es que “17% menos tokens de salida” es real donde el pensamiento domina la salida y se invierte donde no, así que mide tu propia mezcla en lugar de asumir el titular, y recuerda que el dial de la sección anterior mueve esto mucho más que el salto de versión.
¿Es real la ventana de contexto de 1M?
Sí, y falla de forma ruidosa en lugar de silenciosa. Colocamos una aguja de recuperación al principio de prompts de tamaño creciente: seguía recuperándose correctamente con 972K tokens de entrada, y un prompt por encima del límite devolvió un 400 input token count exceeds the maximum limpio en lugar de descartar contenido en silencio. Vale la pena decirlo porque no todos los modelos de “contexto 1M” del mercado sirven realmente la ventana que anuncian. Una nota de prueba para quien quiera reproducir esto: rellena con filler variado y con forma de frase, porque un prompt construido con un único token repetido llevó al modelo a producir galimatías degenerado bastante antes del límite de tamaño.
El prompt caching es automático y cumple la especificación en el número que importa. Google documenta un mínimo de 4.096 tokens para el context caching en los modelos Flash, y nuestro barrido cayó exactamente ahí: los prefijos en o por debajo de ~2.1K nunca se cachearon, los hits empezaron alrededor de 4.1K tokens, y cada hit dejó aproximadamente los últimos 2.1K sin cachear, tras un calentamiento de 5 a 8 llamadas. La entrada cacheada se lee a $0.15/M, un descuento de 10x sobre la tarifa fresca de $1.50. Vale la pena decirlo con claridad porque es el caso tranquilizador: a diferencia de algunos modelos que hemos medido, cuyos números anunciados exageran lo que el endpoint entrega de verdad, tanto el suelo de caché de Gemini 3.6 Flash como su ventana de 1M hacen lo que dicen los docs. El caching sigue mereciendo la pena solo para prefijos genuinamente largos y estables, y ten en cuenta que los tiers Flash solo soportan caching automático (implícito), no la API de cached-content explícito, así que no puedes fijar manualmente un documento grande y reutilizarlo por debajo del suelo.
¿Dónde encaja Gemini 3.5 Flash-Lite?
Flash-Lite es el nivel de coste predecible. Nunca gasta tokens de reasoning de forma silenciosa, así que su factura sigue uno a uno la salida visible. En el mismo problema de matemáticas de varios pasos, Flash-Lite facturó $0.00057 frente a los $0.00368 por defecto de 3.6 Flash, unas 6 veces más barato, y resolvió el problema a la vista en lugar de en un campo de reasoning oculto. A $0.30/M de input y $2.50/M de output es el valor por defecto adecuado para trabajo de un solo paso, de alto volumen y sensible a la latencia; sube a 3.6 Flash cuando una tarea necesite el reasoning que el dial puede devolver. El tokenizador no cambia, ni entre los tres modelos nuevos ni respecto a Gemini 2.5 Flash: recuentos de tokens idénticos en inglés, chino, japonés, coreano y Python en cada generación que revisamos, así que los presupuestos por idioma hechos para 2.5 se trasladan a 3.6 sin rehacer la línea base.
Preguntas frecuentes
¿Se puede desactivar el reasoning por completo en Gemini 3.6 Flash?
reasoning_effort: "minimal" (o thinking_level: "minimal") llevó los tokens de reasoning a cero en nuestras pruebas y es el mínimo del dial; los pasos aceptados son minimal, low, medium y high. No hay un estado “disabled” aparte, y los intentos de desactivar el reasoning por la fuerza se rechazan aguas arriba, así que minimal es lo más bajo posible, y para tareas de un solo paso es lo bastante bajo.
¿Por qué mi factura de Gemini es más alta de lo que sugiere la respuesta visible?
Porque los tokens de reasoning se facturan a la tarifa completa de output y no forman parte del texto que recibes. Una respuesta de dos tokens puede llevar de decenas a miles de tokens de reasoning facturados; lee completion_tokens_details.reasoning_tokens (o reconcilia total_tokens − prompt − completion) para ver el cargo real de output, y baja el dial donde la tarea lo permita.
¿Gemini 3.6 Flash o Claude Haiku 4.5?
Ocupan la misma franja de nivel rápido a precios similares, y la separación es por carga de trabajo, no por un único ganador. Desde nuestra óptica de coste, el diferenciador es el dial de thinking de 3.6 Flash: minimal lo hace un orden de magnitud más barato en tráfico de un solo paso, mientras que su valor por defecto gasta un reasoning que Haiku 4.5, a $1/$5, no gasta. Los benchmarks publicados dan a Haiku 4.5 la ventaja en profundidad de coding y a 3.6 Flash la delantera en matemáticas y precio bruto por token; elige según de qué esté hecho tu tráfico, y mide ambos en tus propias tareas antes de comprometerte.
¿Es Gemini 3.6 Flash más barato que 3.5 Flash?
Sí, en todas las cargas de trabajo que medimos, aunque cuánto depende de la forma. El output bajó de $9/M a $7.50/M, y en tareas cortas con mucho reasoning, 3.6 además gastó menos tokens de output, así que el coste cayó un 32% aproximadamente; en tráfico de agentes gastó algo más de tokens y el ahorro vino solo del recorte de tarifa, un 6% aproximadamente. En cualquier caso es más barato; migra y vuelve a medir tu propia mezcla. Para el desglose del coste por token entre familias, consulta nuestro estudio de anatomía del uso de tokens.
Medido el 2026-07-24 en gemini-3.6-flash, gemini-3.5-flash y gemini-3.5-flash-lite a través del gateway de Synthorai; recuentos de tokens de la matriz de tareas y de la suite de agentes a partir de registros de uso por llamada, resultados del effort-dial de una ablación de cinco tareas con sal (n=3 por celda), pruebas de contexto y caché a partir de needle-recall y barridos de prefijo. Los recuentos de precisión usan tareas con una única respuesta verificable. Los precios y el comportamiento pueden cambiar; verifica contra tus propios registros de uso.