Claude Fable 5.1 vincula los bloques de pensamiento a una sola conversación — Las cuatro ediciones que ahora le cuestan el razonamiento a su agente (2026)

Tres documentos oficiales describen esto, y describen mitades diferentes. Las notas de la versión lo anuncian, la página Novedades en Claude Fable 5.1 resume el cambio disruptivo, y una página dedicada a Pensamiento preservado contiene las reglas completas y una lista de verificación para la migración. Un cuarto artículo del centro de ayuda para el usuario final, actualizado el mismo día, muestra cómo se ve el mismo mecanismo cuando no se toca la API en absoluto.

Los bloques de pensamiento ahora llevan un modelo y una firma

La regla es direccional. En palabras de Anthropic: "Cada bloque de pensamiento registra qué modelo lo produjo, y se preserva en una sola dirección: Claude Fable 5.1 lee los bloques de pensamiento de modelos anteriores, y ningún modelo anterior lee los de Claude Fable 5.1".

Por lo tanto, una conversación que se mueve hacia arriba conserva su razonamiento. Una conversación que se mueve hacia abajo lo pierde en los turnos que se ejecutan allí. Fable 5.1 acepta bloques de Opus 5, Fable 5, Mythos 5 y modelos anteriores. Ninguno de ellos lee los de Fable 5.1.

Cuando una solicitud lleva un bloque que el modelo de destino no puede leer, "la API descarta el bloque antes de que el modelo lo vea". Los bloques descartados no se facturan. Y la parte que importa para la depuración: con la cabecera beta thinking-binding-controls-2026-08-01, el descarte se informa en un array de nivel superior input_transformations. Sin ella, según los documentos, "el descarte es silencioso".

Sobre la comprobación del modelo se sitúan dos más. La API verifica que "Nada antes del bloque haya cambiado" (el prompt system de nivel superior, el conjunto de herramientas en tools y cada mensaje antes del bloque) y que "La cadena de bloques de pensamiento anteriores no esté rota", porque "cada bloque de pensamiento registra el anterior, a lo largo de los turnos".

Las cuatro ediciones que invalidan todo lo posterior

La página de la versión enumera los patrones claramente. Estos invalidan cada bloque de pensamiento posterior:

• "Editar, reordenar o eliminar un turno anterior mientras se mantienen los posteriores".
• "Inyectar texto por solicitud en un turno anterior (un recordatorio o una línea de estado) que luego se elimina en la siguiente solicitud".
• "Reconstruir el prompt system de nivel superior o el array tools entre solicitudes en la misma conversación".
• "Una URL de imagen o documento que sirve bytes diferentes en una solicitud posterior (la comprobación cubre los bytes, no la URL, por lo que una URL firmada rotativa para el mismo archivo está bien)".

Cuatro es el resumen del proveedor, no toda la superficie. La página Pensamiento preservado amplía este mismo terreno en una tabla con más filas: editar una herramienta, eliminar un bloque de pensamiento del medio del historial, reformular un mensaje con alcance de turno. Lea la tabla antes de concluir que su arnés está limpio.

Donde se aplica la comprobación, una solicitud que reproduce un bloque invalidado devuelve un error 400 cuyo mensaje dice The block is bound to a different conversation.

Observe cuál de las cuatro es la trampa. La segunda no es código exótico: inyectar un recordatorio por turno en un mensaje anterior y eliminarlo en la siguiente solicitud es un truco estándar para dirigir un bucle de herramientas largo, y le cuesta cada bloque de pensamiento posterior.

Qué sigue siendo válido y qué se aplica hoy

Los documentos son igualmente explícitamente sobre lo que no cuenta como una edición, y la lista es más generosa de lo que la gente asume. Añadir mensajes al final está bien. También lo está eliminar bloques de pensamiento del inicio del historial, mover los marcadores cache_control y cambiar max_tokens, output_config o tool_choice. La compactación en el lado del servidor y la edición de contexto están explícitamente permitidas, porque "la comprobación compara lo que usted envió, no la copia editada del servidor".

La aplicación es gradual y la fecha es precisa: "Una cuenta nueva es aquella creada a partir del 31 de agosto de 2026 a las 00:00 UTC". Esas cuentas reciben la comprobación hoy mismo. Las cuentas más antiguas tienen el desajuste registrado, pero solo se actúa sobre él si la solicitud establece prefix_mismatch_behavior. La frase orientada al futuro es la que hay que planificar: "Los modelos posteriores aplicarán la comprobación para todos los usuarios".

Lo que produce la advertencia más útil de todo el documento, dirigida a cualquiera que distribuya una herramienta que otras personas ejecutan: "Si mantiene una herramienta o framework que la gente ejecuta con su propia clave de API, sus usuarios en cuentas nuevas se toparán con la comprobación antes que usted: es probable que su propia clave esté en una cuenta más antigua".

El lado del consumidor, donde su memoria puede mover el modelo

El mismo día, Anthropic actualizó un artículo del centro de ayuda sobre por qué Claude cambia de modelo a mitad de la conversación en Fable 5 y Fable 5.1. Está escrito para personas que nunca han visto un array messages, y llega al mismo lugar.

Fable 5.1 ejecuta clasificadores de seguridad en cada solicitud, y las solicitudes bloqueadas recurren a una alternativa (fallback): "Cuando su solicitud falla, Claude vuelve a ejecutar su solicitud bloqueada de Claude Fable 5 o Fable 5.1 en un modelo Opus en la misma conversación". Luego: "Después del cambio, el selector de modelo permanece en Opus durante el resto de la conversación".

Esa es la regla direccional manifestándose en una ventana de chat. Su conversación se acaba de mover a un modelo que no puede leer el razonamiento de Fable 5.1.

Vale la pena reflexionar sobre dos frases más de esa página. Una de las categorías bloqueadas es "Ataques de destilación en Fable 5 y Fable 5.1, incluidos los intentos de extraer el pensamiento resumido del modelo", lo que le indica por qué existe la vinculación en primer lugar. Y los clasificadores no solo leen su último mensaje: "Las comprobaciones también revisan todo lo que lee el modelo, no solo su último mensaje, incluida la memoria, el contenido de los conectores, los resultados de búsqueda web y los archivos, por lo que un bloqueo puede activarse por contenido que usted no escribió".

Lea eso con atención. Lo que está en su capa de memoria puede desencadenar un cambio de modelo, y el cambio de modelo es lo que descarta el razonamiento.

No hace que Claude Fable 5.1 sea peor para recordar. Nada aquí afecta a la memoria persistente como característica, y nada aquí reduce la ventana de contexto de 1M de tokens con la que ambos modelos se envían por defecto.

Tampoco es un recorte disfrazado de política. Anthropic expone la razón directamente: la comprobación de firma existe "para que el razonamiento producido bajo un conjunto de instrucciones no pueda reproducirse bajo otro conjunto de instrucciones potencialmente adverso". Combine eso con la categoría de destilación bloqueada en el lado del consumidor y tendrá una defensa en dos capas. Llamarlo regresión es interpretarlo mal.

Lo que sí cambia es el estado del array de mensajes. Hasta ahora, messages era una memoria de trabajo que se podía reescribir: resumir un turno antiguo en su lugar, parchear un recordatorio, reconstruir el prompt del sistema cuando llegaba una nueva herramienta. En Fable 5.1, ese array se parece más a un registro de solo adición con una suma de comprobación. Las partes de su sistema que asumían lo contrario ahora necesitan otro lugar donde vivir.

Y cambia lo que cuesta una alternativa (fallback). Un enrutador que baraja modelos por precio o disponibilidad antes sacrificaba un poco de calidad. Ahora también puede estar descartando la cadena de razonamiento y, a menos que haya optado por input_transformations, descartándola sin avisarle.

"Fable 5.1 ahora olvida cosas". No es así. La vinculación rige si los bloques de razonamiento se pueden reproducir en una solicitud. No tiene nada que ver con lo que Claude recuerda sobre usted entre conversaciones, que es un sistema independiente con controles independientes.

"Entonces debería dejar de enviar bloques de pensamiento de vuelta". También es incorrecto y costoso. Fable 5.1 lee los bloques de modelos anteriores y los suyos propios; reproducirlos a lo largo de un turno de agente largo es lo que mantiene intacta la cadena de razonamiento. La solución es dejar de editar el historial, no dejar de enviarlo.

"Esto solo afecta a quienes escriben llamadas directas a la API". Mayormente cierto, con una excepción. Los documentos señalan que Claude Code, claude.ai, Claude Managed Agents y el Claude Agent SDK mantienen el prefijo intacto por usted. Si usted mismo construye el array messages (incluso dentro de un wrapper, un proxy o un entorno de evaluación), usted es quien debe realizar la comprobación.

"Un error 400 es el peor de los casos". Un 400 es el buen caso, porque se entera. Los casos silenciosos son peores: un bloque descartado en una degradación de modelo sin cabecera beta, o una URL de documento rotativa que sirve silenciosamente bytes diferentes.

"Simplemente puedo desactivar la comprobación". Puede elegir lo que sucede en caso de desajuste ("drop_block" en lugar del valor predeterminado "error"), pero descartar no es conservar. La API "elimina el bloque y cada bloque de pensamiento posterior en la conversación". Ese es un valor predeterminado de producción razonable, no una reparación.

La regla de solo adición es una restricción sobre una cosa específica: el cuerpo de la solicitud de una sola conversación. No dice nada sobre dónde vive el conocimiento duradero de su proyecto. Esa distinción es toda la solución, y es por eso que los equipos que ya mantienen convenciones, decisiones y preferencias en una capa de memoria fuera de la transcripción apenas sintieron este lanzamiento.

Una capa de memoria funciona de la manera en que la comprobación quiere que funcione. Nada se reescribe dentro de los turnos anteriores, porque los hechos nunca estuvieron dentro de ellos. Y debido a que el almacenamiento es externo, el mismo conocimiento sobrevive a la alternativa a Opus que acaba de descartar su cadena de razonamiento, y sobrevive al modelo posterior. MemoryLake sigue tres pasos.

Paso 1: Crear una clave de API

Inicie sesión y genere una clave de API desde su panel de control. Esta es la credencial que su agente, arnés o backend utiliza para leer y escribir recuerdos, y es independiente de qué modelo de Claude esté ejecutando la conversación actualmente. Esa independencia es el punto clave: una alternativa de Fable 5.1 a Opus cambia lo que puede leer sus bloques de pensamiento, pero no cambia nada sobre lo que puede leer sus recuerdos.

Paso 2: Subir sus primeros recuerdos

Coloque aquí las cosas que tenía la tentación de inyectar en turnos anteriores. Convenciones internas. Decisiones ya tomadas y las razones detrás de ellas. Nombres, definiciones y las reglas que el agente seguía volviendo a aprender. Si ha estado manteniendo un prompt de sistema largo que reconstruye cada vez que cambia un detalle del proyecto, esa reconstrucción es ahora una de las cuatro ediciones que invalidan; mueva su mitad volátil a la memoria y deje la mitad estable en system.

Paso 3: Conectar su IA y agentes

Apunte su arnés al almacenamiento, y la recuperación ocurrirá al inicio del turno en lugar de reescribir la parte posterior del historial. Prácticamente, esto significa que su contexto por turno se ensambla a partir de una fuente externa y se añade, en lugar de parchearse en un mensaje de hace seis turnos. Esa es la forma que pide la comprobación de firma, y también es la forma que mantiene caliente la caché de prompts.

Para una ejecución de agente larga, el cambio inmediato es que la dirección de la conversación debe moverse al final de la misma. Los recordatorios se convierten en turnos añadidos o mensajes de sistema con alcance de turno; los cambios de herramientas pasan por la ruta de cambio de herramientas a mitad de la conversación en lugar de un array tools reconstruido; el recorte se destina a la compactación en el lado del servidor o a la edición de contexto, que la comprobación ignora por diseño.

Para cualquier cosa que tenga un enrutador delante, el cambio es que necesita visibilidad. Enviar la cabecera beta thinking-binding-controls-2026-08-01 y registrar input_transformations convierte un descarte silencioso en una línea que puede contabilizar. La propia receta de detección de Anthropic: ejecute una sesión normal de varios turnos con prefix_mismatch_behavior establecido en "drop_block" y lea lo que se devuelve.

Para todos los demás (las personas que usan Claude en un navegador), el cambio práctico es menor y más extraño. Si una alternativa de seguridad mueve su conversación a Opus, editar su mensaje anterior es la forma documentada de proceder: "Editar su mensaje anterior antes de volver a intentarlo a menudo ayuda". Eso es lo contrario del consejo del lado de la API, y ambos son correctos, porque se refieren a capas diferentes. "No editar el historial" es una regla sobre los cuerpos de las solicitudes, no sobre cómo se usa una ventana de chat.

Una nota sobre los costes apunta en la misma dirección: los patrones que invalidan los bloques de pensamiento son en gran medida los patrones que invalidan la caché de prompts. Corregir uno corrige el otro.

• Añada los turnos del asistente exactamente como se devuelven. Byte por byte, incluidos los bloques de pensamiento vacíos y sus firmas.
• Nunca parchee un turno anterior. Los recordatorios por turno pertenecen a un mensaje de sistema con alcance de turno con clear_at: "next_user_message", que permanece en messages sin coste de tokens y mantiene válidos los bloques posteriores.
• No toque system ni tools a mitad de la conversación. Utilice mensajes de sistema a mitad de la conversación y la ruta de adición y eliminación de herramientas en lugar de reconstruir cualquiera de los dos arrays.
• Recorte en el servidor. La compactación y la edición de contexto no cuentan como ediciones. La resumición en el lado del cliente de un turno anterior sí lo hace.
• Haga referencia a los archivos por ID. La comprobación cubre bytes, no URLs.
• Opte por la visibilidad antes de necesitarla. Envíe la cabecera beta y registre input_transformations para que un bloque descartado sea una métrica, no un misterio.
• Pruebe como lo haría una cuenta nueva. Su propia clave probablemente esté en una cuenta más antigua, así que establezca prefix_mismatch_behavior explícitamente.
• Mantenga el conocimiento duradero fuera de messages. Cualquier cosa que hubiera inyectado en el historial pertenece a una capa de memoria, y vale la pena auditar lo que su agente de programación realmente lee mientras está en ello.

El cambio principal en Claude Fable 5.1 no es el precio de una lectura de caché. Es que la conversación que envía se ha convertido en un objeto firmado, vinculado al modelo y de solo adición, y que cuatro hábitos de edición comunes ahora le cuestan el razonamiento del modelo, uno de ellos de forma silenciosa.

La restricción es estrecha, y las soluciones alternativas son todas características oficiales que Anthropic lanzó junto con ella. La mejor noticia es que la mayor parte de lo que la gente introducía de contrabando en el array de mensajes nunca debió estar allí. El razonamiento está vinculado a una sola conversación a propósito. El conocimiento de su proyecto no tiene por qué estar vinculado a nada en absoluto.