Migración a Opus 5, cuando pensar pasa a ser lo normal

Opus 5 salió el 24 de julio de 2026. Si hiciste la migración a 4.8 recuerdas un playbook tranquilo: cambias el campo del modelo, listo, cero breaking changes. Esta vez es distinto. El cambio de nombre sigue siendo una línea, pero detrás hay dos cambios de comportamiento reales, uno de los cuales vuelve como un error 400 duro, y un tercero que empeora tus prompts existentes en vez de mejorarlos.

Lo bueno primero: el precio se queda en 5 dólares por millón de tokens de entrada y 25 de salida, exactamente como 4.8. Pagas lo mismo por un modelo bastante más fuerte. Este playbook es para ti si tienes código de API, usas Claude Code como daily driver, o operas agentes que hasta ahora corrían sobre 4.8.

Paso 1, el cambio de nombre

Busca el string del modelo en tu código y cámbialo.

grep -rn "claude-opus-4-8" src/
# cada resultado pasa a claude-opus-5

El ID es claude-opus-5, sin sufijo de fecha, mismo esquema que claude-opus-4-8 y claude-sonnet-5. Hay algo nuevo: ya no existe una variante 1M separada. En 4.8 tenías que escribir claude-opus-4-8[1m] si querías la ventana de contexto grande. En Opus 5, 1 millón de tokens es a la vez el valor por defecto y el máximo, sencillamente no hay nada más pequeño. Si tienes una escritura [1m] en algún sitio, fuera.

La salida máxima son 128k tokens. El modelo está disponible en la Claude API, en Amazon Bedrock (como anthropic.claude-opus-5), en Google Cloud y en Microsoft Foundry. Opus 4.8 sigue accesible en todas partes, así que nadie te migra a la fuerza.

En Claude Code necesitas al menos la v2.1.219. En Max, Team Premium, Enterprise pay-as-you-go y la API, Opus 5 ya es el Opus por defecto. Si tu versión es más antigua, corre claude update y después /model para comprobarlo.

Paso 2, el thinking ahora corre siempre

Esta es la migración de verdad, y ocurre sin que cambies una sola línea.

En Opus 4.8 una petición corría sin thinking mientras no pusieras explícitamente thinking: {"type": "adaptive"}. En Opus 5 esa misma petición corre con thinking. El modelo decide solo cuándo y cuánto piensa, controlado por el parámetro effort. El valor antiguo sigue siendo válido, thinking: {"type": "adaptive"} ahora es simplemente idéntico al comportamiento por defecto.

El problema está en otro sitio: max_tokens es un techo duro para la salida total, es decir pensamiento más respuesta visible. Los tokens de pensamiento no quedan fuera de ese límite. Si en 4.8 ibas con max_tokens: 16000 y eso bastaba sin thinking, ahora dos consumidores comparten el mismo presupuesto. En el peor caso el modelo piensa y la respuesta se corta.

# Opus 4.8, corria sin thinking
client.messages.create(
    model="claude-opus-4-8",
    max_tokens=16000,
    messages=[{"role": "user", "content": "..."}],
)

# Opus 5, misma peticion, el thinking corre
# y cuenta contra los mismos 16000
client.messages.create(
    model="claude-opus-5",
    max_tokens=16000,
    messages=[{"role": "user", "content": "..."}],
)

Repasa las cargas que hasta ahora corrían sin thinking y sube max_tokens. Como número orientativo, calcula entre un 30 y un 50 por ciento por encima de lo que necesitabas solo para la respuesta, y luego mide en vez de adivinar.

Paso 3, el 400 que tienes que conocer

thinking: {"type": "disabled"} sigue existiendo, pero solo hasta el nivel de effort high. Si lo combinas con xhigh o max, te vuelve un error 400. En Opus 4.8 eran dos interruptores independientes, aquí es uno solo.

Por eso esta migración no pasa a ciegas. Si desactivas el thinking en algún sitio y a la vez vas con effort alto, la petición se rompe. No de forma sutil, no más lenta, sino de inmediato.

Dos salidas limpias. O dejas el thinking desactivado y bajas el effort a high o menos. O mantienes el effort alto y simplemente quitas el campo thinking, con lo que entra el valor por defecto.

# Rechazado
thinking={"type": "disabled"},
output_config={"effort": "xhigh"},

# Opcion A, el thinking sigue desactivado, baja el effort
thinking={"type": "disabled"},
output_config={"effort": "high"},

# Opcion B, el effort sigue alto, fuera el campo thinking
output_config={"effort": "xhigh"},

Anthropic recomienda la opción B, y hay una razón práctica. Con el thinking desactivado, Opus 5 escribe de vez en cuando una llamada a herramienta como texto normal en la respuesta, en lugar de emitir un bloque tool_use limpio, o se cuelan etiquetas XML internas en la salida visible. Si tu pipeline parsea llamadas a herramientas, esa es justo la clase de fallo que descubres en producción. Dejar el thinking encendido y controlar el coste con un effort más bajo es el camino más estable.

Paso 4, el effort es el mando principal

La escalera está completa: low, medium, high, xhigh, max. El valor por defecto es high. Lo nuevo es cuánto pesa. Opus 5 convierte effort adicional en mejores resultados de forma más fiable que cualquier Opus anterior, o sea que el nivel que elijas cuenta más que antes.

El consejo de Anthropic: empieza en high y ajusta en las dos direcciones según tus propias evals. Hacia abajo donde la calidad aguante, eso ahorra tokens y latencia. Hacia arriba para lo realmente duro. Si vas a xhigh o max, pon max_tokens con generosidad, 64k es un punto de partida útil, para que el modelo tenga sitio para pensar y trabajar a lo largo de varias llamadas a herramientas.

Una trampa específica de Claude Code que es fácil pasar por alto. Con Fable 5, Opus 4.8 y Opus 4.7, Claude Code impone en el primer arranque el effort por defecto del propio modelo, aunque en su día hubieras puesto otra cosa para otro modelo. Opus 5 no hace eso. Un nivel que pusiste antes se mantiene. Así que si hace meses corriste /effort low y se te olvidó, tu Opus 5 va en low y te preguntas por qué el modelo celebrado responde tan plano. Escribir /effort una vez para mirarlo cuesta cinco segundos.

Paso 5, borra la frase de verificación de tus prompts

Este es el punto que más gente pasa por alto, porque no tiene nada que ver con la API.

Opus 5 revisa su propio trabajo por iniciativa propia, sin que se lo pidas. Anthropic lo dice de forma explícita: quita las instrucciones de verificación que escribiste para modelos anteriores. Frases como "añade un paso final de verificación" o "usa un subagente para comprobarlo" tenían sentido en 4.8 y en Opus 5 provocan sobre-verificación. El modelo comprueba entonces dos veces, gasta más tokens y se vuelve más lento sin ser mejor.

Busca esas formulaciones exactas en tus system prompts, tus archivos CLAUDE.md y tus definiciones de agentes, y bórralas. Es el caso poco común en el que menos prompt da mediblemente más resultado.

Otros tres cambios de comportamiento que notarás sin tocar código. Las respuestas y los entregables escritos salen más largos que en 4.8. En sesiones agénticas el modelo cuenta más a menudo lo que está haciendo. Y en montajes multi-agente delega con más facilidad en subagentes. Nada de eso es un fallo, pero si tu pipeline depende de respuestas cortas o de una forma de salida concreta, pasa una vez por tus rutas más importantes.

Paso 6, las novedades menores

El mínimo de la caché de prompts baja de 1.024 a 512 tokens. Prompts que en 4.8 eran demasiado cortos para cachearse ahora generan entradas de caché sin que cambies nada. Si corres muchos system prompts cortos y recurrentes, eso es ahorro silencioso.

Fast mode también existe para Opus 5, como research preview y solo en la Claude API, no en Bedrock, Google Cloud ni Microsoft Foundry. Precio 10 dólares de entrada, 50 de salida por millón, o sea el doble del precio estándar por unas dos veces y media de velocidad. La misma cuenta que en 4.8: solo compensa donde la latencia cuesta dinero real o UX real.

Dos funciones en beta, por si te hacen falta. Las listas de herramientas se pueden cambiar ahora en mitad de la conversación sin perder la caché de prompts, con la cabecera beta mid-conversation-tool-changes-2026-07-01. Y el parámetro fallbacks tiene un modo "default" nuevo que usa los modelos de fallback recomendados por Anthropic en vez de una lista que mantienes tú, con la cabecera server-side-fallback-2026-07-01.

Lo que no funciona en Opus 5

El extended thinking manual con budget_tokens ya no existe, solo queda el thinking adaptativo a través del parámetro effort. El prefill mediante un mensaje de assistant preparado no está soportado, para eso usas instrucciones en el system prompt. La herramienta de web fetch no está disponible. Priority Tier no existe para Opus 5, Opus 4.8 lo conserva. Y como ya pasaba en 4.8, temperature, top_p y top_k devuelven un 400 en cuanto los pones en algo distinto al valor por defecto, así que fuera del todo.

Lista de migración, siete puntos

Uno, cambiar el campo del modelo de claude-opus-4-8 a claude-opus-5 y de paso eliminar toda escritura [1m].

Dos, encontrar todas las cargas que corrían sin campo thinking y subir max_tokens, porque los tokens de pensamiento ahora cuentan.

Tres, buscar la combinación thinking: {"type": "disabled"} más effort xhigh o max y resolverla, si no, 400.

Cuatro, quitar temperature, top_p, top_k de todas las peticiones si aún no lo has hecho.

Cinco, borrar las instrucciones de verificación de los system prompts y las definiciones de agentes, ahora generan sobre-verificación.

Seis, pasar en Claude Code al menos a la v2.1.219 y comprobar una vez /effort, porque Opus 5 se queda con un nivel antiguo en lugar de poner el valor por defecto.

Siete, volver a medir coste y latencia sobre tus cargas reales. Los ajustes de effort de 4.8 ya no son un buen punto de partida.

¿Deberías migrar?

Sí. Mismo precio, modelo bastante más fuerte, y Opus 4.8 sigue disponible como camino de vuelta. Las mejoras están justo donde duele la operación con agentes: aguantar la tarea a lo largo de bucles largos de herramientas, razonamiento en varios pasos, revisión de código con pocos falsos positivos, y coordinación de varios subagentes sin que se pisen el trabajo.

Pero no la apruebes a ciegas. Las tres cosas que de verdad pueden morderte son max_tokens contando ahora el pensamiento, el 400 con el thinking desactivado y effort alto, y las viejas frases de verificación en tus prompts. Las tres las encuentras en diez minutos con grep.

Qué sigue

Si vienes de 4.7 o anterior, haz primero la migración a Opus 4.8 y antes la migración a Opus 4.7, ahí están los breaking changes antiguos. Si quieres saber cómo enterarte siquiera de los lanzamientos de modelos, en vez de descubrirlos por casualidad, Seguir la disponibilidad de modelos enseña el montaje. Para el lado del coste de la nueva escalera de effort, Controles de coste de Claude Code para daily drivers tiene el flujo de medición. Y antes de llevar una migración a producción, lo mejor es construirte un pequeño conjunto de pruebas, para eso está Eval de agentes en 60 minutos.

Source

• Anthropic, Claude Opus 5: https://www.anthropic.com/news/claude-opus-5
• What's new in Claude Opus 5: https://platform.claude.com/docs/en/about-claude/models/whats-new-opus-5
• Migration Guide: https://platform.claude.com/docs/en/about-claude/models/migration-guide
• Prompting Claude Opus 5: https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5
• Claude Code Model Configuration: https://code.claude.com/docs/en/model-config