Cómo escribir prompts para Claude Sonnet 5.5

Esta guía cubre los patrones de prompting específicos de Claude Sonnet 5.5. Para los cambios de API del modelo, consulta Novedades de Claude Sonnet 5.5. Para técnicas que se aplican a todos los modelos actuales de Claude, consulta Mejores prácticas de prompting.

Los prompts existentes de Claude Sonnet 5 deberían funcionar bien sin cambios, y los patrones de Cómo escribir prompts para Claude Sonnet 5 siguen siendo un punto de partida razonable. Para el trabajo de largo horizonte más difícil, un modelo Opus es la mejor opción. Empieza por la sección que corresponda a lo que observas:

• No sabes con qué nivel de esfuerzo ejecutar, o los turnos duran más o menos que en Claude Sonnet 5: Calibra el esfuerzo
• El modelo se detiene a consultar antes de terminar una tarea de programación, o hace más de lo que pediste: Orienta la iniciativa y el alcance
• Tu integración se ejecuta hoy con el pensamiento desactivado: Ejecución sin pensamiento previo
• Las respuestas JSON a tareas que requieren algunos pasos de razonamiento son incorrectas o no se pueden analizar: Tareas de razonamiento con salida JSON
• Los turnos agénticos largos parecen silenciosos: Actualizaciones de progreso para el usuario
• El modelo responde a partir de su conocimiento de entrenamiento cuando una búsqueda detectaría detalles que han cambiado: Uso de herramientas en chat y trabajo de conocimiento
• Los mensajes que los usuarios envían a mitad de una tarea se ignoran o se tratan como texto inyectado: Mensajes del usuario a mitad de turno
• Los cambios de código se reportan como terminados sin ejecutar pruebas ni compilación: Verificación en tareas de programación
• El modelo llama a una herramienta con mayúsculas y minúsculas incorrectas o pasa un parámetro con un nombre ligeramente distinto: Manejo tolerante de llamadas a herramientas
• Las respuestas sobre gráficos densos o dibujos técnicos omiten detalles: Herramientas para entradas visuales complejas
• Las solicitudes devuelven stop_reason: "refusal": Rechazos de las salvaguardas

Calibra el esfuerzo

El "effort" (esfuerzo) es el control principal de cuánto piensa Claude Sonnet 5.5 y, con ello, de la calidad, la "latency" (latencia) y el costo. Sus niveles se han recalibrado: un nivel no produce la misma cantidad de pensamiento que el mismo nivel en Claude Sonnet 5. Haz un nuevo barrido con tus propias evaluaciones en lugar de conservar la configuración que usabas en Claude Sonnet 5. Empieza en high, el valor predeterminado en la Claude API, a menos que tu carga de trabajo sea agéntica o sensible a la latencia. Para programación agéntica y uso de herramientas de varios pasos, empieza en medium para tareas bien especificadas y pasa a high para las más difíciles o largas. Para chat y otros trabajos sensibles a la latencia, empieza en medium o low, porque un esfuerzo mayor implica una espera más larga antes de que comience la respuesta. Aumenta el esfuerzo si la calidad lo requiere.

Un esfuerzo menor también cambia la forma en que el modelo termina el trabajo agéntico. En low, mantiene su pensamiento breve y puede omitir la verificación de un cambio. Consulta Verificación en tareas de programación. En low y medium, en tareas agénticas largas, es más probable que se detenga a consultar con el usuario antes de terminar. Consulta Orienta la iniciativa y el alcance.

Tres ajustes ayudan:

• Configura max_tokens con espacio para el pensamiento y la respuesta que esperas. El pensamiento cuenta para max_tokens incluso cuando el contenido del pensamiento no se te devuelve. Un límite dimensionado para una solicitud sin pensamiento puede cortar la respuesta. Para programación agéntica, configura max_tokens en 128,000, el máximo del modelo, y usa streaming para la respuesta.
• Reserva xhigh y max para trabajos en los que hayas medido una mejora de calidad, porque en esos niveles el pensamiento y las respuestas se alargan mucho. En esos niveles no se acepta between_tools, por lo que no se puede desactivar el pensamiento previo.
• Para obtener menos pensamiento, baja el nivel de esfuerzo. A partir de medium, el modelo piensa brevemente antes de casi todas las respuestas, incluso ante un saludo, lo que aumenta el tiempo hasta el primer token visible. Pedirle en la indicación del sistema que piense menos no reduce su pensamiento de forma fiable. En low, omite el pensamiento en la mayoría de las solicitudes simples.

Cambiar el valor de effort de nivel superior entre solicitudes invalida la caché de prompts. Para ejecutar turnos individuales con un nivel distinto, usa en su lugar un cambio de esfuerzo por mensaje (beta), que conserva la caché. Por ejemplo, ejecuta una sesión interactiva en low y sube el esfuerzo a high cuando el usuario plantee un problema difícil. Los cambios de esfuerzo por mensaje requieren "adaptive thinking" (pensamiento adaptativo). Con between_tools, devuelven un error 400, como explica Ejecución sin pensamiento previo.

Orienta la iniciativa y el alcance

Hasta dónde llega Claude Sonnet 5.5 por su cuenta depende del nivel de esfuerzo y de la solicitud. Con un esfuerzo menor, a veces consulta antes de terminar una tarea de programación. Con un esfuerzo mayor, o ante una solicitud abierta, puede hacer más de lo que pediste. Oriéntalo con el nivel de esfuerzo y con instrucciones en tu indicación del sistema.

Llevar el trabajo hasta el final. En tareas de programación agéntica con esfuerzo low y medium, el modelo a veces consulta antes de terminar el trabajo. Puede detenerse para confirmar un plan, hacer una pregunta que podría responder por sí mismo o detenerse tras una parte de una tarea de varias partes para preguntar si debe continuar. Prueba primero un nivel de esfuerzo mayor. Para que el modelo siga trabajando sin cambiar el esfuerzo, agrega esto a tu indicación del sistema:

Keep working until everything the user asked for is done, and only stop to ask when you can't go on without the user or before a risky step.

When the work the user asked for is done and checked, stop and report. Don't add features, tests, files, docs or refactors that weren't asked for. If you think one would help, mention it at the end instead of doing it.

Con este prompt, el modelo lleva a término una mayor parte del trabajo con esfuerzo low y medium, por lo que las sesiones en esos niveles duran más y cuestan más. El prompt no reemplaza tus propias reglas sobre acciones riesgosas o irreversibles. Mantén esas reglas en tu indicación del sistema.

Adiciones no solicitadas al programar. El modelo tiende a agregar pruebas, documentación y pequeños archivos de soporte que se ajustan a las convenciones de tu repositorio, incluso cuando no los pides. Lo hace en todos los niveles de esfuerzo, y más con un esfuerzo mayor. El cambio solicitado en sí se mantiene cerca de lo que se pidió. La mayoría de los equipos lo agradecerán. Si prefieres cambios limitados a lo que se solicitó explícitamente, agrega solo el segundo párrafo de ese prompt, que comienza con "When the work the user asked for is done". Con esfuerzo xhigh y max, ese párrafo reduce estas adiciones y hace que los cambios sean más pequeños en general.

Exhaustividad con esfuerzo xhigh y max. En estos niveles, el modelo es especialmente exhaustivo. Después de terminar una tarea, puede iniciar sus propias rondas de revisión y verificación, a veces con subagentes si tu "harness" (arnés) los proporciona. También puede hacer correcciones relacionadas que haya notado en el camino. Esto requiere más tiempo y tokens, así que ejecuta el trabajo rutinario en high o menos, donde esto es poco frecuente. Si sí quieres esa exhaustividad adicional de estos niveles de esfuerzo, pero quieres dirigirla a la tarea en sí, agrega esto a tu indicación del sistema:

When the work the user asked for is done and its checks pass, stop and report. Don't start extra rounds of review or hardening on your own, and don't launch reviewer sub-agents unless the user asked for a review. If you think a deeper review is worth doing, say so at the end.

En pruebas con tareas de programación con esfuerzo max, esto evitó que el modelo lanzara subagentes revisores y redujo el costo de la sesión en aproximadamente un tercio, sin cambios en la calidad. Hace que las rondas de revisión iniciadas por el propio agente principal sean menos frecuentes, pero no las elimina por completo.

Solicitudes abiertas. Cuando una solicitud es abierta, por ejemplo "muéstrame lo que puedes hacer con esto", el modelo puede empezar a crear una presentación, un informe o un video cuando solo querías ideas. Si primero quieres ideas o un plan, dilo en la solicitud o agrega esto a tu indicación del sistema:

When the user asks for ideas, options or a plan, give them that and stop. Don't start building or changing anything until they say to go ahead.

Ejecución sin pensamiento previo

Para ejecutar Claude Sonnet 5.5 sin pensamiento previo, envía thinking: {"type": "between_tools"}. Es la configuración de pensamiento más baja de este modelo y se acepta con esfuerzo high o inferior. Si tu integración se ejecuta hoy con el pensamiento desactivado, cámbiala a between_tools y revisa estos puntos:

• Envía between_tools con esfuerzo high o inferior. Con esfuerzo xhigh o max, una solicitud con between_tools devuelve un error 400. Con between_tools, el esfuerzo tampoco puede cambiar a mitad de la conversación: un output_config.effort por mensaje que difiera del nivel vigente devuelve un error 400. Para variar el esfuerzo por turno, usa el pensamiento adaptativo. Con between_tools, elimina cualquier instrucción que le diga al modelo que no piense. Ese tipo de instrucciones aumenta la probabilidad de que el modelo escriba etiquetas XML internas en su salida visible.
• Lee la respuesta según el tipo de bloque. Con el pensamiento adaptativo, una respuesta puede comenzar con un bloque thinking, cuyo campo thinking está vacío con el valor predeterminado display: "omitted". Con between_tools, una respuesta puede comenzar con un bloque thinking de actualización de progreso. No asumas que el primer bloque de contenido es texto.
• Devuelve los bloques thinking sin cambios. Con between_tools, las notas que el modelo escribe entre llamadas a herramientas siguen llegando como bloques thinking cuando ocupan más de una o dos oraciones. Cada bloque incluye un resumen de la nota. Devuélvelos sin cambios junto con el resto del turno del asistente. Un bloque que devuelves le da al modelo la nota completa que escribió, no el resumen.
• Usa el pensamiento adaptativo para tareas de razonamiento sin herramientas. En una solicitud sin herramientas, between_tools significa que el modelo responde sin pensar primero. Para tareas que requieren algunos pasos de razonamiento, usa en su lugar el pensamiento adaptativo. Consulta Tareas de razonamiento con salida JSON.

Tareas de razonamiento con salida JSON

Esta sección se aplica cuando le pides a Claude Sonnet 5.5 una respuesta JSON para una tarea que requiere algunos pasos de razonamiento. Algunos ejemplos son sumar cifras de un documento, aplicar una regla u ordenar elementos. En tareas como estas, el modelo a menudo responde sin pensar primero, sobre todo con esfuerzo low y medium. Lo que ayuda depende de cómo solicites el JSON. Usa "structured outputs" (salidas estructuradas) donde estén disponibles. El texto de la respuesta es entonces JSON que coincide con tu esquema, así que no hay nada que analizar.

Con salidas estructuradas, el texto de la respuesta contiene solo el JSON, por lo que el modelo solo puede resolver el problema en su pensamiento. Cuando omite el pensamiento, puede ser menos preciso en estas tareas. Estos cambios ayudan a mantener una alta precisión.

Pídele al modelo que piense primero. Con el pensamiento adaptativo, agrega esta línea al final de tu indicación del sistema:

Think the problem through before you answer.

Con esta línea, el modelo piensa con más frecuencia antes de responder. Con esfuerzo high, la línea acerca la precisión a la que el modelo alcanza en xhigh, con un aumento moderado de tokens de salida. Con esfuerzo low y medium, aumenta la precisión, aunque no hasta la que el modelo alcanza en high, y el aumento de tokens de salida es mayor.

O usa esfuerzo xhigh. Con el pensamiento adaptativo, xhigh ofrece la mayor precisión en estas tareas incluso sin la línea. Usa más tokens de salida que high.

Usa el pensamiento adaptativo en lugar de between_tools. En una solicitud sin herramientas, el modelo no piensa antes de responder con between_tools. La línea no tiene efecto allí, y la precisión en estas tareas es menor. Usa el pensamiento adaptativo para estas solicitudes, con los pasos de esta sección. En pruebas, dividir la solicitud en dos, una para la respuesta y otra para el JSON, produjo una alta precisión en las respuestas y un alto cumplimiento del formato JSON, pero con un costo y una latencia muy altos.

Con salidas estructuradas y esfuerzo low y medium, el modelo ocasionalmente sigue pensando hasta alcanzar max_tokens. Con esfuerzo high o superior, esto casi nunca ocurre. Trata como fallida cualquier respuesta cuyo stop_reason sea "max_tokens", aunque su texto contenga JSON válido, y vuelve a intentarlo. Configura max_tokens lo suficientemente alto para el pensamiento y el JSON, como se describe en Calibra el esfuerzo, pero no más de lo que estés dispuesto a gastar en un intento.

Si no puedes usar salidas estructuradas, pide el JSON en el prompt. En ese caso, el modelo a menudo resuelve el problema en el texto de la respuesta y escribe el JSON al final. El JSON suele contener la respuesta correcta, pero un analizador que espera que toda la respuesta sea JSON falla. Dos cosas ayudan:

• Analiza el último valor JSON de la respuesta. Lee solo los bloques text y trata como fallida una respuesta cuyo stop_reason sea "max_tokens". Empezando en cada { o [, intenta analizar un valor JSON. Cuando uno se analice correctamente, continúa desde el final de ese valor, para que los valores anidados dentro de él no se cuenten por separado. Conserva el último valor encontrado. No tomes todo desde la primera { hasta la última }. El modelo ocasionalmente escribe un borrador antes de su JSON final, y ese rango incluiría ambos. Si tu respuesta consiste en varios valores JSON seguidos, como un registro por línea, conserva la última secuencia de valores separados solo por espacios, comas o saltos de línea. Comprueba que el resultado tenga los campos que esperas y vuelve a intentarlo una vez si no los tiene. En pruebas, esto hizo que casi todas las respuestas fueran utilizables sin cambiar su precisión.
• Considera también el esfuerzo xhigh con pensamiento adaptativo. En ese caso, el modelo resuelve el problema en su pensamiento y casi siempre devuelve solo el JSON. El total de tokens de salida se mantiene aproximadamente igual que en high, porque el razonamiento pasa del texto de la respuesta al pensamiento.

Actualizaciones de progreso para el usuario

Entre llamadas a herramientas, Claude Sonnet 5.5 escribe notas dirigidas al usuario sobre lo que acaba de encontrar y lo que hará a continuación. Las notas de más de una o dos oraciones llegan como bloques thinking de actualización de progreso. Los comentarios más breves se mantienen como text. Con el valor predeterminado de thinking.display, el texto de un bloque de actualización de progreso está vacío, por lo que un cliente que solo muestra bloques text puede parecer silencioso durante un turno agéntico largo. Esto importa sobre todo en interfaces de chat y otros productos en los que el usuario sigue el trabajo del modelo en tiempo real.

Para mostrar estas notas, configura display: "updates" (beta, encabezado thinking-display-updates-2026-08-18). Con between_tools, las notas llegan con su texto de resumen, así que no se necesita ningún campo display. between_tools no admite ningún otro campo: enviar display, budget_tokens o block_binding junto con él devuelve un error 400. La guía de migración muestra cómo mostrar las notas. A veces el modelo necesita mostrarle al usuario un texto exacto a mitad de un turno largo, como un fragmento de código o una pregunta que necesita que se responda. Para ese caso, dale una herramienta sencilla para enviarle un mensaje al usuario. Indícale al modelo que use esa herramienta solo para ese tipo de contenido. Declara la herramienta en la primera solicitud de la sesión, para que la lista tools no cambie después.

A continuación, elimina instrucciones antiguas como "guarda todos los hallazgos para la respuesta final". Si después quieres actualizaciones en puntos predecibles, por ejemplo una línea sobre lo que el modelo está a punto de hacer antes de su primera llamada a herramienta y un breve resumen al final, indícalo en la indicación del sistema. El modelo sigue instrucciones como esta. Las actualizaciones en puntos definidos son más útiles en el trabajo "human-in-the-loop" (con intervención humana).

Si los turnos largos con llamadas a herramientas siguen quedándose en silencio más tiempo del que quieres, tu arnés puede solicitar una actualización. Haz que cuente los pasos consecutivos de llamadas a herramientas que no envían al usuario ningún texto ni actualización de progreso. Después de varios seguidos, por ejemplo cinco, agrega un recordatorio de un solo turno después de los resultados de herramientas más recientes. Envíalo como un mensaje del sistema con alcance de turno (beta), con un texto como este:

The user hasn't heard from you in a while — say in a few words what you're doing, then continue.

Si el turno sigue en silencio, deja de enviar recordatorios después del segundo o tercero. El texto frecuente del arnés después de los resultados de herramientas puede hacer que el modelo sospeche de una "prompt injection" (inyección de prompts), como explica Mensajes del usuario a mitad de turno. Deja cada recordatorio en messages en las solicitudes posteriores. Como el recordatorio se agrega al final en lugar de insertarse y eliminarse después, la caché de prompts y el pensamiento preservado se mantienen intactos. Con esfuerzo high, y con una herramienta disponible para enviarle mensajes al usuario, el recordatorio hace que el modelo actualice al usuario con más frecuencia y acorta sus tramos de silencio más largos, sin cambios medibles en la calidad de la tarea.

Uso de herramientas en chat y trabajo de conocimiento

En tareas de chat y de trabajo de conocimiento, Claude Sonnet 5.5 a veces responde a partir de su conocimiento de entrenamiento cuando una búsqueda web detectaría detalles que han cambiado. Algunos ejemplos son lo que está permitido, lo que se exige o lo que se cobra.

Primero, revisa tu prompt en busca de expresiones que desalienten el uso de herramientas, como "usa herramientas solo cuando sea estrictamente necesario" o "minimiza las llamadas a herramientas", y elimínalas. Luego, si tu producto le da al modelo una herramienta de búsqueda, agrega esto a tu indicación del sistema:

Use the search tool to check specifics that may have changed since your training, such as what is allowed, required or charged, even when you feel confident. For researched work such as a report or a comparison, gather current sources rather than writing from your training knowledge.

Esto importa sobre todo en productos de investigación y soporte, donde las respuestas dependen de detalles actuales.

Mensajes del usuario a mitad de turno

Claude Sonnet 5.5 está entrenado para resistir la inyección indirecta de prompts, es decir, instrucciones maliciosas que llegan a través de resultados de herramientas y otro contenido que lee durante una tarea. A veces trata un mensaje genuino del usuario como una posible inyección. Supón que un mensaje que el usuario escribió a mitad de una tarea llega al modelo como un mensaje del sistema a mitad de conversación colocado justo después de un resultado de herramienta, o dentro de un bloque tool_result. En ese caso, el modelo puede decirle al usuario que el resultado de la herramienta contenía texto que se hacía pasar por un mensaje suyo, e ignorar el mensaje o pedirle al usuario que lo confirme.

Una cuenta regresiva de tokens que tu arnés agrega después de cada resultado de herramienta puede causar esto. También puede causarlo permitir que los usuarios envíen mensajes mientras el modelo está a mitad de un turno de varios pasos, o que tu arnés agregue instrucciones o contexto después de los resultados de herramientas en cada paso. En cada caso, llega texto justo después de los resultados de herramientas. Con una cuenta regresiva o instrucciones por paso, eso puede ocurrir en cada llamada a herramienta. Un recordatorio ocasional de un solo turno, como el de Actualizaciones de progreso para el usuario, llega con mucha menos frecuencia. Si ves esta reacción ante un recordatorio tuyo, envía el recordatorio con menos frecuencia. Para evitar la interpretación errónea:

• Nunca pongas texto del usuario dentro de un bloque tool_result. Es la ubicación que el modelo malinterpreta con más frecuencia.
• Entrega la entrada del usuario a mitad de turno como un turno de usuario. Agrega las palabras del usuario como un bloque de texto en el mensaje de usuario que contiene los bloques tool_result, después del último tool_result.
• Mantén los avisos del arnés, como los recordatorios, en un mensaje del sistema a mitad de conversación separado, después de las palabras del usuario. Nunca pongas un aviso y las palabras del usuario en el mismo bloque.
• En sesiones interactivas en las que los usuarios pueden escribir a mitad de turno, no agregues tu propia cuenta regresiva de tokens o de presupuesto después de los resultados de herramientas. Los presupuestos de tareas (beta) agregan una cuenta regresiva similar, pero no se ha observado que causen esta interpretación errónea. Si ves la interpretación errónea mientras hay un presupuesto de tarea configurado, prueba la sesión sin él.

Verificación en tareas de programación

En tareas de programación agéntica, Claude Sonnet 5.5 generalmente comprueba su trabajo antes de reportar un cambio como terminado. Sin embargo, con esfuerzo low, a veces reporta un cambio como terminado sin ejecutar una comprobación que lo ponga a prueba. Por ejemplo, podría omitir las pruebas del proyecto porque las dependencias del proyecto no están instaladas.

Si ves cambios reportados como completos sin salida de pruebas o de compilación en la transcripción, agrega este párrafo, o uno similar, a la indicación del sistema. Con esfuerzo low, hace que las comprobaciones omitidas o superficiales sean poco frecuentes, sin cambios medibles en la calidad de la tarea y con un costo por tarea solo ligeramente mayor:

When you change code that can be run, built, or type-checked, run a real check that exercises the change before reporting it done: the project's tests, type-checker, or build, or the changed command itself. A syntax-only check, or a check command that failed to start, does not count; if all that is missing is the project's declared dependencies, install them with its own package manager and lockfile (e.g. npm install, pip install -r requirements.txt), never via sudo or the system package manager, unless told not to. Only if no real check can run here, say which one you did not run and why instead of reporting the change as done.

Manejo tolerante de llamadas a herramientas

Claude Sonnet 5.5 ocasionalmente llama a una herramienta declarada con un nombre que solo difiere en mayúsculas y minúsculas, como bash en lugar de Bash. También puede pasar un parámetro conocido con un nombre ligeramente distinto. En lugar de tratar una llamada así como un error fatal, haz que tu arnés la maneje de una de estas dos formas:

• Acepta la llamada cuando la coincidencia no sea ambigua, aunque las mayúsculas y minúsculas sean incorrectas.
• Devuelve un tool_result con is_error: true que indique el nombre exacto esperado. El modelo suele corregir la llamada en su siguiente turno. Consulta Manejo de errores con is_error.

Herramientas para entradas visuales complejas

Para gráficos densos y dibujos técnicos, dale a Claude Sonnet 5.5 una forma de recortar, ampliar o ejecutar código sobre la imagen. Con esas herramientas, el modelo lee estas entradas con una precisión notablemente mayor. En los gráficos, las herramientas ayudan en todos los niveles de esfuerzo. En los dibujos técnicos, solo ayudan a partir del esfuerzo high, y sobre todo en xhigh y max. En los gráficos, agregar herramientas ayuda más que aumentar el esfuerzo: en pruebas, con herramientas y esfuerzo high, el modelo leyó los gráficos con más precisión que sin herramientas y con esfuerzo max, a una fracción del costo. La receta de la herramienta de recorte incluye una definición de herramienta funcional.

Rechazos de las salvaguardas

Claude Sonnet 5.5 ejecuta clasificadores de seguridad que pueden rechazar una solicitud. Un rechazo llega como una respuesta normal con stop_reason: "refusal", y stop_details.category indica la categoría de rechazo:

• cyber: la solicitud podría facilitar daños cibernéticos, como el desarrollo de malware o exploits. Encontrar vulnerabilidades en código fuente está permitido. El trabajo de ciberseguridad de doble uso de alto riesgo no está permitido.
• bio: la solicitud podría facilitar daños biológicos, como métodos de laboratorio peligrosos. Las preguntas cotidianas de salud y educativas no se ven afectadas.
• frontier_llm: la solicitud podría ayudar al desarrollo de modelos de IA competidores.
• reasoning_extraction: la solicitud le pide al modelo que reproduzca su razonamiento interno en el texto de la respuesta.
• general_harms: la solicitud corresponde a otra área de la política de uso. El trabajo benigno también puede activar esta categoría.

Si el clasificador bio bloquea el trabajo de ciencias de la vida de tu organización, puedes solicitar el ingreso al Programa de Verificación de Ciencias de la Vida.

Si activas el respaldo del lado del servidor (beta), este reintenta los rechazos cyber y frontier_llm en Claude Sonnet 5. No reintenta los rechazos bio, reasoning_extraction ni general_harms. Consulta Rechazos, respaldo y facturación.

Si tus prompts le piden al modelo que incluya su razonamiento en la respuesta, elimina esas instrucciones, porque propician rechazos reasoning_extraction. Con el pensamiento adaptativo, lee el razonamiento en los bloques de pensamiento resumido (display: "summarized").