Corrige un bloque de pensamiento vinculado a una conversación diferente

Enviar la misma solicitud de nuevo no puede funcionar, porque tu historial todavía contiene lo que cambió tu código. Envía "drop_block" y detén los errores ahora. La solución a largo plazo es hacer que tu código sea “append-only” (de solo anexado).

Error: The block is bound to a different conversation

El “thinking block” (bloque de pensamiento) no pasó la “prefix check” (verificación de prefijo): algo anterior a él cambió después de que Claude lo produjera (consulta Qué cuenta como un cambio), o se omitió o se movió un bloque de pensamiento situado entre otros. El error tiene este aspecto y puede continuar para nombrar lo que cambió:

messages.1.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".

“A different conversation” significa contenido diferente antes del bloque: la verificación de prefijo no compara sesiones ni usuarios. El mensaje de error dice que elimines el bloque, pero eliminar solo ese bloque no es suficiente. Otros errores pueden parecer similares.

Si la aplicación no es tuya, inicia una conversación nueva e informa a quien la mantiene. Si eliminaste un secreto, datos personales o texto inyectado, o tus solicitudes desactivan el pensamiento, elimina el pensamiento manualmente en lugar del paso 1.

1. 1

   Detén los errores ahora

   Establece thinking.block_binding.prefix_mismatch_behavior en "drop_block" y envía el encabezado beta anthropic-beta: thinking-binding-controls-2026-08-01. Haz esto en cada solicitud posterior de la conversación, porque la API no almacena el ajuste entre solicitudes. Una conversación guardada todavía contiene el cambio, incluso después de que corrijas tu código, así que almacena el ajuste junto con ella. Establece type en "adaptive", como se muestra:

   {
     "thinking": {
       "type": "adaptive",
       "block_binding": {
         "prefix_mismatch_behavior": "drop_block"
       }
     }
   }

   

   En el SDK, llama al método beta de Messages y pasa el valor del encabezado, como hace el programa de prueba. Si el error sigue pidiendo el encabezado, el encabezado no llegó.

   Eso detiene los errores omitiendo el pensamiento no válido, pero puede costar más y puede afectar la calidad de la salida y la latencia. La siguiente solicitud tiene éxito, y su arreglo input_transformations enumera cada bloque que la API omitió.

   Si tus solicitudes no establecen el parámetro thinking, agregarlo no cambia nada más, porque los modelos con pensamiento preservado piensan de forma adaptativa por defecto.

2. 2

   Solución a largo plazo

   Haz que tu integración sea de solo anexado:

   1. Encuentra el cambio. El error puede nombrarlo. Para encontrar dónde lo hace tu código, ejecuta claude update y luego ejecuta /claude-api preserved-thinking-migration en Claude Code en el repositorio de tu código. O busca manualmente.
   2. Deja de hacer el cambio, o las conversaciones nuevas también pueden recibir el error. Envía una actualización al final en su lugar.
   3. Sigue enviando a cada conversación en curso el system y las tools de su última solicitud exitosa.

Si el cambio fue reciente, puedes deshacerlo en su lugar: restaura lo que cambió tu código. El pensamiento de antes del cambio vuelve a ser válido. El pensamiento producido desde entonces no pasa la verificación de prefijo, así que elimínalo o sigue enviando "drop_block".

Lo que cuesta omitir el pensamiento

Claude puede gastar más tokens de salida elaborando un razonamiento que ya no puede leer. Omitir los bloques también invalida la “prompt cache” (caché de prompts) desde el primer bloque omitido en adelante.

Cuando algo cambia en cada turno, cada turno pierde el pensamiento de los turnos anteriores, así que el aumento se repite. Ejecuta evaluaciones sobre tu propia carga de trabajo antes de depender de "drop_block".

Usa "drop_block" para mantener en marcha las conversaciones existentes mientras contienen un cambio que estás corrigiendo, y para una omisión planificada, como después de tu propio resumen. No lo dejes activado para ocultar un cambio que tu código sigue haciendo. Puedes dejar de enviarlo una vez que los bloques no válidos estén fuera del historial.

Encuentra lo que cambió tu código

El cambio está antes del primer bloque que nombra la API. El error 400 puede decir qué cambió, como system, tools, un bloque de pensamiento que falta o el primer mensaje que difiere. Si no hay error, o si el error no lo dice, empieza por lo que tienes, como una entrada prefix_binding_mismatch o más tokens de salida.

Prueba tu código para detectar fallos de la verificación de prefijo

Puedes confiar en una prueba una vez que la has visto fallar. Primero, a través de tu propio código, ejecuta una sesión que haga pensar a Claude y cambia algo a propósito. Envía "drop_block" en este paso, para que la respuesta enumere cada bloque no válido en lugar de detenerse en el primero, como muestran cinco pasos y un programa.

Luego quita ese cambio y ejecuta tus sesiones reales. En cada solicitud, envía el encabezado beta thinking-binding-controls-2026-08-01 y establece prefix_mismatch_behavior en "error", para que un cambio que haga tu código en esas sesiones haga fallar la compilación con el error 400.

Prueba sesiones que compactan, agregan herramientas tarde, cambian instrucciones, cambian de modelo o se reanudan: los turnos simples no llegan a ese código.

Una ejecución limpia no tiene ninguna entrada prefix_binding_mismatch ni ningún error. Solo muestra que los bloques que verificó son válidos, en las sesiones que ejecutaste. No demuestra nada si:

• la sesión no tuvo bloques de pensamiento
• tu código elimina todo el pensamiento, o el modelo no tiene pensamiento preservado
• no enviaste el encabezado beta, y el modelo podría dejar pasar bloques que no pasan la verificación de prefijo sin un error

Vigila producción y encuentra razonamiento perdido sin error

Registra cada error 400 y manéjalo en código para que la conversación continúe. Si en cambio no incluyes prefix_mismatch_behavior en la solicitud, vigila el tráfico de producción para detectar pensamiento que no pasa la verificación de prefijo y que llegó a Claude.

El razonamiento puede perderse sin error a través de "drop_block", un elemento de lote, un cambio de modelo, un paso a otra cuenta o un código que no devuelve ningún pensamiento. Con el encabezado beta, cada uno deja una entrada excepto el último. Para ese, comprueba que tus solicitudes contengan bloques thinking.

Detalles técnicos

Qué más puede decir el mensaje de error

El mensaje de error continúa nombrando lo que cambió, cuando la API puede determinarlo, como system, tools, el primer mensaje o bloque que difiere, contenido que falta o es nuevo, o un bloque de pensamiento anterior que falta o está fuera de orden. La redacción de esa oración puede cambiar, así que no hagas coincidencias con ella. Si la solicitud no tenía encabezado beta, el mensaje de error agrega esta oración:

That setting requires the `thinking-binding-controls-2026-08-01` value in the `anthropic-beta` header.

El error sigue pidiendo el encabezado, o dice Extra inputs are not permitted

Si el error sigue pidiendo el encabezado, el encabezado no llegó a la API: un proxy o una biblioteca podría haberlo eliminado. Un error diferente, que termina en block_binding: Extra inputs are not permitted, significa lo mismo, o que el pensamiento está desactivado.

Elimina manualmente el pensamiento no válido

Usa esto donde no puedas enviar el ajuste, o en uno de estos casos:

• Después de eliminar un secreto, datos personales o texto inyectado, porque "drop_block" deja el pensamiento en tu historial almacenado.
• Cuando el pensamiento está desactivado ("disabled" o "between_tools"), porque "drop_block" necesita "adaptive", lo que activaría el pensamiento y agregaría tokens de salida.

1. Elimina el bloque que nombra el error, y cada bloque thinking y redacted_thinking posterior a él, o el mismo error nombrará luego el siguiente bloque no válido. Pero si tu historial contiene mensajes role: "system", o dos mensajes del mismo rol seguidos, elimina todos los bloques thinking y redacted_thinking. El error cuenta ese tipo de mensaje como parte del mensaje anterior, así que la posición que nombra puede ser menor que el índice en tu arreglo. El path de una entrada de input_transformations cuenta cada mensaje por separado.
2. Conserva todos los demás bloques y envía la solicitud de nuevo. No vuelvas a poner los bloques eliminados.

Errores que se parecen a este

Estos errores no dicen que el bloque esté vinculado a una conversación diferente, y establecer prefix_mismatch_behavior podría no resolverlos:

• Un mensaje que termina después de “Invalid signature in thinking block”, que dice “cannot be modified” o que trata sobre budget_tokens: Solución de problemas del pensamiento
• Un mensaje sobre temperature o una respuesta prellenada: Límites y compatibilidad de funciones

Cuándo puedes dejar de enviar "drop_block"

Para dejar de enviar "drop_block", elimina los bloques que omite y conserva el pensamiento producido desde entonces. Si nada más ha cambiado, la conversación pasa entonces con "error".

Maneja el error en código

Para manejar el error en código, envía el encabezado beta y "error" en cada solicitud, para que un fallo sea un error 400 en todos los modelos. Cuando llegue, cambia solo esa conversación a "drop_block" para cada solicitud posterior, almacena esa elección junto con ella, envía de nuevo una vez y registra el error. Si vuelve el mismo error, el ajuste no llegó a la API: consulta El error sigue pidiendo el encabezado, o dice Extra inputs are not permitted.

Tu código tiene que reconocer este error por su campo message, la excepción al consejo general de no hacer coincidencias con el texto de un error. Todos los errores 400 tienen el tipo invalid_request_error, y este no tiene error.details.error_code. Haz coincidencias solo con “The block is bound to a different conversation”, porque el resto del mensaje puede cambiar.

No tienes ningún error, o tienes uno que no dice qué cambió

• El error 400, y no nombra ningún cambio: Compara las solicitudes tú mismo. Una causa es un bloque de compactación enviado sin eliminar los mensajes que resume.

• Una entrada prefix_binding_mismatch: Compara system, tools y messages hasta el path de la primera entrada con la conversación tal como era cuando se produjo ese bloque. Si todos los bloques están enumerados, empieza por system y tools.

  Si nada difiere, busca una URL de imagen o documento cuyo contenido cambió, una lista de herramientas de un servidor MCP que cambió (consulta Fija la lista de herramientas de un servidor MCP), o un bloque de pensamiento omitido, movido o vuelto a poner. Sin registros de solicitudes, envía la solicitud de nuevo con "error" y lee la oración que dice qué difiere, si la hay.

• Un proxy o una biblioteca que no es tuyo, en medio: Compara lo que envía con lo que enviaste tú, e indica a quien lo mantiene la sección Bibliotecas, proxies y gateways.

• Solo una sospecha, y sin Claude Code: Captura los cuerpos de las solicitudes de una conversación, una que tenga una compactación o un cambio de herramientas. Compara cada uno con el anterior, dejando fuera sus turnos nuevos.

Cinco pasos para una prueba que puede fallar, y un programa que los ejecuta

1. En tu propio código, envía el encabezado beta y "drop_block" en cada solicitud de una sesión, a un modelo con pensamiento preservado.
2. Usa prompts que hagan pensar a Claude y comprueba que la primera respuesta tenga un bloque thinking. Con el pensamiento adaptativo, Claude puede omitir el pensamiento en un prompt fácil.
3. Falla solo ante una entrada de input_transformations cuyo motivo sea prefix_binding_mismatch. Una prueba que espera un arreglo vacío también falla después de un cambio de modelo, porque en ese caso se esperan entradas con model_binding_mismatch u organization_binding_mismatch.
4. Cambia algo a propósito, como agregar un prompt system solo en la tercera solicitud.
5. Comprueba que input_transformations enumere los bloques de pensamiento que están después del cambio. Si no enumera ninguno, comprueba que el historial contenga un bloque de pensamiento.

Este programa realiza los pasos 1, 2, 4 y 5. Imprime cuántos bloques de pensamiento y entradas de input_transformations tiene cada respuesta, y luego cada entrada, que es lo que verifica el paso 3:

client = anthropic.Anthropic()

user_turns = [
    "How many positive integers below 500 have exactly 6 positive divisors?",
    "How many have exactly 8?",
    "How many have exactly 10?",
]

messages = []
for turn, user_turn in enumerate(user_turns, start=1):
    messages.append({"role": "user", "content": user_turn})
    response = client.beta.messages.create(
        model="claude-opus-5-5",
        max_tokens=16000,
        thinking={
            "type": "adaptive",
            "block_binding": {"prefix_mismatch_behavior": "drop_block"},
        },
        # Solo la última solicitud agrega una indicación del sistema, lo que cambia el prefijo a propósito
        system="Answer briefly." if turn == len(user_turns) else anthropic.omit,
        messages=messages,
        betas=["thinking-binding-controls-2026-08-01"],
    )
    messages.append({"role": "assistant", "content": response.content})
    thinking_blocks = sum(block.type == "thinking" for block in response.content)
    entries = response.input_transformations or []
    print(f"thinking blocks: {thinking_blocks}, entries: {len(entries)}")
    for entry in entries:
        if entry.type == "thinking_dropped":
            print(entry.type, entry.path, entry.reason)

thinking blocks: 1, entries: 0
thinking blocks: 1, entries: 0
thinking blocks: 1, entries: 2
thinking_dropped messages.1.content.0 prefix_binding_mismatch
thinking_dropped messages.3.content.0 prefix_binding_mismatch

Con "error" en lugar de "drop_block", la tercera solicitud recibe el error 400.

Qué significa cada entrada de input_transformations, y cuáles te corresponde corregir

Con el encabezado beta, una respuesta de un modelo que admite el pensamiento tiene el arreglo input_transformations junto a usage. Está vacío cuando no se omitió nada y no se dejó pasar nada no válido. Cuando usas streaming, está en el message del evento message_start; después de un fallback a mitad del stream, el evento message_delta final contiene el que cuenta. A diferencia de la posición del error, path es siempre el lugar del bloque tal como lo enviaste:

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

El type y el reason de cada entrada, y lo que significan:

• thinking_dropped, prefix_binding_mismatch: Lo que venía antes de este bloque no es lo que registró. Te corresponde corregirlo: Encuentra lo que cambió tu código.
• thinking_mismatch_allowed, prefix_binding_mismatch: Lo mismo, pero Claude leyó el bloque sin cambios, y se factura. Esta entrada aparece solo cuando la solicitud no incluye el ajuste, en algunos modelos. Te corresponde corregirlo.
• thinking_dropped, model_binding_mismatch: Este modelo no puede leer bloques del modelo que lo produjo. No te corresponde corregirlo: sigue enviando la conversación completa.
• thinking_dropped, organization_binding_mismatch: Otra cuenta produjo el bloque, así que la API lo omitió. No te corresponde corregirlo.

Ignora cualquier entrada cuyo type o reason no reconozcas.

Lotes y conteo de tokens

• Lotes de mensajes: Un elemento que no incluye prefix_mismatch_behavior nunca recibe el error 400. La API omite los bloques no válidos o, en algunos modelos, puede dejarlos pasar. Un elemento que establece "error" se resuelve como errored cuando un bloque no pasa la verificación de prefijo. block_binding va en el params.thinking del elemento.
• Conteo de tokens: En la Claude API, el conteo de tokens puede devolver el mismo error 400 y acepta prefix_mismatch_behavior con el mismo encabezado. Deja los bloques omitidos fuera del conteo y no devuelve input_transformations.

Próximos pasos