Actualizar un modelo cambia el contrato de integración, no solo su identificador

Anthropic lanzó Claude Sonnet 5.5 el 28 de septiembre y comunicó mejoras de velocidad y eficiencia por tarea. Para los equipos que construyen sus propias solicitudes a la Messages API, la guía de migración merece tanta atención como las cifras de rendimiento. Describe cambios en los parámetros aceptados y en el tratamiento de las conversaciones. En cambio, Anthropic indica que quienes usan Claude Managed Agents solo necesitan actualizar el nombre del modelo. El análisis que sigue se centra en las integraciones propias con la API. [1] [2]

Una prueba rápida de un solo turno puede pasar por alto dos problemas distintos: una solicitud que falla de inmediato y otra que se completa con un contexto diferente. Cada caso exige un criterio de aceptación propio. Una respuesta HTTP correcta demuestra que el servicio respondió, no que la aplicación conservó su flujo de trabajo. Esa distinción debe guiar el plan de migración.

Sonnet 5 aceptaba thinking: {"type": "disabled"}. Sonnet 5.5 rechaza esa configuración con un error 400. Su nivel mínimo de razonamiento es between_tools, disponible con los niveles de esfuerzo low, medium y high; xhigh y max lo rechazan. Cambia el contrato de la solicitud, no solo una preferencia de ajuste. Los equipos que desactivaban el razonamiento para controlar la latencia deben elegir expresamente la nueva configuración y volver a medir el flujo de trabajo, en vez de suponer que la solicitud anterior seguirá funcionando. [2]

El modo between_tools elimina el razonamiento extendido previo a la respuesta, pero las actualizaciones de progreso entre llamadas a herramientas aún pueden llegar como bloques thinking. El bucle de herramientas debe devolver esos bloques intactos junto con el mensaje completo del asistente. Conviene revisar cualquier lector que suponga que el primer bloque de contenido siempre es texto, o que reconstruya un turno solo con texto y llamadas a herramientas. Para leer, importa el tipo de cada bloque; para continuar la conversación, hay que conservar el turno del asistente tal como llegó. [2] [6]

Sonnet 5.5 rechaza los valores de tool_choice que fuerzan una llamada: tool y any. Anthropic recomienda auto con esquemas de herramientas strict cuando la plataforma lo admite. El modo estricto puede limitar la forma de los argumentos de una llamada que sí ocurra; auto todavía permite al modelo responder sin llamar a ninguna herramienta. Amazon Bedrock no ofrece strict tool use para este modelo, por lo que allí la aplicación debe validar por sí misma los argumentos. [2] [4]

La distinción afecta al resultado operativo. Si un flujo exige consultar el registro actual antes de responder, una respuesta bien formada no demuestra que se haya hecho la consulta. Marque ese paso como completo solo cuando reciba y valide el resultado de la herramienta requerida. Lleve esa regla a la aplicación y pruebe ambas rutas: una llamada válida y una respuesta directa cuando la llamada era obligatoria. Es una inferencia arquitectónica a partir del comportamiento documentado, no una afirmación sobre la frecuencia con la que Sonnet 5.5 omite herramientas.

Los bloques thinking de Sonnet 5.5 solo pueden reutilizarse desde la cuenta que los generó o desde una cuenta vinculada. Si los devuelve una cuenta no vinculada, la API los descarta antes de la inferencia y la solicitud se completa; sin la cabecera de diagnóstico correspondiente, el descarte es silencioso. Un cambio de modelo también puede hacer ilegible un bloque. Por tanto, una respuesta correcta del enrutador no demuestra que el modelo haya recibido el razonamiento anterior. [3]

Existe además una regla de prefijo: las instrucciones system, las herramientas y los mensajes anteriores deben permanecer intactos al reenviar un bloque thinking firmado. Las cuentas creadas a partir del 31 de agosto de 2026 tienen esta comprobación activada por defecto; las más antiguas tienen otra configuración predeterminada, así que una prueba sin errores con una clave no garantiza lo mismo para todos. Conserve el historial de forma que solo se añadan mensajes y pruebe la reanudación de sesiones guardadas, los cambios de herramientas, el recorte del historial en el cliente y los cambios de ruta. Cuando esté disponible, consulte input_transformations para detectar bloques descartados. [3]

La guía de migración también pide gestionar los rechazos. Un rechazo debe entrar en la lógica de respuesta y revisión del producto; reenviar la solicitud a ciegas como si hubiera fallado la red confunde una decisión de política con una caída del servicio. Anthropic documenta una alternativa de servidor opcional y limitada a ciertas categorías de rechazo en la Claude API. Eso no convierte todos los rechazos en solicitudes reintentables ni promete el mismo comportamiento en todas las plataformas. [5]

En las pruebas de aceptación, registre el motivo de detención real, si se activó una alternativa configurada oficialmente y qué vio la persona usuaria. Así se puede observar el tratamiento de seguridad sin usar un reintento de bajo nivel para eludir un rechazo. También evita que un panel basado solo en respuestas HTTP correctas oculte cambios en las respuestas que reciben los usuarios.

Proponemos cinco rutas de aceptación: una solicitud antigua con el razonamiento desactivado; una llamada a herramienta antes forzada; un intercambio de varios turnos que reenvíe bloques thinking; una conversación guardada que se reanude con la cuenta y el enrutamiento reales; y un rechazo gestionado por el producto. Compruebe el estado HTTP, los tipos de bloques, la ejecución y validación de herramientas, los diagnósticos de continuidad disponibles y el estado final visible para el usuario. Incluya una sesión larga y un cambio de ruta: una prueba rápida de un solo turno no revela los errores del historial.

Después, compare la tasa de tareas aceptadas, el tiempo total y el coste por tarea aceptada para un nivel de esfuerzo declarado. Las cifras de velocidad y coste de Anthropic sirven como hipótesis para ese experimento, no sustituyen una medición de su propia carga de trabajo. La lección se extiende más allá de este lanzamiento: un modelo forma parte del protocolo entre la aplicación, las herramientas, el historial y los usuarios. La actualización termina cuando ese protocolo sigue entregando el resultado previsto. [1]