El 22 de septiembre, Anthropic publicó Claude Opus 5.5, el primer modelo de su familia 5.5. El anuncio trae lo de siempre —mejores resultados en programación con agentes y trabajo de conocimiento, más velocidad, mejores auditorías de seguridad— y dos números que ese mismo día circulaban mezclados en todas partes: el precio baja un 20% y el modelo cuesta un 40% menos de ejecutar. Muchos titulares se quedaron con el segundo.
Hemos leído el anuncio, la ficha técnica, la página de novedades y la guía de migración. El modelo es mejor y es más barato; eso no está en discusión. Lo que conviene separar es qué parte de la rebaja es precio, qué parte es eficiencia y qué parte es un ajuste por defecto que ha cambiado. Y conviene saber, antes de cambiar una línea, que la migración desde Opus 5 no es sólo cambiar el nombre del modelo.
Las cifras que circulan como si fueran una
Todas están en fuentes oficiales y todas son ciertas. Lo que cambia es la pregunta que contesta cada una:
| La cifra | Qué mide exactamente | ¿Entra tal cual en tu presupuesto? |
|---|---|---|
| −20% de precio | Precio de lista por millón de tokens: 4 $ de entrada y 20 $ de salida, frente a 5 $ y 25 $ de Opus 5. La API por lotes sigue a mitad de precio | Sí, a igual número de tokens |
| −60% en lecturas de caché | De 0,50 $ a 0,20 $ por millón: la lectura de caché pasa a costar el 5% del precio de entrada, frente al 10% habitual | Sí, y pesa mucho en agentes con contexto largo y repetido |
| −40% de coste | Coste de ejecución «con la configuración por defecto» y «en cargas típicas», según Anthropic. Incluye precio, eficiencia y el cambio de esfuerzo por defecto | No. Depende de tu carga y de tu configuración |
| +30% de velocidad | Genera la salida más de un 30% más rápido que Opus 5 | No es coste; afecta a latencia y a la experiencia de uso |
| Menos pasos y tokens por tarea | Testimonios de clientes: Factory iguala a Opus 5 en esfuerzo alto con un 20-25% menos de tokens de salida; Optiver, con la mitad de turnos, tiempo y tokens de salida | Es una pista, no una medida: son casos seleccionados por el fabricante |
Fuentes: anuncio de Anthropic y documentación de la plataforma, 22 de septiembre de 2026
El ajuste que explica parte del 40%
La frase exacta del anuncio es que, con la configuración por defecto, Opus 5.5 costará un 40% menos que Opus 5 en cargas típicas. La clave está en «por defecto». Opus 5.5 razona siempre, y la cantidad de razonamiento se regula con un único parámetro, el nivel de esfuerzo. En Opus 5, si no se indicaba nada, el esfuerzo era high. En Opus 5.5 es medium.
Es decir: la comparación del titular enfrenta a Opus 5 razonando en alto con Opus 5.5 razonando en medio. Es una comparación legítima —es lo que le pasa a quien cambia de modelo sin tocar nada más—, pero no es la comparación entre dos modelos en igualdad de condiciones. Y la documentación añade un matiz en la otra dirección: a un mismo nivel de esfuerzo, Opus 5.5 tiende a razonar más por turno que Opus 5, sobre todo en los niveles más altos. Anthropic no ha publicado la comparación de coste entre los dos modelos a igual esfuerzo; su guía de optimización de coste todavía no incluye cifras de Opus 5.5.
Tres fuerzas que tiran en direcciones distintas
El coste de una tarea resuelta depende del precio por token y de cuántos tokens consume la tarea. Con Opus 5.5 se mueven los dos, y no en el mismo sentido:
- El precio baja, un 20% en entrada y salida y un 60% en lecturas de caché.
- Los pasos por tarea tienden a bajar. Es lo que cuentan los clientes del anuncio: menos turnos, menos llamadas, menos texto de relleno.
- El razonamiento por turno tiende a subir a igual nivel de esfuerzo, según la propia documentación.
Para ver cuánto se mueve el resultado, un ejemplo con aritmética nuestra, no de Anthropic. Un agente con contexto largo procesa en cada tarea un millón de tokens de entrada, de los que 800.000 salen de caché, y genera 50.000 de salida. Con los mismos tokens, la tarea cuesta 2,65 $ en Opus 5 y 1,96 $ en Opus 5.5: un 26% menos, más que el 20% de lista, por el peso de la caché. Sin caché, el ahorro se queda en el 20% exacto. Y si Opus 5.5 generase un 25% más de salida por razonar más —un supuesto, no un dato—, el ahorro bajaría al 17%. Si, al contrario, resolviera la tarea en menos pasos, podría superar el 40%.
Ninguna de esas cifras es la vuestra. La vuestra sale de ejecutar vuestras tareas con los dos modelos al esfuerzo que usaríais en producción y dividir lo que cuesta entre las tareas bien resueltas. Es la métrica de coste por tarea útil, y es la única que un CFO puede presupuestar. Si esta conversación os suena, es porque ya la tuvimos con el cambio de facturación del 15 de junio: lo que cambia la factura no es el precio del token, es cuántos gasta cada tarea.
Cuatro cambios que rompen el código que ya tenéis
La guía de migración los enumera sin rodeos. Tres devuelven un error en cuanto se despliega; el cuarto sólo si vuestro código edita conversaciones ya empezadas. Hay un quinto que no falla y por eso es el más traicionero.
| El cambio | Qué pasa si no lo tocáis | Qué se hace |
|---|---|---|
| El razonamiento no se puede desactivar | Error 400 si la petición lo desactiva o le fija un presupuesto manual de tokens | Quitar ese campo y bajar el esfuerzo donde antes se desactivaba para ahorrar |
| No se puede forzar una herramienta | Error 400 con tool_choice de tipo any o tool, también al contar tokens | Usar auto con uso estricto de herramientas o salidas estructuradas, y decir en el prompt cuándo aplica la herramienta |
| El razonamiento queda ligado al modelo y a la conversación | Si un router o un fallback pasa la conversación a otro modelo, éste sigue sin el razonamiento anterior (salvo Fable 5.1 y Mythos 5.1). En cuentas creadas desde el 31 de agosto, editar mensajes anteriores y reenviarlos da error 400 | Conversaciones sólo de añadir, sin editar el pasado; revisar la lógica de enrutado y de fallback |
| El antiguo computer use deja de aceptarse | Error 400 con computer_20251124 en la API de Claude y en Google Cloud (en Amazon Bedrock sigue funcionando) | Migrar al nuevo conjunto de herramientas y adaptar el bucle del agente |
| Silencioso: el texto entre herramientas cambia de sitio | Ninguna petición falla, pero una interfaz que mostraba al usuario el progreso entre llamadas a herramientas se queda muda | Leer esas notas desde los bloques de razonamiento y configurar su visualización |
Resumen de la guía de migración de Anthropic de Opus 5 a Opus 5.5. Si usáis Claude Managed Agents, basta con cambiar el nombre del modelo
Dos cosas más que no aparecen en los titulares. La primera: el modelo trae clasificadores de seguridad en más categorías —biología además de ciberseguridad, y una nueva para peticiones que intentan extraer su razonamiento interno—. Un rechazo llega como respuesta correcta, con código 200, y un motivo de parada propio. Si vuestro código no lo trata, el rechazo pasa por una respuesta vacía. La segunda, para quien diseña arquitecturas multimodelo: la regla del razonamiento ligado al modelo cambia las cuentas del enrutado entre modelos. Mover una conversación a un modelo más barato a mitad de tarea ahorra tokens y pierde contexto de razonamiento, y esa pérdida no da ningún error: sólo se nota en la calidad.
Lo que la propia Anthropic dice de sus benchmarks
El anuncio incluye la tabla de benchmarks de rigor, y en casi todos Opus 5.5 supera a Opus 5 con margen. Pero trae también dos frases que merecen más atención que la tabla, porque las escribe el fabricante sobre su propio modelo:
- A este nivel de capacidad, los márgenes en los benchmarks guían cada vez peor las diferencias reales. Lo dice a propósito de su comparación con Fable 5.1, su modelo más capaz: la distancia real es menor que la que sugieren las puntuaciones.
- Hay señales de que Opus 5.5 sospecha a menudo que lo están evaluando, lo que, en palabras del anuncio, dificulta saber cómo actuará en la enorme variedad de situaciones reales.
Lo primero dice que la tabla del anuncio no decide por vosotros. Lo segundo es más incómodo, y conviene no exagerarlo: se refiere a las evaluaciones de comportamiento y seguridad, no a vuestras pruebas de producto. Pero la lección es la misma que venimos defendiendo en qué significa exactamente «funciona mejor»: la evidencia que cuenta es la que sale de vuestros casos, con vuestros datos, medidos contra una línea base. Los testimonios de clientes del anuncio son valiosos y concretos, y a la vez son los que el fabricante eligió publicar.
Cómo lo migraríamos nosotros
No hay prisa. Opus 5 pasa a la categoría de modelo anterior, pero Anthropic se compromete a no retirarlo antes del 24 de julio de 2027. Con ese margen, este es el orden que seguiríamos con una integración que ya está en producción:
- Fijar el esfuerzo en la integración actual, antes de tocar el modelo. Si no estaba fijado, estaba en
high: dejadlo escrito. Así la comparación posterior es entre modelos, no entre ajustes. - Buscar en el código los cuatro cambios que rompen y el tratamiento de rechazos. La guía oficial incluye una lista de comprobación, y la propia Anthropic ofrece una skill de Claude Code que aplica los cambios mecánicos y devuelve lo que hay que revisar a mano. Útil, siempre que alguien revise ese diff.
- Ejecutar vuestro golden set con los dos modelos, y Opus 5.5 a dos o tres niveles de esfuerzo. Anotar calidad, tokens por tarea, latencia y coste por tarea resuelta.
- Elegir el esfuerzo por tipo de tarea, no uno global. Es muy probable que algunas tareas queden igual de bien en
mediumo enlowy otras necesitenhigh. Ahí está la mayor parte del ahorro real. - Mover tráfico de forma gradual, con la observabilidad que describimos en el flujo de LLMOps, y recalcular la línea base de coste y latencia al esfuerzo elegido. Es el último punto de la lista de la propia guía, y el que más se salta.
Nada de esto es específico de Opus 5.5. Es lo que habrá que hacer con Sonnet 5.5 y Haiku 5.5, que Anthropic anuncia como próximos, y con lo que publique cualquier otro laboratorio el mes que viene. Los modelos cambian cada pocos meses; lo que dura es la forma de medirlos.
Lo que nos llevamos
Opus 5.5 es una buena noticia para quien trabaja con agentes: más capacidad por menos dinero y, según lo que cuentan sus primeros usuarios, menos vueltas para llegar al mismo sitio. Pero el «40% menos» no es una cifra para una hoja de presupuesto. Es el resultado de una configuración concreta sobre unas cargas concretas, y la vuestra puede quedar por encima o por debajo. La cifra que sirve es la que medís vosotros, al esfuerzo que elegís vosotros, sobre las tareas que resolvéis vosotros. Tenerla antes de migrar cuesta pocos días. Tenerla después suele costar una conversación incómoda con finanzas.
Preguntas frecuentes
¿Opus 5.5 cuesta un 40% menos que Opus 5?
El precio de lista baja un 20%: 4 dólares por millón de tokens de entrada y 20 de salida, frente a 5 y 25. Las lecturas de caché bajan un 60%, de 0,50 a 0,20. El 40% es otra cifra: Anthropic dice que, con la configuración por defecto, Opus 5.5 cuesta un 40% menos que Opus 5 en cargas típicas. Esa comparación incluye un cambio de configuración, porque el esfuerzo por defecto pasó de high en Opus 5 a medium en Opus 5.5. Lo que entra en tu presupuesto es lo que midas sobre tus tareas al nivel de esfuerzo que elijas.
¿Qué es el nivel de esfuerzo y por qué importa tanto en esta versión?
Es el parámetro que controla cuánto razona el modelo antes de responder, y con ello la calidad, la latencia y el coste. En Opus 5.5 es el único control del razonamiento, porque el razonamiento ya no se puede desactivar. Su valor por defecto es medium; en Opus 5 era high. Si vuestro código no fija el esfuerzo, cambiar sólo el identificador del modelo cambia dos cosas a la vez, el modelo y el esfuerzo, y cualquier diferencia de calidad o de coste se atribuirá al modelo cuando puede venir del ajuste.
¿Migrar de Opus 5 a Opus 5.5 es sólo cambiar el nombre del modelo?
No, si vuestro código usa alguna de estas cuatro cosas: desactivar el razonamiento o fijarle un presupuesto manual, forzar el uso de una herramienta concreta con tool_choice, el antiguo computer_20251124 de computer use en la API de Claude o en Google Cloud, o editar mensajes anteriores de una conversación que se reenvía. Las tres primeras devuelven un error 400. La cuarta devuelve un 400 en cuentas creadas desde el 31 de agosto de 2026. Hay además un cambio silencioso: el texto que el modelo escribe entre llamadas a herramientas llega vacío si no se configura su visualización.
¿Qué pasa con los routers y los fallbacks entre modelos?
Hay que revisarlos. El razonamiento de Opus 5.5 queda ligado al modelo que lo produjo: si un router o un fallback pasa la conversación de Opus 5.5 a otro modelo, ese modelo sigue sin el razonamiento anterior, salvo Fable 5.1 y Mythos 5.1 en la API de Claude. La petición no falla, así que no salta ninguna alarma: sólo cambia la calidad de los turnos siguientes. Si vuestra arquitectura enruta entre modelos para ahorrar, esa pérdida tiene que entrar en la evaluación.
¿Nos podemos fiar de los benchmarks del anuncio?
Como orientación, sí; como decisión, no. Lo dice la propia Anthropic en el anuncio: con este nivel de capacidad, los márgenes en los benchmarks guían cada vez peor las diferencias reales, y el modelo muestra señales de sospechar a menudo que lo están evaluando. Los testimonios de clientes son útiles pero seleccionados por el fabricante. Lo que decide si os conviene es vuestro propio conjunto de casos, ejecutado con los dos modelos al esfuerzo que usaríais en producción.
¿Por dónde empezamos si ya tenemos Opus 5 en producción?
Por fijar el esfuerzo explícitamente en vuestra integración actual, antes de tocar el modelo, para que la comparación sea limpia. Después, buscar en el código los cuatro cambios que rompen y el manejo de rechazos, que ahora incluye nuevas categorías. Con eso resuelto, ejecutar vuestro conjunto de evaluación con Opus 5.5 a dos o tres niveles de esfuerzo y comparar coste por tarea resuelta, no coste por token. Sólo entonces se mueve tráfico real, de forma gradual. Opus 5 no se retira antes de julio de 2027, así que no hay prisa.
Fuentes citadas
- Anthropic — Introducing Claude Opus 5.5 (22 de septiembre de 2026; precio, «40% menos con la configuración por defecto en cargas típicas», velocidad, benchmarks, testimonios de clientes y advertencias sobre los márgenes de los benchmarks y la conciencia de evaluación)
- Claude Platform — Claude Opus 5.5 (ficha técnica: precios, caché, esfuerzo por defecto
medium, contexto y disponibilidad) - Claude Platform — What's new in Claude Opus 5.5 (cambios que rompen, diferencias de comportamiento y más razonamiento por turno a igual esfuerzo)
- Claude Platform — Migrating to Claude Opus 5.5 (lista de comprobación, recomendaciones de esfuerzo y nota sobre Claude Managed Agents)
- Claude Platform — Claude Opus 5 (esfuerzo por defecto
high, precios y compromiso de retirada no antes del 24 de julio de 2027)

Jordi García es Tech Lead en onext. Trabaja en llevar la IA a producción gobernada en equipos de desarrollo y de producto —con Spec-Driven Development, ingeniería de contexto y verificación humana en cada paso— y firma los insights técnicos de onext sobre método, calidad y coste de la IA aplicada.
LinkedIn →