Claude Opus 5.5: más barato por token, sin probar por tarea

Un Opus más barato que rechaza algunas de tus solicitudes actuales

Claude Opus 5.5 es el reemplazo de Anthropic para Opus 5 dentro del mismo nivel, anunciado hoy, solo por API, sin pesos públicos. Para quien tiene Opus 5 en producción, dos cosas cambian a la vez y tiran en direcciones distintas.

La primera es la factura. Según la tabla del proveedor, la entrada baja de $5 a $4 por millón de tokens, la salida de $25 a $20, y las lecturas de caché de $0.50 a $0.20. El anuncio de Anthropic plantea el titular así:

It costs less per token than Opus 5 and uses fewer tokens per task, which nets out to a 40% drop in costs.

Esa frase contiene dos afirmaciones. El precio por token es un dato que puedes leer directamente en la tabla. Los tokens por tarea son una medición, y en la carga de trabajo de quién se midió importa más que el porcentaje.

El segundo cambio es que la API ya no acepta solicitudes que Opus 5 sí aceptaba. La página What's new de Anthropic enumera cuatro cambios que rompen compatibilidad: no se puede desactivar el thinking, forzar el uso de una herramienta devuelve un error, los bloques de thinking quedan ligados al modelo y a la conversación, y la herramienta de uso de ordenador anterior, computer_20251124, ya no se acepta en la API de Claude ni en Google Cloud.

Los dos primeros son los que afectarán a la mayoría de las integraciones con Opus 5. Cualquier solicitud que envíe thinking: {"type": "disabled"} o un presupuesto de thinking manual recibe un 400. Cualquier solicitud que envíe tool_choice de any o una herramienta nombrada recibe un 400. Los reemplazos que recomienda el proveedor son el parámetro effort para el primer caso y tool_choice: auto junto con strict tool use o structured outputs para el segundo. Si forzabas una llamada a herramienta para obtener JSON válido según un esquema, eso es un cambio de código, no de configuración.

Un quinto cambio no hace fallar nada, y es más fácil pasarlo por alto:

text between tool calls comes back in thinking blocks

Con el valor por defecto de display, esos bloques tienen el texto vacío, así que una aplicación que transmite en streaming las notas de progreso del modelo a los usuarios se queda en silencio entre llamadas a herramientas, sin ningún error que capturar.

La afirmación sobre el coste y el effort por defecto son la misma frase

La causa es el propio lanzamiento, y lo que lo hace urgente es que, para buena parte de las integraciones con Opus 5, migrar no es opcional como suele serlo con un modelo nuevo. La propia página del proveedor dice que el código que ya corre en Opus 5 con thinking activado no necesita cambios. El código que ejecuta con thinking desactivado, fuerza una llamada a herramienta, usa la herramienta de uso de ordenador anterior, o edita el contexto anterior de una conversación en una cuenta creada desde el 31 de agosto, no se puede simplemente apuntar a Opus 5.5 y dejar así. Cualquiera que esté en Opus 5 tiene que decidir, y el argumento del proveedor para decidir que sí es el coste.

El matiz de ese argumento está en la misma página que el titular:

at default settings it will cost 40% less than Opus 5 on typical workloads

«Configuración por defecto» hace más trabajo del que parece. La documentación de effort de Anthropic dice que Opus 5.5 usa por defecto effort medium, donde Opus 5 usaba por defecto high:

a request that omits effort runs one level lower than it did on Claude Opus 5

Así que el 40% del proveedor compara Opus 5.5 en medium con Opus 5 en high. Es una comparación legítima entre configuraciones por defecto. No es una comparación al mismo nivel de effort, y la propia guía de prompting del proveedor dice qué pasa si mantienes el effort constante:

At a given level, Claude Opus 5.5 tends to think more per turn than Claude Opus 5, especially at xhigh and max.

Juntando esas dos líneas, la migración toma forma. Si migras y adoptas el nuevo valor por defecto, estás corriendo un nivel de effort menos que antes, en un modelo que el proveedor dice que es más fuerte en ese nivel. Si migras y conservas tu valor de effort de Opus 5, el propio proveedor te dice que esperes turnos más largos y más tokens de salida, a un precio por token solo un 20% más bajo. El 40% corresponde a la primera vía. Nada en la página del anuncio lo reclama para la segunda.

Tres informes independientes, y nadie ha probado la configuración por defecto

La evidencia más sólida del proveedor sobre el coste por tarea es un gráfico, y el proveedor lo publicó con los ejes etiquetados.

Según el propio Anthropic, Opus 5.5 con effort por defecto supera a Opus 5 con effort máximo en Terminal-Bench 4.0 por aproximadamente una quinta parte del coste por intento. Es el benchmark del proveedor, las ejecuciones del proveedor y el gráfico del proveedor, y es la versión más sólida de su argumento porque es por intento, no por token. El anuncio también nombra a unos dos docenas de socios de lanzamiento que reportan buenos resultados. Eso es material del proveedor. Ninguno de ellos publicó un recuento de tokens.

Tres partes ajenas a Anthropic sí publicaron algo el día del lanzamiento. Ninguna es una prueba equivalente de la afirmación del proveedor sobre la configuración por defecto, y cada una muestra algo más limitado que el titular que suele recibir: un aumento de tokens a nivel de pipeline frente a una mezcla de producción, una solicitud que alcanzó el límite de salida en max, y una ejecución de índice max contra max.

CodeRabbit ejecutó Opus 5.5 dentro de su pipeline de revisión de código y reportó un mayor uso de tokens en todas las configuraciones: +49.2% y +57.6% en 80 patrones de bugs de código abierto, +40.6% y +60.1% en 13 casos más difíciles. Esas cifras vienen con dos condiciones. La línea base es la propia mezcla de modelos de producción de CodeRabbit, no Opus 5, y «Standard» y «Max» son sus configuraciones a nivel de pipeline, no valores de effort de la API. CodeRabbit lo dice sobre la primera condición:

The token increase is also a different comparison from the price reduction relative to Opus 5.

Las cifras provienen de un resumen de ejecución que no separa los tokens de entrada de los de salida, y no establecen ni el coste en dólares ni la latencia. La publicación no dice si CodeRabbit tuvo acceso previo al lanzamiento. Lo que sí dice es dónde recae la carga de la prueba:

Its efficiency remains an open question, so teams should verify whether its lower token prices actually translate into lower production-review costs.

No es una reseña hostil. La razón que la misma publicación da para probar el modelo es la capacidad, no el precio:

The strongest reason to try Opus 5.5 is that it finds a different mix of bugs.

Simon Willison dio con el otro extremo del thinking siempre activo. Al pedir un SVG con effort max:

it hit the limit of 128,000 cap for output tokens while it was still reasoning about the question!

So that failed attempt on max cost me $2.56.

Este es un comportamiento documentado, no un bug. La página de effort de Anthropic te dice que

set a large max_tokens at the higher levels: it's a hard limit on total output (thinking plus response text)

y la guía de migración confirma que el límite se mantuvo en 128k. En Opus 5 podías desactivar el thinking y hacer irrelevante ese techo. En Opus 5.5 no puedes, así que en los niveles de effort más altos una solicitud puede gastar todo su presupuesto razonando y no devolver nada, y aun así pagas por ese razonamiento.

Artificial Analysis ejecutó su Intelligence Index en ambos modelos con effort max, con el fallback activado para Opus 5.5. Consultadas el día del lanzamiento, las dos páginas decían:

When evaluating the Intelligence Index, it generated 260M tokens, which is very verbose in comparison to the median of 88M.

When evaluating the Intelligence Index, it generated 140M tokens, which is very verbose in comparison to the median of 88M.

Opus 5.5 obtuvo 58 frente al 51 de Opus 5 en ese índice, y las mismas páginas, leídas el día del lanzamiento, sitúan la ejecución completa en $8,708.20 frente a $7,274.74, o $5.98 por tarea frente a $5.86. Veinte por ciento más barato por token, 86% más tokens, dos por ciento más por tarea. Dos salvedades: esto es max contra max, así que no dice nada sobre la configuración por defecto en medium en la que se apoya la afirmación del proveedor, y el fallback estaba activado, así que algunas tareas puede que las haya respondido otro modelo. La misma página indica la velocidad de salida de Opus 5.5 como no disponible. El anuncio de Anthropic dice que el modelo genera la salida más de un 30% más rápido que Opus 5. Hasta hoy, nadie fuera de Anthropic lo ha medido.

Lo que nadie independiente ha probado todavía: la propia comparación con la configuración por defecto, Opus 5.5 en medium frente a Opus 5 en high, en una carga de trabajo real. Esa es la única medición que zanjaría la cifra del proveedor, y es la que puedes hacer tú mismo.

Hay un desacuerdo más, y es entre dos páginas del propio Anthropic. El anuncio describe las nuevas salvaguardas sobre ciberseguridad, biología y destilación como

all of which fall back to another model transparently

La documentación de refusals-and-fallback nombra a Opus 5.5 en su primera frase y luego describe algo que quien llama a la API tiene que configurar. Un rechazo no es un error:

When that happens, you receive a normal response, not an error, with stop_reason: "refusal".

Conseguir una respuesta de otro modelo significa optar activamente por una de tres vías: server-side fallback, middleware del SDK, o un reintento que escribes tú mismo. Sobre la primera, la misma página dice:

Server-side fallback is in beta on the Claude API.

A continuación dice que el parámetro fallbacks no es compatible con la Message Batches API y no está disponible en Amazon Bedrock, Google Cloud ni Microsoft Foundry, donde la vía es el middleware del SDK en su lugar. La facturación también queda por escrito:

An attempt that declined before producing any output is not billed: its tokens are reported on its usage.iterations entry but not charged.

Todo intento que sí produjo salida, incluido uno que se rechazó a mitad de camino, se factura a las tarifas del modelo que lo ejecutó, y usage.iterations es el registro por intento. Cuando se ejecuta un fallback, la respuesta nombra el modelo que la sirvió. Así que «transparently» significa visible, no automático. Un pipeline que no activa nada y solo comprueba errores leerá un rechazo de salvaguarda como una llamada exitosa sin respuesta dentro.

Mide los tokens por tarea terminada, y luego decide

La migración es un trabajo en dos partes, y el orden importa. Primero, haz válidas las solicitudes: elimina el campo thinking, reemplaza el tool_choice forzado por auto junto con strict tool use o structured outputs, cambia al conjunto de herramientas de uso de ordenador más reciente si usas una, y pon display en updates si transmites en streaming entre llamadas a herramientas. Define effort explícitamente en lugar de heredar el nuevo valor por defecto por accidente, y fija max_tokens lo bastante alto en los niveles superiores para que el razonamiento tenga espacio.

Luego, antes de que nada de eso llegue a producción, haz la comparación que recomienda la propia página de effort del proveedor: un barrido de effort sobre tus evals, en vez de arrastrar la configuración anterior. El número que hay que registrar no es el precio por token. Es el total de tokens, dividido en entrada, salida y lecturas de caché, por tarea que realmente terminó, en cada nivel de effort, sobre tus propios prompts. Las lecturas de caché importan más de lo que parece: Anthropic dice que suponen la mayor parte del coste en trabajo agéntico y de código, y son la partida que bajó un 60%, así que una carga de trabajo intensiva en caché puede salir ganando aunque los tokens de salida suban. Una carga de trabajo con poca caché y razonamiento largo puede salir perdiendo. No sabrás cuál eres hasta que cuentes.

Esa comparación es un flujo de trabajo pequeño, y es justo el tipo de cosa para la que está hecho Latenode, sea o no el modelo bajo prueba el punto central. Toma los treinta prompts que tu producto realmente envía, ejecuta cada uno en dos configuraciones, Opus 5 con el effort que usas hoy y Opus 5.5 en medium, y haz que un nodo de JavaScript, que puede instalar cualquier librería de NPM, haga ambas llamadas a través del SDK del proveedor y registre tokens de entrada, tokens de salida, lecturas de caché y tiempo real para cada una. Un plan de pago incluye 5 workers de ejecución en paralelo, así que el barrido corre a una concurrencia parecida a la que atiendes en producción, en vez de un prompt a la vez. El medidor coopera con el experimento: Latenode factura los segundos de CPU que un run realmente consume, no por nodo ni por llamada a la API, y sin mínimo por ejecución, así que unos pocos cientos de ejecuciones cortas de comparación cuestan los segundos que tardan. La factura que importa es la del modelo, y el barrido existe para producir esa cifra antes de que te comprometas con ella.

Migra esta semana si tu carga de trabajo es intensiva en caché y puedes contar

Migra ahora si se cumplen tres cosas: ejecutas Opus 5 con thinking activado, tu tráfico es trabajo agéntico o de código donde dominan las lecturas de caché, y tienes forma de medir los tokens por tarea completada antes y después. En ese régimen, la tabla de precios del proveedor hace casi todo el trabajo por sí sola, la bajada del effort por defecto es un extra que puedes aceptar o rechazar, y los cambios que rompen compatibilidad te cuestan una tarde. Empieza por medium. Sube de nivel solo si tus evals lo indican.

No migres esta semana si se cumple alguna de estas condiciones. Ejecutas Opus 5 con thinking desactivado: esa configuración ya no existe, y el sustituto más cercano es un nivel de effort más bajo que no has calibrado. Fuerzas llamadas a herramientas para obtener JSON válido: esa vía ha desaparecido y el reemplazo necesita pruebas. Ejecutas en xhigh o max: las únicas mediciones independientes en ese extremo muestran más tokens, y el techo de 128k ahora incluye razonamiento que no puedes desactivar. Tu cuenta de API se creó el 31 de agosto de 2026 o después, y tu pipeline edita el system prompt o las herramientas a mitad de conversación: el preserved thinking rechazará la repetición. Tu tráfico toca herramientas de seguridad o biología: un rechazo de salvaguarda vuelve como una respuesta normal con un stop reason de refusal, no como un error, y conseguir una respuesta de otro modelo significa optar por una vía de fallback, de las cuales la de servidor está en beta en la API de Claude y no se ofrece en batches ni en las plataformas cloud. Construye el reintento antes de necesitarlo.

Y no te muevas por el 40%. Es la cifra del proveedor para sus propias cargas de trabajo con sus propias configuraciones por defecto, y hoy nadie fuera del proveedor la ha reproducido en nada. La primera medición independiente de la comparación por defecto contra por defecto en una carga de trabajo de producción valdrá más que todos los benchmarks de la página del anuncio juntos. Hasta que exista, la cifra que decide tu migración es la que produces tú mismo.