Claude Opus 5: precio, niveles de esfuerzo y cuándo usarlo

Claude Opus 5 es el modelo premium de Anthropic para programación compleja, agentes y trabajo empresarial. Se lanzó el 24 de julio de 2026 con una promesa sencilla: ofrecer gran parte de la capacidad de Fable 5 al precio del anterior Opus.

Por precio, actualizar desde Opus 4.8 es una decisión fácil. Adoptarlo en producción exige más cuidado. El razonamiento ahora está activo de forma predeterminada, el nivel de esfuerzo cambia cuánto trabaja el modelo con texto y herramientas, y un límite de salida antiguo puede interrumpir una tarea antes de que termine de razonar.

Claude Opus 5 es el modelo premium para cada día, no el techo absoluto

Opus 5 encaja en el trabajo difícil que se repite a diario. Sonnet 5 conviene cuando mandan el volumen y la latencia. Fable 5 debe reservarse para tareas que ya hayan fallado en una evaluación con Opus y cuyo costo de fallo supere la prima de 2x por token.

Así presenta también Anthropic su catálogo actual. Su guía vigente de modelos recomienda a los desarrolladores indecisos comenzar con Opus 5 para programación agéntica compleja y trabajo empresarial, y pasar a Fable 5 cuando necesiten la máxima capacidad disponible.

Opus 5 dispone de una ventana de contexto de 1 millón de tokens y una salida síncrona máxima de 128,000 tokens. La ventana de contexto es el material que el modelo puede mantener a la vista durante una solicitud; no garantiza que todos los tokens reciban la misma atención. El límite de salida incluye tanto el razonamiento oculto como la respuesta visible, algo especialmente importante al migrar.

El ID del modelo es claude-opus-5. Está disponible mediante la API de Claude, Amazon Bedrock, Google Cloud y Microsoft Foundry. En la aplicación Claude, Anthropic lo convirtió en el modelo predeterminado de Max y en el más potente disponible en Pro.

No se trata de una clasificación permanente. Es una política de enrutamiento capaz de sobrevivir al próximo lanzamiento de modelos, porque cada cambio depende de evidencia obtenida con la carga de trabajo y no de la lealtad a una categoría.

El dato clave del benchmark es el costo por tarea completada

El resultado útil de Opus 5 en los benchmarks no es que gane en todo, sino que a menudo consigue el mismo resultado aceptado con una ejecución más barata.

Anthropic publica cinco resultados que orientan la decisión:

• En Frontier-Bench v0.1, Opus 5 supera por más del doble el rendimiento de Opus 4.8 con un costo por tarea inferior.
• En CursorBench 3.2, Opus 5 con esfuerzo max queda a no más de un 0.5% del mejor resultado de Fable 5 y cuesta la mitad por tarea.
• En ARC-AGI 3, obtiene una puntuación tres veces superior a la del siguiente mejor modelo de la comparación de Anthropic.
• En Zapier AutomationBench, su tasa de aprobación es de alrededor de 1.5 veces la del siguiente mejor modelo con el mismo costo por tarea. Incluso con el nivel de esfuerzo más bajo, supera en tareas aprobadas a cualquier otro modelo de esa comparación.
• En OSWorld 2.0, supera el mejor resultado de Fable 5 en uso de computadoras por poco más de un tercio del costo.

Son resultados de lanzamiento publicados por el proveedor, no una clasificación universal para cualquier repositorio, documento de políticas o flujo de trabajo en el navegador. Sí aportan evidencia orientativa de que el esfuerzo puede convertir tokens adicionales en trabajo aceptado. No indican cuántos reintentos necesitará un agente propio, con qué frecuencia una persona rechazará una respuesta ni si un resultado más rápido pero algo más débil se adapta mejor al objetivo de nivel de servicio.

El costo por tarea completada incorpora esas variables. Hay que sumar el costo de tokens de todos los intentos, los cargos por llamadas a herramientas, la latencia que tenga valor para el producto y la revisión humana. Después, se divide el total entre los resultados que cumplen la regla de aceptación.

En un agente de programación, el éxito podría significar que las pruebas pasan, el diff se mantiene dentro del alcance y un revisor lo acepta sin una ronda de correcciones. En un agente de operaciones, podría significar que el registro se actualiza correctamente, se solicita la aprobación adecuada y no se ejecuta ninguna acción sin respaldo. La rúbrica debe describir el resultado antes de comparar niveles de esfuerzo.

La inteligencia aparente del modelo no es la métrica. Lo es el resultado aceptado con un costo conocido.

Una carga de trabajo fija cuesta $9, $22.50 o $45

Con la misma distribución de tokens, Opus 5 queda exactamente a medio camino entre el precio temporal de Sonnet 5 y el de Fable 5.

Supongamos 100 tareas. Cada una envía 20,000 tokens de entrada y recibe 5,000 tokens de salida. El lote consume 2 millones de tokens de entrada y 500,000 de salida:

• Sonnet 5, con su tarifa introductoria de $2 para entrada y $10 para salida, cuesta $9.
• Opus 5, a $5 para entrada y $25 para salida, cuesta $22.50.
• Fable 5, a $10 para entrada y $50 para salida, cuesta $45.

El cálculo utiliza los precios vigentes de la API de Anthropic. La tarifa de Sonnet 5 de $2/$10 se mantiene hasta el 31 de agosto de 2026; después, el precio estándar pasa a $3/$15. El cálculo excluye el almacenamiento en caché de prompts, los descuentos por lotes, la búsqueda web, la ejecución de código, los reintentos y cualquier variación en el uso de tokens provocada por el modelo o el nivel de esfuerzo.

A esta escala reducida, Opus cuesta $13.50 más que Sonnet y Fable cuesta $22.50 más que Opus. A Opus le basta evitar una corrección valorada en más de $13.50 para justificar la prima frente a Sonnet en todo el lote. Fable debe evitar más de $22.50 en fallos o revisión para justificar el siguiente salto.

Con 10,000 tareas de la misma forma, los totales suben a $900, $2,250 y $4,500. Opus queda $1,350 por encima de Sonnet, mientras que Fable añade otros $2,250. Una decisión de enrutamiento que parece trivial en un prototipo se convierte en una partida presupuestaria al llegar a producción.

El modo Fast aclara todavía más la diferencia. Ejecuta Opus 5 unas 2.5 veces más rápido a $10/$50, el doble del precio normal. El ejemplo de 100 tareas costaría $45, el mismo total base por tokens que Fable 5. Tiene sentido cuando el tiempo de respuesta aporta suficiente valor al producto para justificar la prima, no como interruptor de velocidad predeterminado.

El control de esfuerzo es una política, no un presupuesto de tokens

El punto de partida es high. Es el valor predeterminado de la API de Claude y de Claude Code, y Anthropic indica que establecer high de forma explícita produce el mismo comportamiento que omitir el parámetro de esfuerzo.

El esfuerzo determina cuánto trabajo dedica Claude a toda la respuesta: texto visible, razonamiento, llamadas a herramientas y argumentos de funciones. Reducirlo puede disminuir el uso de tokens y la actividad de las herramientas; aumentarlo puede permitir una exploración más profunda. Sigue siendo una señal de comportamiento, no un límite estricto, por lo que una solicitud difícil en low todavía puede activar el razonamiento.

Los cinco niveles cumplen funciones distintas:

low sirve para trabajo barato y acotado. Es apropiado para clasificación, extracción, transformaciones simples y tareas estrechas de subagentes cuyo resultado sea fácil de verificar. Un agente de triaje que decide a qué cola enviar una solicitud encaja mejor que uno encargado de resolverla.

medium es el nivel equilibrado para producción. Conviene en trabajo rutinario asistido por herramientas cuando la ruta está clara pero cambia la entrada: resumir el expediente de un cliente, redactar una respuesta estándar o aplicar un procedimiento operativo bien definido. Es el primer escalón por debajo del valor predeterminado cuando importan el costo de tokens o la latencia.

high es el valor predeterminado para el trabajo diario difícil. Es adecuado para cambios de código, análisis con matices y agentes de varios pasos donde los errores cuestan lo suficiente como para exigir un razonamiento cuidadoso. Es el punto inicial correcto de medición, porque permite comparar cualquier nivel superior o inferior.

xhigh está pensado para trabajo de largo alcance. Anthropic lo describe como un nivel para tareas agénticas o de programación que pueden durar más de 30 minutos y usar presupuestos de millones de tokens. Conviene cuando el modelo debe explorar repetidamente, recurrir a muchas herramientas o mantener un plan durante una ejecución prolongada.

max es una ruta excepcional. Elimina las restricciones al gasto de tokens para buscar la máxima capacidad. Una tarea solo debe llegar aquí después de que falle xhigh, o cuando el resultado sea tan valioso que la eficiencia de tokens quede en segundo plano.

Hay dos errores fáciles de cometer.

Primero, no hay que usar el esfuerzo para controlar la longitud del texto. La documentación de Anthropic explica que cambiar el esfuerzo no acorta de forma fiable la respuesta visible de Opus 5. La extensión deseada debe pedirse en el prompt.

Segundo, no conviene comenzar en max todas las tareas que parecen difíciles. Así se impide comprobar si high habría sido suficiente y cualquier conversación posterior sobre costos queda en el terreno de las hipótesis. La comparación útil busca el nivel más bajo que alcanza el resultado de forma fiable, no la puntuación más alta que se pueda comprar.

Quién debería usar Opus 5, Sonnet 5 o Fable 5

La mayoría de los compradores no debería elegir un único modelo para todas las solicitudes. Resulta más eficaz definir un valor predeterminado y una ruta de escalamiento estrecha.

Una startup con financiación que desarrolla un producto de agentes

Sonnet 5 sirve para interacciones de gran volumen fáciles de validar; Opus 5, para los pasos que planifican, concilian contexto contradictorio o se recuperan tras el fallo de una herramienta.

El riesgo para una startup es poner Opus en cada turno porque parece la alternativa más segura. Si la mayoría de las solicitudes sigue una ruta predecible, la prima se gasta en trabajo que nunca la necesitó. La ruta económica debe ser amplia y la de Opus debe reservarse para los pasos que tienen consecuencias.

La orquestación compleja debe comenzar con Opus en high. Una clase difícil ya identificada solo debería subir a xhigh cuando la mejora de la tasa de aceptación cubra el uso adicional de tokens. Una tarea debe llegar a Fable únicamente después de que Opus falle en una versión representativa y el impacto para el negocio justifique el precio unitario de 2x.

Un CTO de una empresa mediana que estandariza la capa de modelos

Opus 5 puede ser el valor premium predeterminado, con el enrutamiento de modelos visible en la política. Así, el responsable de una carga de trabajo puede explicar por qué una tarea utiliza Sonnet, Opus o Fable y qué evaluación haría cambiar la ruta.

Migrar todas las solicitudes de Opus 4.8 no consiste en cambiar una cadena con el nombre del modelo y dar el trabajo por terminado. El razonamiento predeterminado altera el comportamiento de salida y el consumo de tokens. También deben revisarse la configuración existente de max_tokens, el diseño de conversaciones almacenadas en caché y los prompts de verificación.

El análisis de Claude Sonnet 5 sirve como referencia del límite inferior: Sonnet gana cuando mantiene resultados aceptados al precio vigente. Fable marca el límite superior. Opus ocupa el espacio intermedio hasta que alguno de los dos extremos demuestre ser mejor en una carga de trabajo concreta.

Un responsable sénior que automatiza operaciones de negocio

Opus conviene cuando el trabajo atraviesa sistemas o límites de políticas. Leer una solicitud, comprobar una cuenta, aplicar una regla y decidir si una persona debe aprobar es más difícil que redactar un resumen, porque cada paso cambia las consecuencias del siguiente.

medium es adecuado para procedimientos estables con herramientas acotadas. high resulta más apropiado cuando abundan las excepciones, los registros ambiguos o los textos de políticas contradictorios. Las acciones irreversibles deben conservar la aprobación humana incluso cuando el benchmark sea sólido. Un modelo mejor reduce la revisión rutinaria; no elimina la responsabilidad.

Fable solo resulta razonable cuando la tarea es a la vez extraordinariamente difícil y valiosa. Si una persona revisará todos los resultados de todos modos, mejorar la interfaz de revisión puede aportar más que pagar la prima adicional del modelo.

Una persona que desarrolla por su cuenta

Sonnet 5 es un buen punto de partida mientras cambia la forma del producto. Opus 5 puede asumir la depuración difícil, la revisión de arquitectura y las implementaciones que abarcan varios archivos. La diferencia importa sobre todo cuando un intento fallido obliga a reconstruir mucho contexto, no cuando se trata de una edición pequeña.

La elección más amplia entre proveedores sigue siendo independiente. GPT-5.6 y Claude Sonnet 5 difieren tanto en sus sistemas de ejecución como en la calidad del modelo. Opus 5 refuerza la ruta premium de Anthropic, pero no vuelve intercambiables la orquestación, los permisos de herramientas ni la observabilidad.

Para los cuatro perfiles, la decisión cambia en el mismo punto: hay que actualizar cuando el costo medido de los fallos y la revisión supera la prima del modelo. Si nadie ha cuantificado ese costo, la decisión empresarial prudente es evaluar antes de escalar.

Migrar desde Opus 4.8 cambia dos comportamientos

Cambiar claude-opus-4-8 por claude-opus-5 mantiene el mismo precio unitario de $5/$25, pero no conserva el mismo comportamiento durante la ejecución.

El primer cambio es el razonamiento predeterminado. Opus 4.8 podía funcionar sin razonar salvo que la solicitud lo activara. Opus 5 decide por defecto cuándo y cuánto razonar. Como max_tokens limita tanto el razonamiento como la respuesta visible, un valor que contenía con holgura una respuesta de Opus 4.8 puede truncar un agente de Opus 5 antes de que termine.

El segundo cambio es la relación entre razonamiento y esfuerzo. Si una solicitud desactiva el razonamiento y, a la vez, establece xhigh o max, la API devuelve HTTP 400. Cuando el razonamiento deba permanecer desactivado, el esfuerzo debe quedarse en high o menos; para niveles superiores, hay que retirar el campo que lo desactiva.

Anthropic también advierte que desactivar el razonamiento puede hacer que Opus 5 escriba ocasionalmente una llamada a una herramienta como texto normal o exponga etiquetas XML internas, en vez de emitir un bloque tool_use correcto. Siempre que sea posible, conviene mantener el razonamiento activo y controlar el gasto mediante el esfuerzo.

Esta es una solicitud válida en Python para una tarea prolongada de programación o de agentes:

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-5",
    max_tokens=64000,
    output_config={"effort": "xhigh"},
    messages=[
        {
            "role": "user",
            "content": (
                "Review this repository migration plan. Identify unsafe "
                "assumptions, propose the smallest sound change, and verify "
                "the final plan against the stated acceptance criteria."
            ),
        }
    ],
)

for block in response.content:
    if block.type == "text":
        print(block.text)

El límite de 64,000 tokens es el punto de partida sugerido por Anthropic para xhigh o max, no un requisito para todas las solicitudes. Debe reducirse después de observar el uso real y cómo terminan las ejecuciones.

También habrá diferencias cualitativas. Anthropic afirma que Opus 5 tiende a redactar entregables más largos, narrar más su progreso durante las sesiones de agentes, delegar con mayor facilidad en subagentes y verificar su trabajo sin una instrucción específica. Estas conductas pueden aportar valor, pero quizá sea necesario adaptar una interfaz de agentes, un pipeline de registros o una capa de orquestación concebidos para el comportamiento más discreto de Opus 4.8.

Tres detalles de producción determinan la factura

El esfuerzo, la caché y la velocidad interactúan. Optimizar cualquiera de ellos de forma aislada puede empeorar los otros dos.

Mantener el esfuerzo constante dentro de una conversación en caché

Cambiar output_config.effort entre solicitudes modifica el prompt renderizado por Anthropic, de modo que la solicitud posterior no conserva el prefijo almacenado en caché. Un sistema que sube y baja el esfuerzo dentro de una conversación larga puede perder el ahorro de caché que esperaba obtener.

El nivel de esfuerzo debe elegirse al inicio de una sesión dependiente de la caché y mantenerse. Si el trabajo posterior requiere otro nivel, puede dirigirse a una conversación nueva o asumir el fallo de caché como parte del costo del escalamiento.

Opus 5 reduce el prompt mínimo que se puede almacenar en caché de 1,024 tokens en Opus 4.8 a 512 tokens. Esto habilita la caché para instrucciones repetidas más cortas, pero solo si el prefijo del prompt y el esfuerzo permanecen estables.

Comprar el modo Fast por la latencia, no por la capacidad

El modo Fast funciona unas 2.5 veces más rápido que el normal y cuesta $10/$50 por millón de tokens. No convierte Opus en Fable. En el ejemplo fijo de 100 tareas, eleva el total de Opus de $22.50 a $45 antes de considerar la caché o los reintentos.

El modo Fast es una versión preliminar de investigación en la API de Claude. Actualmente no está disponible en Amazon Bedrock, Google Cloud ni Microsoft Foundry. Una arquitectura multinube no puede asumir que la opción de velocidad acompañará al modelo en todas las plataformas.

Tratar como beta los nuevos controles beta

Los cambios de herramientas a mitad de una conversación permiten que una aplicación añada o retire herramientas entre turnos sin perder la caché del prompt. La función utiliza el encabezado beta mid-conversation-tool-changes-2026-07-01.

Los fallbacks automáticos pueden redirigir una solicitud de Opus 5 o Fable 5 marcada por un clasificador hacia una alternativa recomendada por Anthropic, en lugar de bloquearla. Tanto las listas de fallback predeterminadas como las explícitas utilizan el encabezado beta server-side-fallback-2026-07-01.

Ambos controles resuelven problemas operativos. También modifican lo que puede hacer una única sesión lógica y qué modelo podría responder. Antes de habilitarlos en un flujo de trabajo irreversible, hay que probar los cambios de permisos, la gestión de fallos y la calidad de salida.

Evaluar los cinco niveles de esfuerzo antes del despliegue

Una evaluación de 375 ejecuciones basta para convertir el control de esfuerzo en datos de enrutamiento: 25 tareas representativas, cinco niveles de esfuerzo y tres repeticiones de cada combinación.

Las repeticiones importan porque un agente puede acertar una vez por suerte y fallar en la siguiente ruta de herramientas. El conjunto de tareas importa más que su tamaño. Debe incluir trabajo habitual, casos límite conocidos y fallos que antes exigieron una corrección humana.

Si la producción depende de la caché de prompts, no conviene variar el esfuerzo en mitad de una sesión durante esta prueba. Cada nivel debe evaluarse con un diseño de conversación estable; de lo contrario, los fallos de caché se convierten en una variable sin controlar.

Un resultado útil podría indicar que medium aprueba el trabajo rutinario de cuentas, high es necesario para gestionar excepciones y xhigh mejora una categoría limitada de depuración. Eso no justifica usar xhigh en todas partes. Justifica tres rutas con economías distintas.

El mismo proceso determina si Fable 5 merece su precio. Fable debe añadirse únicamente a las tareas de Opus que continúen por debajo del umbral. Si Fable no mejora la aceptación lo suficiente como para compensar su prima de $22.50 en el ejemplo de 100 tareas, conviene mantener Opus.

El límite de seguridad difiere del de Fable 5

Opus 5 es menos restrictivo que Fable 5 para el trabajo legítimo de seguridad, pero no es un modelo cibernético sin restricciones.

Anthropic afirma que los clasificadores cibernéticos de Opus 5 deberían intervenir alrededor de un 85% menos que los de Fable 5. El modelo puede encontrar vulnerabilidades en código fuente, mientras que las salvaguardas bloquean el análisis de vulnerabilidades basado en binarios, las pruebas de penetración y la generación de exploits. También sigue por detrás de Mythos 5 en ciberseguridad ofensiva e investigación biológica.

Ese límite importa en los agentes de depuración y seguridad. Una revisión de código fuente puede funcionar, mientras que un paso posterior de validación de exploits podría rechazarse o enviarse a otra ruta. El flujo de trabajo debe tratar el rechazo como un estado previsto, no como un fallo inesperado del parser.

El Cyber Verification Program permite a empresas e investigadores que cumplen los requisitos acceder a una versión con menos restricciones de seguridad. Los usuarios generales no deben diseñar un flujo de producción alrededor de esa vía hasta tener el acceso confirmado.

La auditoría interna de comportamiento de Anthropic otorga a Opus 5 una puntuación de 2.3 en conducta desalineada general, la más baja entre sus modelos recientes. Debe entenderse como evidencia sobre el conjunto de pruebas de Anthropic, no como permiso para retirar aprobaciones, entornos aislados ni accesos de herramientas con privilegios mínimos.

La decisión

Claude Opus 5 debería sustituir a Opus 4.8 en las nuevas cargas de trabajo premium y en la mayoría de las existentes después de una migración gradual. Cuesta lo mismo, escala de manera más fiable con el esfuerzo y se acerca a Fable 5 en varias evaluaciones importantes.

No debería reemplazar a Sonnet 5 en todas las rutas de gran volumen ni convertir max en el valor predeterminado. La ventaja económica nace del enrutamiento: Sonnet o un esfuerzo menor para el trabajo aceptado barato, Opus en high para el trabajo diario difícil, xhigh para casos de largo alcance medidos y Fable solo cuando un fallo de Opus demuestre ser costoso.

El control de esfuerzo resulta valioso porque vuelve explícita esa política. Debe utilizarse como variable de evaluación, mantenerse estable donde importe la caché y vincular cada escalamiento a un fallo concreto.

¿Quiere convertir el próximo cambio de modelo en una decisión de producción? Suscríbase al boletín.