Los modelos nuevos traen dos cambios que rompen código que hoy funciona, y ninguno de los dos aparece en los titulares del lanzamiento. El primero: en Fable 5.1 y Mythos 5.1, los valores any y tool del parámetro tool_choice devuelven un error 400. El segundo: los bloques de pensamiento quedan atados al modelo que los generó, lo que cierra una técnica de destilación y, de paso, afecta a cualquier agente que reescriba su propio historial.
Qué hacía tool_choice y por qué el 400 escuece
Repasemos el parámetro, porque es de los que se configuran una vez y se olvidan. tool_choice le dice al modelo cómo debe comportarse con las herramientas que le has declarado. Con auto, decide él si usa alguna. Con none, no usa ninguna. Con any, se le obliga a usar alguna herramienta, la que sea. Y con tool, se le obliga a usar una concreta.
Esos dos últimos son justo los que usa todo el mundo cuando quiere una respuesta con forma garantizada: forzar una herramienta era la manera clásica de asegurarse de que la salida venía como un objeto con los campos que esperas, en lugar de como texto libre que luego hay que parsear. Es el patrón que hay detrás de la mitad de las integraciones de extracción de datos que se han escrito en los últimos dos años.
Por eso el cambio duele más de lo que parece: no falla cuando actualizas una librería ni cuando cambias un prompt. Falla el día que cambias el identificador del modelo a claude-fable-5-1 en una llamada que llevaba meses funcionando. Y si eso ocurre dentro de un nodo de n8n que se ejecuta de madrugada, el aviso llega tarde.
Qué poner en su lugar
La documentación señala cuatro alternativas: auto, none, el uso estricto de herramientas y las salidas estructuradas. La elección depende de para qué usabas el parámetro.
Si lo que buscabas era garantizar el formato de la respuesta —el caso más común—, el sustituto natural son las salidas estructuradas: defines el esquema y el modelo responde con esa forma, sin depender de que una herramienta actúe de molde. Es, de hecho, una solución más limpia que la que estabas usando.
Si lo que necesitabas era asegurar que se llamara a una función concreta dentro de una cadena de pasos, toca replantear un poco el flujo: dejar el paso en auto con una instrucción explícita y validar después que la llamada se produjo, o partir el proceso en dos turnos donde el segundo solo tenga esa herramienta disponible.
Este error no aparece al actualizar la librería: aparece el día que cambias el nombre del modelo.
Los bloques de pensamiento se atan a su modelo
El segundo cambio es más sutil y tiene más recorrido. Ahora los bloques de pensamiento solo se preservan para el modelo que los produjo o para modelos más nuevos. En la práctica, Fable 5.1 acepta bloques de pensamiento generados por Opus 5, Fable 5, Mythos 5 y modelos anteriores, pero la validación deja de ser laxa: las cuentas creadas después del 31 de agosto de 2026 reciben una comprobación más estricta, bajo la cabecera beta thinking-binding-controls-2026-08-01.
La consecuencia visible es la que describe el propio anuncio del modelo: ya no se puede editar a mano el contexto previo de una conversación conservando intacta la transcripción del razonamiento. Antes se podía reescribir lo que Claude había «dicho» en turnos anteriores manteniendo su cadena de pensamiento; ahora, no.
El motivo declarado es impedir la destilación: usar las transcripciones de razonamiento de un modelo caro para entrenar otro más barato. Es una técnica documentada y, desde el punto de vista de quien paga el entrenamiento, cerrarla tiene toda la lógica del mundo.
A quién pilla de rebote: los harnesses de agentes
El daño colateral está en un sitio que no tiene nada que ver con la destilación. Los agentes que gestionan conversaciones largas reescriben su propio historial constantemente: compactan turnos antiguos para no reventar el contexto, resumen lo que ya no cabe, sustituyen una tanda de mensajes por una versión condensada. Es una técnica estándar y es exactamente «editar el contexto previo».
Si tu harness hace eso y además arrastra los bloques de pensamiento, la validación estricta te va a rechazar peticiones que antes pasaban. No es un problema para quien usa Claude Code —el harness oficial ya se encarga—, pero sí para quien ha construido su propio orquestador de agentes, que es cada vez más gente.
💡 Migración en tres pasos, antes de tocar producción
1. Busca tool_choice en todo tu código y tus workflows; cada aparición con any o tool es una llamada que fallará con los modelos 5.1. 2. Sustituye por salidas estructuradas donde solo querías garantizar el formato. 3. Si tienes un orquestador propio, comprueba si compacta o reescribe el historial conservando bloques de pensamiento, y prueba una conversación larga completa antes de cambiar el modelo en el flujo bueno.
La lectura general de estos dos cambios es la misma que llevamos viendo todo el verano: la API está pasando de ser permisiva a ser explícita. Menos formas de conseguir lo mismo, más validación por delante y menos margen para montajes que funcionaban por costumbre. A medio plazo es una buena noticia, porque los flujos frágiles fallan antes y de forma más clara. A corto, significa que actualizar de modelo dejó de ser cambiar una cadena de texto en una variable de entorno.
Si mantienes integraciones para clientes, este es el momento de hacer el inventario tranquilo: mejor encontrar los cuatro sitios donde forzabas una herramienta ahora que en la llamada del cliente el martes por la mañana.
