Claude Opus 5: qué cambia para los que lo usamos desde la API

Ayer Anthropic presentó Claude Opus 5 y, en paralelo, Claude Sonnet 5. La narrativa oficial habla de "step change" en el tier Opus y, esta vez, los números de los benchmarks acompañan la declaración. En coding agentico, Opus 5 supera a todos los modelos en Frontier-Bench v0.1 y duplica la performance de Opus 4.8 a un costo menor por tarea. En ARC-AGI 3 (problemas nuevos que el modelo nunca vio) su score es 3× el del segundo mejor modelo. Y en OSWorld 2.0, que mide computer use, le gana a Fable 5 (el modelo más caro de Anthropic) a un tercio del costo.

Hasta acá parece otro lanzamiento más en la ola interminable de modelos. Pero hay un detalle técnico que a nosotros, los developers que usamos la API, nos cambia la forma de integrarlo: un effort setting configurable. Es el knob nuevo más importante desde que salió el temperature. De ahí que valga la pena mirar Opus 5 con detalle, no con hype.

Qué es el effort setting y por qué te debería importar

El effort es un parámetro nuevo en la API que controla cuánto "piensa" el modelo antes de responder. Anthropic lo presenta como un dial entre inteligencia y costo: cuanto más alto el effort, mejor el resultado, pero más tokens consume. En los charts oficiales se ve que Opus 5 en max effort rinde casi igual que Fable 5 en CursorBench 3.2, pero a la mitad del costo por tarea.

Para un developer esto significa algo concreto: ya no tenés que elegir entre "el modelo caro" o "el modelo barato". Podés decirle a la API "dame lo mejor que tengas para esta query difícil" o "respondé rápido y barato para esta clasificación de mil tickets". El caso de uso típico es mandar low para tareas rutinarias y reservar max effort para los casos donde la calidad manda.

En el SDK de TypeScript se invoca así:

import Anthropic from "@anthropic-ai/sdk";

const client = new Anthropic();

const response = await client.messages.create({
  model: "claude-opus-5",
  max_tokens: 4096,
  effort: "high", // low | medium | high | xhigh | max
  messages: [
    {
      role: "user",
      content: "Refactorizá este módulo para usar dependency injection y explicá los cambios",
    },
  ],
});

console.log(response.content[0].text);

Y desde Python, con anthropic SDK:

import anthropic

client = anthropic.Anthropic()

message = client.messages.create(
    model="claude-opus-5",
    max_tokens=4096,
    effort="max",
    messages=[
        {
            "role": "user",
            "content": "Encontrá el bug de race condition en este código y arreglalo",
        }
    ],
)

print(message.content[0].text)

El effort no es lo mismo que thinking tokens El effort setting es un control de alto nivel que el modelo administra internamente. Distinto al parámetro thinking (que ya existía) que te deja definir un budget fijo de tokens de razonamiento. Si querés control fino, combiná ambos. Si querés simplicidad, usá solo effort y listo.

Los benchmarks que importan (y cuáles ignorar)

La página de Anthropic tira una lista larga de números. Vale la pena separar la paja del trigo y mirar tres que sí se traducen a trabajo real:

• CursorBench 3.2: mide tareas de coding agentico. A max effort, Opus 5 queda a 0.5% del peak de Fable 5, pero a mitad de precio. Si usás Cursor o algún IDE con agentes, este es el número que más te dice.
• ARC-AGI 3: el test que se hizo famoso porque mide razonamiento sobre problemas nuevos. 3× el score del segundo modelo es una diferencia enorme, no marginal.
• OSWorld 2.0: computer use (el modelo controla una pantalla como un humano). Si te interesa el browser-use o agentes que automatizan UI, acá Opus 5 le gana a Fable 5 a un tercio del costo.

Los benchmarks de "knowledge work" tipo GDPval-AA también son relevantes si tu flujo de agente incluye investigación o análisis de documentos. Donde no hay que detenerse tanto es en los benchmarks genéricos de "common sense reasoning" o de preguntas y respuestas aisladas, que están bastante saturados y no reflejan trabajo profesional real.

El costo real: misma plata que Opus 4.8, mejor resultado

Anthropic destaca que Opus 5 mantiene el mismo precio por token que su predecesor (Opus 4.8). O sea: si ya tenías un budget asignado a Opus 4.8 en tu sistema, no necesitás pedir más presupuesto para migrar. Directamente recibís mejor modelo por la misma plata. En max effort gastás más tokens por tarea, pero como el modelo termina en menos iteraciones (precisa menos reintentos), el costo por tarea terminada suele ser igual o menor.

Para un caso práctico: si tenés un agente de refactor que antes necesitaba 3-4 iteraciones para dejar el código limpio, Opus 5 probablemente lo haga en 1-2. El esfuerzo extra en tokens se compensa con menos roundtrips. El parámetro effort te da el control fino para optimizar esto según tu workload.

Dónde brilla (y dónde no) según Anthropic

Los reportes de early access que cita Anthropic son bastante concretos:

• Un ingeniero de una trading firm usó Opus 5 para armar un feed de market data para un exchange nuevo en una sola sesión. Como no había feed de referencia para validar, el modelo se construyó su propio test harness para chequear que parseaba bien la data del exchange.
• En un test interno, le dieron a Opus 5 un dibujo de una pieza mecánica y le pidieron escribir código para reconstruirla como modelo 3D en FreeCAD. El modelo escribió su propio pipeline de computer vision para extraer la geometría de los pixeles crudos y después reconstruyó la pieza completa.
• En un bug real de un package manager open-source conocido, Opus 5 encontró la root cause y arregló un edge case que el patch de la comunidad se había perdido.

El patrón que se repite: el modelo verifica su propio trabajo e itera hasta que sale bien. Eso es exactamente el perfil que necesitás para agentes de larga duración, que es el ángulo que cubrí en el post de IA Agéntica. La diferencia con el hype de 2025 es que ahora hay un modelo específico con un knob específico que te permite optimizar el tradeoff.

Lo que sigue sin estar claro Anthropic no publicó en detalle el "traffic mix" entre los distintos levels de effort. Si en producción real el 80% de las queries se mandan en low y solo el 20% en max, el ahorro puede ser enorme. Si en cambio se tiende a usar max siempre por miedo, el costo puede explotar. Es un knob que hay que medir en cada caso.

Cómo encaja con el resto del stack

Si ya integraste MCP en tu flujo, como expliqué en MCP, la buena noticia es que Opus 5 funciona como backend de cualquier cliente compatible con el protocolo. No necesitás cambiar tu infra. Si venís de usar Sonnet 4.5 para tareas rutinarias, podés dejar Sonnet para eso y reservar Opus 5 (con effort alto o max) para los casos donde la calidad justifica el costo extra.

El contraste con el lanzamiento reciente de Grok 4.5 es interesante: xAI apostó a "Opus class" como narrativa de marketing; Anthropic, en cambio, publicó benchmarks concretos donde Opus 5 iguala o supera a Fable 5 a menor costo. Es la diferencia entre un claim aspiracional y un lanzamiento con substance técnico real. El mercado dirá si los precios se sostienen, pero por ahora la propuesta de valor de Opus 5 está claramente del lado de Anthropic en coding agentico.

Y si te interesa comparar contra modelos open-source corriendo en tu propio hardware (como vimos en Ollama), recordá que la ventaja de Opus 5 no está solo en la calidad: está en el knob effort, en la integración con Claude Code y en el SLA de Anthropic. Para prototipos y datos sensibles seguís prefiriendo local; para producción con tareas críticas de razonamiento, el modelo frontier con API es la mejor herramienta que hay hoy.

Mi recomendación práctica

Si querés probar Opus 5 sin romper tu budget, este es el approach que estoy usando:

1. Empezá en low o medium para tareas de clasificación, summarization y refactor rutinario. En estos casos la diferencia con max es marginal y el costo se reduce hasta 5×.
2. Reservá high o xhigh para generación de código nuevo, debugging complejo y análisis de código legacy. Acá la mejora en calidad justifica el gasto extra.
3. max solo para casos donde la calidad es no-negociable: auditorías de seguridad, refactors de arquitectura críticos, o generación de código que va a producción sin revisión humana.
4. Medí siempre costo por tarea terminada, no por token. El effort más alto consume más tokens, pero si termina en menos iteraciones, el costo total puede ser igual o menor.

Opus 5 no es magia, pero es un salto real en la familia de modelos de Anthropic. El effort setting te da el control que veníamos pidiendo hace rato: pagar más solo cuando vale la pena. Para los que usamos LLMs desde la API todos los días, eso es más útil que cualquier benchmark.

¿Ya lo probaste? Contame qué nivel de effort te funcionó mejor para tu caso de uso, y si los números de costo por tarea terminada cierran con tu presupuesto real.