La mayoría de las guías de migración te dicen qué se rompe en tu código. Esta trata sobre lo que se rompe en tus prompts.
Claude Opus 5 se lanzó el 24 de julio de 2026, y Anthropic publicó una guía de prompting dedicada junto a él. Esa guía documenta algo a lo que vale la pena prestar atención: varias instrucciones que mejoraban Opus 4.8 empeoran Opus 5. No sutilmente peor. Es mediblemente más caro, mediblemente más verboso, y en un caso activamente roto.
La razón es simple. Opus 5 ya hace, por sí mismo, varias cosas que antes tenías que pedir. Cuando tu prompt antiguo lo pide de todos modos, la instrucción se combina con el comportamiento que el modelo ya tiene. Obtienes el doble de pases de verificación, no el doble de precisión.
Esta guía recorre cada cambio de comportamiento documentado con un fragmento de prompt que puedes copiar y pegar en tu prompt del sistema hoy mismo. También cubre los dos modos de fallo que aparecen cuando deshabilitas el pensamiento, que es el único lugar donde un prompt de Opus 5 puede producir una salida que parece correcta y corrompe silenciosamente un bucle de agente. Si todavía estás trabajando en los cambios a nivel de código, la guía de migración de Opus 4.8 a Opus 5 los cubre por separado. Y si quieres ver cómo cambian estos comportamientos en cargas útiles de solicitud y respuesta reales, Apidog es una forma sencilla de enviar el mismo prompt con diferentes configuraciones y comparar los resultados.
El resumen de una línea
Opus 5 verifica más, escribe más, delega más y se explica más que Opus 4.8. Tu prompt de Opus 4.8 estaba ajustado para empujar a un modelo hacia esos comportamientos. Ahora los excede.
Así que el trabajo es sustractivo. En su mayoría estás eliminando instrucciones, no añadiéndolas. Las adiciones que haces son restricciones: sé más conciso, mantente dentro del alcance, no generes ayudantes.
1. Elimina tus instrucciones de verificación
Esta es la clave, y es la razón del título.
Anthropic afirma que Opus 5 verifica su propio trabajo sin necesidad de ser solicitado. Relee lo que escribió, comprueba su aritmética, vuelve a ejecutar una prueba y busca el caso límite que no mencionaste. Ese era el comportamiento exacto que todo el mundo impulsaba manualmente en Opus 4.8 con líneas como "revisa tu trabajo antes de responder" o "verifica cada paso".
Si mantienes esas líneas, obtendrás una sobre-verificación. El modelo ejecuta los pases de verificación que habría ejecutado de todos modos, más los que le pediste, y pagas por cada token de ello. En ejecuciones de agente largas, esto es una factura real, no un error de redondeo.
La solución es una eliminación. Busca estos patrones en tus prompts del sistema y elimínalos:
Double-check your work before responding.
Verify each step before moving to the next one.
Review your answer for errors, then revise it.
Check your reasoning carefully.
Make sure the output is correct before returning it.
Si tienes un paso genuinamente de alto riesgo donde quieres un pase de verificación explícito, limítalo a ese paso en lugar de convertirlo en una regla global:
Do not add general verification passes; you already verify by default.
The only exception: after writing the migration SQL, run it against the
schema dump once and report any mismatch. Do not re-verify anything else.
Esa forma importa. Una instrucción global de "verificar todo" en Opus 5 es un multiplicador de costos. Una única excepción con ámbito es un control.
Si estás rastreando el gasto de la API a lo largo de esta migración, las palancas de caché y lote en el desglose de precios de Opus 5 se acumulan con esta, y nuestra guía para reducir la factura de la API de Claude cubre las palancas generales.
2. Solicita concisión explícitamente, porque el esfuerzo no lo hará
Las respuestas predeterminadas de Opus 5 son más largas que las de Opus 4.8. Lo mismo ocurre con sus entregables escritos: los informes, resúmenes, documentos de diseño y READMEs que produce cuando pides un documento.
Aquí es donde la gente se confunde. Bajar el parámetro effort no soluciona esto. El esfuerzo controla cuánto piensa el modelo. No controla cuánto escribe el modelo. Baja de xhigh a medium y reducirás los tokens de pensamiento mientras que la respuesta visible permanece casi tan larga como estaba. Si asumiste que el esfuerzo era un dial de verbosidad, tu factura no se moverá como esperabas. La guía del parámetro de esfuerzo de Opus 5 cubre lo que cada nivel realmente cambia.
La longitud es un problema de prompting, así que resuélvelo en el prompt. Sé específico sobre el límite en lugar de decir "sé breve", lo que los modelos interpretan generosamente:
Response format: at most 150 words unless I ask for more.
No preamble, no restatement of my question, no summary at the end.
Lead with the answer, then the reasoning if it is needed.
Para los entregables escritos, pon el límite en el artefacto y nombra qué eliminar:
Write the migration doc at 800 words maximum.
Include: the breaking changes, the fix for each, and a rollback step.
Exclude: background on the old system, a glossary, and a conclusion section.
If a section would exceed its share, cut examples before cutting steps.
Para trabajos con mucho código, la restricción equivalente se refiere a los comentarios, no al código:
Return the diff and nothing else.
No explanation of what you changed unless the change is non-obvious,
in which case one sentence above the hunk.
3. Limita la delegación de subagentes
Opus 5 delega en subagentes con mayor facilidad que Opus 4.8. Dada una tarea de varias partes y un arnés que soporte la generación, se expandirá.
Esa suele ser la decisión correcta. También es una decisión de costo que el modelo toma en tu nombre, y cada subagente conlleva su propio contexto y su propia factura de tokens. Para cargas de trabajo sensibles al costo o a la latencia, ponle un número en lugar de dejarlo al juicio del modelo:
Do not spawn subagents for this task. Handle it in this conversation.
O, cuando la ramificación es genuinamente útil pero debería ser limitada:
You may delegate to at most 2 subagents, and only for independent
file-level work that can run in parallel.
Do research, planning, and final synthesis yourself in this thread.
El patrón a evitar es la delegación por sí misma: un subagente generado para leer un archivo, o para tomar una decisión para la que el hilo principal ya tenía el contexto. Si construyes con subagentes deliberadamente, nuestra guía para crear subagentes de código de Claude cubre el lado del arnés para delimitarlos.
4. Restringe explícitamente el alcance en tareas específicas
Opus 5 expande el alcance de las tareas. Pídele que arregle una prueba fallida y puede que también refactorice la función auxiliar que la prueba llama, actualice la firma de tipos y añada dos casos de prueba más. Pídele que cambie el nombre de una variable y puede que ordene la función circundante.
A veces esto es una característica. En una tarea específica y quirúrgica no lo es: una refactorización no solicitada significa un diff más grande para que un revisor lo lea y un radio de explosión mayor para un cambio que se suponía que era de una sola línea.
Establece el límite como un límite, y nombra lo que está prohibido:
Scope: change only the retry-count constant in src/client/http.ts.
Do not refactor surrounding code, do not rename anything, do not add
tests, do not update docs. If you believe another change is required,
stop and tell me instead of making it.
Esa última cláusula es la mitad útil. Sin ella, el modelo no tiene una forma autorizada de plantear un problema real, por lo que o realiza el cambio de todos modos o ignora la observación. Con ella, obtienes una preocupación señalada y un diff sin cambios.
5. Espera más narración de correcciones y desactívala si no la quieres
Opus 5 narra sus correcciones más que Opus 4.8. Cuando cambia de opinión a mitad de una respuesta, te lo dice: señala que un enfoque anterior era erróneo, explica por qué y describe el cambio.
Para el trabajo interactivo, esto es útil. Para un pipeline donde la respuesta alimenta un analizador, una interfaz de usuario u otro modelo, esa narración es ruido que se encuentra en un campo que se supone que debe contener una respuesta.
La instrucción es breve:
Do not narrate corrections or changes of approach.
Return only the final answer. If you revised your thinking, that
revision belongs in your reasoning, not in the response.
Si diriges las respuestas a un almacenamiento estructurado, combínalo con salidas estructuradas para que la forma se aplique en lugar de solicitarse.
Los modos de fallo con el pensamiento deshabilitado
Todo lo anterior es un problema de ajuste. Esta parte es un problema de corrección.
Anthropic documenta dos artefactos que aparecen ocasionalmente en Opus 5 cuando el pensamiento está deshabilitado a través de thinking: {type: "disabled"}. Ambos vale la pena conocerlos antes de implementar un agente.
Llamadas a herramientas escritas como texto plano. El modelo emite algo que parece una llamada a una herramienta, pero como texto en el cuerpo de la respuesta en lugar de como un bloque estructurado tool_use. Nada se ejecuta. En un chat de una sola interacción lo notarías. En un bucle de agente a menudo no: el bucle no ve ninguna llamada a herramienta, por lo que no realiza ninguna acción, y el texto filtrado permanece en el historial de conversación. Las interacciones posteriores leen ese texto como si se hubiera producido una llamada. El fallo se agrava a lo largo de las interacciones, y para cuando la salida parece incorrecta, la causa se remonta varias interacciones atrás.
Etiquetas XML internas en la salida visible. Etiquetas como <thinking> aparecen en la respuesta que el usuario ve. Estéticamente malo por sí solo, y peor si renderizas las respuestas como HTML o las analizas para obtener su estructura.
La parte contraintuitiva: nombrar las etiquetas en tu prompt empeora la fuga, no la mejora. Una instrucción como "nunca muestres etiquetas <thinking>" pone la secuencia de tokens en contexto y aumenta las probabilidades de que aparezca. No escribas esa instrucción.
La mitigación recomendada por Anthropic no es un prompt en absoluto. Es mantener el pensamiento habilitado y controlar el costo con un nivel de esfuerzo más bajo en su lugar:
{
"model": "claude-opus-5",
"max_tokens": 4096,
"output_config": { "effort": "low" },
"messages": [
{ "role": "user", "content": "..." }
]
}
Eso te da el extremo barato del rango sin los artefactos de pensamiento deshabilitado. También evita una trampa relacionada: en Opus 5, combinar thinking: {type: "disabled"} con un esfuerzo xhigh o max devuelve un 400, porque deshabilitar el pensamiento está limitado a un esfuerzo high. Ten en cuenta también que el pensamiento está ahora activado por defecto, por lo que una solicitud que simplemente omite el campo thinking se ejecuta con pensamiento adaptativo en lugar de sin él, como habría ocurrido en Opus 4.8.
Si tienes un requisito estricto para deshabilitar el pensamiento, añade una verificación defensiva en tu bucle en lugar de una instrucción en el prompt: rechaza cualquier turno del asistente cuyo cuerpo de texto contenga una cadena con forma de llamada no ejecutada antes de añadirla al historial. Falla ruidosamente en lugar de permitir que una llamada fantasma entre en la transcripción.
Prueba los cambios en lugar de adivinar
Es difícil evaluar los cambios en los prompts leyéndolos. Los comportamientos aquí (longitud de la respuesta, pases de verificación, recuento de subagentes) se muestran como recuentos de tokens y estructura de la carga útil, lo que significa que la forma honesta de verificar tu trabajo es enviar las solicitudes y comparar.
Eso es sencillo de configurar en Apidog, que es una plataforma todo en uno para el desarrollo y prueba de API:
- Crea una solicitud contra el endpoint de mensajes de Anthropic con
"model": "claude-opus-5", y guarda tu clave API como una variable de entorno en lugar de pegarla en el cuerpo. - Guarda tu antiguo prompt del sistema Opus 4.8 y tu versión recortada de Opus 5 como dos solicitudes guardadas contra la misma entrada.
- Compara el bloque
usageen cada respuesta. Los tokens de salida te indicarán si la restricción de concisión se aplicó; los tokens de entrada y los campos de caché te indicarán si tus ediciones del prompt rompieron un prefijo de caché. - Duplica la solicitud a través de diferentes niveles de esfuerzo para ver por ti mismo cómo los tokens de pensamiento disminuyen mientras la longitud visible se mantiene.
- Inspecciona la respuesta de streaming para confirmar que las llamadas a herramientas llegan como bloques estructurados
tool_usey no como texto.
El paso cinco es el que detecta el fallo de la llamada a la herramienta en texto plano antes de que llegue a producción. Descarga Apidog si quieres ejecutar esto lado a lado, y consulta el tutorial de la API de Opus 5 para ver la forma completa de la solicitud.
El techo honesto
Vale la pena decirlo claramente, ya que las guías de prompting tienden a leerse como si el modelo fuera el último que necesitarás: Opus 5 no es la cima de la pila de Claude. Fable 5 mantiene la designación de "el más capaz ampliamente lanzado", y Opus 5 todavía está por detrás de Mythos 5 en explotación de ciberseguridad e investigación de biología autónoma. Anthropic dice ambas cosas en su propia publicación de lanzamiento. El encuadre preciso es una capacidad de clase frontera a la mitad del precio de frontera, con un techo nombrado por encima.
Las afirmaciones de los benchmarks de lanzamiento (Frontier-Bench, ARC-AGI 3, OSWorld 2.0, CursorBench) son todas cifras propias de Anthropic y no han sido reproducidas de forma independiente hasta el 25 de julio de 2026. Trátalas como informadas por el proveedor y ejecuta tus propias evaluaciones en los prompts que realmente implementes.
Armándolo todo
Un prompt de sistema Opus 5 recortado para una tarea de agente sensible al costo se vería aproximadamente así:
Do not add verification passes; you verify by default.
Responses: 150 words maximum, no preamble, no closing summary.
Do not spawn subagents. Handle this in one thread.
Stay strictly within the task I state. If another change seems
required, stop and tell me rather than making it.
Do not narrate corrections or changes of approach.
Seis líneas, cinco de las cuales son restricciones y ninguna de las cuales pide al modelo que se esfuerce más. Ese es el cambio. En Opus 4.8 se solicitaba elevar un piso. En Opus 5 se solicita establecer un techo.
Comienza ahí, luego realiza un barrido de esfuerzo en tus propias evaluaciones en lugar de trasladar tus configuraciones de 4.8, ya que los niveles fueron recalibrados. Para la mecánica de los parámetros, consulta la guía del parámetro de esfuerzo, para el flujo de trabajo del lado del editor, consulta usando Opus 5 en Claude Code, y para la imagen completa del modelo, comienza en qué es Claude Opus 5. La visión general de modelos de Anthropic tiene la tabla de especificaciones actual.
Preguntas Frecuentes
¿Debería realmente eliminar "revisa tu trabajo" de mis prompts? Sí. La guía de prompting de Anthropic dice que Opus 5 verifica sin necesidad de ser solicitado, y las instrucciones de verificación heredadas causan una sobre-verificación. Elimina la regla global. Si un paso específico realmente necesita una verificación explícita, limita la instrucción solo a ese paso.
¿Por qué Opus 5 es tan verboso incluso con poco esfuerzo? Porque el esfuerzo controla el pensamiento, no la longitud de la salida visible. Reducir el esfuerzo recorta los tokens de razonamiento mientras las respuestas permanecen aproximadamente igual de largas. Establece un límite de palabras o formato en el propio prompt.
¿Cómo evito que Opus 5 genere subagentes? Dilo directamente: "No generes subagentes; maneja esto en esta conversación". Si alguna ramificación es útil, establece un límite numérico y restringe el trabajo a tareas paralelas independientes.
¿Por qué veo etiquetas <thinking> en mi salida? Ese artefacto aparece ocasionalmente cuando el pensamiento está deshabilitado. No añadas una instrucción en el prompt que nombre las etiquetas, ya que eso hace que la fuga sea más probable. La solución recomendada por Anthropic es mantener el pensamiento habilitado y usar un nivel de esfuerzo más bajo para controlar el costo.
¿Qué sucede si una llamada a una herramienta regresa como texto plano? Nada se ejecuta, y el texto filtrado permanece en el historial de conversación donde los turnos posteriores lo tratan como una acción completada. Valida los turnos del asistente antes de agregarlos al historial, y prefiere mantener el pensamiento activado en lugar de deshabilitarlo.