Dirigir el pensamiento

El pensamiento de Claude es adaptativo: el modelo evalúa cada solicitud y decide por sí mismo si pensar y cuánto. Tú estableces una intención, opcionalmente especificas el esfuerzo, y el modelo asigna razonamiento donde juzga que el razonamiento ayudará.

Esto hace que el pensamiento sea una excelente opción para cargas de trabajo que mezclan solicitudes triviales y complejas, y para flujos de trabajo agénticos de largo horizonte donde la cantidad adecuada de razonamiento varía de un paso a otro.

Para saber cómo activar el pensamiento, cómo leer la salida del pensamiento y la salida del pensamiento en Claude Fable 5 y Claude Mythos 5, consulta la descripción general de Pensamiento. Esta página cubre cómo Claude decide cuándo pensar, cómo dirigir esa decisión, y la mecánica de almacenamiento en caché, costo y precios que se deriva de ello.



Cómo decide Claude cuándo pensar

El pensamiento es opcional para el modelo. En cada solicitud, Claude sopesa la complejidad de la entrada y decide si un razonamiento más profundo mejoraría la respuesta. Una pregunta factual simple puede recibir una respuesta directa sin ningún bloque de pensamiento; un problema matemático de varios pasos o una tarea de depuración complicada desencadena un razonamiento más profundo.

La decisión ocurre por solicitud. La misma conversación puede contener turnos con y sin pensamiento, y un turno en el que Claude eligió no pensar no contiene ningún bloque de pensamiento. No construyas lógica de aplicación que asuma que cada turno del asistente comienza con uno.

El control principal sobre esta decisión es el parámetro effort, que actúa como guía suave sobre qué tan dispuesto debe estar Claude a pensar y con qué profundidad; consulta Niveles de esfuerzo en esta página para saber qué hace cada nivel.

Si quieres que Claude piense con menos frecuencia, baja el nivel de esfuerzo antes de recurrir a la dirección basada en prompts.

El pensamiento también se intercala automáticamente con el uso de herramientas: Claude puede pensar entre llamadas a herramientas, reflexionando sobre cada resultado de herramienta antes de decidir qué hacer a continuación (pensamiento intercalado). No necesitas un encabezado beta ni ninguna configuración adicional para esto.

Para obtener una visión completa de cómo interactúan la configuración de pensamiento y el parámetro effort, consulta Pensamiento y esfuerzo.



Dirigir con qué frecuencia piensa Claude

Que Claude piense en un turno determinado es algo que se puede controlar mediante prompts. El esfuerzo establece la postura general, pero también puedes moldear la decisión directamente con guía en lenguaje natural, ya sea globalmente en la indicación del sistema o por mensaje desde el turno del usuario.

Usa las dos palancas juntas en este orden:

1. Establece el nivel de esfuerzo que coincida con el equilibrio predeterminado de calidad y latencia de tu carga de trabajo.
2. Agrega guía en el prompt solo si la activación de Claude aún no coincide con tus necesidades en ese nivel.

Para obtener una guía más amplia sobre prompts con pensamiento, consulta aprovechar las capacidades de pensamiento y pensamiento intercalado.



Niveles de esfuerzo

El esfuerzo es la palanca de dirección principal para el pensamiento. Cada nivel establece un valor predeterminado diferente para la frecuencia con la que Claude piensa y con qué profundidad:

Esta tabla describe cómo cada nivel cambia el comportamiento de pensamiento. Para obtener orientación sobre qué nivel elegir para una carga de trabajo determinada, incluidas recomendaciones por modelo, consulta Cuándo ajustar el parámetro effort en la página de effort.

El esfuerzo se establece en output_config.effort, no dentro del objeto thinking; para ver ejemplos completos por lenguaje, consulta Effort.

{
  "model": "claude-opus-4-8",
  "max_tokens": 4096,
  "output_config": { "effort": "medium" },
  "messages": [{ "role": "user", "content": "..." }]
}

La disponibilidad de niveles varía según el modelo; la tabla de disponibilidad de effort en la página de effort es la autoridad sobre qué niveles admite cada modelo.



Guía en la indicación del sistema

La guía en la indicación del sistema desplaza el umbral de pensamiento de Claude para cada solicitud en la conversación. Si Claude está pensando con más frecuencia de la que tu carga de trabajo necesita, agrega una guía como esta a tu indicación del sistema:

Extended thinking adds latency and should only be used when it
will meaningfully improve answer quality, typically for problems
that require multistep reasoning. When in doubt, respond directly.

Para fomentar el pensamiento en su lugar, usa una frase como:

This task involves multistep reasoning. Think carefully before responding.

La efectividad de la dirección puede ser sensible a la redacción exacta. Si una formulación no produce el comportamiento que deseas, prueba una variante más directa.



Dirección por mensaje

También puedes dirigir el pensamiento mensaje por mensaje desde el turno del usuario, independientemente de la indicación del sistema. Agregar "Please think hard before responding." a un mensaje de usuario anima a Claude a pensar en ese turno; "Answer directly without deliberating." lo suprime.

La dirección por mensaje es útil cuando solo algunas solicitudes en una conversación justifican un razonamiento extendido. Un arnés de agente, por ejemplo, puede agregar la frase de fomento en los pasos de planificación y la frase de supresión en las confirmaciones rutinarias, sin tocar la indicación del sistema ni cambiar ningún parámetro de solicitud entre turnos.



Verifica la dirección en tu carga de trabajo

La dirección basada en prompts cambia el comportamiento del modelo, así que trátala como cualquier otro cambio de prompt: mide antes de lanzar. Ejecuta una muestra representativa de tu tráfico con y sin la guía, y compara con qué frecuencia se activa el pensamiento (la presencia de bloques de pensamiento en las respuestas), el uso de tokens de salida, la latencia y la calidad de las respuestas en los casos que te importan.



Mecánica

Tres mecánicas se derivan de que Claude gestione su propio pensamiento: la validación de turnos, el almacenamiento en caché de prompts y cómo acotas el costo.



Validación de turnos

Los turnos del asistente no necesitan comenzar con un bloque de pensamiento. (Los modelos que usan un presupuesto de pensamiento manual heredado exigen que el turno final del asistente de una solicitud con pensamiento habilitado comience con uno; consulta Estructura de turnos en modo manual.)

Para aplicaciones de múltiples turnos, esto significa que puedes devolver el historial de conversación en la forma en que lo tengas:

• Los turnos del asistente donde Claude eligió no pensar son historial válido tal cual.
• Puedes reanudar una conversación que comenzó sin pensamiento, o que usó una configuración de pensamiento diferente, sin reescribir su historial.
• El historial ensamblado a partir de fuentes mixtas no necesita que se reinserten bloques de pensamiento al inicio de cada turno del asistente para pasar la validación.

La relajación se refiere a la validación, no a lo que deberías enviar. Cuando tengas bloques de pensamiento, devuélvelos sin modificar, particularmente durante el uso de herramientas, donde llevan el razonamiento detrás de las llamadas a herramientas de Claude. Consulta la descripción general de Pensamiento para ver las reglas completas.



Almacenamiento en caché de prompts

Las solicitudes consecutivas que mantienen la misma configuración de pensamiento y nivel de esfuerzo preservan el almacenamiento en caché de prompts; consulta Pensamiento y almacenamiento en caché de prompts para ver las reglas completas. El valor de effort resuelto se renderiza en el prompt, por lo que cambiarlo entre solicitudes invalida los puntos de interrupción de caché, al igual que lo hace cambiar el parámetro heredado budget_tokens en los modelos que lo usan. Establecer effort explícitamente en el valor predeterminado del modelo es equivalente a omitirlo y no rompe la caché.

La consecuencia práctica: elige una configuración de pensamiento y un nivel de esfuerzo por conversación y mantenlos. Si algunos turnos necesitan más o menos pensamiento, dirige con prompts por mensaje: la guía agregada al mensaje de usuario más reciente deja intactos los puntos de interrupción de caché anteriores, mientras que un cambio de configuración o de esfuerzo no lo hace.

El siguiente ejemplo demuestra la invalidación con un script de múltiples turnos que puedes ejecutar tú mismo:



Control de costos

No estableces un presupuesto de tokens de pensamiento. Dos controles acotan el costo:

• max_tokens es un límite estricto sobre la salida total de la solicitud, pensamiento y texto de respuesta combinados. Claude nunca genera más allá de él. En un bucle de uso de herramientas, cada solicitud del turno tiene su propio max_tokens, por lo que no acota el gasto de todo el turno.
• effort es una guía suave sobre cuánto de esa salida Claude asigna al pensamiento. Moldea el comportamiento pero no garantiza un recuento de tokens.

Debido a que el pensamiento cuenta para max_tokens, establécelo lo suficientemente alto como para dejar espacio tanto para el razonamiento como para la respuesta. Un max_tokens dimensionado para una respuesta sin pensamiento suele ser demasiado pequeño una vez que Claude comienza a pensar en solicitudes difíciles.

Con esfuerzo high y superior, Claude puede pensar extensamente y es más probable que agote el presupuesto. Si ves stop_reason: "max_tokens" en las respuestas, tienes dos remedios:

• Aumenta max_tokens para darle al modelo más espacio para el pensamiento más la respuesta.
• Baja el nivel de esfuerzo para que Claude piense menos y deje más del presupuesto para el texto de respuesta.

Cuál es el correcto depende de si las respuestas truncadas necesitaban el razonamiento. Si la calidad en esas solicitudes importa, aumenta el límite; si se pensaron en exceso, baja el esfuerzo.



Precios

El pensamiento genera cargos por:

• Los tokens que Claude usa mientras piensa (facturados como tokens de salida)
• Los bloques de pensamiento de turnos anteriores del asistente que permanecen en el contexto, según el valor predeterminado de preservación: todos los turnos de forma predeterminada en los modelos que conservan todo, solo el último turno en los demás (facturados como tokens de entrada)
• Tokens de salida de texto estándar

Lo que se te factura es lo mismo independientemente de la configuración de display; solo cambia lo que ves:

Para ver cuántos tokens de salida facturados se gastaron en razonamiento interno, lee usage.output_tokens_details.thinking_tokens en la respuesta. Este valor refleja el razonamiento sin procesar que generó el modelo (no el texto resumido devuelto en el cuerpo) y siempre es menor o igual que output_tokens. Réstalo de output_tokens para aproximar la porción de la salida que no es razonamiento. Al hacer streaming, este desglose aparece solo en el evento message_delta final.

{
  "usage": {
    "input_tokens": 25,
    "output_tokens": 348,
    "output_tokens_details": {
      "thinking_tokens": 312
    }
  }
}

output_tokens sigue siendo el total inclusivo y autoritativo utilizado para la facturación. output_tokens_details es un desglose de solo lectura para observabilidad. Para obtener información completa de precios, incluidas las tarifas base, las escrituras en caché, los aciertos de caché y los tokens de salida, consulta Precios.



Próximos pasos