Casi Fable 5 a mitad de precio: por qué Opus 5 cambia tu decisión de modelo de por-proyecto a por-tarea
Llevo dos años viendo a los equipos elegir “un modelo” de la misma forma en que se elige una base de datos: una vez, al principio, con una reunión larga y una planilla. Opus 5, que Anthropic lanzó el 24 de julio, jubila esa reunión sin hacer ruido. No porque sea un nuevo state-of-the-art —lo es—, sino porque convierte el tradeoff costo/inteligencia en una perilla que mueves por tarea, en lugar de una apuesta que haces por proyecto.
El número que va a viajar es el titular: Opus 5 “comes close to the frontier intelligence of Claude Fable 5 at half the price”. En CursorBench 3.2, a max effort, queda dentro del 0.5% del pico de Fable 5 a la mitad del costo por tarea. Es el state-of-the-art absoluto en Frontier-Bench v0.1 y GDPval-AA, y más que duplica el puntaje de Opus 4.8 en Frontier-Bench a un costo por tarea menor. Mismo precio que su predecesor —$5 por millón de input tokens, $25 de output—, disponible ya en la API como claude-opus-5, y ya es el modelo default en Claude Max y la opción más fuerte en Pro.
Pero el precio no es la parte interesante. La parte interesante es el effort setting.
Opus 5 trae un control de effort —low, medium, high, xhigh, max— que permite cambiar inteligencia por tokens en cada request. Esto es lo que cambia cómo un equipo debería pensar. Hasta ahora, “más barato vs. más inteligente” era una decisión de selección de modelo: se ruteaba a Haiku para el camino barato y a Opus para el camino difícil, y había que mantener esa lógica de ruteo. Con Opus 5, el mismo modelo cubre todo el rango. Se baja el effort para el boilerplate y se sube para el refactor complicado, y se factura en consecuencia.
Los reportes de early-access apuntan en la misma dirección. Un cliente de workflows legales encontró que Opus 5 mantuvo la precisión generando un 26% menos de tokens en promedio que Opus 4.8 a max reasoning. Otros describen la ganancia de eficiencia distinto —una firma de trading cita alrededor de un séptimo de los reasoning tokens y menos de la mitad de la latencia de Opus 4.8; un equipo de modelado financiero vio un tercio menos de turns y tool calls y 60% menos de tiempo de reloj—. Los números puntuales varían según la carga de trabajo, pero el patrón no: en Opus 5, más effort compra menos desperdicio que antes.
Aquí va el encuadre de CTO que yo usaría de verdad en una reunión de planificación. Tu decisión de modelo era un costo fijo: elegías un tier y vivías con su piso y su techo. Opus 5 convierte ese costo fijo en uno variable que controlas en el momento de la llamada. Eso es un cambio de presupuesto disfrazado de flag de API. Significa que tu costo por tarea ahora es función de un parámetro que ponen tus ingenieros, no de un contrato que firmaste. También significa que “qué modelo” deja de ser la palanca y “cuánto effort por tarea” pasa a serlo.
Dos advertencias que conviene mantener honestas. Primero, el encuadre de los benchmarks: los claims de SOTA son en Frontier-Bench y GDPval-AA; la historia de CursorBench es cercanía a Fable 5 a la mitad del costo, no un nuevo pico —no conviene confundir las dos—. Segundo, Opus 5 está deliberadamente por detrás de Mythos 5 en cybersecurity y biología. Anthropic no lo entrenó en tareas de ciber; sus clasificadores de ciber son ~85% menos restrictivos que los de Fable 5, pero igual bloquean la generación de exploits y el escaneo de vulnerabilidades basado en binarios, y los requests marcados caen de vuelta a Opus 4.8 en Claude.ai, Claude Code y Cowork. Si tu trabajo vive en seguridad ofensiva, este no es tu modelo —y es por diseño—. (Anthropic también lo llama su modelo más alineado hasta la fecha, con el puntaje más bajo en su auditoría interna de misalignment —vale notarlo, dado que el mismo lanzamiento aflojó las barandas de ciber—).
Nota práctica para la gente de Claude Code (el rincón de Devy): el effort setting no es solo una abstracción de API —es la palanca a la que se recurre cuando una corrida agéntica larga está quemando tokens en pasos fáciles—. Conviene arrancar una sesión en un effort más bajo para scaffolding y ediciones rutinarias, y subirlo a high/xhigh/max cuando se le pasa el debugging difícil o una búsqueda de root-cause. Varios equipos de early-access reportan la misma precisión en niveles de effort más bajos, así que el default de “siempre max” ahora es el hábito caro, no el seguro.
El cambio real no es que hay un nuevo mejor modelo esta semana —hay un nuevo mejor modelo casi todas las semanas—. Es que la elección entre inteligente y barato se movió de la decisión de compra al código, donde un desarrollador la fija por tarea. Si todavía eliges un modelo por proyecto, estás dejando la perilla sobre la mesa.
¿Ya estás ruteando por effort setting, o sigues eligiendo un modelo fijo por proyecto? ¿Dónde pones el corte entre “baja el effort” y “dale max”?