Precio de Qwen 3.8 Max: 16 tokens superan a desactivar thinking

Qwen 3.8 Max cobra $2 por millón de tokens de entrada y $6 por millón de tokens de salida, pero la configuración fiable más barata no es la que parece ofrecer la API. Al desactivar thinking con reasoning_effort: "none", nuestra tarea aritmética de dos pasos pasó de 4/4 respuestas correctas a 1/6. Con un presupuesto estricto de solo 16 tokens de thinking volvió a 6/6 y consumió, de media, una quinta parte menos de tokens de salida que la configuración predeterminada. Durante la semana del lanzamiento hubo muchas afirmaciones sobre sus capacidades, pero pocos datos para contrastarlas: no había model card ni tabla pública de benchmarks, y las evaluaciones eran solo internas, algo que Hacker News señaló enseguida. El comportamiento de facturación sí puede comprobarlo cualquiera con una API key. Medimos qwen3.8-max el primer día a través del gateway de Synthorai: todos los controles de thinking que acepta la API, el coste de razonamiento de cada ajuste, el umbral mínimo y el tiempo de creación de la caché implícita, la supuesta ventana de contexto de 1M y lo que se mantiene respecto a Qwen 3.7.

TL;DR

• Los siete valores de reasoning_effort de qwen3.8-max se reducen a cuatro comportamientos medidos: desactivado, límite de 4,096 tokens, límite de 16,384 y sin límite.
• thinking_budget es exacto: si se solicitan 16 tokens, el contador marca 16; el máximo es 262,144.
• Con thinking desactivado, la precisión en matemáticas de dos pasos cayó a 1/6; con un presupuesto de 16 tokens llegó a 6/6 por menos coste.
• La caché implícita se crea en menos de 0.3 segundos y las lecturas cuestan $0.25/1M, pero no se almacena nada con prompts de menos de unos 4,300 tokens.
• Los límites de entrada son exactos y fallan explícitamente: 991,808 (thinking desactivado) y 983,616 (thinking activado).

¿Qué hacen realmente los controles de thinking de Qwen 3.8 Max?

Hay tres parámetros operativos, y no son los tres que enumera la documentación. La documentación de terceros describe reasoning_effort con tres valores (low, medium y xhigh, siendo xhigh el predeterminado). La API que medimos acepta siete: none, minimal, low, medium, high, xhigh y max. Si se envía un valor no válido, la respuesta incluye exactamente esa lista de valores permitidos. También pasan al proveedor los parámetros nativos thinking_budget (un entero positivo de hasta 262,144) y enable_thinking (booleano). El propio proveedor los valida: un presupuesto de 0 o 262,145 devuelve un error 400 que indica el límite.

En tareas normales, los niveles de esfuerzo no se distinguen. En preguntas sencillas, matemáticas de dos pasos y un problema de combinatoria de dificultad media, low, medium, high, xhigh y el valor predeterminado consumieron tokens de razonamiento dentro del mismo intervalo variable. No hubo diferencias claras. Estas solo aparecen en tareas que requieren decenas de miles de tokens de thinking. En un problema de recuento de números primos cuya ejecución sin restricciones consumió 45,129 tokens de razonamiento, los niveles empezaron por fin a imponer límites:

El modelo mental que encaja con todas las observaciones es este: cada nivel de esfuerzo predefine un límite para el presupuesto de thinking, y los siete nombres se reducen a cuatro comportamientos. El primero es desactivado: none y enable_thinking: false se comportan igual. Minimal y low comparten el límite de 4,096 tokens. Medium lo cuadruplica hasta 16,384. High, xhigh, max y el valor predeterminado forman el cuarto nivel: ninguno llegó al límite en esta tarea y consumieron entre 35K y 45K tokens según la ejecución, una variación normal a esta profundidad. Si los tres niveles superiores difieren, la separación está por encima de 45K tokens de thinking, más lejos de lo que suele alcanzar la mayoría del tráfico de producción. La afirmación de la documentación de que xhigh es el valor predeterminado coincide con todo lo que medimos. La diferencia es clara: todas las ejecuciones limitadas respondieron mal y todas las que no alcanzaron el límite respondieron bien. Por debajo del límite, todos los niveles se comportan igual; por eso el selector parece no hacer nada con el tráfico habitual. Al superarlo, el límite interrumpe el thinking a mitad de la tarea. Si necesitas un máximo concreto, evita los presets y define thinking_budget directamente. La siguiente sección analiza ese parámetro.

¿Cómo funciona realmente thinking_budget?

Se aplica con precisión de token, actúa como máximo y no como cuota, y un límite intermedio puede encarecer una tarea más que no establecer ninguno. thinking_budget es el parámetro entero nativo de DashScope (de 1 a 262,144, con un valor predeterminado documentado de 131,072, heredado de la familia Qwen3 de pesos abiertos) que fija el máximo de tokens de razonamiento por llamada. Las solicitudes con 0 o 262,145 se rechazan con un error 400 que indica el intervalo válido. Por debajo del límite no cambia nada: con un presupuesto de 8,192, una tarea que de forma natural usa unos cientos de tokens consumió 331 y 485, igual que sin presupuesto. Cuando se alcanza el máximo, la aplicación es exacta: los presupuestos de 16, 64 y 256 detuvieron el razonamiento exactamente en 16, 64 y 256 tokens en todas las ejecuciones.

Lo interesante es lo que ocurre al llegar al límite. El modelo no abandona el trabajo: deja de razonar y termina la tarea en la respuesta visible. En una tarea de combinatoria de dificultad media (contar las formas de cubrir una cuadrícula de 2x12 con fichas de dominó), todos los presupuestos dieron la respuesta correcta, pero los totales no son los esperables:

La curva no es monótona. Un presupuesto de 256 tokens costó 2.5x más que no establecer ninguno: el modelo gastó el presupuesto iniciando una cadena de razonamiento, la perdió a mitad del proceso y volvió a obtener la respuesta paso a paso en el canal visible. El presupuesto más pequeño superó a los intermedios porque 16 tokens no bastan para empezar nada, así que el modelo pasa directamente a un desarrollo visible y compacto. De aquí salen tres reglas. Primero, los presupuestos mínimos permiten reducir de verdad el consumo en tareas de profundidad baja o media: 16 tokens lograron 6/6 en nuestro lote de matemáticas de dos pasos, con 98-161 tokens totales frente a los 126-207 del valor predeterminado. Segundo, no uses límites intermedios con tráfico de profundidad desconocida. Pueden caer en una zona muerta donde el límite interrumpe un razonamiento real y acabas pagando dos veces por el trabajo (las filas de 4,096 y 16,384 de la tarea profunda muestran el mismo fallo a mayor escala, además con respuestas incorrectas). Tercero, un presupuesto que llega al límite cambia la forma de la salida: las ejecuciones limitadas muestran el desarrollo en la respuesta, algo relevante si el parser espera solo el resultado.

¿Qué parte de la documentación inicial se confirma al medirla?

Aproximadamente la mitad. Conviene publicar la diferencia porque, por ahora, no hay forma de verificar de manera independiente el resto de las afirmaciones del lanzamiento. Todos los resultados siguientes proceden de nuestras mediciones y pruebas:

El patrón favorece al plano de facturación: todo lo que determina cuánto pagas es preciso y se aplica tal como está descrito, mientras que la documentación de parámetros va por detrás de lo que realmente admite la API.

¿Desactivar thinking ahorra dinero?

Ahorra tokens a costa de la precisión, y existe una alternativa mejor a dos líneas de distancia. En nuestro lote reproducible de aritmética de dos pasos (1850 cajas multiplicadas por 24 piezas, se envía el 75% y llegan 3,120), la configuración predeterminada logró 4/4 con 126-207 tokens de completion por llamada. reasoning_effort: "none" generó respuestas de 4-5 tokens y obtuvo 1/6. Con el mismo prompt y thinking_budget: 16, el resultado fue 6/6 con 98-161 tokens de completion: en esta clase de tareas, fue más barato y tan preciso como el valor predeterminado. La aritmética de un paso mantuvo 3/3 incluso con none, por lo que desactivar thinking es seguro para consultas y transformaciones de un solo paso. El desplome aparece en tareas de varios pasos. No es una regresión de 3.8: qwen3.7-max con thinking desactivado logró 3/6 en el mismo lote.

La zona muerta descrita en la sección sobre presupuestos tiene un coste concreto en tareas difíciles. En la ejecución profunda de recuento de primos, el preset low consumió sus 4,096 tokens de thinking, añadió otros 13,882 tokens visibles comprobando candidatos y aun así respondió mal: $0.11 por una respuesta incorrecta, frente a $0.27 por la respuesta correcta de la configuración predeterminada. Desactivar thinking produce el mismo efecto en tareas difíciles: tanto 3.8 como 3.7 generaron una enumeración visible de 13-15K tokens. En una única ejecución por modelo, uno acertó el recuento y el otro se desvió en un solo número primo. Un presupuesto que se agota a mitad del razonamiento puede aumentar el gasto total y reducir la calidad. Limita thinking en tareas que sabes que son sencillas; deja razonar a las tareas profundas.

¿Es real la ventana de contexto de 1M tokens?

En la práctica, sí, con límites exactos y transparentes. La API acepta hasta 991,808 tokens de entrada con thinking desactivado y 983,616 con thinking activado. Ambos límites fallan explícitamente: una solicitud demasiado grande se rechaza con un error 400 que indica el máximo exacto, en lugar de truncar el documento sin avisar. La recuperación de información puntual funcionó en todos los tamaños probados: 161K, 677K y 919K tokens. El modelo devolvió literalmente el código de anulación insertado en entre 11 y 63 segundos. Una solicitud de 919K tokens cuesta unos $1.84 a precio de lista. La ventana es real, pero usarla completa debe ser una decisión de diseño, no la opción predeterminada.

¿Qué ofrece la caché implícita y cuál es su umbral?

Es la creación de caché más rápida que hemos medido, aunque exige un prompt mínimo inusualmente grande. Al repetir un prompt de 6,103 tokens con un identificador único, la siguiente solicitud ya obtuvo un hit 0.3 segundos después. No hay que diseñar el sistema alrededor de una fase de calentamiento, a diferencia de los tiempos de creación de decenas de segundos de Gemini. Siguió habiendo hits a los +5 y +15 minutos sin volver a inicializar la entrada, pero había desaparecido a los +45. Por tanto, su vida útil operativa está entre 15 y 45 minutos sin actividad. Las lecturas cuestan $0.25 por millón, 0.125x la tarifa de entrada, y no hay recargo de escritura. El descuento apareció automáticamente tanto en el campo cached_tokens como en el coste medido.

El problema está en el umbral. Un prompt de 4,221 tokens nunca produjo un hit; uno de 4,360 sí, y el primer hit siempre fue de exactamente 4,096 tokens. Por debajo de unos 4.3K tokens de prompt, esta caché no se aplica. La diferencia es marcada frente al mínimo de 1,024 tokens de Claude y al almacenamiento automático en bloques pequeños de Kimi K3. Por encima del umbral, los hits se cuantizan en bloques de 128 tokens (observamos 4,096, 8,320, 12,544 y 16,768), pero la cobertura del prefijo inicializado varió entre el 51% y el 96%. Al estimar costes, cuenta con que se aplicará el descuento a la mayor parte de un prefijo largo, no a todo.

¿La salida estructurada y las tool calls pagan el coste de razonamiento?

Sí de forma predeterminada, y son los casos más seguros para eliminarlo. La salida estricta con json_schema funciona y aplica el esquema de verdad: la misma extracción sin esquema devolvió el resultado dentro de un bloque de código Markdown. Con la configuración predeterminada, la extracción de cuatro campos de una factura consumió 252 tokens de razonamiento antes de emitir 57 tokens de JSON. Con reasoning_effort: "none" produjo un JSON válido y correcto en 54 tokens totales, 5.7x menos; thinking_budget: 16 quedó entre ambos. La selección de herramientas mostró el mismo patrón: con thinking desactivado, el modelo llamó a la función correcta usando un tercio de los tokens del valor predeterminado. La extracción y el enrutamiento de un solo paso son justo el tipo de tarea donde desactivar thinking es seguro. A $6/1M de salida, el ahorro se acumula.

Otro detalle de facturación para quienes construyen agentes: la API devuelve la cadena de pensamiento completa en reasoning_content, y la documentación indica que los clientes multivuelta deben reenviarla sin modificar. Esta condición no se aplica. Repetimos turnos incluyendo el razonamiento, omitiéndolo y manipulándolo deliberadamente. Los tres casos fueron aceptados y no afectaron a la precisión en cadenas cortas. El razonamiento reenviado se factura como tokens de entrada normales. Omitirlo permite ahorrar de verdad en tráfico multivuelta, salvo que tus pruebas muestren una pérdida de calidad.

¿Qué se mantiene desde Qwen 3.7 y qué ha cambiado?

El tokenizer no ha cambiado, así que los presupuestos de tokens se pueden trasladar directamente. Corpus idénticos en inglés, chino, japonés y código produjeron los mismos recuentos en qwen3.8-max, qwen3.7-max, qwen3.7-plus, qwen3.6-flash y qwen3.5-flash. Por tanto, la planificación de costes por idioma de nuestro estudio de tokenizers por idioma sigue siendo válida sin cambios.

Sí cambiaron dos cosas. Primero, 3.8-max incorpora una sobrecarga fija de prompt que no tienen los otros modelos: el mismo mensaje de un carácter contó como 49 tokens de prompt en 3.8-max, frente a 11 en todos los demás Qwen que probamos. Son 38 tokens adicionales y constantes por llamada. En prompts largos apenas se notan, pero representan un porcentaje medible en solicitudes breves y frecuentes. Segundo, thinking está siempre disponible en lugar de funcionar como un cambio de modo, con el selector de siete niveles y el parámetro de presupuesto exacto descritos antes. Los controles de 3.7 eran menos precisos. Conviene aclarar el precio porque durante la preview circularon dos esquemas: las suscripciones Token Plan (de $6 a $68 mensuales, con grandes descuentos en horas valle) se aplican a las propias aplicaciones de Alibaba, no a la API. A través de la API se paga la tarifa de lista de $2/$6, y el contador de nuestro gateway coincidió con ella hasta el cuarto decimal en todas las llamadas del estudio.

Preguntas frecuentes

¿Se puede desactivar thinking en Qwen 3.8 Max?

Sí, por completo: reasoning_effort: "none" (o enable_thinking: false) elimina todos los tokens de razonamiento. Resérvalo para tareas de un solo paso. En aritmética de dos pasos obtuvo 1/6 en nuestro lote, mientras que un thinking_budget de 16 tokens logró 6/6 con un consumo de tokens similar o menor. Para tráfico de varios pasos, la configuración mínima debería ser un presupuesto pequeño, no thinking desactivado.

¿Cuál es el tamaño mínimo de prompt para la caché de Qwen 3.8 Max?

Unos 4,300 tokens según nuestras pruebas: un prompt de 4,221 tokens nunca produjo un hit y uno de 4,360 sí; además, los primeros hits siempre son de exactamente 4,096 tokens. Por debajo del umbral no hay descuento. Por encima, las lecturas se facturan a $0.25/1M sin recargo de escritura, y la entrada se puede leer 0.3 segundos después de inicializarla.

¿Qwen 3.8 Max admite reasoning_effort?

Se aceptan siete valores (none, minimal, low, medium, high, xhigh y max), pero los niveles funcionan como límites del presupuesto de thinking y solo se diferencian cuando una tarea los supera. Para un control determinista, define thinking_budget directamente: se aplica con precisión de token, rechaza 0 y admite hasta 262,144. Las herramientas cliente no coinciden actualmente sobre los niveles disponibles; la lista anterior es la que aceptó la API el primer día.

¿Hay que reenviar reasoning_content en conversaciones multivuelta?

La documentación dice que sí, pero la API no lo comprueba. En nuestras pruebas, los historiales de razonamiento omitidos e incluso manipulados se aceptaron sin errores ni pérdidas de precisión en cadenas cortas. El razonamiento reenviado se factura como entrada normal. Omitirlo permite reducir costes hasta que tus propias evaluaciones detecten una pérdida de calidad en cadenas largas.

Medido el 2026-08-03 a través del gateway de Synthorai con qwen3.8-max (y comparativas con qwen3.7-max, qwen3.7-plus, qwen3.6-flash y qwen3.5-flash): pruebas de valores aceptados por el selector, valores no válidos y límites de max_tokens; una tarea profunda con consumo natural de 45K para activar los límites de esfuerzo; un lote fijo y reproducible para medir el desplome de precisión (n=4-6 por variante, con identificadores únicos); pares de caché con identificadores únicos, intervalos de 2-3s y escalones temporales; pruebas de recuperación y desbordamiento entre 161K y 919K tokens; y recuentos idénticos del tokenizer sobre cuatro corpus. Los importes en dólares proceden del coste facturado por el contador del gateway según las tarifas de lista ($2/$6 por 1M). Los descuentos, precios y comportamientos del periodo de preview pueden cambiar; compruébalos con tus propios registros de uso.

← Volver al blog