Una tarjeta de título para la guía de la API de Claude Opus 5.5, que dice «ID del modelo, cuatro cambios que rompen la compatibilidad y el quinto silencioso», con una franja de especificaciones que muestra el id del modelo claude-opus-5-5, una ventana de contexto de 1M, una salida de 128K y $4 / $20 por 1M de tokens.
Engineering & Research

Guía de la API de Claude Opus 5.5: el ID del modelo, cuatro cambios disruptivos y el quinto silencioso

Autor

Alistair Wren

Fecha de publicación

Últimos modelos · 20Ver todos los modelos
Benchmarks: Artificial Analysis · actualizado a diario
Volver a todas las publicaciones

Cambia la cadena del modelo de claude-opus-5 a claude-opus-5-5 y tu código todavía compila, todavía pasa la comprobación de tipos, y todavía pasa lo que sea que pase por una suite de pruebas. Luego devuelve un 400 en producción. Cuatro formas de solicitud que Claude Opus 5 aceptaba son rechazadas de plano por Claude Opus 5.5, y un quinto cambio no rompe absolutamente nada — que es exactamente por lo que será el que llegue a tus usuarios. Esta es la referencia de integración para el modelo: el identificador, las superficies que lo sirven, el contrato de solicitud, los cuatro errores, el quinto silencioso, y cómo funciona ahora el parámetro effort. Donde el comportamiento coincide con Claude Fable 5.1, un equipo que ya migró allí ha hecho parte del trabajo, así que cada cambio que aparece a continuación indica si también se aplica a ese modelo.

Todo lo que aparece aquí está tomado de la propia documentación de Claude de Anthropic, con fecha 2026-09-24, dos días después de que se lanzara el modelo. Las afirmaciones del proveedor se etiquetan como afirmaciones del proveedor, las cifras independientes como independientes, y nunca se presentan ambas con el mismo ajuste de esfuerzo como si fueran comparables.

El id del modelo, y dónde se sirve

El identificador es claude-opus-5-5 — un id de modelo fijo sin sufijo de fecha, el mismo esquema que claude-opus-5. No existe una forma independiente de snapshot fijado que adoptar ni ningún alias que resuelva a otra cosa.

La descripción general de los modelos de Anthropic enumera cinco superficies, con estas cadenas exactas:

• Claude API — claude-opus-5-5, disponible para todos los clientes.

• Amazon Bedrock — anthropic.claude-opus-5-5 (la única superficie que antepone el proveedor).

• Claude Platform on AWS — claude-opus-5-5, usando ids de la API de Claude en lugar de ids estilo Bedrock.

Google Cloud — claude-opus-5-5.

• Microsoft Foundry — claude-opus-5-5; el nombre de implementación es lo que se envía, y Foundry sigue el calendario del ciclo de vida de la API de Claude.

Dos de esos cinco importan más que el resto de esta sección. Amazon Bedrock y Google Cloud establecen sus propias fechas de ciclo de vida y retirada y, como muestran los cambios disruptivos a continuación, Bedrock es también la única plataforma en la que la antigua herramienta de uso de computadora sigue funcionando. Si usas Bedrock, no estás en la misma migración que todos los demás.

Lo que toda solicitud debe cumplir ahora

La guía de migración de Anthropic presenta el contrato como una lista, y la lista es lo bastante corta como para contrastar tu propio cliente con ella. Vengas del modelo que vengas, una solicitud a claude-opus-5-5 debe:

• No envíe ningún campo thinking o envíe thinking: {"type": "adaptive"} — ambas son equivalentes, porque el thinking adaptativo siempre está activado.

• Controla la profundidad del razonamiento con effort, el único parámetro de solicitud que lo hace; se admiten los cinco niveles y el valor predeterminado es medio.

• Use tool_choice con {"type": "auto"} (el valor predeterminado) o {"type": "none"}. Forzar una herramienta se rechaza.

• Omite temperature, top_p y top_k, o déjalos en sus valores predeterminados. Cualquier otro valor se rechaza, tanto en este modelo como en todo a partir de Claude Opus 4.7.

• No terminar los mensajes con un turno de asistente prerrellenado; eso ya se rechazó en Opus 4.6 y versiones posteriores.

• Declara el uso de computadora como el conjunto de herramientas computer_toolset_20260801 en la API de Claude y Google Cloud.

• No envíes ningún encabezado beta de ventana de contexto. La ventana de contexto de 1M es la predeterminada, y un encabezado escrito para un modelo anterior no tiene ningún efecto.

Cuando la guía indica que se rechaza una configuración, la API devuelve HTTP 400. Ese es todo el modo de fallo de migrar a este modelo: no una salida degradada, no una advertencia en un registro, sino una solicitud que nunca se ejecuta.

Anthropic's Migrating to Claude Opus 5.5 documentation page, showing the 'What every request to Claude Opus 5.5 must satisfy' list: the claude-opus-5-5 model id with no date suffix, thinking adaptive-only, the effort parameter with five levels low through max defaulting to medium, tool_choice auto or none, sampling parameters at their defaults, no prefilled assistant turn, the computer_toolset_20260801 toolset on the Claude API and Google Cloud, and a 1M-token context window requiring no beta header.

Los cuatro cambios importantes

1. El pensamiento no se puede desactivar

El pensamiento adaptativo siempre está activado. thinking: {"type": "disabled"} devuelve un 400, y un presupuesto manual también — thinking: {"type": "enabled", "budget_tokens": N}. El texto del error nombra el tipo que enviaste y luego nombra el reemplazo:

• "thinking.type.disabled" no es compatible con este modelo. Utilice "thinking.type.adaptive" y "output_config.effort" para controlar el comportamiento del razonamiento.

• "thinking.type.enabled" no es compatible con este modelo. Utilice "thinking.type.adaptive" y "output_config.effort" para controlar el comportamiento de pensamiento.

La consecuencia práctica no es el error, sino lo que ocurre después de corregirlo. En Claude Opus 4.8 y versiones anteriores, una solicitud sin el campo thinking se ejecutaba sin razonamiento. En Claude Opus 5.5, toda solicitud razona, y max_tokens sigue siendo un límite estricto que abarca el razonamiento más el texto de la respuesta. Los tokens de razonamiento se facturan como tokens de salida incluso cuando el texto del razonamiento nunca se te devuelve. Por lo tanto, un endpoint que antes se ejecutaba sin razonamiento puede producir más tokens de salida por solicitud después de la «corrección» que antes. La recomendación de Anthropic es reducir el esfuerzo donde antes desactivabas el razonamiento y, con un esfuerzo xhigh o max, empezar con max_tokens en 64k y ajustar a partir de ahí.

La forma de la respuesta también cambia. Una respuesta puede comenzar con uno o más bloques de pensamiento antes del primer bloque de texto, por lo que el código que lee la respuesta por posición — content[0].text, o un controlador de flujo que trata el primer content_block_start como texto — se rompen con estas respuestas incluso cuando la solicitud se realizó correctamente. Selecciona los bloques por su campo type en su lugar.

2. El uso forzado de herramientas devuelve un error

tool_choice los tipos any y tool devuelven un 400, y la misma validación se aplica al endpoint de conteo de tokens, así que un conteo previo falla de la misma manera que la llamada real:

• tool_choice: los tipos "tool" y "any" no son compatibles con este modelo.

auto y none no se ven afectados. El reemplazo documentado es mantener tool_choice: {"type": "auto"}, marcar las herramientas con strict: true para argumentos válidos según el esquema, o mover el esquema a salidas estructuradas — y decir en el prompt cuándo aplica la herramienta, ya que auto no garantiza una llamada. El uso estricto de herramientas acepta un subconjunto de JSON Schema: cada objeto en el input_schema de una herramienta debe establecer additionalProperties: false, así que revisa cada esquema antes de activar el flag. Y ten en cuenta la brecha que esto deja: si tu código dependía de forzar una llamada en lugar de simplemente permitirla, auto restaura el permiso y no la garantía. Comprueba que realmente haya vuelto un bloque tool_use.

3. Los bloques de pensamiento están vinculados al modelo y a la conversación

Cada bloque de pensamiento registra qué modelo lo produjo, y cada modelo lee sus propios bloques más un conjunto definido de los de otros. Las reglas funcionan en ambas direcciones:

• Claude Opus 5.5 lee bloques de pensamiento de Claude Opus 5 y de los modelos anteriores de Opus, Sonnet y Haiku, pero no de los modelos Claude Fable o Claude Mythos.

• En la API de Claude, Claude Fable 5.1 y Claude Mythos 5.1 leen bloques de Claude Opus 5.5. Ningún otro modelo lo hace.

• Una conversación que pasa de Claude Opus 5.5 a cualquier cosa que no sean esos dos, ejecuta sus turnos posteriores sin el razonamiento anterior.

Un enrutador o mecanismo de respaldo que traslada una conversación es la forma obvia de toparse con esto. La mitad más sutil es que el bloque también está vinculado al prefijo de la conversación: el mensaje de sistema, las herramientas y cada mensaje anterior a él. Anthropic aplica la comprobación del prefijo de forma predeterminada para las cuentas creadas a partir del 2026-08-31 00:00 UTC, tanto en la API de Claude como en las plataformas en la nube: si reenvías un bloque después de editar el mensaje de sistema, la lista de herramientas o un mensaje anterior, la solicitud devuelve 400. Existen dos vías de escape. Envía la thinking-binding-controls-2026-08-01 cabecera beta y establece thinking.block_binding.prefix_mismatch_behavior en "drop_block" para descartar los bloques afectados en lugar de que la solicitud falle. O mantén la conversación en modo de solo añadir y cambia las instrucciones con un mensaje de sistema a mitad de conversación en lugar de editarlas, que es lo que ya hacen Claude Code, claude.ai, Claude Managed Agents y el Claude Agent SDK.

Hay una buena noticia que es fácil pasar por alto: cuando una solicitud incluye un bloque que el modelo de destino no puede leer, la API lo descarta antes de que el modelo lo vea. La solicitud se completa correctamente y los bloques descartados no se facturan.

4. La herramienta más antigua de uso de computadora es rechazada en la API de Claude y Google Cloud

Una entrada de tools de tipo computer_20251124 devuelve un 400 en la API de Claude y Google Cloud. El mensaje nombra el tipo rechazado y luego enumera los tipos que el modelo sí acepta:

• 'claude-opus-5-5' no admite tipos de herramientas: computer_20251124.

El reemplazo es el computer_toolset_20260801 toolset: elimina el computer-use-2025-11-24 encabezado beta y envía la entrada de herramientas sin nombre y sin dimensiones de pantalla. No se trata solo de un cambio en la solicitud: el bucle del agente cambia con ello. Las acciones llegan como bloques member tool_use en lugar de una única herramienta computer; puede haber varias en un turno, la acción es el name del bloque en lugar de input.action, y cada resultado debe devolver toolset_name. En Amazon Bedrock, computer_20251124 sigue funcionando exactamente igual que en Claude Opus 5 y no se necesita ningún cambio.

¿Cuál de los cuatro se aplica también a Claude Fable 5.1?

Anthropic afirma que las tres primeras también se aplican en Claude Fable 5.1 —pensamiento siempre activo, sin elección forzada de herramientas y bloques de pensamiento vinculados al modelo y a la conversación—. El cambio de uso de computadora no: ese es específico de este modelo en la API de Claude y Google Cloud. Así que un equipo que ya migró a Claude Fable 5.1 ha retirado sus rutas de código con el pensamiento desactivado y sus elecciones forzadas de herramientas, y tiene un patrón de conversación de solo adición; lo que queda es el id del modelo y el conjunto de herramientas de uso de computadora. Un equipo que viene de Claude Opus 5se enfrenta a los cuatro a la vez. Esa es la migración que vale la pena planificar, y supone una cantidad de trabajo distinta según dónde empieces.

El quinto cambio: nada da error y tu feed de progreso se queda en silencio

En Claude Opus 5, las notas breves que el modelo escribe entre llamadas a herramientas vuelven como bloques de texto normales. En Claude Opus 5.5 —al igual que en Claude Fable 5.1— esa narración vuelve como bloques de pensamiento de actualización de progreso, como máximo uno antes de cada llamada a herramientas. Y thinking.display tiene como valor predeterminado "omitted", por lo que esos bloques llegan con un campo thinking vacío junto con su firma.

Ninguna solicitud falla. No se registra ningún error. Una aplicación que transmite a sus usuarios el texto entre herramientas como indicador de progreso simplemente deja de mostrar progreso entre llamadas a herramientas y empieza a no mostrar nada. El síntoma visible es una interfaz que parece congelada durante el tramo exacto de trabajo en el que el usuario más desea tranquilidad, y se reportará como un problema de rendimiento, un problema de red o un cuelgue, no como un error de migración. Este es el cambio que llega a producción.

La solución es una configuración de pantalla, además de una lectura que coincida con ella:

• Establece thinking.display en "updates" — beta, detrás del encabezado thinking-display-updates-2026-08-18 — para recuperar las actualizaciones de progreso mientras el razonamiento en sí permanece oculto. Esta es la configuración que quiere un feed de progreso.

• O configúralo en "resumido" para recibir actualizaciones de progreso y resúmenes de razonamiento combinados en los mismos bloques.

• Luego, lee el texto de los bloques de pensamiento en lugar de los bloques de texto, renderiza cada bloque de pensamiento no vacío delante del bloque tool_use al que precede, y devuelve los bloques sin cambios junto con el resto del turno del asistente.

La propia nota de Anthropic al respecto merece citarse en esencia: se espera que una interfaz que muestra texto entre llamadas a herramientas establezca un valor de visualización en lugar de depender del valor predeterminado. Si tu integración ignora por completo los bloques de pensamiento hoy en día, ese es el único lugar donde el valor predeterminado es seguro.

A single-column scoreboard titled 'Claude Opus 5.5 — the migration at a glance' listing six rows: thinking always on and cannot be disabled; forced tool use returning a 400 error; thinking blocks bound to the model and the conversation; the old computer tool rejected on the Claude API and Google Cloud; progress text hidden by default; and the fix of setting thinking.display to summarized. Footer reads: per Anthropic's Claude Opus 5.5 migration guide, read 2026-09-24; vendor-reported.

El esfuerzo es la superficie de la API.

Con el razonamiento imposible de desactivar, output_config.effort se convierte en el único control sobre cuánto razona el modelo y, por lo tanto, en el único control sobre el coste y la latencia en una tarea determinada. Hay cuatro cosas que conviene saber al respecto antes de copiar una configuración del modelo anterior.

El valor predeterminado cambió. Claude Opus 5.5 usa por defecto el esfuerzo medio, mientras que Claude Opus 5 y los modelos Opus anteriores usaban por defecto el nivel alto. Una solicitud que omite el esfuerzo ahora se ejecuta un nivel por debajo de lo que lo hacía antes del cambio. Anthropic también documenta que el modelo tiende a pensar más por turno con un ajuste de esfuerzo determinado de lo que lo hacía Claude Opus 5, sobre todo en xhigh y max. Esos dos efectos empujan en direcciones opuestas, que es precisamente la razón por la que la instrucción del proveedor es realizar un nuevo barrido de esfuerzo en tus propias evaluaciones en lugar de trasladar un ajuste de un modelo a otro.

La escala es low / medium / high / xhigh / max, las cinco son compatibles aquí. El nivel con nombre no es, de entrada, un presupuesto fijo de tokens —Anthropic describe el esfuerzo como una señal de comportamiento, no como un presupuesto estricto—, y la asignación de tokens que hay detrás de cada nivel cambió entre modelos, así que "high" en Claude Opus 5.5 no es "high" en Claude Opus 5. Ajustar el esfuerzo al valor predeterminado del modelo equivale a omitirlo.

Dos detalles operativos, porque ambos cuestan dinero cuando se pasan por alto. Primero, cambiar el valor de esfuerzo de nivel superior entre solicitudes invalida la caché de prompts: elige un nivel y mantenlo constante dentro de una conversación que dependa de aciertos de caché, y, en su lugar, varíalo entre cargas de trabajo. Segundo, este modelo admite esfuerzo por mensaje (encabezado beta mid-conversation-output-config-2026-07-01), que cambia el nivel a partir de un turno posterior sin reiniciar la caché. El mínimo de la caché de prompts aquí es de 512 tokens, frente a los 1,024 de la generación anterior, por lo que los prompts que antes eran demasiado cortos para almacenarse en caché ahora pueden crear entradas sin ningún cambio en el código.

Límites de salida: 128K en modo síncrono, 300K en Batch

La API de Messages síncrona limita la salida a 128K tokens. La API de Message Batches llega hasta 300K tokens de salida por detrás de la output-300k-2026-03-24 cabecera beta — esa cadena exacta. La entrada es la ventana de contexto completa de 1M de tokens de forma predeterminada, sin necesidad de ninguna cabecera.

La lectura práctica: el techo de 128K no ha cambiado respecto a Claude Opus 5, así que nada de una integración síncrona necesita recalcular el presupuesto solo por ese eje. Lo que sí necesita recalcular el presupuesto es el pensamiento que hay dentro. Dado que max_tokens ahora abarca el pensamiento más el texto en cada solicitud, un valor que era ajustado para el texto de respuesta en Claude Opus 5 aquí queda más estrecho — y con esfuerzo xhigh o max, el proveedor sugiere empezar en 64k y ajustar. Si un trabajo de larga duración se dimensionó según el techo síncrono de 128K y ahora se trunca, el techo no es lo que se movió.

El enrutamiento de Safeguard es parte de la especificación

Esto es un hecho de integración, no una nota al pie de política: en algunos prompts, la cadena de modelo que envías no describe lo que respondió.

Claude Opus 5.5 se entrega con clasificadores de seguridad, y una solicitud rechazada vuelve como HTTP 200 con stop_reason: "refusal" y un objeto stop_details que indica el área de política. Este modelo cubre más categorías que Claude Opus 5 — espera bio, frontier_llm y reasoning_extraction junto con las ya conocidas cyber. El rechazo de reasoning_extraction se bloquea directamente en lugar de reintentarse: el fallback del lado del servidor de Anthropic no lo reintenta y el rechazo se te devuelve.

Para las categorías que sí reintentan, el mecanismo es un parámetro. Establezca fallbacks en "default" con el encabezado beta server-side-fallback-2026-07-01 y la API vuelve a ejecutar una solicitud rechazada en el modelo que Anthropic recomienda para esa categoría, dentro de una sola llamada, devolviendo una única respuesta. El centro de ayuda de Anthropic nombra directamente el enrutamiento para este modelo: las solicitudes de ciberseguridad marcadas recurren a Claude Opus 4.8, y sus clasificadores de biología —el conjunto al estilo de Fable-5— provocan una alternancia a Claude Opus 5 para trabajos de ciencias de la vida de doble uso. Un conjunto reducido de capacidades de desarrollo de LLM de frontera también se enruta a Claude Opus 5. Anthropic también señala que las comprobaciones revisan todo lo que lee el modelo, no solo su último mensaje, por lo que la memoria, el contenido de los conectores, los resultados de búsqueda y los archivos pueden desencadenar un cambio.

Tres cosas se derivan para tu integración. Lee el campo model de nivel superior en cada respuesta, porque informa el modelo que realmente produjo el mensaje, y un bloque de contenido fallback marca cada punto de traspaso. Verifica los límites de velocidad del propio fallback, porque un fallback que alcanza su límite de velocidad no se intenta y en su lugar se devuelve el rechazo: los fallbacks se degradan a rechazos bajo carga. Y trata cualquier ejecución de benchmark publicada con las salvaguardas habilitadas como una medición del sistema enrutado y no solo de Claude Opus 5.5, que es exactamente lo que Anthropic dice sobre sus propias cifras a continuación.

El fallback del lado del servidor es beta y solo para la API de Claude: no es compatible con la API de Message Batches, y no está disponible en Amazon Bedrock, Google Cloud o Microsoft Foundry, donde el middleware del SDK es la ruta documentada en su lugar. En el lado de la verificación, existen rutas de acceso para ambas categorías —el Cyber Verification Program y el Life Sciences Verification Program—, pero observa la asimetría que el centro de ayuda de Anthropic documenta a la fecha de esta redacción: Claude Opus 5.5 no está actualmente listado en el Cyber Verification Program, mientras que el programa de ciencias de la vida se describe como dando a las organizaciones verificadas acceso a los modelos más capaces.

Contexto, corte, retirada y Fast mode

El resto del sobre, de la página del modelo y de la tabla de deprecaciones:

• Ventana de contexto — 1M tokens, predeterminada, sin encabezado beta.

• Fecha de corte de conocimiento: junio de 2026, que también es la fecha de corte de los datos de entrenamiento.

• Retiro — no antes del 2027-09-22 en las plataformas operadas por Anthropic, con un aviso de al menos 60 días. Amazon Bedrock y Google Cloud establecen sus propias fechas. Claude Opus 5 está Activo hasta al menos el 2027-07-24, por lo que no hay una migración forzada.

• Tarifa — $4.00 por millón de tokens de entrada, $20.00 por millón de tokens de salida, $5.00 por millón de escrituras en caché de 5 minutos, $8.00 por millón de escrituras en caché de 1 hora, $0.20 por millón de lecturas de caché. Batch cuesta la mitad en ambos sentidos, a $2.00 / $10.00.

• Las lecturas de caché son la excepción que merece atención: $0.20 es el 5% de la entrada base, mientras que la mayoría de los modelos Claude se sitúan en el 10% y Claude Fable 5.1 en el 2.5%. Las cargas de trabajo mixtas con un uso intensivo de la reutilización de caché lo perciben como un descuento real.

• Modo rápido — todavía documentado como una vista previa de investigación, solo en la API de Claude, con un precio independiente de $8.00 de entrada / $40.00 de salida por millón. Actívalo con speed: "fast" y el fast-mode-2026-02-01 encabezado beta. No está disponible en Bedrock, Claude Platform on AWS, Google Cloud ni Microsoft Foundry, ni con la API por lotes, ni con un compromiso de Priority Tier. Ten en cuenta que Claude Opus 5.5 no admite Priority Tier en absoluto.

Qué dicen los benchmarks y en qué configuración

Los ajustes de esfuerzo son la razón por la que una tabla de proveedor y una tabla independiente no se pueden comparar fila por fila, y por la que cada número a continuación lleva su ajuste.

Reportado por el proveedor, el propio sistema de evaluación de Anthropic. La nota de lanzamiento de Anthropic dice que, salvo que se indique lo contrario, todos los resultados de Claude Opus 5.5 usan pensamiento adaptativo con esfuerzo máximo; la excepción es Terminal-Bench 4.0, reportado con xhigh para Claude Opus 5.5 y con high para GPT-6 Astra, porque esas son las puntuaciones más altas de cada modelo. Sobre esa base, el proveedor informa Terminal-Bench 4.0 con 66,4 %, FrontierCode v1.1 Main con 54,4 %, CursorBench 4.0 con 57,8 %, GDPval-AA v2.1 con 1.846 Elo, AutomationBench con 40,0 %, Humanity's Last Exam con herramientas al 67,7 %, Terminal-Bench-Science 0.1 con 58,7 %, OSWorld 2.0 con 81,8 % parcial, y Chartography con herramientas al 89,0 %. Con el esfuerzo medio predeterminado del modelo, el proveedor otorga a FrontierCode un 54,6 % y a CursorBench un 52,5 %. Observe lo que revela la misma nota: las evaluaciones se ejecutaron con las salvaguardas de producción habilitadas y, cuando estas se activaron, las tareas de ciberseguridad las completó Claude Opus 4.8, y las tareas de biología y de desarrollo de LLM de frontera, Claude Opus 5 —Anthropic dice que esto probablemente reduce el rendimiento de Claude Opus 5.5 en esos benchmarks. Por lo tanto, las puntuaciones publicadas en las evaluaciones afectadas no son mediciones limpias de este modelo.

Independiente, Artificial Analysis. En el Intelligence Index v4.3.2, Claude Opus 5.5 obtiene 58 en la configuración que Artificial Analysis etiqueta como «Adaptive Reasoning, Max Effort, Default Fallback» —su puntuación medida más alta, por varios puntos de diferencia, y lidera seis de las diez evaluaciones constituyentes. En el mismo índice y con el mismo harness, Claude Fable 5.1 obtiene 53 y Claude Opus 5 obtiene 51. Artificial Analysis publica la escala completa de esfuerzo, que es el artefacto independiente más útil aquí: max 58, xhigh 56, high 54, medium 51, low 42. Sus propias mediciones sitúan a Claude Opus 5.5 en aproximadamente 119.000 tokens de salida por tarea del índice con esfuerzo máximo, frente a unos 73.000 de Claude Opus 5, 78.000 de Claude Fable 5.1 y 27.000 de GPT-6 Astra —tokens que se facturan como tokens de salida—, y su página reporta un costo de 5,98 $ por tarea del índice. También mide Terminal-Bench 4.0 en 59,6 % y Humanity's Last Exam en 61,4 %, frente al 66,4 % y el 67,7 % del proveedor con esfuerzo máximo en un harness distinto.

Si se leen esos dos párrafos en contraste, la conclusión honesta es limitada. El 66.4 % de Terminal-Bench del proveedor y el 59.6 % independiente son el mismo benchmark ejecutado por personas distintas con configuraciones que no garantizan coincidir, y ninguno es evidencia sobre tu carga de trabajo. La escala de esfuerzo es el hallazgo transferible: en un índice independiente, las propias configuraciones de este modelo abarcan dieciséis puntos, lo cual es una dispersión mayor que la brecha entre este y su predecesor. Elegir un nivel de esfuerzo importa más que elegir entre estos modelos, y la cláusula «Default Fallback» de esa etiqueta es el enrutamiento de salvaguarda descrito arriba, no un artefacto del benchmark.

Eficiencia reportada por el proveedor, atribuida. Anthropic afirma que Claude Opus 5.5 rinde al nivel de Claude Fable 5.1 en la mayoría de las tareas con un costo de ejecución aproximadamente un 40 % menor, y que las cargas de trabajo típicas cuestan alrededor de un 40 % menos que en Claude Opus 5 frente a una rebaja del precio de lista del 20 %. La salida es más de un 30 % más rápida. Estas son caracterizaciones del proveedor de promedios de cargas de trabajo que el propio proveedor seleccionó. Las declaraciones de clientes en el momento del lanzamiento son el mismo tipo de evidencia: Box reporta un tercio de los tokens y respuestas alrededor de un 40 % menos verbosas, Kiro aproximadamente la mitad de los tokens y cerca de un 40 % menos de llamadas, Factory entre un 20 y un 25 % menos de tokens de salida, GitHub entre los valores más bajos de tokens y pasos que ha medido. Anthropic también reporta una prueba interna de verificación de datos en la que 16 de sus 18 informes superaron un umbral de calidad que ni Claude Fable 5.1 ni Claude Opus 5 alcanzaron en ningún intento. Todo ello está reportado por el proveedor y nada de ello ha sido auditado. La limitación divulgada es inusualmente sincera y vale la pena destacarla: Anthropic dice que Claude Opus 5.5 «con frecuencia sospecha que está siendo evaluado».

Por último, los modelos hermanos: Anthropic dice que Claude Sonnet 5.5 y Claude Haiku 5.5 llegan "en las próximas semanas". Ninguno se ha lanzado, ninguno tiene precio y ninguno está hoy en ninguna superficie.

Probar los cuatro cambios sin una migración completa

El riesgo de la migración aquí no es la calidad, sino que una ruta de código que nunca ejecutaste en el entorno de pruebas sea justamente la que devuelve 400 en producción. Los cuatro cambios que rompen la compatibilidad son todos cambios en la forma de las solicitudes, lo que significa que fallan de forma determinista e inmediata, y la única manera de encontrar las rutas que se te pasaron por alto es hacer pasar tráfico real por ellas.

Claude Opus 5.5 está en OrcaRouter como anthropic/claude-opus-5.5al precio de lista del propio Anthropic con un 0 % de recargo — el precio de lista del proveedor se traspasa tal cual, por lo que cualquier cambio de precio del proveedor se refleja aquí el mismo día.

The OrcaRouter model page for Claude Opus 5.5, showing the identifier anthropic/claude-opus-5.5, input at $4.00 and output at $20.00 per 1M tokens, a 1M-token context window, 128K max output, text plus image and file input, and OpenAI-compatible and Anthropic Messages endpoints served from api.orcarouter.ai.

Eso te permite dirigir un porcentaje del tráfico de producción al modelo mientras el resto sigue ejecutándose en Claude Opus 5, observar qué solicitudes fallan y por qué, y corregirlas una a una. Los cuatro errores se describen por sí mismos: cada uno nombra el parámetro que rechazó y, en tres de los cuatro casos, el reemplazo. La conmutación por error automática cubre el vacío mientras una ruta aún está rota: una solicitud que falla contra un modelo que no has caracterizado por completo recurre a uno que sí tienes, en lugar de mostrar el 400 al usuario.

Un orden de trabajo práctico: cambiar el id del modelo y establecer el esfuerzo explícitamente primero, ya que el valor predeterminado pasó a medium; eliminar a continuación las rutas de thinking deshabilitado y de elección forzada de herramientas; luego corregir el lector de streaming —la selección de bloques por tipo y el ajuste thinking.display—, porque es el que falla en silencio en lugar de fallar de forma evidente; y dejar para el final la migración del conjunto de herramientas de computer use si usas Bedrock, ya que es el que no aplica allí. Todo lo demás —el precio, la ventana de contexto, las tarifas de caché y el valor predeterminado de 1M de tokens— ya está donde lo dejaste.

Dirige una parte del tráfico en vivo al nuevo modelo sin una migración completa: Claude Opus 5.5 en OrcaRouter se ejecuta al precio de lista de Anthropic con conmutación por error automática a un modelo que ya has caracterizado.

Comparados en este artículo4

Detectado en este artículo · Benchmarks: Artificial Analysis · actualizado a diario