BookinglyTech News
Inteligencia artificial

Anthropic abarata Opus 5.5 y rompe cuatro cosas de las que dependen los agentes

El modelo baja de 5 a 4 dólares por millón de tokens de entrada y de 25 a 20 por millón de salida, pero migrar arrastra cuatro rupturas de compatibilidad para los agentes en producción.

4 min de lecturaThe New Stack0 vistas

Anthropic ha abaratado Claude Opus 5.5, publicado el martes: la entrada pasa de 5 a 4 dólares por millón de tokens y la salida, de 25 a 20. La ventana de contexto de un millón de tokens y la salida máxima de 128.000 siguen igual. Sobre el papel, actualizar es cambiar el identificador del modelo y ya. En la práctica, quien tenga agentes en producción se va a comer cuatro cambios que rompen compatibilidad.

Los cuatro que devuelven un 400

El primero toca el control del razonamiento. Si la petición pone thinking a disabled, o a enabled con budget_tokens, Opus 5.5 responde con un error 400. La única palanca que queda es effort. Los agentes que apagaban el pensamiento en pasos simples para ahorrar tokens tendrán que asignarles un effort más bajo. Como el razonamiento va ahora siempre activo, las respuestas empiezan con bloques de thinking: el código que asume que el primer bloque de contenido es texto hay que tocarlo. Y el effort por defecto baja de high en Opus 5 a medium en Opus 5.5, así que las peticiones que no mandan el parámetro se ejecutan más baratas y con menos esfuerzo sin avisar. Anthropic recomienda fijarlo de forma explícita y repetir las evaluaciones de effort.

El segundo: se acabó forzar el uso de herramientas. Poner tool_choice a any o a tool devuelve 400, también en el endpoint de conteo de tokens, con lo que las estimaciones de coste montadas sobre esos ajustes fallan junto a las peticiones que pretendían tasar. Los bucles que forzaban una llamada para consultar una base de datos o ejecutar código tienen que pasar a auto combinado con strict tool use o structured outputs, y dejar escrito en el prompt cuándo aplica la herramienta.

El tercero afecta a los enrutadores. Los bloques de thinking quedan atados al modelo y a la conversación que los generó. Solo Fable 5.1 y Mythos 5.1, además del propio Opus 5.5, saben leerlos; cualquier otro modelo al que se derive la conversación ejecutará esos turnos sin el razonamiento previo, y sin dar error. Opus 5.5 sí lee bloques de Opus 5 y de Opus, Sonnet y Haiku anteriores, pero no de Fable ni Mythos. La conversación tiene que seguir siendo solo-añadir: recortar mensajes antiguos, cambiar definiciones de herramientas, resumir contexto en el cliente o reescribir el system prompt invalida los bloques existentes. En cuentas creadas desde el 31 de agosto de 2026 a medianoche UTC, reproducir un bloque tras una de esas ediciones devuelve 400 por defecto. Las cuentas antiguas no ven el error, pero los bloques inválidos llegan igual al modelo. La compañía tiene documentación de preserved thinking para quien compacte su propio contexto.

El cuarto es para agentes de uso de ordenador en la API de Claude y en Google Cloud: Opus 5.5 rechaza la herramienta computer_20251124 y solo acepta computer_toolset_20260801. La petición se simplifica (fuera la cabecera beta, la entrada del toolset no lleva nombre ni dimensiones), pero el bucle del agente se complica: cada acción llega como su propio bloque tool_use identificado por nombre y no por input.action, un turno puede traer varios y cada resultado debe devolver toolset_name. La herramienta antigua sigue funcionando en Amazon Bedrock.

Lo que no da error y también muerde

El cambio más silencioso no lanza nada. En Opus 5, el texto que Claude escribía entre llamadas a herramientas volvía como bloques de texto; en 5.5 llega como bloques de progreso y, con thinking.display en su valor por defecto (omitted), esos bloques van vacíos. Cualquier interfaz que streamee esa narración al usuario se queda muda entre herramienta y herramienta hasta que se ponga display a updates o a summarized, y se rendericen los bloques no vacíos antes de la llamada que preceden.

Además, los clasificadores de seguridad son más amplios: el stop_reason puede ser refusal con categorías que ahora incluyen bio y reasoning_extraction junto a cyber, y el fallback del lado del servidor no reintenta lo rechazado por reasoning_extraction. Quien no maneje rechazos verá al agente pararse a mitad de tarea.

Los equipos que vienen de Opus 4.8 tienen que hacer antes la migración a Opus 5, que ya cubre el razonamiento activo por defecto y el cambio de forma de las respuestas. Los de Opus 4.7 o anteriores tienen más terreno por delante. La pregunta práctica no es si compensa el dólar de diferencia en entrada, sino cuántos de esos cuatro 400 aparecen en los logs la primera semana.