Claude Fable 5.1 Pensamiento Conservado: Cómo solucionar el error El bloque está vinculado a una conversación diferente

Cómo corregir el error 400 de bloques de pensamiento en Claude Fable 5.1

Si migraste un arnés de agente a Claude Fable 5.1 y ves un error 400 que indica que un bloque de pensamiento está «vinculado a una conversación diferente», tu código está modificando el historial entre solicitudes. Fable 5.1 es el primer modelo de Claude que rechaza este patrón. Esta guía explica la verificación, a quién afecta, qué la activa, cómo recuperarse y cómo diseñar historiales de solo agregar que mantengan también la caché de prompts caliente.

Prueba Apidog hoy

La verificación está documentada en Pensamiento preservado y en Novedades de Claude Fable 5.1. Es uno de los tres cambios principales de Fable 5.1 y el único que puede degradar silenciosamente un arnés. Para los otros cambios, consulta la guía de migración.

El error

messages.5.content.0: Invalid `signature` in `thinking` block. The block is bound to a different conversation. Remove the block, or set `thinking.block_binding.prefix_mismatch_behavior` to "drop_block". That setting requires the `thinking-binding-controls-2026-08-01` value in the `anthropic-beta` header.

Es un error 400 invalid_request_error que se produce antes de cualquier salida. Reintentar con el mismo cuerpo falla de la misma forma.

La ruta messages.5.content.0 identifica el primer bloque de pensamiento que ya no coincide. El mensaje puede incluir también el primer mensaje que cambió; ese es el diagnóstico más útil. El endpoint de conteo de tokens ejecuta la misma verificación.

Existe un error parecido, pero diferente: si aparece la misma cláusula inicial sin «vinculado a una conversación diferente», la firma está manipulada o no se puede interpretar. prefix_mismatch_behavior no se aplica en ese caso.

Qué verifica la API

Cada bloque de pensamiento de Fable 5.1 incluye una firma que registra:

• El modelo que produjo el bloque.
• El prefijo exacto de la conversación anterior al bloque: el prompt de sistema de nivel superior, el array tools y todos los mensajes anteriores.
• La relación con el bloque de pensamiento previo.

Cuando envías de nuevo la transcripción, la API verifica que ese prefijo sea idéntico byte a byte al que existía cuando se generó el bloque.

Anthropic cita dos motivos:

1. Antidestilación: las cuentas nuevas de API ya no pueden editar manualmente el contexto previo de Claude en una conversación de varios turnos y conservar la transcripción del pensamiento anterior.
2. Caché de prompts: las mismas modificaciones que rompen la verificación también reinician la caché. Un historial que pasa la verificación puede aprovechar lecturas de caché de $0.25 por millón de tokens en cada turno.

A quién aplica

Aplicación predeterminada

Afecta a las cuentas creadas a partir del 31 de agosto de 2026, incluyendo:

• Organizaciones de la API de Claude.
• Amazon Bedrock.
• Google Cloud.
• Microsoft Foundry.

Registrado, pero no aplicado

Las cuentas creadas antes de esa fecha registran la discrepancia, pero solo actúan sobre ella si la solicitud establece thinking.block_binding.prefix_mismatch_behavior, incluso con el valor "error".

Anthropic indica que los modelos futuros aplicarán la verificación a todas las cuentas.

No afectados

No ejecutan esta verificación:

• Claude Code.
• claude.ai.
• Agentes Administrados de Claude.
• El SDK de Agentes de Claude.

Estas superficies mantienen intacto el prefijo. Claude Mythos 5.1 tampoco ejecuta la verificación, aunque modificar el historial sigue reiniciando su caché.

Afectados

El problema puede aparecer en cualquier código que construya manualmente el array messages, por ejemplo:

• Bucles de agentes personalizados.
• Backends de chat.
• Frameworks que envuelven la API de Mensajes.

Si distribuyes una herramienta que los usuarios ejecutan con sus propias claves de API, prueba con la verificación activada. Tu cuenta puede ser antigua y no aplicar todavía la regla, mientras que la cuenta de tus usuarios sí.

Para comprobar si tu cuenta aplica la verificación, envía una solicitud que modifique el historial sin la cabecera beta. Si recibes un error 400 que menciona esa cabecera, la aplicación está activa.

Qué invalida los bloques de pensamiento

Cualquiera de estas modificaciones puede invalidar los bloques posteriores:

• Editar, reordenar o eliminar un turno anterior. Esto incluye eliminar resultados de herramientas, cortar turnos intermedios o aplicar compactación del lado del cliente conservando textualmente los turnos recientes detrás de un resumen.
• Inyectar contenido temporal, como un recordatorio por turno, una línea de estado o un contador de tokens restantes que cambia en cada solicitud.
• Reconstruir system o tools entre solicitudes, por ejemplo al actualizar la fecha actual o añadir una herramienta a mitad de la sesión.
• Usar una URL de imagen o documento que más tarde sirva bytes diferentes. La API vincula los bytes, no la cadena de URL. Una URL firmada rotativa para el mismo archivo sí es válida.
• Eliminar un bloque de pensamiento que no esté al inicio de la ejecución. Los bloques iniciales se pueden eliminar empezando por los más antiguos; no se puede eliminar un bloque intermedio.

Qué mantiene válidos los bloques

• Historiales de solo agregar, incluidos los mensajes role: "system" añadidos y los mensajes con ámbito de turno que se dejan en su posición.
• Eliminar una secuencia inicial de bloques de pensamiento, siempre desde los más antiguos.
• Cambiar parámetros fuera de system, tools y messages, como max_tokens, output_config, effort, tool_choice o metadata.
• Añadir, mover o eliminar marcadores cache_control.
• Usar compactación y edición de contexto del lado del servidor, incluida la limpieza de bloques de pensamiento. La API compara la conversación tal como la envías, no la copia que el servidor edita. Después de una compactación, el prefijo verificado comienza en el bloque de compactación.

La vía de escape: drop_block

Envía la cabecera beta y configura explícitamente el comportamiento:

response = client.beta.messages.create(
    model="claude-fable-5-1",
    max_tokens=16000,
    thinking={"type": "adaptive", "block_binding": {"prefix_mismatch_behavior": "drop_block"}},
    betas=["thinking-binding-controls-2026-08-01"],
    messages=history,
)
for t in response.input_transformations or []:
    print(t.type, t.path, t.reason)

Con drop_block, la API elimina el primer bloque que no coincide y todos los bloques de pensamiento posteriores. Después continúa con la solicitud e informa cada eliminación en el array de nivel superior input_transformations:

{
  "input_transformations": [
    {
      "type": "thinking_dropped",
      "path": "messages.1.content.0",
      "reason": "prefix_binding_mismatch"
    }
  ]
}

Ten en cuenta lo siguiente:

• Solo se aplica a esa solicitud. Sigue enviándolo durante el resto de la sesión.
• Los valores predeterminados dependen de la superficie. En una cuenta con aplicación activa, omitir la cabecera produce un error; enviar la cabecera puede activar drop_block como valor predeterminado de la beta. Configúralo siempre de forma explícita.
• Enviar block_binding sin la cabecera beta produce un error 400:

block_binding: Extra inputs are not permitted

El campo reason distingue dos casos:

• prefix_binding_mismatch: cambió el historial.
• model_binding_mismatch: la conversación cambió de modelo y el modelo de destino no puede leer un bloque producido por Fable 5.1. Esto puede ocurrir con un router, un reintento o una estrategia de reserva, y no necesariamente indica un error en tu código.

Con la cabecera beta, cada respuesta incluye input_transformations, vacío cuando no se eliminó ningún bloque.

Eliminar bloques una vez, por ejemplo durante una compactación, tiene un costo bajo. Un arnés que invalida su propio historial en cada solicitud pierde el razonamiento del modelo en cada turno y reinicia la caché de prompts. Usa drop_block como diagnóstico y red de seguridad, no como solución permanente.

Recuperación sin la beta

Si tu plataforma todavía no ofrece estos controles —Microsoft Foundry no los ofrecía en el lanzamiento; Bedrock y Google Cloud los estaban incorporando por modelo—:

1. Elimina todos los bloques thinking y redacted_thinking.
2. Conserva los bloques text y tool_use de cada turno.
3. Reintenta una sola vez.

El modelo responderá sin el razonamiento contenido en esos bloques. Es una recuperación puntual, no un patrón operativo.

Auditoría en tres pasos

Ejecuta esta auditoría antes de cambiar el tráfico:

1. Captura solicitudes reales. Registra los cuerpos exactos que envía el arnés durante varios turnos normales, incluyendo compactaciones o cambios de herramientas. Compara cada par de solicitudes consecutivas: system, tools y el prefijo compartido de messages deben ser idénticos byte a byte hasta los turnos recién añadidos.
2. Activa drop_block en una sesión de prueba. Ejecuta una conversación de varios turnos contra claude-fable-5-1 con la cabecera beta y prefix_mismatch_behavior: "drop_block". Registra input_transformations en cada respuesta:
   • Un array vacío indica que el historial está intacto.
   • prefix_binding_mismatch identifica una modificación anterior al bloque indicado en path.

Establecer el campo activa la verificación de la solicitud incluso en cuentas antiguas. En CI, usa "error" para que cualquier edición detenga la ejecución.

1. Define el comportamiento de producción. Bajo la cabecera beta, establece explícitamente:
   • "error" si una discrepancia siempre indica un error.
   • "drop_block" si prefieres degradar en lugar de fallar.

Monitorea tanto los errores 400 como las entradas de input_transformations. No dejes el campo sin configurar en cuentas antiguas: la discrepancia solo se registrará en el servidor y no tendrás nada útil que monitorear.

En Apidog, el segundo paso puede probarse con dos solicitudes:

1. Envía un turno.
2. Modifica el prompt de sistema.
3. Envía el siguiente turno con la cabecera beta.
4. Verifica input_transformations.

Conserva la prueba en la colección para ejecutarla después de cada cambio del arnés. También puedes descargar Apidog para construirla.

Diseña un arnés de solo agregar

Reemplaza las ediciones del historial por operaciones que mantengan intacto el prefijo:

Lo que hacías	Haz esto
Editar el prompt de sistema a mitad de sesión, por ejemplo para cambiar la fecha o el modo.	Congela system al inicio. Cuando el cambio sea efectivo, añade {"role": "system", "content": "La fecha actual es 14-09-2026."}. El nuevo mensaje se convierte en parte del prefijo de los bloques posteriores.
Editar el array tools a mitad de sesión.	Declara el conjunto completo al inicio y usa defer_loading: true para las herramientas que comienzan ocultas. Envía bloques tool_addition y tool_removal en un mensaje role: "system" con la beta mid-conversation-tool-changes-2026-07-01.
Inyectar un recordatorio por turno y eliminarlo en la siguiente solicitud.	Usa {"role": "system", "clear_at": "next_user_message", "content": "..."} con la beta mid-conversation-system-clear-at-2026-08-21, después del resultado de la herramienta. Deja las copias anteriores en su lugar. Sin la beta, añade el recordatorio como un bloque de texto después de los bloques tool_result del mismo mensaje de usuario y conserva las copias anteriores.
Eliminar resultados antiguos de herramientas en el cliente.	Usa edición de contexto del lado del servidor con limpieza de resultados de herramientas.
Compactar el historial en el cliente conservando los turnos recientes.	Prefiere la compactación del lado del servidor con la beta compact-2026-01-12; su parámetro instructions acepta tu propio prompt de resumen. Si debes compactar en el cliente, reemplaza todo el historial por un mensaje de resumen y el nuevo turno de usuario, sin repetir contenido.
Referenciar una imagen o documento mediante URL en varios turnos.	Sube el archivo una vez a la API de Archivos y envía su file_id, o utiliza base64.

Dos estrategias de compactación del lado del cliente fallan con esta verificación:

• Compactación de cola: resume los turnos antiguos y conserva textualmente los recientes. Los bloques retenidos se produjeron contra el historial completo.
• Compactación en segundo plano: inserta más tarde un resumen creado fuera de la ruta crítica. Los turnos generados entre el inicio del resumen y su inserción quedan invalidados.

Cortar turnos individuales del medio invalida todos los bloques posteriores. Para cambios de instrucciones, usa un mensaje de sistema a mitad de conversación; para eliminar contenido específico, usa edición de contexto del lado del servidor.

Por qué también es un problema de caché

Todo lo que reinicia la verificación también reinicia la caché de prompts.

Fable 5.1 hizo que las lecturas de caché fueran cuatro veces más baratas que en Fable 5, mientras que los fallos son proporcionalmente más costosos. Un arnés de solo agregar obtiene dos beneficios:

• Conserva el razonamiento del modelo.
• Lee el prefijo en caché a $0.25 por millón, en lugar de volver a escribirlo a $12.50.

Consulta el desglose de precios, el recorrido de la API, la guía de prompting y la guía de Claude Code.

Debido al menor precio de las lecturas de caché, compactar demasiado pronto para ahorrar dinero puede dejar de ser la mejor compensación en Fable 5.1. Experimenta con puntos de compactación posteriores.

Preguntas frecuentes

¿Qué significa «El bloque está vinculado a una conversación diferente»?

Un bloque de pensamiento de Claude Fable 5.1 se reprodujo después de que cambiara algo anterior: el prompt de sistema, el array de herramientas o un mensaje previo. En las cuentas con aplicación forzosa, la API rechaza la solicitud con un error 400.

¿Qué cuentas aplican la verificación del historial?

Las cuentas creadas a partir del 31 de agosto de 2026, en todas las plataformas. Las cuentas antiguas solo la aplican cuando una solicitud establece thinking.block_binding.prefix_mismatch_behavior. Anthropic planea aplicarla a todas las cuentas en modelos futuros.

¿Cómo hago desaparecer rápidamente el error?

Envía la cabecera beta thinking-binding-controls-2026-08-01 con prefix_mismatch_behavior: "drop_block". La API eliminará los bloques afectados y continuará. Después corrige la modificación del historial: eliminar bloques en cada turno consume razonamiento y reinicia la caché.

¿Cambiar effort o max_tokens invalida los bloques?

No. Puedes cambiar libremente cualquier parámetro fuera de system, tools y messages, incluidos max_tokens, output_config, effort, tool_choice, metadata y los marcadores cache_control.

¿La compactación del lado del servidor rompe la verificación?

No. La compactación y la edición de contexto ocurren después de la verificación, que compara la conversación tal como la enviaste. La compactación del lado del cliente que conserva textualmente los turnos recientes sí puede romperla.

¿Claude Mythos 5.1 tiene la misma verificación?

No. Mythos 5.1 no ejecuta la verificación de conversación. Sin embargo, sus bloques siguen vinculados al modelo productor y las ediciones del historial todavía reinician la caché.

Referencias

• Pensamiento preservado
• Novedades de Claude Fable 5.1
• Guía de migración
• claude.ai
• Apidog
• Descargar Apidog
• Mensajes de sistema a mitad de conversación
• Compactación del lado del servidor
• Desglose de precios
• Recorrido de la API
• Guía de prompting
• Guía de Claude Code