Controles de razonamiento: qué hacen 13 modelos LLM

El mismo parámetro de control de razonamiento significa tres cosas diferentes según a qué modelo lo envíes: thinking_budget: 16 consume exactamente 16 tokens de razonamiento en Qwen 3.8 Max, GLM 5.2 y ambas versiones de DeepSeek V4, se ignora silenciosamente en Kimi K3 y MiniMax M3, y es rechazado con un 400 por GPT-5.6. Sometimos a prueba 13 modelos de nueve proveedores con cada variante de escritura del control que la superficie compatible con OpenAI acepta, y luego medimos cuánto cuesta cada posición del dial en tokens de razonamiento y qué rompe en precisión, en las mismas cuatro tareas con sal, tres ejecuciones por celda.

TL;DR

• thinking: {"type": "disabled"} anula el razonamiento en 11 de 13 modelos; las dos excepciones (Gemini pro, GPT-5.6) lo rechazan.
• Qwen, GLM y DeepSeek consumen thinking_budget: 16 como exactamente 16; Kimi y MiniMax aceptan el campo y no cambian nada: Kimi consumió 8-97 frente a ese límite, nunca 16.
• Desactivar el razonamiento redujo la aritmética de 5 pasos de 3/3 a 0-1/3 en ocho modelos; DeepSeek V4 Pro y Claude mantuvieron 3/3 escribiendo los pasos en la respuesta visible.
• La extracción de JSON obtuvo 3/3 con el razonamiento desactivado en los 12 modelos que admiten la desactivación.

¿Qué controles de razonamiento acepta cada API?

Las interfaces compatibles con OpenAI suelen exponer tres familias de controles, pero ningún modelo respeta las tres. reasoning_effort acepta un enum (de none a max), thinking_budget recibe un número de tokens y thinking: {"type": "disabled"} —junto con su variante enable_thinking: false— solicita desactivar el razonamiento por completo. Este es el mapa de compatibilidad que medimos con una pregunta trivial y una variante aleatoria por celda:

Dos filas merecen una advertencia. Google divide su propia línea: el nivel flash se apaga limpiamente mientras que el nivel pro rechaza toda variante de desactivación con un 400, en consonancia con la postura de Google de que el pensamiento de clase pro no puede desactivarse. Y las dos celdas de claude-fable-5 marcadas como “accepted” difieren del contrato publicado por Anthropic para ese modelo, que especifica que el pensamiento no puede desactivarse; considera esas celdas como sujetas a cambios.

¿«Aceptado» significa «aplicado»?

No, y la diferencia se factura. Una respuesta 200 solo confirma que el parámetro se ha procesado, no que haya llegado al modelo. La prueba para distinguir ambos casos es sencilla: envía un presupuesto de 16 y consulta el contador.

Qwen, GLM y ambas compilaciones de DeepSeek consumieron exactamente 16. Kimi consumió 8, 19, 79 y 97 contra el mismo límite en cuatro ejecuciones, nunca 16, y MiniMax se comportó igual en 18-44, facturado como de costumbre, sin nada en la respuesta que insinuara que el límite se había eliminado. Gemini traduce los presupuestos a su control nativo con granularidad gruesa: en flash, los límites de 0 a 64 se comportaron como un apagado total, mientras que 1,024 permitió el razonamiento (mediana de 141 en nuestra tarea de 5 pasos); el nivel pro redujo su consumo bajo un límite pero se estabilizó en torno a 200 contra un 64 solicitado y no puede llegar a cero. GPT-5.6 y Claude se sitúan en el extremo honesto del espectro: los presupuestos numéricos se rechazan con un 400 y sabes de inmediato a qué atenerte.

La regla práctica es comprobar completion_tokens_details.reasoning_tokens en la siguiente respuesta después de configurar cualquier control de razonamiento y confirmar que el valor ha cambiado. Un control que falla de forma explícita cuesta un reintento; uno que falla en silencio cobra en cada llamada el razonamiento que creías haber limitado.

¿Existe una forma universal de desactivarlo?

thinking: {"type": "disabled"} es lo más cercano que hay: puso el razonamiento en cero en 11 de los 13 modelos, abarcando Kimi, Qwen, ambos DeepSeeks, GLM, Gemini flash, MiniMax, la línea Seed de ByteDance y los tres modelos Claude. Su similar enable_thinking: false lo iguala casi en todas partes, con una excepción silenciosa: MiniMax lo acepta y mantiene el razonamiento (31 tokens de razonamiento en nuestra prueba).

Las dos excepciones fallan de forma ruidosa en lugar de silenciosa: Gemini pro devuelve un 400 por cada error de escritura (el nivel no puede desactivar el razonamiento), y GPT-5.6 también rechaza el campo. GPT-5.6 no necesita un interruptor de apagado en el mismo sentido: gpt-5.6-luna consume cero tokens de razonamiento en búsquedas y extracciones simples por defecto (el patrón de dos palancas de esa familia), y reasoning_effort: "none" fija ese comportamiento también para entradas con forma matemática.

¿Cuánta precisión se pierde al desactivar el razonamiento?

En una cadena aritmética de 5 pasos, toda: ocho modelos pasaron de 3/3 a 0/3 o 1/3 en cuanto se desactivó el razonamiento. En un problema verbal de 2 saltos, la caída fue mucho menor: la mayoría mantuvo 3/3 sin razonamiento. Solo Kimi y MiniMax bajaron a 0/3, el mismo estado frágil sin razonamiento que detectó el estudio de K3 en la versión de lanzamiento. El desplome aparece cuando el número de pasos supera lo que el modelo puede resolver en una única pasada visible.

Los tres modelos que conservaron la precisión recurrieron al mismo método: con el razonamiento desactivado, escribieron los pasos intermedios en la respuesta visible. La mediana de DeepSeek V4 Pro pasó de 115 a 142 tokens; la de Sonnet 5, de 70 a 139. Se deja de pagar por razonamiento oculto y se empieza a pagar por razonamiento visible, que en la mayoría de tarifas se cobra al mismo precio de salida. El interruptor para desactivarlo cambia la etiqueta del gasto más de lo que lo elimina. Los modelos que, al apagarlo, responden con solo 1-4 tokens son los que pierden precisión de forma drástica.

Cuando se produce esa caída, un presupuesto pequeño basta para recuperar la precisión: thinking_budget: 256 devolvió el 3/3 a Qwen y a las dos variantes de DeepSeek, con una mediana de 77-128 tokens de razonamiento. Es el mismo patrón de recuperación con un límite bajo que medimos en el reentrenamiento de DeepSeek y en los límites ocultos de Qwen 3.8.

Una celda de la matriz no produjo ningún dato: claude-fable-5 devolvió stop_reason: "refusal" (categoría cyber) en 12 de 12 ejecuciones con nuestra formulación aritmética exacta y en todos los niveles de esfuerzo, mientras que una reformulación con el mismo significado pasó en 12 de 12. Anthropic documenta el rechazo como un motivo de parada específico y ofrece un mecanismo de fallback opcional. Si incluyes modelos de la clase fable en tu rotación, gestiona ese motivo de parada antes de que aparezca en producción.

¿Qué aportan realmente los niveles de esfuerzo?

Cada proveedor presenta una curva distinta y solo la de Google aumenta de forma sostenida. Ejecutamos el enum completo aceptado por cada modelo sobre la misma tarea de 5 pasos, con tres ejecuciones por posición, y representamos las medianas en una única escala:

Las líneas se agrupan en cuatro perfiles. Controles reales: las dos variantes de Gemini aumentan de forma monotónica, de 137 a 390 tokens de razonamiento en flash y de 180 a 387 en pro —donde se estabiliza en high—. El nivel low mantuvo una precisión de 3/3 consumiendo entre un tercio y la mitad de los tokens de las posiciones superiores, por lo que conviene fijarlo como valor predeterminado en pipelines con Gemini. Líneas planas: DeepSeek (78 en low y 54 en max, con tendencia descendente), Kimi (94 en minimal y 67 en max) y MiniMax (61-93 sin un orden claro) exponen un control con varias posiciones que no cambian nada. La propia ficha de DeepSeek publica benchmarks con «max reasoning effort», un ajuste que ya comprobamos que no se distingue del predeterminado. Límites que no llegan a aplicarse: los niveles de Qwen son topes de presupuesto que no se alcanzan en una tarea de este tamaño (85-156, sin tendencia) y solo tienen efecto en trabajos complejos, como medimos por separado. No monotónico: el nivel high de GLM consumió 116 tokens, frente a los 184 de low y los 345 de max. Hasta que ese mapeo se estabilice, conviene tratar las posiciones intermedias como valores sin ordenar. Los dos modelos adaptativos apenas necesitan el control: gpt-5.6-luna se mueve entre 32 y 41 tokens en todo el enum, y output_config.effort de Opus 5 solo alteró la salida visible dentro del margen de ruido (54-63 tokens; Sonnet 5 se comportó igual, con 71-92). El razonamiento adaptativo toma la decisión real.

La regla operativa se desprende de estos perfiles: en Gemini hay que elegir el nivel de forma deliberada, porque cada paso cuesta dinero. En Qwen, GLM y DeepSeek conviene usar thinking_budget —que sí es exacto— y el interruptor de apagado, no el enum. En los demás modelos, el enum es decorativo entre «desactivado» y «predeterminado». La única forma de saber qué comportamiento ofrece cada modelo es ejecutar la prueba anterior: misma tarea, todas las posiciones y lectura del contador.

La forma de la tarea también importa: en nuestra extracción de JSON de un solo paso, el razonamiento activado produjo los consumos más altos de toda la matriz —377 tokens de razonamiento en GLM y 332 en Gemini flash— sin aportar nada. Los 12 modelos que permiten desactivarlo obtuvieron 3/3 en esa tarea con el razonamiento apagado. La extracción estructurada paga el mayor coste inútil de razonamiento y, al mismo tiempo, es precisamente la carga donde resulta seguro desactivarlo.

¿Puedes ver aquello por lo que pagas?

El contador de facturación es universal; el razonamiento no es visible en todos los modelos. Seis modelos de familias con pesos abiertos devuelven el texto de razonamiento en reasoning_content: GLM 5.2 y DeepSeek V4 Pro devolvieron lo que parece ser la cadena completa (508 y 312 caracteres para 167 y 100 tokens de razonamiento), mientras que Kimi, Qwen, DeepSeek Flash, MiniMax y Seed devolvieron trazas más cortas, acordes con su bajo consumo. GPT-5.6 y las dos variantes de Gemini no devuelven nada: los tokens de razonamiento se facturan, pero permanecen ocultos. Claude devuelve bloques thinking cuyo contenido se omite por defecto en la interfaz que medimos. Se puede saber que hubo razonamiento, pero no ver su contenido.

Esta diferencia de visibilidad afecta al diagnóstico de los presupuestos: en los modelos que no devuelven nada, reasoning_tokens dentro de los detalles de uso es el único dato disponible. La regla sigue siendo la misma: confía en el contador, no en el 200.

Preguntas frecuentes

¿Cómo desactivo el razonamiento en una API compatible con OpenAI?

Envía thinking: {"type": "disabled"}; en nuestra matriz de 13 modelos, esto redujo a cero el razonamiento en 11 (Kimi, Qwen, DeepSeek x2, GLM, Gemini flash, MiniMax, Seed y la familia Claude). Gemini pro no se puede desactivar y devuelve un 400; GPT-5.6 rechaza el campo, pero apenas razona en tareas simples de forma predeterminada. Verifica leyendo reasoning_tokens en la siguiente respuesta.

¿thinking_budget: 0 desactiva el razonamiento?

Depende del modelo. En Gemini flash y ByteDance Seed, 0 se comporta como una desactivación limpia; Qwen y DeepSeek rechazan 0 con un 400; Kimi y MiniMax aceptan cualquier presupuesto y lo ignoran. Donde los presupuestos se aplican al token (Qwen, GLM, DeepSeek), el valor mínimo útil es un número positivo pequeño: 256 mantuvo 3/3 en Qwen y ambas versiones de DeepSeek en nuestra tarea de 5 pasos, mientras que GLM vaciló a 2/3 con el mismo ajuste.

¿Es seguro desactivar el razonamiento para extraer JSON?

En nuestras pruebas, sí: la extracción de un solo paso obtuvo 3/3 con el razonamiento desactivado en todos los modelos que permiten apagarlo, mientras que mantenerlo activo consumió hasta 377 tokens de razonamiento para producir la misma salida. El límite depende del número de pasos, no del formato de salida: las tareas de varios pasos perdieron precisión sin razonamiento en 8 de 11 modelos. Hay una salvedad de nuestro estudio de DeepSeek: en el reentrenamiento 0731, activar el razonamiento corrompía los valores de JSON estricto, por lo que desactivarlo también corrige el resultado.

¿Qué modelos aplican los presupuestos de razonamiento de forma exacta?

Qwen 3.8 Max, GLM 5.2 y ambas compilaciones de DeepSeek V4: se solicitan 16, el medidor marca 16. Kimi K3 y MiniMax aceptan el mismo campo y lo ignoran; Gemini lo traduce de forma imprecisa (los valores pequeños actúan como desactivado en flash, pro establece un mínimo alto); GPT-5.6 y los modelos de la generación Claude 5 rechazan directamente los presupuestos numéricos (el budget_tokens de Claude devuelve un 400 que apunta al razonamiento adaptativo).

Medido entre el 2026-08-11/12 a través de la pasarela Synthorai: sondas de aceptación para reasoning_effort (7 valores), thinking_budget (0/16/1024), enable_thinking y thinking:{"type":"disabled"} en 13 modelos, re-verificadas horas antes de la publicación; luego una matriz fiscal de 552 llamadas (cuatro formas de tarea con sal x 3 ejecuciones por brazo, brazos limitados a los controles verificados como funcionales de cada modelo), una escalera de enumeración completa de 183 llamadas en la tarea de 5 pasos (los datos del gráfico), celdas de recarga y una sonda de visibilidad de razonamiento por modelo. Precisión calificada a partir de respuestas en bruto; medianas de tokens de n=3; tokens de razonamiento leídos desde completion_tokens_details.reasoning_tokens (los modelos Claude reportan solo tokens de salida). Prompts con sal por llamada. La semántica de los diales y las enumeraciones son la superficie que medimos en esta fecha y pueden cambiar; vuelve a sondear antes de confiar en cualquier celda individual.

← Volver al blog