Pasar a Claude Opus 5.5: Cinco cambios significativos detrás del ID del modelo

Una cadena, cinco sorpresas

Imagínese el viernes posterior al anuncio del lanzamiento. Anthropic ha distribuido Claude Opus 5.5 (22 de septiembre de 2026), descrito como capaz de alcanzar el nivel de Fable en la mayoría de las tareas, un 40% más económico en ejecuciones típicas, con un precio de lista de $4 por entrada y $20 por salida por millón de tokens. Todos están entusiasmados con el descuento, mientras que su herramienta de producción sigue diseñada para Opus 5 y solo existe un parámetro del modelo que se interpone en el camino. Cambie model por claude-opus-5-5.

El primer canario no parece más inteligente. Falla con un HTTP 400 por pensar que algo estaba mal, o debido a una tool_choice que su bucle impone en cada turno. O bien la solicitud se procesa, siguen apareciendo piezas de herramienta, pero la narración entre herramientas que antes transmitía la interfaz de progreso queda en silencio. Sin error, sin agente más eficiente, y el equipo de operaciones comienza a preguntarse si la tarea se ha atascado.

Esto es una verificación previa al lanzamiento y no un resumen posterior. Cinco aspectos esperan detrás del nuevo ID de modelo: pensamiento constante, uso forzado de herramientas, bloqueos en el razonamiento vinculados al modelo, una herramienta de uso informático ya retirada, y un cambio en la estructura de transmisión que nunca genera un error 400. Cambiar la cadena de texto es fácil; lo realmente difícil es sobrevivir a la siguiente solicitud.

Lo que dice la cobertura y lo que dicen los documentos

La cobertura mediática se centra en el precio. El anuncio y los artículos relacionados refuerzan las afirmaciones sobre el nivel de Fable, las medidas de seguridad cibernética y un Opus más económico. Las cifras de Anthropic lo respaldan: resultados del orden de Fable 5.1 en la mayoría de las tareas, un gasto aproximadamente un 40% menor en una ejecución típica, precios de 4 $/20 $ frente a 5 $/25 $ para Opus 5, y una velocidad de salida un 30% mayor. Una tasa de lectura de caché de 0,20 $ es solo un dato en la lista de precios y no constituye el punto principal.

La documentación dice menos, pero es precisa. Su resumen de la plataforma menciona cuatro cambios significativos en el código que ya funciona con Opus 5. No se puede desactivar la capacidad de razonamiento. Existen errores por uso forzado de herramientas. Los bloques de razonamiento quedan vinculados a un modelo y a una conversación específicos. Además, la herramienta antigua computer_20251124 no es aceptada en la API de Claude ni en Google Cloud.

El riesgo radica en los bucles de agentes de la API de Mensajes personalizados, los enrutadores multimodelo y los flujos de trabajo que obligan al uso de herramientas y agentes en la API de Claude o en GCP, ya que todos ellos siguen enviando solicitudes en el formato Opus 5. Algunas configuraciones son más seguras. Los Agentes Gestionados de Claude solo necesitan el nuevo nombre del modelo, y Claude Code junto con el SDK de Agentes se integran en las conversaciones, lo que reduce la exposición a problemas relacionados con el enlace de procesamiento de pensamientos. Afirmar que todo deja de funcionar sería inexacto. No obstante, la actualización merece ser adoptada, y los daños son reales para quienes consideran que un mensaje de lanzamiento equivale a una puerta de entrada definitiva. Los precios bajaron mientras se endurecían las reglas de solicitud, por lo que no se trata simplemente de un reemplazo directo de texto.

Los cinco puntos son:

1. El procesamiento adaptativo está siempre activo. Tanto thinking.type.disabled como enabled junto con budget_tokens devuelven un código 400.

La imposición forzada de tool_choice con los valores any o tool genera un código 400.

Los bloques de razonamiento están vinculados al modelo que los creó, por lo que los enrutadores pierden la información de razonamiento no legible aunque la solicitud siga teniendo éxito.

computer_20251124 es rechazado en la API de Claude y en GCP (Bedrock aún lo acepta).

La narración entre herramientas se traslada a bloques thinking que quedan vacíos con el valor predeterminado display: "omitted", y esto nunca genera un código 400.

Cuatro de estos escenarios fallan de manera evidente con un código 400. Los casos silenciosos no lo hacen, y así es como la interfaz de progreso desaparece tras recibir un código 200. El nivel de esfuerzo predeterminado también cambió: Opus 5 utilizaba high y 5.5 emplea medium, por lo que un cambio simple altera el comportamiento incluso sin errores. Un Opus más económico que rechaza tu configuración provoca tiempo de inactividad acompañado de un comunicado de prensa.

Primera regla: el pensamiento no se puede apagar

En Opus 5, enviar thinking: {"type": "disabled"} con un nivel de esfuerzo high o inferior funcionaba, al igual que tener enabled en modo manual junto con budget_tokens. Opus 5.5 ignora lo que hacía anteriormente la ruta de latencia. La documentación indica que el pensamiento adaptativo está siempre activo y que la profundidad se controla a través del parámetro de esfuerzo.

Al enviar thinking.type.disabled, la API responde con un HTTP 400 que señala a thinking.type.adaptive y output_config.effort. Lo mismo ocurre con el valor enabled. Las rutas de chat ajustadas para minimizar la latencia y los ciclos de herramientas económicas que desactivan el proceso de razonamiento para ahorrar tokens fallan primero, en la primera llamada después del cambio. El código que espera que el primer bloque de contenido sea de tipo text también falla, ya que las respuestas pueden comenzar con bloques thinking cuyo texto está vacío debido a la configuración predeterminada display: "omitted".

Soluciones:

• Omitir thinking o enviar {"type": "adaptive"}.
• Establecer la profundidad con output_config.effort, teniendo en cuenta que el valor predeterminado es medium. En los casos en que se haya desactivado previamente el proceso de razonamiento, elegir low.

Selecciona los bloques de contenido por type, y refleja el proceso de razonamiento sin modificaciones en los bucles de la herramienta.

Deja espacio adicional en max_tokens para el razonamiento del que ya no se puede prescindir.

El funcionamiento constante no implica necesariamente más capacidad, ya que el esfuerzo invertido es lo que determina los límites. Solo en la API de Claude existe un modo rápido (aproximadamente 2,5 veces más rápido por $8 / $40), para casos en los que la latencia es la verdadera limitación, y no en Bedrock ni GCP. thinking: disabled no es simplemente obsoleto; genera un error 400.

Régimen dos: fin del uso forzado de herramientas

Opus 5.5 no admite el uso forzado de herramientas, lo cual constituye un cambio en el comportamiento y no una descontinuación gradual. Un tool_choice de {"type": "any"} o {"type": "tool", "name": "..."} devuelve un código 400 indicando que el tool y los tipos any no son compatibles con este modelo. Los valores auto (el valor predeterminado) y none siguen funcionando.

Los agentes que fuerzan el uso de una herramienta en cada turno, como búsquedas meteorológicas, llamadas a bases de datos o una regla que indica “siempre llamar a search_codebase”, fallan en este caso, al igual que la aplicación de esquemas que dependía del nombre de una herramienta. Las pruebas previas de CI que acceden al endpoint de conteo de tokens con una selección forzada también fallan, por lo que un “canary” puede quedar afectado en los cálculos de facturación antes incluso de que se realice la llamada a Messages. Desde el exterior, la interrupción parece ser “solo cambiamos el modelo”, mientras que el rastro de llamadas muestra que aún se está enviando un plano de control Opus 5.

Soluciones:

• Usar tool_choice: {"type": "auto"}.
• Agregar strict: true a las herramientas, o utilizar salidas estructuradas.
• Especificar en la instrucción cuándo se debe usar cada herramienta, por ejemplo “llamar a la herramienta get_X cuando...”, lo cual funciona mejor que una selección forzada que ahora rechaza la API.

Ejecuta nuevamente cada llamada a count_tokens si aún pasa las pruebas any o tool.

Esto falla antes de que se ejecute el modelo, y no existe una solución alternativa que haga que, en la mayoría de los casos, se utilice la herramienta. Una política de “siempre realizar búsqueda” se ha convertido en un obstáculo para el despliegue.

Ruina tres: bloques de razonamiento vinculados a un modelo

Cada bloque de razonamiento lleva marcado el modelo que lo generó, y un modelo puede interpretar sus propios bloques además de un conjunto limitado de bloques de otros modelos. Opus 5.5 puede manejar el razonamiento de Opus 5 y versiones anteriores de Opus, así como de Sonnet y Haiku. Los resultados de Fable y Mythos no forman parte de ese conjunto. Por otro lado, solo Fable 5.1 y Mythos 5.1 (en la API de Claude) pueden interpretar lo que escribió Opus 5.5.

Si un router o solución de respaldo envía una conversación desde claude-opus-5-5 a Sonnet, GPT u otro modelo, la API descarta los bloques que el destino no puede leer. La solicitud sigue teniendo éxito y los bloques descartados no se facturan. Lo que ocurre a continuación es una disminución silenciosa en la calidad, sin error 400, razonamiento más superficial y un panel de control que permanece en verde.

Alterar system, tools o configuraciones anteriores a mitad de una conversación también puede invalidar los bloques. Las cuentas abiertas a partir del 31 de agosto de 2026 (00:00 UTC) reciben un error 400 de forma predeterminada cuando se vuelve a reproducir un bloque de razonamiento después de editar un prefijo. La versión beta thinking-binding-controls-2026-08-01 permite utilizar prefix_mismatch_behavior: "drop_block" en su lugar. Claude Code, claude.ai, Managed Agents y el Agent SDK ya solo añaden contenido, lo que mantiene su exposición reducida.

Correcciones:

• Mantenga las conversaciones de forma exclusivamente append-only.
• Cambie las instrucciones mediante mensajes del sistema durante la conversación, y no reescribiendo el prefijo.
• Considere un cambio de modelo como un reinicio del razonamiento, a menos que la documentación indique lo contrario.
• Devuelva los bloques de razonamiento tal como aparecieron, y no asuma que cada modelo Claude pueda seguir el razonamiento del 5.5 después de un cambio.

Incluso una solución alternativa que “funcione” puede descartar el razonamiento que hizo posible esa respuesta.

Ruptura cuatro: la antigua herramienta de uso en computadoras

Opus 5 requiere tanto computer_toolset_20260801 como, en versión beta, computer_20251124. En la API de Claude y Google Cloud, Opus 5.5 solo necesita el conjunto de herramientas, y al declarar computer_20251124 se obtiene un error 400 que indica que claude-opus-5-5 no admite ese tipo de herramienta. Amazon Bedrock aún lo acepta, por lo que no hay cambios en ese caso. La familia de modelos es la misma, aunque la matriz de plataformas difiere; por eso, los colegas que solo trabajan con Bedrock no deberían verse obligados a realizar una reescritura que no necesitan.

Los agentes de escritorio y del navegador en la API de Claude o GCP que aún declaran el tipo antiguo y envían el encabezado beta computer-use-2025-11-24 fallan en la primera declaración de herramienta. Sustituir únicamente el tipo no es suficiente, ya que las bucles que leen input.action también se interrumpen. Los bloques con el miembro tool_use colocan la acción en el campo name del bloque; una sola iteración puede contener varios usos de herramienta, y cada resultado necesita que se devuelva toolset_name: "computer".

Soluciones:

• Eliminar el encabezado beta.
• Enviar tools=[{"type": "computer_toolset_20260801"}], omitiendo el campo name y las dimensiones de visualización en la declaración.
• Actualizar el bucle del agente para que utilice los nombres de los miembros y toolset_name.

La capacidad aumentó (una puntuación de OSWorld 2.0 reportada por la empresa fue del 81,8%, clasificada como parcial), y con ella llegó la función de integración.

Ruptura cinco: el flujo se silencia

Bajo Opus 5, las comunicaciones entre las llamadas a las herramientas se mostraban como bloques text, de modo que la interfaz podía imprimir algo como “Verificando migraciones...” y los operadores permanecían tranquilos. Opus 5.5 mantiene la estructura de Fable 5.1, y en esta versión esas comunicaciones aparecen como bloques thinking de actualización de progreso, uno como máximo antes de cada llamada a una herramienta. Dado que thinking.display tiene como valor por defecto “omitted”, el campo thinking se muestra vacío. La documentación advierte que una interfaz que muestre esas líneas como progreso se quedará en silencio entre las llamadas a las herramientas hasta que se seleccione un valor de display que devuelva el texto.

Ninguna solicitud falla y el estado es 200. Las piezas de la herramienta siguen mostrándose, pero el diálogo entre ellas ha desaparecido, y los usuarios consideran que el agente se colgó.

Correcciones:

• Elija display: "updates" (se necesita la versión beta thinking-display-updates-2026-08-18) para el texto de progreso sin los razonamientos, o "summarized" para ambos, y muestre cualquier razonamiento distinto de vacío antes del tool_use que sigue. Los bloques manuales se devuelven sin cambios.

Las cuatro interrupciones graves generan un error 400, pero esta no lo hace nunca, y así es como las interfaces de progreso parecen funcionar correctamente en un entorno de prueba. El error de migración más problemático es aquel que devuelve 200.

Lista de verificación: sí o no

Trate este cambio como una prueba piloto y no como un ajuste de configuración rutinario. Antes de que claude-opus-5-5 reciba tráfico:

• Actualice el ID del modelo a claude-opus-5-5, utilizando el ID específico de la plataforma en Bedrock, GCP o Azure.
• Elimine thinking: disabled y enabled junto con budget_tokens, y luego establezca explícitamente output_config.effort, ya que el valor predeterminado es medium.
• Sustituya tool_choice con valores de any o tool por auto, además de especificar herramientas estrictas o salidas estructuradas, junto con una instrucción para el prompt.
• Para su uso en computadora a través de la API de Claude o GCP, cambie al conjunto de herramientas computer_toolset_20260801 y actualice el bucle del agente. Bedrock podría mantener computer_20251124.
• En los routers, espere que se pierda la capacidad de razonamiento al pasar de la versión 5.5, excepto en los casos de Fable o Mythos 5.1 en la API de Claude.
• Elija el contenido por type y mantenga los bloques thinking sin modificaciones.

En las interfaces en proceso, establezca display en "updates" o "summarized".

Mantenga las conversaciones de solo escritura, y siga las pautas de conservación de pensamientos si se editan los prefijos, especialmente en cuentas creadas a partir del 31 de agosto de 2026.

Establezca nuevamente como referencia el costo y la latencia según el nivel de esfuerzo que realmente desee, y pruebe en entorno de desarrollo antes de activar el tráfico de producción.

Opcionalmente, ejecute la habilidad Claude Code /claude-api migrate.

Solo los agentes gestionados por Claude pueden cambiar únicamente con el nombre, y la documentación no indica nada más aparte de que es necesario actualizar allí el nombre del modelo. Las herramientas de la API de mensajes personalizados no forman parte de ese grupo, y mantienen las estructuras de solicitud de Opus 5 hasta que la lista esté en estado verde. La habilidad de migración puede detectar estructuras obsoletas antes del cambio, pero los enrutadores y las interfaces de progreso siguen requiriendo pruebas propias, ya que no reemplazan a un canario. El esfuerzo por defecto pasó de alto en Opus 5 a medio en 5.5, así que no aplique suposiciones antiguas de alto esfuerzo a un valor por defecto de nivel medio.

Elija la actualización intencionadamente

Opus 5.5 merece ser adoptado intencionadamente, ya que para solicitudes de clase Fable ofrece un costo aproximadamente un 40% más bajo por ejecución típica y un tiempo de respuesta más rápido. Migre porque el modelo es mejor, no porque un anuncio de lanzamiento pareciera una barrera para acceder a él. Lo que importa ahora es la forma de realizar la solicitud, y las cuatro interrupciones documentadas junto con el flujo silencioso constituyen esa barrera. La cobertura no las enumera junto a la reducción de precios.

Los errores graves del tipo 400 son ruidosos, mientras que las caídas del enrutador y display: "omitted" son silenciosos; por lo tanto, debe monitorear ambos tipos o solo detectará los fallos que son evidentes. Las diferencias entre plataformas también cuentan: Bedrock sigue aceptando computer_20251124, mientras que la API de Claude y GCP no lo hacen. Los Agentes gestionados requieren un cambio de nombre, pero una API de mensajes personalizada no goza de tal exención. El esfuerzo necesario ha reemplazado al interruptor de apagado, por lo que el costo y la latencia necesitan una nueva base de referencia, y no se debe asumir que las consideraciones económicas relacionadas con el modo desactivado sigan siendo válidas.

Cambiar la cadena de texto no cuesta nada, mientras que migrar sí lo hace. La actualización es real y la historia de reemplazo inmediato es ficción. Complete la lista de verificación, establezca nuevamente el punto de referencia y solo entonces redirija el tráfico a claude-opus-5-5.