Cómo escribir prompts para Claude Fable 5.2

Esta guía cubre los patrones de prompts específicos de Claude Fable 5.2. Para conocer las capacidades del modelo y los cambios en la API, consulta Novedades de Claude Fable 5.2. Para técnicas que se aplican a todos los modelos Claude actuales, consulta Mejores prácticas de prompts.

Claude Fable 5.2 se comporta de forma diferente a los modelos anteriores en algunos aspectos. Empieza por la sección que corresponda a lo que observas:

• No sabes qué nivel de esfuerzo usar, o las solicitudes sencillas tardan demasiado: Calibra el esfuerzo
• Un turno termina antes de que el trabajo esté hecho: Termina la tarea completa
• Apruebas pasos mientras el agente trabaja, o tu indicación del sistema tiene reglas de aprobación: Aprobaciones
• Un agente de programación repite código existente en lugar de fusionarlo, o informa de problemas cercanos sin corregirlos: Indica a quién pertenece el código
• Los turnos agénticos largos parecen silenciosos: Mantén informados a los usuarios durante los turnos largos
• Las sesiones del agente inician más subagentes de los que la tarea necesita: Establece expectativas para los subagentes
• Los agentes piden aprobaciones que no necesitan, o frenan trabajo rutinario: Evita que la precaución se acumule
• Reutilizas una indicación del sistema, skills o un harness escritos para Claude Fable 5.1 o Claude Opus 5.5: Revisa las instrucciones escritas para modelos anteriores
• Tus usuarios leen informes finales o traspasos después de tareas largas: Haz que los informes sean fáciles de seguir
• Las solicitudes devuelven stop_reason: "refusal": Rechazos de las salvaguardas

Calibra el esfuerzo

Empieza con high, el valor predeterminado en la Claude API. Si tu caso de uso lo requiere, sube o baja el esfuerzo y prueba cada cambio con tus propias evaluaciones. El nivel de esfuerzo determina cuánto piensa Claude Fable 5.2, cuánto tarda un turno y cuántos tokens usa. Ajusta el esfuerzo junto con tu prompt, porque el nivel también cambia la forma en que piensa el modelo y cuántas llamadas a herramientas hace.

En general, los niveles de esfuerzo siguen el mismo orden en todos los modelos Claude, pero la cantidad de pensamiento detrás de cada nivel puede variar de un modelo a otro. Así que vuelve a hacer tu barrido de esfuerzo en lugar de reutilizar una configuración que ajustaste en Claude Fable 5.1 o Claude Opus 5.5.

Elige un nivel según el tipo de trabajo:

• low es adecuado para intercambios rápidos, tareas bien especificadas y cargas de trabajo de alto volumen, como subagentes rápidos e inteligentes. En las pruebas de Anthropic, las puntuaciones del modelo en low quedaron cerca de las puntuaciones de Claude Fable 5.1 en niveles de esfuerzo más altos.
• medium es adecuado para programación interactiva, chat y trabajo de conocimiento cotidiano.
• high es adecuado para programación difícil, investigación, trabajo agéntico y ejecuciones largas sin supervisión. Los turnos tardan notablemente más en terminar que en medium.
• xhigh es para tu trabajo de programación y agéntico más difícil y de larga duración, donde hayas medido una mejora. En las evaluaciones internas de programación de Anthropic, subió ligeramente las puntuaciones y usó muchos más tokens.
• max es para medir el techo del modelo, o para la tarea poco común en la que el tiempo y los tokens no importan. Es más adecuado para problemas abiertos, como el descubrimiento científico y las matemáticas. Los turnos son lentos y usan muchos más tokens que en xhigh.

La mayor parte de la mejora en capacidad ya está presente en high. El paso de medium a high subió las puntuaciones en la mayoría de las evaluaciones de programación y trabajo de conocimiento que Anthropic sigue. Ese paso también usa más tokens y más tiempo, así que baja a medium siempre que tus evaluaciones muestren que la calidad se mantiene. Por encima de high, las mejoras son desiguales y dependen de la tarea.

Al elegir un nivel, ten en cuenta tres comportamientos:

• Es más probable que el modelo se detenga antes de tiempo en niveles de esfuerzo más bajos. Para trabajo agéntico en low o medium, añade el texto de Termina la tarea completa.
• En high y superiores, el modelo piensa antes de casi todas las respuestas, incluida la respuesta a un saludo. Si las solicitudes sencillas tardan demasiado o cuestan demasiado, usa un nivel de esfuerzo más bajo para esos turnos. En las pruebas de Anthropic, una instrucción de responder directamente sin deliberar no impidió que el modelo pensara en medium y superiores.
• El esfuerzo apenas cambia la longitud de las respuestas del modelo. Para cambiar la longitud y el tono de una respuesta, usa tu prompt.

También puedes combinar niveles en un mismo flujo de trabajo. Por ejemplo, podrías planificar e iterar con el modelo en medium y luego subir el esfuerzo para la parte larga y sin supervisión. Para cambiar de nivel dentro de una conversación y conservar la caché de prompts, usa un cambio de esfuerzo por mensaje (beta, encabezado mid-conversation-output-config-2026-07-01); esa sección enumera las plataformas en las que está disponible. Un cambio se mantiene hasta que otro lo reemplaza. Donde el esfuerzo por mensaje no esté disponible, establece un nuevo valor de effort de nivel superior en la siguiente solicitud, lo que reinicia la caché.

Termina la tarea completa

En tareas largas de varios pasos, Claude Fable 5.2 a veces termina un turno antes de que el trabajo esté hecho. El turno se cierra con una lista de lo que queda, una oferta para continuar o una detención ante un obstáculo común, como un tiempo de espera agotado. Esto ocurre con más frecuencia con esfuerzo low y medium.

Si ves estas detenciones en tu agente, añade un texto como este a tu indicación del sistema:

# Finishing work
Please avoid stopping while you still owe work the user asked for. Be persistent and do not stop unless needed.

While status notes are welcome, as is clarifying with the user on open decisions, carry on with work that does not depend on the user's answer without unnecessary stops.

If you notice yourself inviting the user to redirect you or offering to wait, instead proceed on the next part of the task. You may meet ordinary obstacles like errors, timeouts, locked files, empty results or failing tools. Diagnose them first, and when they are not real blockers, work through them with the access you have (wait and retry, fix the request, use another tool or source) rather than stopping unnecessarily.

If someone clearly decided something is a hard blocker, such as a file marked not to be touched, access that was intentionally withheld, or a safety guardrail, leave it alone, say plainly what you found, and look for another safe way to finish the task. Stopping before the task is complete is very rarely merited, as in when the task can't move forward without user input, or where the blocker is deliberate and should not be worked past. This does not override the need for confirmation on risky or destructive actions.

Este texto distingue dos tipos de obstáculo. Le indica al modelo que diagnostique y supere los obstáculos comunes, como errores, tiempos de espera agotados y herramientas que fallan. Le indica que no toque los bloqueos deliberados, como un archivo marcado para no modificarse, y que informe de ellos. Trata el texto como un punto de partida y conserva esa distinción al adaptarlo a tu aplicación.

Anthropic reprodujo sesiones grabadas de un producto de programación agéntica con esfuerzo medium. Con una versión de este texto, el número de sesiones que terminaron con trabajo factible pendiente se redujo a aproximadamente la mitad de lo que era. El texto eliminó la mayoría de los finales que piden permiso u ofrecen continuar, pero no los finales que enumeran lo que falta y luego se detienen. Los tokens de salida aumentaron alrededor de un 30 por ciento.

Como el modelo pregunta con menos frecuencia con este texto, mantén tu propio paso de confirmación para acciones arriesgadas o irreversibles.

Aprobaciones

Cuando le digas al modelo que continúe, di claramente lo que quieres de él en lugar de enviar un simple “continúa”. Por ejemplo, responde “Sí, ejecuta la migración en la base de datos de staging” donde podrías haber enviado “adelante” o un pulgar arriba.

Si tu indicación del sistema tiene reglas de aprobación, nombra las acciones exactas que cubren, porque el modelo las aplica tal como están escritas. En las pruebas de Anthropic con tareas simuladas sin nadie presente para aprobar, una regla incluía “enviar mensajes a personas fuera de esta conversación” entre los pasos que necesitan aprobación. Con esa regla, el modelo frenó aproximadamente la mitad de sus solicitudes rutinarias a colegas y otros equipos.

Indica a quién pertenece el código

Claude Fable 5.2 responde de cerca a lo que dice el prompt sobre a quién pertenece el código en el que trabaja. En las pruebas de Anthropic con tareas de programación pequeñas, cuando un prompt no decía nada sobre la propiedad o presentaba la base de código como de otra persona, el modelo tendía a añadir a la estructura existente, incluso cuando eso repetía código existente. También tendía a informar de problemas cercanos en lugar de corregirlos. Cuando el prompt dice que la base de código es del propio modelo, este a menudo fusiona el código repetido y hace correcciones relacionadas sin que se lo pidan.

Si quieres que el modelo mejore la estructura mientras trabaja, di que el código es suyo:

This codebase is yours: what it's for and how it's built are your call, and you'll keep building on it.

En las pruebas de Anthropic con tareas de programación pequeñas, el modelo fusionó código repetido en aproximadamente la mitad de los intentos con esta oración, y en menos de una décima parte de los intentos sin ella. La tasa varió según la tarea. El resultado se mantuvo cuando la oración estaba dentro de una indicación del sistema larga. La funcionalidad solicitada funcionó en casi todos los intentos en ambos casos.

En las mismas pruebas, el modelo también usó alrededor de 1,5 veces los tokens de salida con la oración e hizo varios cambios que nadie había pedido, muchos de ellos pruebas nuevas y documentación. Aparte de las correcciones de errores, cambió el comportamiento de una funcionalidad existente en uno de cada seis a diez intentos, y con más frecuencia con mayor esfuerzo. Su resumen final mencionaba los cambios más grandes, pero a menudo omitía los pequeños, así que revisa el diff y no solo el resumen.

Omite la oración de propiedad cuando el código pertenezca al usuario y este quiera que se cambie lo menos posible. Una regla en otra parte del prompt que limite el alcance no anula la oración de propiedad. En las pruebas de Anthropic, con “No drive-by refactors, renames or cleanups” antes en el mismo prompt, el modelo aún fusionó código repetido en aproximadamente un tercio de los intentos.

Mantén informados a los usuarios durante los turnos largos

Claude Fable 5.2 a veces escribe poco texto visible para el usuario durante secuencias largas de llamadas a herramientas. El modelo también podría hacer su primera llamada a herramienta sin decir lo que está a punto de hacer.

Primero, comprueba que tu cliente recibe las actualizaciones del modelo. En Claude Fable 5.2, las actualizaciones que el modelo escribe entre llamadas a herramientas llegan como bloques thinking de actualización de progreso. Estas actualizaciones dicen lo que el modelo encontró y lo que hará a continuación. Su texto está vacío con el valor predeterminado de thinking.display, "omitted". Por eso, un cliente que solo renderiza bloques text puede parecer silencioso durante un turno agéntico largo. Establece display: "updates" (beta, encabezado thinking-display-updates-2026-08-18) para recibir un breve resumen de cada actualización, o "summarized" para recibir las actualizaciones junto con el razonamiento resumido. Luego renderiza los bloques thinking no vacíos entre llamadas a herramientas.

Las actualizaciones frecuentes importan más cuando un usuario observa el trabajo en tiempo real, como en la programación interactiva. Si tus usuarios observan el trabajo y aun así reciben muy pocas actualizaciones, usa una o más de estas opciones.

Si puedes cambiar tu harness, una opción eficaz es que cuente los pasos consecutivos de llamadas a herramientas que no le dan al usuario nada que leer: ningún bloque text y ningún bloque thinking con texto. Cuenta con display establecido en "updates" o "summarized", porque con "omitted" todos los bloques thinking están vacíos. Esta opción funciona donde tu plataforma admita mensajes del sistema a mitad de conversación. Tras varios de esos pasos seguidos, haz que el harness añada este recordatorio después de los resultados de herramientas más recientes como un mensaje del sistema limitado al turno (clear_at: "next_user_message", beta, encabezado mid-conversation-system-clear-at-2026-08-21):

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

En las pruebas de Anthropic con tareas de programación de varios turnos, el recordatorio redujo aproximadamente a la mitad el tramo silencioso más largo, sin un aumento apreciable de tokens ni de tiempo.

Deja cada recordatorio en messages en las solicitudes posteriores. Quitar o reformular uno edita un turno anterior, lo que invalida los bloques de pensamiento posteriores. Consulta Envía recordatorios por turno como mensajes de sistema con alcance de turno.

Para obtener también una línea inicial antes de la primera llamada a herramienta, actualizaciones breves y un resumen final, añade este texto a tu indicación del sistema:

Before you start, say in a line what you're about to do; brief updates while you work help the user follow along. Close with a short recap that stands on its own (what you found, what you did, and what's next), so a reader who only sees the last message has the full picture.

En las pruebas de Anthropic con tareas de programación, el modelo habló antes de su primera llamada a herramienta en todas las ocasiones con este texto. El texto también aumentó los tokens de salida por tarea en aproximadamente un 20 por ciento. Usa este texto cuando haya una persona directamente involucrada. Para obtener el máximo de actualizaciones, combínalo con el recordatorio que añade tu harness.

Si no puedes cambiar el harness, o tu plataforma no tiene mensajes del sistema a mitad de conversación, añade esta oración a tu indicación del sistema:

Every few tool calls, give the user a one-line update on where things stand.

En las pruebas de Anthropic con tareas de automatización de flujos de trabajo, esta oración eliminó la mayoría de los tramos silenciosos largos.

Incluso con el recordatorio y el texto de apertura y resumen juntos, espera secuencias de varias llamadas a herramientas entre actualizaciones. Claude Fable 5.2 funciona bien en tareas asíncronas de larga duración, en las que el usuario vuelve a por el resultado en lugar de observar cada paso. Ahí, los intervalos entre actualizaciones importan menos.

Establece expectativas para los subagentes

Cuánto trabajo delega Claude Fable 5.2 a subagentes depende de tu harness y tus tareas. En las pruebas de Anthropic con tareas cortas y una herramienta mínima para iniciar subagentes, rara vez inició uno. En un producto de programación agéntica cuyos prompts invitan a delegar, delega con facilidad.

Si tu indicación del sistema, tus skills o tus archivos de agente le dicen al modelo que delegue, revisa primero esas líneas. Cambia la descripción de la herramienta que inicia subagentes solo si Claude Fable 5.2 sigue iniciando más subagentes de los que tus tareas necesitan. Si la herramienta tiene una descripción simple y nada más en tus prompts pide delegar, probablemente no necesites una descripción nueva.

En la nueva descripción, indica lo que un subagente añade al costo de una sesión, di cuándo vale la pena delegar y cuándo no, y dile al modelo cómo informar a un subagente que inicie. La descripción que probó Anthropic hace estas tres cosas y pone el costo primero. Una descripción de este tipo es más útil cuando tu harness ya invita a delegar y los subagentes representan una gran parte de tu uso de tokens.

En las pruebas de Anthropic con tareas cortas, el modelo delegó aproximadamente un tercio menos a menudo con la descripción probada que con una que enumeraba principalmente razones para delegar. El éxito de las tareas fue el mismo.

En la descripción probada, las oraciones iniciales sobre el costo frenan la delegación. Habla menos del costo si el modelo delega demasiado poco. Si aun así delega demasiado, di más sobre lo que cuesta un subagente en tu harness y prueba el cambio.

Anthropic también observó que Claude Fable 5.2 usaba subagentes para revisar su propio trabajo en un producto de programación agéntica con niveles de esfuerzo más altos, como xhigh y max. Claude Fable 5.1 no hizo esto en las mismas tareas. Los primeros evaluadores obtuvieron buenos resultados con Claude Fable 5.2 como planificador y orquestador de otros modelos. Delegar puede acelerar el trabajo que se ejecuta bien en paralelo. Sin embargo, los subagentes pueden representar una gran parte del costo de una sesión, así que comprueba en qué modelo ejecuta tu harness los subagentes de forma predeterminada.

Evita que la precaución se acumule

Las instrucciones cautelosas se acumulan dondequiera que el contexto se traslada: memoria, notas, archivos de instrucciones y mensajes entre agentes. Claude Fable 5.2 sigue estas instrucciones de cerca, por lo que podría pedir aprobaciones que no necesita o frenar trabajo rutinario. Algunos de los primeros evaluadores vieron este comportamiento, sobre todo donde varios agentes trabajan juntos. Los modelos anteriores también siguen este tipo de instrucciones, pero en una de las configuraciones descritas aquí solo Claude Fable 5.2 se contuvo.

Si ves este comportamiento, limpia lo que llevan tus agentes:

• Elimina las notas que ya no necesitas. En las pruebas de Anthropic con tareas simuladas, una de una docena de notas de sesiones anteriores decía que nunca se reintentara. Con esas notas en contexto, y sin nada en el prompt que permitiera reintentos, el modelo reintentó tras encontrar una herramienta ocupada en aproximadamente cuatro de cada diez intentos, frente a casi todos sin esas notas.
• Nombra los pasos que no necesitan aprobación. En las pruebas de Anthropic con tareas simuladas, el contexto contenía reglas de “nunca”, notas y las condiciones de un revisor. Una línea al final de las reglas que incluía los reintentos entre los pasos que no necesitan aprobación aumentó los reintentos de casi ninguno a aproximadamente la mitad de los intentos. En la misma configuración, una instrucción general de actuar con más libertad no cambió nada. Nombra los reintentos solo para las llamadas que es seguro repetir.
• Comprueba lo que adjuntan los agentes revisores. En las pruebas de Anthropic con tareas simuladas, una configuración tenía una línea en el prompt que incluía los reintentos entre los pasos que no necesitan aprobación, y un “detente en el primer error” de un revisor en el contexto. Claude Fable 5.2 no reintentó en aproximadamente un tercio de los intentos. Claude Fable 5.1 y Claude Opus 5.5 sí reintentaron.
• Escribe la excepción en la regla. En las pruebas de Anthropic con tareas simuladas, la persona a cargo había aprobado un paso. Bajo una regla de “nunca”, el modelo dio ese paso en aproximadamente uno de cada diez intentos. Una línea aparte que decía que un paso aprobado tiene luz verde no cambió mucho esa tasa. Cuando la propia regla decía que primero se obtuviera luz verde, el modelo dio el paso en aproximadamente nueve de cada diez intentos. Consulta Aprobaciones.

Mantén también tu propio paso de confirmación para acciones arriesgadas o irreversibles.

Revisa las instrucciones escritas para modelos anteriores

Cuando migres a Claude Fable 5.2, revisa tus prompts. En las pruebas de Anthropic, algunas instrucciones escritas para modelos anteriores aumentaron el costo, causaron efectos secundarios o dejaron de tener efecto. Reconsidera estas instrucciones:

• Instrucciones permanentes de delegar: Las líneas que envían trabajo a subagentes pueden estar en indicaciones del sistema, skills y archivos de agente. Lee esos archivos antes de migrar. Si, en tus pruebas, el modelo inicia más subagentes de los que tus tareas necesitan, elimina las líneas que ya no necesites. Consulta Establece expectativas para los subagentes.
• Un presupuesto de tokens que tu harness escribe en el prompt: Algunos harnesses le indican al modelo en el prompt cuántos tokens puede usar la tarea y cuántos quedan. El tamaño de ese presupuesto cambia cuánto gasta Claude Fable 5.2. En las pruebas de Anthropic con tareas de programación con esfuerzo high y xhigh, eliminar un presupuesto grande redujo el costo, con un rendimiento equivalente. Prueba tus tareas sin el presupuesto. Este hallazgo se refiere al texto en el prompt, no a los presupuestos de tareas de la API, una función beta que las pruebas no cubrieron.
• Código del harness que edita turnos anteriores: Claude Fable 5.2 usa pensamiento preservado. Si tu harness cambia la indicación del sistema, las herramientas o un mensaje anterior entre solicitudes, los bloques de pensamiento que siguen al punto modificado en el historial dejan de ser válidos. De forma predeterminada, la Messages API entonces rechaza la solicitud, y la Message Batches API descarta esos bloques. Para acortar el historial sin este error, usa la edición de contexto o una compactación que no conserve turnos anteriores después del resumen. Para que la Messages API también descarte los bloques, establece thinking.block_binding.prefix_mismatch_behavior en "drop_block" (beta, encabezado thinking-binding-controls-2026-08-01). En las pruebas de Anthropic, cuando se descartaba el pensamiento anterior en cada turno, el modelo volvía a pensar y usaba más tokens de salida. Ese es el peor caso, y el aumento depende de la frecuencia con la que tu harness edite turnos anteriores. Aparte de la compactación y la edición de contexto, mantén el historial como solo de anexado. Así se mantiene alta la tasa de aciertos de caché y no se descarta ningún pensamiento. Mide los tokens de salida en tus propias tareas antes de depender de "drop_block". Consulta Qué hace la API con un bloque no válido y Haz cambios sin editar el prefijo.
• Las líneas de “trata esa respuesta como terminada”: Cómo escribir prompts para Claude Opus 5.5 ofrece dos oraciones para indicaciones del sistema de chat. Le indican al modelo que trate una respuesta anterior como terminada y que centre su pensamiento en el mensaje nuevo. En las pruebas de Anthropic con esfuerzo high, estas oraciones redujeron el pensamiento de Claude Fable 5.2 en las preguntas de seguimiento, pero el modelo también se volvió mucho menos propenso a señalar errores en sus respuestas anteriores. Omite estas líneas cuando quieras que el modelo siga reexaminando sus respuestas anteriores. En los demás casos, prueba si el modelo sigue señalando sus propios errores antes de adoptar las líneas.
• Instrucciones de pensar menos: Claude Fable 5.1 suele seguir una línea como “responde directamente sin deliberar”. En las pruebas de Anthropic, una línea así no impidió que Claude Fable 5.2 pensara en medium y superiores. Elimina estas líneas y baja el nivel de esfuerzo, como se describe en Calibra el esfuerzo.
• Reglas de estilo de escritura: Claude Fable 5.2 sigue las reglas de estilo de cerca, por lo que un límite estricto como “una instrucción por oración, en 20 palabras o menos” puede hacer que su prosa sea entrecortada. Elimina las reglas que ya no necesites antes de añadir el texto de Haz que los informes sean fáciles de seguir.
• Reglas, notas y memorias que se han acumulado: Los archivos de memoria, las notas y los archivos de instrucciones acumulan advertencias con el tiempo, y el propio modelo podría haber escrito algunas. Antes de migrar, elimina las advertencias cuyo motivo ya no se aplique y reescribe las reglas absolutas para que indiquen su alcance y su motivo. Si un sistema ya está atascado, considera reiniciarlo con su memoria y sus notas recortadas, y guarda una copia de los originales. Consulta Evita que la precaución se acumule.

Haz que los informes sean fáciles de seguir

Después de un trabajo agéntico largo, las personas que leen el informe final de Claude Fable 5.2 normalmente no han visto las llamadas a herramientas ni los archivos que hay detrás. El informe debe tener sentido por sí solo.

Si le pides a Claude Fable 5.2 que escriba informes finales o traspasos, añade este texto a tu indicación del sistema y ajústalo a tus lectores y tu producto:

# Communicating clearly
Write for an intelligent but low-context reader. The person reading has not seen your tool calls, your reasoning or the files you opened, and may be switching in from other work. Messages should generally be self-contained: the reader should understand what you mean without having to dig for other context. Put the key points in the first few sentences. Practice progressive disclosure in your sentence order, and do not use undefined references and ideas in line 1 that won't make sense until the reader reaches line 12.

Use plain words, and write in clear, understandable full sentences. Do not use a term or abbreviation that you made up during the work. Say what the thing is in a way any reader would understand. Write mostly in the style of ASD-STE100 Simplified Technical English: short sentences, one idea per sentence, active voice, and consistently using the same word for the same thing. Use a paragraph of flowing prose where ideas connect, and keep bullets for lists of separate items. Leave out unnecessary details unless the reader asks and practice concision, but do ensure that your messages have the key context. Aim to make your user-facing text as human-readable and clear as possible.

En las pruebas de Anthropic con tareas agénticas, este texto hizo que los informes finales fueran menos densos, con menos punto y coma. En tareas de automatización de flujos de trabajo, también acortó las oraciones. También podrías añadir instrucciones sobre la longitud o pedirle al modelo que incluya detalles específicos.

Rechazos de las salvaguardas

Claude Fable 5.2 ejecuta clasificadores de seguridad que pueden rechazar una solicitud. Una solicitud rechazada devuelve 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.
• bio: la solicitud podría facilitar daños biológicos, como métodos de laboratorio peligrosos.
• 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 pertenece a otra área de la política de uso.

El trabajo benigno de ciberseguridad y ciencias de la vida también puede activar los clasificadores cyber y bio. Si bloquean el trabajo legítimo de tu organización, consulta el Cyber Verification Program y el Life Sciences Verification Program de Anthropic. Claude Mythos 5.2 ofrece las mismas capacidades que Claude Fable 5.2 solo a las organizaciones verificadas mediante estos programas.

Si tus prompts, skills o descripciones de herramientas le piden al modelo que escriba su razonamiento en la respuesta, elimina esas instrucciones. Para ver cómo razonó el modelo, establece display: "summarized" y lee los bloques de pensamiento. Consulta Mantén el razonamiento en los bloques de pensamiento.

Para reintentar una solicitud rechazada en otro modelo, consulta Rechazos, fallback y facturación.

Por dónde empezar

Cuando migres, sigue estos pasos en orden:

1. Establece effort en high de forma explícita y luego ejecuta también tus evaluaciones en medium y xhigh.
2. Lee las indicaciones del sistema, skills, archivos de agente, archivos de memoria, notas y texto del harness que reutilizas. Elimina o prueba las instrucciones enumeradas en Revisa las instrucciones escritas para modelos anteriores.
3. Ejecuta tus tareas agénticas más largas. Anota dónde el modelo se detiene antes de tiempo, pide aprobaciones que no necesita, se queda en silencio, delega más de lo que la tarea necesita o añade a código existente donde querías que lo reestructurara.
4. Aplica la guía para cada comportamiento que observaste, de uno en uno, y mide su efecto y su costo en tokens en tus propias tareas.