Extended thinking no siempre mejora la respuesta — en tareas simples solo añade latencia y costo. La habilidad real está en saber cuándo activarlo y con cuánta profundidad.
Extended thinking permite que Claude genere una cadena de razonamiento interno — bloques de tipo `thinking` — antes de producir la respuesta final visible. En los modelos actuales (familia Opus 4.6 en adelante, Sonnet 5) el modo recomendado es razonamiento adaptativo (`thinking: {type: "adaptive"}`), donde el propio modelo decide cuánto y cuándo razonar según la complejidad detectada en la tarea, en vez de que el desarrollador fije un presupuesto de tokens de razonamiento por adelantado.
El parámetro complementario es `effort`, dentro de `output_config`, con niveles de bajo a máximo (incluyendo `xhigh` en los modelos más recientes). Controla la profundidad de razonamiento y el gasto total de tokens; combinado con razonamiento adaptativo da el mejor balance costo-calidad para la mayoría de los casos.
Un detalle importante: por defecto, el campo `thinking` de estos bloques viene vacío (`display: "omitted"`) — si tu producto necesita mostrar el razonamiento al usuario (por ejemplo, para transparencia en una herramienta de análisis financiero), hay que fijar explícitamente `display: "summarized"`.
La pregunta que hay que hacerse no es "¿es esta tarea difícil?" en abstracto, sino "¿el error más probable viene de razonamiento insuficiente o de falta de información?". Extended thinking ayuda cuando la tarea requiere múltiples pasos de lógica encadenada donde un error temprano se propaga — depuración de un bug con causa no obvia, planificación de una migración con dependencias cruzadas, resolución de problemas matemáticos o algorítmicos, o la fase de planificación de un agente que debe decidir una secuencia de acciones de herramientas.
No ayuda, y de hecho puede ser contraproducente en latencia, en tareas de clasificación simple, extracción estructurada de datos con formato claro, generación de contenido de bajo riesgo, o cualquier tarea donde la respuesta correcta no depende de encadenar varios pasos de lógica sino de aplicar un patrón directo.
Es tentador tratar `effort: "max"` como la opción segura por defecto, pero en la práctica el nivel `high` es frecuentemente el punto óptimo: niveles más altos pueden mostrar retornos decrecientes y, en algunos casos, sobre-analizar problemas que no lo requieren. La recomendación operativa es empezar en `high` como línea base, medir en tu propio conjunto de evaluación, y ajustar por ruta: `xhigh` para las tareas más exigentes de codificación y trabajo agéntico, `medium` cuando el costo es una restricción real, y `low` para subagentes o pasos rutinarios dentro de un flujo mayor.
Un patrón frecuente en producción es variar el effort según el tipo de subtarea dentro de un mismo agente: la fase de planificación inicial con `effort: "high"`, y los pasos de ejecución rutinarios delegados a subagentes con `effort: "low"` — esto reduce el gasto total sin sacrificar calidad en el paso que realmente la necesita.
Para flujos agénticos de larga duración (muchas llamadas de herramienta encadenadas), existe además el concepto de "task budget" — un techo de tokens del que el modelo es consciente durante toda la ejecución, distinto de `max_tokens` (que es un límite duro por respuesta del que el modelo no tiene noción). Con un task budget, el modelo ve una cuenta regresiva y prioriza el trabajo para terminar de forma ordenada en vez de quedarse a mitad de tarea cuando se agota el presupuesto.
Esto es particularmente útil en agentes autónomos de larga duración donde quieres acotar el gasto sin necesariamente saber de antemano cuántos pasos tomará resolver la tarea.
Como con cualquier parámetro que afecta costo y latencia, la validación empírica sobre tu propio conjunto de casos vale más que la intuición. La práctica recomendada es correr un barrido de niveles de effort (bajo, medio, alto) sobre una muestra representativa de tus consultas reales, y elegir el nivel según la relación calidad-latencia-costo observada para tu dominio específico — no según lo que funcionó bien en un caso de uso distinto. Para tareas donde la latencia es crítica y visible al usuario (chat interactivo), esta medición debe incluir el tiempo real percibido, no solo el conteo de tokens, porque el razonamiento adaptativo puede añadir varios segundos de espera antes del primer token de respuesta visible si no se configura streaming con resumen de pensamiento.
Carlos Montiel es arquitecto de soluciones IA empresarial. Implementa LLMs, Agentes, RAG y orquestadores en empresas de Guatemala y Latinoamérica. Contáctalo para una consultoría.
Contactar a Carlos Montiel