Entender el reasoning y el extended thinking

En la lección 1 aprendiste chain of thought. Escribes "piensa paso a paso" en el prompt y el modelo enseña sus pasos intermedios. Durante años eso fue un truco que tenías que disparar tú. Hoy muchos modelos lo hacen por su cuenta, y además en un modo propio que tú como desarrollador enciendes y apagas. Se llama extended thinking, o en algunos proveedores sencillamente reasoning. Me llama la atención que mucha gente no conoce la diferencia entre "le pido al modelo que piense" y "activo un modo de reasoning de verdad". De eso va justamente esto.

El núcleo es simple. Un modelo normal lee tu prompt y produce de inmediato la respuesta token a token. Un modelo con extended thinking hace antes una ronda intermedia. Primero genera un bloque de pensamientos, ordena el problema, descarta callejones sin salida, y después escribe la respuesta propiamente dicha. Esos pensamientos son tokens de verdad, cuestan dinero, y según el modelo los ves resumidos o no los ves. El efecto es medible en todo lo que necesita varios pasos: matemáticas, depuración de código, cadenas lógicas, planes con dependencias.

¿Cuándo compensa? Regla práctica: cuando la tarea tiene una respuesta correcta y muchas incorrectas y el camino hasta ella no es evidente. Un caso límite fiscal con tres condiciones. Una consulta SQL que hace join sobre cuatro tablas. Un bug que solo aparece bajo cierta condición de carrera. Ahí el reasoning aporta precisión real. ¿Cuándo no compensa? Resúmenes de texto, reformulaciones, clasificación sencilla, ajuste de tono. Ahí el modelo se pone a pensar sobre algo que no tiene una solución dura, y pagas por tokens que no mejoran nada.

El parámetro que pones de verdad

En la Messages API de Anthropic esto lo controlas con un campo llamado thinking. Con modelos antiguos como Sonnet 4.5 u Opus 4.5 se ve así:

{
  "model": "claude-sonnet-4-5",
  "max_tokens": 4096,
  "thinking": {
    "type": "enabled",
    "budget_tokens": 8000
  },
  "messages": [
    { "role": "user", "content": "Resuelve este puzle logico..." }
  ]
}

El budget_tokens es el techo del bloque de pensamiento. Un punto interesante: ese valor puede ser mayor que max_tokens, porque el pensamiento y la respuesta son presupuestos separados. Pensar 8000 tokens y después responder con 4096 es un montaje perfectamente legítimo.

Con los modelos nuevos esto cambió, y ese es el punto en el que la mayoría de los tutoriales antiguos se equivocan. Opus 4.6 y Sonnet 4.6 ya no usan budget_tokens. Ahí thinking.type: "enabled" con presupuesto fijo está deprecado. En su lugar pones thinking.type: "adaptive" y controlas la profundidad con un parámetro effort. El modelo decide entonces por su cuenta cuánto piensa, según la dificultad de la tarea. En Opus 4.7 y Opus 4.8 ese es incluso el único camino, ahí ya no se acepta el budget_tokens manual.

{
  "model": "claude-opus-4-8",
  "max_tokens": 4096,
  "thinking": { "type": "adaptive" },
  "messages": [
    { "role": "user", "content": "Planifica una migracion..." }
  ]
}

¿Por qué este cambio? Un presupuesto fijo de tokens es siempre un compromiso. Si lo pones demasiado bajo, el modelo piensa poco en las tareas duras. Si lo pones demasiado alto, quemas dinero en las fáciles. El thinking adaptativo lo resuelve acoplando la profundidad a la tarea. Tú solo marcas la dirección a grandes rasgos, con effort. Más effort significa que el modelo puede pensar más si lo considera necesario.

Desde Opus 5, del 24 de julio de 2026, el camino ha dado un paso más: ahí el thinking es el valor por defecto, ya no tienes que poner nada. Una petición sin campo thinking piensa igualmente. Dos consecuencias que conviene conocer. Primera, max_tokens cuenta el pensamiento, es un techo duro para pensamiento y respuesta juntos. Si vienes de un modelo anterior donde esa misma petición corría sin thinking, sube el límite. Segunda, desactivarlo sigue existiendo, pero solo hasta el nivel de effort high. La combinación thinking: {"type": "disabled"} con effort xhigh o max la responde la API con un 400. Los detalles están en el playbook Migración a Opus 5.

Interleaved thinking, cuando hay herramientas de por medio

Hay un caso especial que se vuelve importante en cuanto tu modelo llama herramientas. Normalmente el modelo piensa una vez al principio y luego responde. Con interleaved thinking puede volver a pensar entre llamadas a herramientas. Llama a una herramienta, ve el resultado, piensa sobre él, llama a la siguiente. Ese es justo el comportamiento que quieres para un agente que planifica varios pasos.

Se activa con una cabecera beta:

anthropic-beta: interleaved-thinking-2025-05-14

Aquí también queda claro por qué budget_tokens puede ser mayor que max_tokens. Con interleaved thinking el presupuesto es la suma de todos los bloques de pensamiento dentro de un único turno del asistente, no por bloque. Si tu agente llama cinco herramientas seguidas y antes de cada una piensa un poco, eso se suma.

Un detalle que provoca confusión a menudo: la cabecera anthropic-version: 2023-06-01 sigue siendo correcta también en 2026. Esa es la versión de la API, no una fecha que tenga que ver con el modelo. Que no te despiste, la pones exactamente así, también con Opus 4.8.

Qué haces con esto en el día a día

Tres patrones concretos que veo una y otra vez.

Primero, reasoning solo para las rutas duras. En una aplicación que procesa muchas peticiones distintas, no activas el extended thinking de forma global. Primero clasificas la petición con una llamada barata sin thinking, y solo cuando la tarea se marca como "compleja" la mandas a un modelo con reasoning activado. Eso ahorra a menudo más de la mitad del coste.

Segundo, acoplar el effort al tipo de usuario. Si pregunta un usuario gratuito, effort bajo. Si un usuario de pago hace la misma pregunta, más alto. La calidad escala con lo que te puedes permitir por petición.

Tercero, registrar los pensamientos pero no entregarlos. El bloque de pensamiento es oro para depurar. Cuando el modelo da una respuesta equivocada, en el reasoning ves a menudo justo dónde se desvió. Eso lo guardas en tus logs, pero no se lo enseñas al usuario final. Él quiere la respuesta, no el monólogo.

Un último apunte honesto. El extended thinking no es una varita mágica. Hace a un modelo más preciso en tareas con solución clara, pero no lo hace más creativo ni más honesto. Si el modelo no sabe algo, con reasoning pasa de largo por la respuesta equivocada con la misma seguridad, solo que con más extensión. Las alucinaciones de la lección 2 del nivel 1 no desaparecen por esto. A veces incluso se presentan mejor argumentadas. El reasoning es una herramienta para la precisión, no un sustituto de comprobar la respuesta.

Qué sigue

Ahora entiendes la diferencia entre un prompt de chain of thought y un modo de reasoning de verdad, y conoces el parámetro que pones para eso en la API. La siguiente lección va de system prompts y de cómo diriges el comportamiento de un modelo más allá de una petición suelta. Si quieres profundizar en los modelos actuales, mira en el nivel 1 la lección del panorama de modelos 2026, ahí pone qué modelo soporta qué modo de thinking.

Source

• Documentación de extended thinking: https://platform.claude.com/docs/en/build-with-claude/extended-thinking
• Parámetro effort: https://platform.claude.com/docs/en/build-with-claude/effort
• Guía de migración de los modelos nuevos: https://platform.claude.com/docs/en/about-claude/models/migration-guide