Pedirle a Claude que razone en voz alta ya puede provocar un rechazo en los modelos más recientes: qué usar en su lugar

Una instrucción de manual que ahora puede salir rechazada

Durante años, una de las primeras recetas de cualquier curso de prompting fue pedirle al modelo que pensara en voz alta: «razona paso a paso dentro de unas etiquetas de pensamiento y después da la respuesta final». Funcionaba, era fácil de extraer con un análisis de texto y daba una sensación de control. En los modelos más recientes de Anthropic esa receta tiene un problema documentado: una petición que empuja al modelo a reproducir su razonamiento interno en el texto de la respuesta puede ser rechazada. No llega como un error de solicitud, sino como una respuesta normal cuyo campo stop_reason vale «refusal» y cuyo detalle de parada, stop_details, indica la categoría: reasoning_extraction.

Qué dice exactamente la documentación

La página de rechazos de Anthropic define la categoría como una petición que pide al modelo reproducir su razonamiento interno en la respuesta, y explica que suele proceder de un prompt que le pide volcar su pensamiento, literalmente o en un formato fijo. Los dos patrones que menciona son muy reconocibles. El primero es una sección de pensamiento, de razonamiento o de borrador que el modelo rellena antes de responder. El segundo es un campo llamado razonamiento, pensamiento o traza dentro de una salida JSON o de la entrada de una herramienta. La advertencia no se limita al mensaje de usuario: las guías de prompting de Claude Fable 5, Fable 5.1, Opus 5.5 y Sonnet 5.5 señalan que también pueden provocar el rechazo los prompts de sistema, las skills y las descripciones de herramientas que contengan esa clase de instrucción. La página general de buenas prácticas añade la consecuencia práctica: en esos modelos, para razonar paso a paso hay que apoyarse en el pensamiento nativo, con un nivel de esfuerzo más bajo si importan el coste o la latencia.

Las tres reescrituras que sí funcionan

La sustitución que propone Anthropic tiene dos vías: pedir una explicación breve de la respuesta o un resumen de las acciones realizadas, o leer el razonamiento desde los bloques de pensamiento en formato resumido. Aplicado a los tres patrones más habituales, el cambio queda así.

Primer caso, el clásico paso a paso en etiquetas. Un prompt del tipo «piensa dentro de las etiquetas <thinking> y responde dentro de <answer>» debe desaparecer. En su lugar, no se pide nada especial: el pensamiento ya forma parte del modelo, se controla con el parámetro de esfuerzo y, si hace falta verlo, se activa la visualización resumida. En código, la solicitud queda más limpia que antes:

client.messages.create(
    model="claude-sonnet-5-5",
    max_tokens=16000,
    thinking={"type": "adaptive", "display": "summarized"},
    output_config={"effort": "medium"},
    messages=[{"role": "user", "content": "..."}],
)

La respuesta llegará con bloques de pensamiento resumidos que se leen por su tipo, no por su posición, y con el texto final aparte. Segundo caso, el campo de razonamiento en un JSON. Si el esquema pedía una clave «reasoning» con la cadena de pensamiento completa, hay que sustituirla por algo que describa una justificación breve de la respuesta, por ejemplo una clave «justificacion» con una o dos frases sobre por qué se ha elegido esa categoría. Es la diferencia entre transcribir el proceso y explicar el resultado, y es justo la que la documentación admite explícitamente. Tercer caso, las skills y los archivos de instrucciones de agentes que dicen cosas como «reflexiona en voz alta sobre cada paso»: conviene sustituirlas por «al terminar, resume las acciones realizadas y el resultado», que es el otro formato que la documentación permite.

Matices que conviene tener presentes antes de tocar nada

El primero es operativo: el rechazo hay que gestionarlo en el código. Comprobar el stop_reason de cada respuesta y, cuando valga «refusal», leer la categoría deja de ser opcional. Y no basta con confiar en la red de seguridad: la documentación aclara que la reintentación automática en un modelo alternativo, la función de fallback del lado del servidor, no reintenta los rechazos de tipo reasoning_extraction; los devuelve tal cual a la aplicación. En Sonnet 5.5, por ejemplo, el fallback en beta cubre únicamente determinadas categorías, como las relacionadas con ciberseguridad y modelos de lenguaje de frontera, y deja fuera las de biología, daños generales y esta misma. Si el flujo depende de que la respuesta llegue siempre, la corrección del prompt es la única solución.

El segundo matiz es de alcance. Las guías hablan de los modelos más recientes, no de todo el catálogo: los modelos anteriores siguen aceptando el razonamiento escrito a mano, y la propia página de buenas prácticas conserva esa técnica, con la respuesta final en etiquetas para poder extraerla, como alternativa para modelos con el pensamiento desactivado. Antes de borrar instrucciones en un sistema que usa varios modelos, conviene separar qué prompts se envían a cuáles. El tercero es de expectativas: el pensamiento resumido es, como dice su nombre, un resumen; sirve para entender el camino general de una respuesta, no para auditar cada paso con exactitud, así que no debería usarse como una transcripción literal del razonamiento en un proceso que exija trazabilidad estricta.

Por qué importa hoy

Con la cantidad de tutoriales, plantillas de prompts y skills de terceros que siguen incluyendo una instrucción de «piensa en voz alta», esta es una de esas migraciones silenciosas que se descubren en producción, cuando un porcentaje de respuestas llega vacío y con un motivo de rechazo. La revisión que merece la pena hacer hoy es una búsqueda de texto en los prompts de sistema, las skills, los archivos de instrucciones de proyecto y las descripciones de herramientas por expresiones como razona, piensa en voz alta, scratchpad o campos llamados reasoning y trace, y probar cada uno contra el modelo nuevo mientras se registra el motivo de cualquier rechazo.