¿Qué pasa cuando «piensa»?
Por defecto el modelo empieza a escribir la respuesta de inmediato. En modo reasoning primero se razona algo para sí: descompone la tarea, examina opciones, comprueba resultados intermedios — y solo entonces escribe la respuesta. Ese razonamiento normalmente no se ve, solo su resultado.
No es otro modelo ni una inteligencia superior. Es el mismo modelo dando más pasos. El principio se conoce desde hace tiempo: si le pides que piense paso a paso, responde con más precisión a tareas complejas. El reasoning mode incorpora eso al sistema, de forma automática.
El cambio importante: hoy esto es un mando
Hace un año o dos esto era una categoría de producto: existían modelos «pensadores» aparte, con nombre propio. Ya no. En la mayoría de los modelos actuales es un ajuste — los proveedores lo llaman esfuerzo, pensamiento extendido o presupuesto de razonamiento, pero todos regulan lo mismo: cuánto trabajar antes de responder.
Si lees en algún sitio que «los modelos de razonamiento son mejores que los convencionales», ese texto está desfasado.
¿Qué pagas por ello?
Aquí es donde se rompen la mayoría de las estimaciones de coste.
Los pasos de pensamiento cuentan como tokens de salida. No los ves, pero están en la factura — y los tokens de salida son los caros. En una pregunta difícil, el razonamiento invisible puede ser tranquilamente diez veces más largo que la respuesta.
Así es como dos modelos con precios de lista parecidos acaban con costes reales separados por un orden de magnitud. Solo hay una forma sensata de comparar: ejecuta las mismas veinte tareas reales en ambos y mira el total. Una tabla de precios por token no te lo va a decir.
El otro precio es el tiempo. Con esfuerzo alto la respuesta no tarda segundos, sino diez y pico segundos, a veces minutos. En una interfaz conversacional se aguanta. En un chat de atención al cliente, no.
¿Cuándo subirlo?
Compensa subirlo cuando la tarea tiene varios pasos que se apoyan unos en otros:
- matemáticas, cálculo, conversión de unidades
- localizar un error de programación donde hay que encontrar la causa, no el síntoma
- analizar un texto jurídico o contractual con condiciones y excepciones
- preparar una decisión que pondera varios criterios
- cualquier cosa donde una respuesta equivocada cueste más que la espera
¿Cuándo no?
Compensa dejarlo bajo cuando la tarea es de un solo paso o formal:
- resumir, reformular, traducir
- clasificar, etiquetar, extraer datos
- redactar un correo, escribir una descripción de producto
- cualquier cosa que corra muchas veces al día
En estas, el esfuerzo alto no mejora el resultado — solo añade coste y espera. Un resumen no queda mejor resumido porque el modelo le haya dado vueltas antes.
Dos cosas que no resuelve
No elimina la alucinación. Sin apoyos, pensar más rato produce un error mejor construido y más convincente. Eso no lo hace cierto. Darle el material ayuda más que cualquier nivel de esfuerzo — véase Por qué la IA se inventa cosas.
No arregla un prompt malo. Si a la instrucción le falta la información que haría inequívoca la tarea, el modelo se limitará a dar más vueltas al mismo hueco. Una pregunta más precisa vale más que un mando subido.
Una prueba que cuesta cinco minutos
Elige una tarea típica de tu trabajo. Ejecútala con esfuerzo bajo y con esfuerzo alto, con el mismo prompt.
Hay tres desenlaces posibles:
- El alto es claramente mejor → la tarea es compleja, déjalo subido.
- No hay diferencia apreciable → a partir de ahora en bajo. Es el caso más frecuente.
- El alto es peor → también pasa: el modelo le da demasiadas vueltas a una tarea simple y explica cosas que no le pediste.
Esta prueba de cinco minutos es lo más rentable que puedes hacer con una herramienta de IA.
Qué llevarte
El reasoning mode no es un «modo más listo», es más trabajo invertido por el mismo modelo. Súbelo para tareas complejas y poco frecuentes. Déjalo bajo para tareas simples y frecuentes — ahí solo engorda la factura.