Si movió un arnés de agente a Claude Fable 5.1 y comenzó a ver un error 400 cuyo mensaje dice que un bloque de pensamiento "está vinculado a una conversación diferente", su código edita el historial de la conversación entre solicitudes, y Fable 5.1 es el primer modelo de Claude que objeta esto. Esta guía explica qué es la verificación, a quién se aplica, qué la activa exactamente, la vía de escape y los patrones de solo agregar que hacen que el error desaparezca mientras también mantienen su caché de prompts "caliente".
La verificación está documentada en pensamiento preservado y en Novedades de Claude Fable 5.1. Es el tercero de los tres cambios importantes de Fable 5.1, y el único que puede degradar un arnés silenciosamente. Para los otros dos, consulte 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, decidido antes de cualquier salida. Reintentar con el mismo cuerpo falla de la misma manera. La ruta (messages.5.content.0) apunta al primer bloque de pensamiento que ya no coincide, y el mensaje puede terminar con una frase más que nombra el primer mensaje que cambió, que es el diagnóstico que desea. El endpoint de conteo de tokens ejecuta la misma verificación.
Un fallo diferente parece similar pero no es este: la misma cláusula inicial sin la frase "vinculado a una conversación diferente" significa que la firma en sí está manipulada o es indescifrable, y prefix_mismatch_behavior no se aplica.
Qué hace la verificación
Cada bloque de pensamiento de Fable 5.1 lleva una firma que registra dos cosas: qué modelo lo produjo y el prefijo exacto de la conversación que lo precedió, es decir, el prompt system de nivel superior, el array tools y cada mensaje anterior al bloque. Cada bloque también se encadena al bloque de pensamiento anterior. Cuando envía la transcripción de vuelta, la API verifica que ese prefijo sea idéntico byte a byte a lo que produjo el bloque.
Anthropic da dos razones. La declarada es anti-destilación: la publicación de lanzamiento dice que las nuevas cuentas de API ya no pueden editar manualmente el contexto previo de Claude en una conversación de múltiples turnos mientras preservan la transcripción del pensamiento previo, lo que cierra una técnica de destilación documentada. La práctica es que las mismas ediciones que rompen la verificación también reinician la caché de prompts, por lo que el código que pasa la verificación es también código que obtiene las lecturas de caché de $0.25 por millón en cada turno.
A quién se aplica
Aplicado por defecto: cuentas creadas a partir del 31 de agosto de 2026. Esto cubre organizaciones de la API de Claude, cuentas de Amazon Bedrock, proyectos de Google Cloud y recursos de Microsoft Foundry.
Registrado pero no aplicado: cuentas creadas anteriormente. La API anota la discrepancia pero actúa sobre ella solo cuando la solicitud establece thinking.block_binding.prefix_mismatch_behavior a cualquier valor, incluido "error". Anthropic dice que los modelos futuros lo aplicarán para todos.
No afectados: Claude Code, claude.ai, Agentes Administrados de Claude y el SDK de Agentes de Claude, que mantienen el prefijo intacto. Claude Mythos 5.1 no ejecuta la verificación en absoluto, aunque las ediciones del historial aún reinician su caché.
Afectados: cualquier código que construya el array messages por sí mismo. Esto incluye cada bucle de agente personalizado, cada backend de chat y cada framework que envuelva la API de Mensajes.
La trampa para los autores de herramientas: si distribuye algo que la gente ejecuta con sus propias claves de API, su clave probablemente esté en una cuenta más antigua y la de ellos puede que no lo esté. Realice pruebas con el campo configurado, para que encuentre la verificación antes que sus usuarios. Para saber si su propia cuenta está siendo aplicada, envíe una solicitud que edite el historial sin la cabecera beta; un error 400 que nombra la cabecera significa que sí lo está.
Qué invalida cada bloque de pensamiento posterior
- Editar, reordenar o eliminar un turno anterior. Esto incluye eliminar resultados de herramientas antiguos, cortar turnos del medio de la transcripción y la compactación del lado del cliente que mantiene los turnos recientes textualmente detrás de un resumen.
- Inyectar contenido que no persiste. Un recordatorio por turno añadido después de los resultados de la herramienta y eliminado en la siguiente solicitud. Una línea de estado. Un conteo de tokens restantes que cambia en cada turno.
- Reconstruir
systemotoolsentre solicitudes. Actualizar la fecha actual en el prompt del sistema. Añadir o eliminar una herramienta a mitad de sesión. - Una URL de imagen o documento que sirva bytes diferentes más tarde. Los bytes están vinculados, no la cadena de URL, por lo que una URL firmada rotativa para el mismo archivo está bien.
- Eliminar un bloque de pensamiento de cualquier lugar que no sea el inicio de la ejecución. Los bloques iniciales pueden irse, los más antiguos primero. Un bloque del medio no puede.
Qué los mantiene válidos
- Historiales de solo añadir, incluidos los mensajes
role: "system"añadidos y los mensajes de ámbito de turno borrados dejados en su lugar. - Eliminar una serie inicial de bloques de pensamiento, los más antiguos primero.
- Cambiar cualquier parámetro fuera de
system,toolsymessages:max_tokens,output_configincluyendoeffort,tool_choice,metadata. - Añadir, mover o eliminar marcadores
cache_control. - Compactación del lado del servidor y edición de contexto, incluida la limpieza de bloques de pensamiento. No cuentan como ediciones porque la verificación compara la conversación tal como usted la envió, no la copia editada del servidor. Después de una compactación, el prefijo verificado comienza desde el bloque de compactación.
La vía de escape: drop_block
Envíe la cabecera beta thinking-binding-controls-2026-08-01 y establezca el campo explícitamente:
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 no coincidente y cada bloque de pensamiento posterior, procede con la solicitud e informa de cada eliminación en un array input_transformations de nivel superior:
"input_transformations": [
{"type": "thinking_dropped", "path": "messages.1.content.0", "reason": "prefix_binding_mismatch"}
]
Tres cosas que saber sobre el campo. Se aplica solo a esa solicitud, así que siga enviándolo durante el resto de la sesión. Los valores predeterminados difieren según la superficie: sin la cabecera, una cuenta aplicada genera errores; enviar la cabecera sola cambia al valor predeterminado propio de la beta, que es drop_block; así que configúrelo explícitamente y nunca dependa de ninguno de los valores predeterminados. Y enviar block_binding sin la cabecera es un error 400 que termina en block_binding: Extra inputs are not permitted.
El campo reason distingue dos casos. prefix_binding_mismatch significa que su historial cambió. model_binding_mismatch significa que la conversación cambió de modelo (un enrutador, un reintento, una estrategia de reserva por rechazo) y el destino no pudo leer un bloque de Fable 5.1. El segundo no es un error en su código. Con la cabecera, cada respuesta lleva el array, vacío cuando no se eliminó nada.
Eliminar bloques una vez, en un límite de compactación, cuesta poco. 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 en cada turno, y Anthropic advierte que esto eleva el costo por tarea. Trate drop_block como un diagnóstico y una red de seguridad, no como un estado estable.
La recuperación sin beta
En una plataforma sin los controles (Microsoft Foundry no los ofrecía en el lanzamiento; Bedrock y Google Cloud los estaban agregando por modelo), elimine cada bloque thinking y redacted_thinking del historial, conserve los bloques text y tool_use de cada turno y reintente una vez. El modelo responde a ese turno sin el razonamiento que esos bloques contenían. Esto es una recuperación única, no un patrón.
La auditoría de tres pasos
Ejecute esto antes de cambiar el tráfico, no después.
- Capture los cuerpos de solicitud exactos que su arnés envía durante algunos turnos normales, incluyendo una compactación o un cambio de herramienta si su producto los tiene. Para cada par de solicitudes consecutivas, compare el prompt
system, el arraytoolsy el prefijo compartido demessages. Deberían ser idénticos byte a byte hasta los turnos recién añadidos. - Ejecute una sesión normal de múltiples turnos contra
claude-fable-5-1con la cabecera beta yprefix_mismatch_behavior: "drop_block", registrandoinput_transformationsen cada respuesta. Un array vacío en cada turno significa que el historial está intacto. Una entradaprefix_binding_mismatchsignifica que algo antes del bloque enpathcambió. Esto funciona desde cualquier cuenta, porque al establecer el campo se opta por la aplicación de la solicitud. En CI, establezca"error"en su lugar para que una edición falle la ejecución. - Elija una configuración de producción y establézcala explícitamente bajo la cabecera:
"error"si una discrepancia solo puede significar un error,"drop_block"para degradar en lugar de fallar. Monitoree los errores 400 o las entradasinput_transformationsde cualquier manera. No deje el campo sin establecer en una cuenta antigua, porque entonces la verificación solo se registra del lado del servidor y no obtendrá nada que monitorear.
En Apidog, el paso 2 es una prueba de dos solicitudes: envíe un turno, edite el prompt del sistema, envíe el siguiente turno con la cabecera establecida y afirme sobre input_transformations. Manténgalo en la colección para que cada cambio del arnés lo vuelva a ejecutar. Descargue Apidog para construirlo.
Haciendo un arnés de solo añadir
Cada fila reemplaza una edición del historial con algo que mantiene el prefijo intacto y mantiene la caché "caliente".
| Lo que estabas haciendo | Haz esto en su lugar |
|---|---|
| Editar el prompt del sistema a mitad de sesión (nueva fecha, nuevo modo) | Congela system al inicio de la sesión. Añade {"role": "system", "content": "La fecha actual es 14-09-2026."} en el punto en que el cambio se hace efectivo (mensajes de sistema a mitad de conversación). Sin cabecera beta; obtiene autoridad de prompt de sistema y se convierte en parte del prefijo al que se vinculan los bloques posteriores. |
Editar el array tools a mitad de sesión |
Declara el conjunto completo al inicio de la sesión (defer_loading: true en los que empiezan ocultos). Envía bloques tool_addition y tool_removal en un mensaje role: "system" (beta mid-conversation-tool-changes-2026-07-01). |
| Inyectar un recordatorio por turno y eliminarlo en la siguiente solicitud | Envíalo como un mensaje de sistema con ámbito de turno: {"role": "system", "clear_at": "next_user_message", "content": "..."} (beta mid-conversation-system-clear-at-2026-08-21) después del mensaje de resultado de la herramienta, y deja todas las copias anteriores en su lugar. Las copias borradas no renderizan nada y no cuestan nada. Sin la beta, pon el recordatorio en un bloque de texto después de los bloques tool_result en el mismo mensaje de usuario, manteniendo las copias anteriores. |
| Eliminar resultados de herramientas antiguos del lado del cliente | Edición de contexto del lado del servidor con limpieza de resultados de herramientas. |
| Compactar en el cliente | Prefiere la compactación del lado del servidor (beta compact-2026-01-12; su parámetro instructions toma tu propio prompt de resumen). Si te quedas en el lado del cliente, usa compactación simple: reemplaza todo el historial con un mensaje de resumen más el nuevo turno de usuario y no repitas nada más. |
| Referenciar una imagen o documento por URL a lo largo de los turnos | Sube una vez a la API de Archivos y envía el file_id, o envía base64. |
Dos formas de compactación del lado del cliente fallan con la verificación y necesitan drop_block o bloques de pensamiento eliminados en los turnos retenidos. La **compactación de cola** (resume los turnos más antiguos, mantiene los más recientes textualmente) falla en los turnos retenidos, porque su pensamiento se produjo contra el historial completo. La **compactación en segundo plano** (construye el resumen fuera de la ruta crítica y lo inserta más tarde) falla en cada turno producido entre el inicio del resumen y el intercambio. Cortar turnos individuales del medio de la transcripción invalida cada bloque posterior, y ninguna forma del lado del cliente lo evita. Use un mensaje del sistema a mitad de conversación para el cambio de instrucción que estaba realizando, o edición de contexto del lado del servidor para la eliminación selectiva.
Una consideración de costo más: debido a que las lecturas de caché ahora cuestan $0.25 por millón, la compactación temprana para ahorrar dinero puede que ya no sea la compensación adecuada en Fable 5.1. Anthropic sugiere experimentar con puntos de compactación posteriores.
Por qué esta es también la historia de la caché
Todo lo que aparece en la tabla anterior es también la lista de cosas que reinician una caché de prompts. Fable 5.1 hizo que los aciertos de caché fueran cuatro veces más baratos que Fable 5 y que los fallos fueran proporcionalmente más costosos, por lo que un arnés de solo añadir obtiene doble beneficio: el pensamiento sobrevive y cada turno lee el prefijo a $0.25 en lugar de reescribirlo a $12.50. El desglose de precios tiene los números; el recorrido de la API muestra las formas de solicitud con ámbito de turno y esfuerzo por mensaje en contexto, la guía de prompting cubre qué instrucciones por turno vale la pena enviar de esa manera, y la guía de Claude Code explica por qué los usuarios de Claude Code nunca ven este error.
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 algo anterior cambiara: el prompt del sistema, el array de herramientas o un mensaje anterior. La API rechaza la solicitud con un error 400 en cuentas con aplicación forzosa.
¿Qué cuentas aplican la verificación del historial de Fable 5.1? Cuentas creadas a partir del 31 de agosto de 2026, en todas las plataformas. Las cuentas más antiguas lo aplican solo cuando una solicitud establece thinking.block_binding.prefix_mismatch_behavior. Anthropic planea aplicarlo a todos en modelos futuros.
¿Cómo hago que el error desaparezca rápidamente? Envíe la cabecera beta thinking-binding-controls-2026-08-01 con prefix_mismatch_behavior: "drop_block". La API elimina los bloques afectados y continúa. Luego, corrija la edición del historial, porque eliminar bloques en cada turno cuesta razonamiento y reinicia su caché.
¿Cambiar effort o max_tokens invalida los bloques de pensamiento? No. Cualquier parámetro fuera de system, tools y messages puede cambiarse libremente, al igual que 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 usted la envió. La compactación del lado del cliente que mantiene los turnos recientes textualmente sí la rompe.
¿Claude Mythos 5.1 tiene la misma verificación? No. Mythos 5.1 no ejecuta la verificación de conversación, aunque aún vincula los bloques de pensamiento al modelo productor y las ediciones del historial aún reinician su caché.