Cambias una línea. Un campo model dentro de un JSON. Diez segundos de trabajo, deploy a staging, a otra cosa.
Veinte minutos después el endpoint de resúmenes devuelve textos cortados a mitad de frase. Y una ruta concreta —la de análisis largo, la que más te importa— devuelve 400 sin que hayas tocado nada más.
No es un bug de Anthropic. Eres tú, migrando a Claude Opus 5 como si fuera un cambio de versión menor.
No lo es. Y el problema es que casi todo lo que vas a leer estos días sobre este modelo son tablas de benchmarks. El titular es que cuesta la mitad que Fable 5. La letra pequeña es que si no tocas dos parámetros, tu aplicación empieza a devolver respuestas cortadas y errores 400.
Este post va de la letra pequeña.
Qué es Claude Opus 5 y qué cambia respecto a Opus 4.8
Claude Opus 5 es el modelo más capaz de Anthropic, disponible desde el 24 de julio de 2026 con el identificador de API claude-opus-5, sin sufijo de fecha. Cuesta $5 por millón de tokens de entrada y $25 de salida —el mismo precio que Opus 4.8— y trae dos breaking changes respecto a la generación anterior: el thinking viene activado por defecto y desactivarlo deja de ser compatible con los niveles de effort xhigh y max.
| Atributo | Claude Opus 5 | Claude Opus 4.8 |
|---|---|---|
| ID de API | claude-opus-5 |
claude-opus-4-8 |
| Precio entrada / salida | $5 / $25 por millón | $5 / $25 por millón |
| Fast mode (solo API de Anthropic) | $10 / $50 por millón | — |
| Thinking al omitir el parámetro | Adaptativo, activado | Desactivado |
Qué cubre max_tokens |
Thinking + respuesta | Solo la respuesta |
| Effort por defecto en la API | high |
— |
thinking: disabled + xhigh/max |
HTTP 400 | Válido |
| Mínimo para prompt caching | 512 tokens | 1024 tokens |
| Ventana de contexto | 1M tokens (defecto y máximo) | — |
| Salida máxima | 128K tokens | — |
| Rate limits | Cubo propio | Pool combinado Opus 4.x |
Está disponible en Claude.ai, Claude Code, Claude Cowork, la API de Anthropic, Amazon Bedrock (anthropic.claude-opus-5), Google Cloud y Microsoft Foundry. Es el modelo por defecto en Claude Max y el más potente disponible en Claude Pro. Los datos de esta tabla están contrastados con la documentación oficial de Anthropic.
Los benchmarks de Claude Opus 5, en treinta segundos
Sí, los números son buenos. Los despacho rápido porque no son el tema.
En CursorBench 3.2, a máximo effort, Claude Opus 5 se queda a un 0,5% del pico de Fable 5 —a la mitad de coste por tarea—. En ARC-AGI 3 triplica la puntuación del siguiente mejor modelo. En Frontier-Bench v0.1 más que dobla el rendimiento de Opus 4.8. Los tres resultados salen de las cifras publicadas por Anthropic.
No es el mejor en todo: sigue por detrás de Mythos 5 en tareas de ciberseguridad ofensiva. Y Anthropic lo describe como su modelo mejor alineado hasta la fecha, con la menor tasa de comportamiento engañoso.
Si vienes de Claude Opus 4.8, pagas lo mismo por token por un modelo bastante mejor. Con un matiz que casi nadie menciona: Opus 5 piensa por defecto y escribe más largo, así que gasta más tokens por tarea. Misma tarifa no significa misma factura. Y si estabas pagando el premium de Fable 5 por tareas de agente, ahí sí: Anthropic mide la mitad de coste por tarea.
Perfecto. Ahora la parte que rompe cosas.
Breaking change 1 de Claude Opus 5: el thinking viene activado por defecto
En Claude Opus 5, omitir el parámetro thinking ejecuta thinking adaptativo; en Opus 4.8 y 4.7 omitirlo significaba no razonar. Este es el cambio que corta tus respuestas a mitad de frase.
Antes, el silencio equivalía a "no razones, contéstame". Ahora el silencio es un sí.
Y aquí viene la parte que duele: max_tokens es un tope duro sobre thinking más texto de respuesta, juntos. No son dos presupuestos separados.
Si tenías max_tokens ajustado al milímetro para tu respuesta —y todo el que ha optimizado costes lo tiene ajustado al milímetro— el modelo se gasta parte de ese presupuesto razonando y la respuesta se corta.
Este código funcionaba perfectamente ayer:
import Anthropic from "@anthropic-ai/sdk";
const client = new Anthropic();
// Opus 4.8 — omitir "thinking" = sin razonamiento; 1024 tokens íntegros para la respuesta
const res = await client.messages.create({
model: "claude-opus-4-8",
max_tokens: 1024,
messages: [{ role: "user", content: prompt }],
});
Cambias el model a claude-opus-5 y esos 1024 tokens ahora se reparten entre razonamiento y respuesta. Nadie te avisa: no hay error, solo un texto que termina a media frase.
Tienes dos salidas. La buena:
// Opus 5 — thinking explícito y presupuesto con margen
const res = await client.messages.create({
model: "claude-opus-5",
max_tokens: 8192, // cubre thinking + respuesta
thinking: { type: "adaptive", display: "summarized" },
output_config: { effort: "medium" },
messages: [{ role: "user", content: prompt }],
});
Y la que replica el comportamiento anterior:
thinking: { type: "disabled" }
Cuidado con esa segunda, porque tiene trampa. Es exactamente el breaking change número dos.
Sobre display: los tokens de razonamiento en crudo no se devuelven nunca. El valor por defecto es "omitted". Si pones "summarized" recibes un resumen legible del razonamiento, útil para logs y para depurar por qué el modelo llegó a donde llegó.
Breaking change 2: desactivar el thinking en Opus 5 está capado a effort high
Esta es la que devuelve 400.
En Opus 5 la escala completa de effort es low, medium, high, xhigh y max. El valor por defecto de la API es high.
Combinar thinking: { type: "disabled" } con effort xhigh o max devuelve HTTP 400. En Opus 4.8 esa combinación era perfectamente válida.
// Válido en Opus 4.8 — error 400 en Opus 5
const res = await client.messages.create({
model: "claude-opus-5",
max_tokens: 4096,
thinking: { type: "disabled" },
output_config: { effort: "xhigh" }, // 400
messages: [{ role: "user", content: prompt }],
});
Y ahora el detalle que hace que esto sea peligroso de verdad: la validación es por petición. No hay un chequeo global al arrancar. Puedes tener veinte llamadas funcionando con thinking desactivado y effort high, y que la veintiuna —la que sube a xhigh para el caso difícil— se rechace. Las anteriores funcionando no te protegen de nada.
Traducido: cualquier ruta de tu código que desactive el thinking hay que auditarla antes de migrar, no después. Búscalo con un grep por "disabled" y revisa qué effort viaja en cada una de esas peticiones.
Mi recomendación es no mantener esa ruta. En lugar de desactivar el thinking, bájalo a effort medium con thinking activado:
// Sustituto recomendado para las rutas que antes desactivaban thinking
thinking: { type: "adaptive" },
output_config: { effort: "medium" },
En Opus 5 los niveles low y medium rinden inusualmente bien. La intuición de "menos effort, peor respuesta" que traías de la generación anterior ya no aplica igual: prueba medium antes de asumir que necesitas high.
Con un matiz, para que nadie me lea en diagonal: para coding y trabajo agéntico, Anthropic recomienda arrancar en xhigh y bajar solo donde tus evals demuestren que la calidad aguanta. Lo de medium es el sustituto de las rutas que antes desactivaban el thinking, no un consejo para bajarle el effort a tu agente de coding. Y si al bajarlo compruebas que la tarea nunca necesitó Opus, Claude Sonnet 5 cubre buena parte de ese terreno por bastante menos dinero.
El tercer sitio donde revienta: el rechazo que llega con un 200
Este no está en la lista oficial de breaking changes, pero te va a tirar producción igual.
Los clasificadores de seguridad pueden declinar una petición. Cuando lo hacen, la API devuelve HTTP 200 con stop_reason: "refusal". No es un error. Tu try/catch no lo captura, tu retry no se dispara, tu monitorización no lo ve.
Y content llega vacío: un array sin bloques. Así que este patrón —el que escribe todo el mundo la primera vez— revienta con un TypeError:
const res = await client.messages.create({ /* ... */ });
const text = res.content[0].text; // 💥 TypeError: content llega vacío
La corrección son cuatro líneas:
const res = await client.messages.create({ /* ... */ });
if (res.stop_reason === "refusal") {
logger.warn("Petición declinada por los clasificadores", { requestId: res.id });
return fallbackResponse();
}
const text = res.content.find((b) => b.type === "text")?.text ?? "";
Dos datos más que ayudan aquí. Un rechazo que llega antes de emitir output no se factura, aunque sí consume rate limit. Y si no quieres montar el fallback a mano, Anthropic tiene un parámetro fallbacks en modo "default" (con el beta header server-side-fallback-2026-07-01) que reencamina la petición rechazada a otro modelo dentro de la misma llamada: los rechazos de categoría ciber caen a Opus 4.8.
Comprueba stop_reason antes de leer content. Siempre. Con este modelo y con el siguiente.
Dos cambios de comportamiento que te van a sorprender
Escribe respuestas más largas por defecto. Y bajar el effort no lo arregla —es un eje distinto—. Si necesitas respuestas breves, pídelo en el prompt de forma explícita: límite de palabras, formato, o ambos.
Verifica su propio trabajo sin que se lo pidas. Esta es la importante, porque invierte una buena práctica de prompting que era válida hasta la semana pasada.
Todos tenemos system prompts con alguna variante de "revisa tu respuesta antes de contestar". En Opus 5 esas instrucciones provocan verificación excesiva: más tokens, más latencia, misma calidad. La solución no es reescribirlas con mejor redacción. Es borrarlas.
Con la delegación en subagentes el ajuste es distinto. Opus 5 delega más que Opus 4.8 por defecto, así que los empujones que añadiste para forzarla ahora sobran. Pero aquí no basta con borrar: la recomendación de Anthropic es poner límites —en qué escenarios se delega, o cuántos subagentes como máximo—. Pasas de empujar a acotar.
Es la parte contraintuitiva del oficio: mantener un system prompt no es acumular reglas, es borrarlas cuando el modelo ya no las necesita. Es exactamente el criterio que trabajo en el curso Construye con IA, donde el prompt se trata como código con mantenimiento, no como un texto que se escribe una vez y se olvida.
Lo que mejora en Claude Opus 5 sin que toques nada
El mínimo de prompt caching baja a 512 tokens. En Opus 4.8 eran 1024, y el umbral está en la documentación de prompt caching. Prompts de sistema que antes se quedaban justo por debajo del umbral y no cacheaban, ahora sí cachean, sin cambiar una línea de código.
Si tienes muchas llamadas cortas y repetitivas, revisa la factura la semana que viene: puede bajar sola. Y si aún no tienes el caching bien montado, la mecánica completa está en Prompt Caching en Claude: reduce tu factura de API un 90%.
Otros dos datos que conviene tener a mano: la ventana de contexto es de 1M tokens —es a la vez el valor por defecto y el máximo— con 128K tokens de salida. Y los rate limits de Opus 5 son un cubo separado del pool combinado de Opus 4.x: al migrar tráfico no heredas tu cuota anterior. Si mueves un volumen serio, comprueba límites antes del despliegue y no el lunes por la mañana con todo el tráfico encima.
Cómo migrar a Claude Opus 5 en 4 pasos
Cuatro pasos, en este orden:
- Grep por
"disabled"en todas tus llamadas al thinking. Cada resultado, con su effort al lado. Si hayxhighomax, es un 400 esperándote. - Revisa tus
max_tokens. Todo lo que esté ajustado al límite de la respuesta necesita margen para el thinking, o cambia athinking: { type: "disabled" }con efforthighcomo máximo. - Comprueba
stop_reasonantes de leercontent. Cuatro líneas. - Borra las instrucciones de auto-verificación de tus system prompts. No las reescribas. Y en las de delegación, cambia el empujón por un límite: cuándo se delega y cuántos subagentes como máximo.
Media hora de trabajo. Y a cambio: te acercas a la inteligencia frontera de Fable 5 por la mitad de coste por tarea.
Si quieres ver este tipo de migraciones aplicadas sobre proyectos reales —con los prompts, el código y los errores que salen por el camino— es lo que hacemos en Dominicode Labs, y voy publicando los análisis modelo a modelo en el canal de YouTube.
El precio lo pone Anthropic. Los 400 los pones tú.
Preguntas frecuentes sobre Claude Opus 5
¿Cuánto cuesta Claude Opus 5?
$5 por millón de tokens de entrada y $25 por millón de tokens de salida, exactamente el mismo precio que tenía Opus 4.8. Fable 5 cuesta $10/$50, así que Opus 5 se acerca a esa franja de inteligencia frontera por la mitad. Existe un fast mode disponible únicamente en la API de Anthropic que cuesta el doble: $10/$50. En suscripciones, es el modelo por defecto de Claude Max y el más potente disponible en Claude Pro.
¿Qué se rompe al migrar de Opus 4.8 a Claude Opus 5?
Dos cosas concretas. Primera: el parámetro thinking ahora viene activado por defecto, y como max_tokens es un tope duro sobre thinking más respuesta juntos, los presupuestos ajustados provocan respuestas cortadas a mitad de frase. Segunda: thinking: { type: "disabled" } combinado con effort xhigh o max devuelve un error 400, cuando en Opus 4.8 esa combinación era válida. A eso conviene sumar una tercera comprobación: los rechazos de los clasificadores llegan como HTTP 200 con stop_reason: "refusal", no como error.
¿Cómo desactivo el thinking en Claude Opus 5?
Con thinking: { type: "disabled" }, pero solo puedes hacerlo hasta effort high. Si envías esa configuración con xhigh o max, la petición se rechaza con un 400. Y ojo: la validación se hace petición a petición, así que una llamada posterior que suba el effort se rechazará aunque todas las anteriores hayan funcionado. En la mayoría de casos compensa más bajar a effort medium con el thinking activado, porque en Opus 5 los niveles low y medium rinden bastante mejor de lo que esperarías.
¿Sigo necesitando el «revisa tu respuesta antes de contestar» en mis prompts?
No, y además es contraproducente. Opus 5 verifica su propio trabajo sin que se lo pidas, así que esas instrucciones provocan verificación excesiva: gastas más tokens y añades latencia sin ganar calidad. La recomendación es borrarlas, no reescribirlas. Con la delegación en subagentes el ajuste es distinto: los empujones para forzarla sobran, pero Anthropic recomienda sustituirlos por un límite explícito —en qué escenarios se delega y cuántos subagentes como máximo—, porque Opus 5 delega más que Opus 4.8 por defecto.
¿Hay que cambiar algo para aprovechar el prompt caching en Opus 5?
Nada. El mínimo de tokens necesario para cachear baja de 1024 a 512, así que los prompts que antes eran demasiado cortos para entrar en caché ahora cachean automáticamente, sin tocar código. Si tu carga de trabajo son muchas llamadas cortas con un system prompt repetido, es probable que la factura baje sola tras migrar.
¿Puedo mover todo mi tráfico de Opus 4.x a Opus 5 de golpe?
Técnicamente sí, pero revisa los rate limits antes. Los límites de Opus 5 son un cubo separado del pool combinado de Opus 4.x, de modo que al migrar no heredas la cuota que ya tenías asignada. Si mueves un volumen alto sin comprobarlo, puedes empezar a recibir throttling con un código que hasta ese momento no lo veía nunca.
Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.
