Correggi un blocco di ragionamento vincolato a una conversazione diversa

Inviare di nuovo la stessa richiesta non può funzionare, perché la tua cronologia contiene ancora ciò che il tuo codice ha modificato. Invia "drop_block" e ferma subito gli errori. La soluzione a lungo termine è rendere il tuo codice append-only (solo in aggiunta).

Errore: The block is bound to a different conversation

Il “thinking block” (blocco di ragionamento) non ha superato il “prefix check” (controllo del prefisso): qualcosa prima di esso è cambiato dopo che Claude lo ha prodotto (vedi Cosa conta come modifica), oppure un blocco di ragionamento tra altri è stato omesso o spostato. L’errore appare così e può proseguire indicando cosa è cambiato:

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 un contenuto diverso prima del blocco: il controllo del prefisso non confronta sessioni o utenti. Il messaggio di errore dice di rimuovere il blocco, ma rimuovere solo quel blocco non basta. Altri errori possono sembrare simili.

Se l’app non è tua, avvia una nuova conversazione e avvisa chi la mantiene. Se hai rimosso un segreto, dati personali o testo iniettato, oppure le tue richieste disattivano il ragionamento, rimuovi a mano il ragionamento invece di seguire il passaggio 1.

1. 1

   Ferma subito gli errori

   Imposta thinking.block_binding.prefix_mismatch_behavior su "drop_block" e invia l’header beta anthropic-beta: thinking-binding-controls-2026-08-01. Fallo su ogni richiesta successiva della conversazione, perché l’API non memorizza l’impostazione tra una richiesta e l’altra. Una conversazione salvata contiene ancora la modifica, anche dopo che hai corretto il tuo codice, quindi memorizza l’impostazione insieme a essa. Imposta type su "adaptive", come mostrato:

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

   

   Nell’SDK, chiama il metodo Messages beta e passa il valore dell’header, come fa il programma di test. Se l’errore chiede ancora l’header, l’header non è arrivato.

   Questo ferma gli errori scartando il ragionamento non valido, ma può costare di più e può influire sulla qualità dell’output e sulla latenza. La richiesta successiva va a buon fine e il suo array input_transformations elenca ogni blocco che l’API ha scartato.

   Se le tue richieste non impostano il parametro thinking, aggiungerlo non cambia nient’altro, perché i modelli con ragionamento preservato ragionano in modo adattivo per impostazione predefinita.

2. 2

   Soluzione a lungo termine

   Rendi la tua integrazione append-only:

   1. Trova la modifica. L’errore può indicarla. Per trovare dove il tuo codice la effettua, esegui claude update, poi esegui /claude-api preserved-thinking-migration in Claude Code nel repository del tuo codice. Oppure cerca a mano.
   2. Smetti di effettuare la modifica, altrimenti anche le nuove conversazioni possono ricevere l’errore. Invia invece un aggiornamento alla fine.
   3. Continua a inviare a ogni conversazione in corso il system e i tools della sua ultima richiesta riuscita.

Se la modifica è recente, puoi invece annullarla: ripristina ciò che il tuo codice ha modificato. Il ragionamento precedente alla modifica torna valido. Il ragionamento prodotto da allora non supera il controllo del prefisso, quindi rimuovilo oppure continua a inviare "drop_block".

Quanto costa scartare il ragionamento

Claude può spendere più token di output per ricostruire un ragionamento che non può più leggere. Scartare i blocchi invalida inoltre la cache dei prompt dal primo blocco scartato in poi.

Quando qualcosa cambia a ogni turno, ogni turno perde il ragionamento dei turni precedenti, quindi l’aumento si ripete. Esegui delle valutazioni sul tuo carico di lavoro prima di affidarti a "drop_block".

Usa "drop_block" per far proseguire le conversazioni esistenti mentre contengono una modifica che stai correggendo, e per uno scarto pianificato, ad esempio dopo un tuo riepilogo. Non lasciarlo attivo per nascondere una modifica che il tuo codice continua a effettuare. Puoi smettere di inviarlo quando i blocchi non validi non sono più nella cronologia.

Trova cosa ha modificato il tuo codice

La modifica si trova prima del primo blocco che l’API indica. L’errore 400 può dire cosa è cambiato, ad esempio system, tools, un blocco di ragionamento mancante o il primo messaggio che differisce. Senza errore, o con uno che non lo dice, parti da ciò che hai, ad esempio una voce prefix_binding_mismatch o più token di output.

Testa il tuo codice per i casi in cui non supera il controllo del prefisso

Puoi fidarti di un test dopo averlo visto fallire. Per prima cosa, tramite il tuo codice, esegui una sessione che faccia ragionare Claude e modifica qualcosa di proposito. Invia "drop_block" per questo passaggio, in modo che la risposta elenchi ogni blocco non valido invece di fermarsi al primo, come mostrano cinque passaggi e un programma.

Poi togli quella modifica ed esegui le tue sessioni reali. Su ogni richiesta, invia l’header beta thinking-binding-controls-2026-08-01 e imposta prefix_mismatch_behavior su "error", in modo che una modifica effettuata dal tuo codice in quelle sessioni faccia fallire la build con l’errore 400.

Testa sessioni che eseguono la compattazione, aggiungono strumenti in ritardo, cambiano le istruzioni, cambiano modello o vengono riprese: i turni semplici non raggiungono quel codice.

Un’esecuzione pulita non ha alcuna voce prefix_binding_mismatch né errori. Mostra solo che i blocchi che ha controllato sono validi, nelle sessioni che hai eseguito. Non dimostra nulla se:

• la sessione non aveva blocchi di ragionamento
• il tuo codice rimuove tutto il ragionamento, oppure il modello non ha il ragionamento preservato
• non hai inviato l’header beta e il modello potrebbe lasciar passare i blocchi che non superano il controllo del prefisso senza un errore

Monitora la produzione e trova il ragionamento perso senza errori

Registra ogni errore 400 e gestiscilo nel codice in modo che la conversazione prosegua. Se invece lasci prefix_mismatch_behavior non specificato, monitora il traffico di produzione per individuare il ragionamento che non supera il controllo del prefisso e che ha raggiunto Claude.

Il ragionamento può andare perso senza errori tramite "drop_block", un elemento di un batch, un cambio di modello, il passaggio a un altro account o un codice che non rinvia alcun ragionamento. Con l’header beta, ognuno di questi lascia una voce, tranne l’ultimo. Per quello, verifica che le tue richieste contengano blocchi thinking.

Dettagli tecnici

Cos’altro può dire il messaggio di errore

Il messaggio di errore prosegue indicando cosa è cambiato, dove l’API è in grado di stabilirlo, ad esempio system, tools, il primo messaggio o blocco che differisce, contenuto mancante o nuovo, oppure un blocco di ragionamento precedente mancante o fuori ordine. La formulazione di quella frase può cambiare, quindi non basarti su di essa per il confronto. Se la richiesta non aveva l’header beta, il messaggio di errore aggiunge questa frase:

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

L’errore chiede ancora l’header, oppure dice Extra inputs are not permitted

Se l’errore chiede ancora l’header, l’header non ha raggiunto l’API: un proxy o una libreria potrebbe averlo rimosso. Un errore diverso, che termina con block_binding: Extra inputs are not permitted, significa la stessa cosa, oppure che il ragionamento è disattivato.

Rimuovi a mano il ragionamento non valido

Usa questo metodo dove non puoi inviare l’impostazione, o in uno di questi casi:

• Dopo aver rimosso un segreto, dati personali o testo iniettato, perché "drop_block" lascia il ragionamento nella tua cronologia memorizzata.
• Quando il ragionamento è disattivato ("disabled" o "between_tools"), perché "drop_block" richiede "adaptive", che attiverebbe il ragionamento e aggiungerebbe token di output.

1. Rimuovi il blocco indicato dall’errore e ogni blocco thinking e redacted_thinking successivo, altrimenti lo stesso errore indicherà poi il successivo blocco non valido. Ma se la tua cronologia contiene messaggi role: "system", o due messaggi dello stesso ruolo di seguito, rimuovi ogni blocco thinking e redacted_thinking. L’errore conta un messaggio di questo tipo come parte del messaggio precedente, quindi la posizione che indica può essere inferiore all’indice nel tuo array. Il path di una voce input_transformations conta ogni messaggio separatamente.
2. Mantieni ogni altro blocco e invia di nuovo la richiesta. Non reinserire i blocchi rimossi.

Errori simili a questo

Questi errori non dicono che il blocco è vincolato a una conversazione diversa, e impostare prefix_mismatch_behavior potrebbe non risolverli:

• Un messaggio che si ferma dopo “Invalid signature in thinking block”, dice “cannot be modified” o riguarda budget_tokens: Risoluzione dei problemi del ragionamento
• Un messaggio su temperature o su una risposta precompilata: Limiti e compatibilità delle funzionalità

Quando puoi smettere di inviare "drop_block"

Per smettere di inviare "drop_block", rimuovi i blocchi che scarta e mantieni il ragionamento prodotto da allora. Se non è cambiato nient’altro, la conversazione supera quindi il controllo del prefisso con "error".

Gestisci l’errore nel codice

Per gestire l’errore nel codice, invia l’header beta e "error" su ogni richiesta, in modo che il mancato superamento del controllo del prefisso sia un errore 400 su ogni modello. Quando arriva, passa solo quella conversazione a "drop_block" per ogni richiesta successiva, memorizza quella scelta insieme alla conversazione, invia di nuovo una volta e registra l’errore. Se lo stesso errore si ripresenta, l’impostazione non ha raggiunto l’API: consulta L’errore chiede ancora l’header, oppure dice Extra inputs are not permitted.

Il tuo codice deve riconoscere questo errore tramite il suo campo message, l’eccezione al consiglio generale di non basarsi sul testo di un errore. Ogni errore 400 ha il tipo invalid_request_error, e questo non ha alcun error.details.error_code. Confronta solo “The block is bound to a different conversation”, perché il resto del messaggio può cambiare.

Non hai alcun errore, oppure ne hai uno che non dice cosa è cambiato

• L’errore 400, che non indica alcuna modifica: Confronta tu stesso le richieste. Una causa è un blocco di compattazione inviato senza rimuovere i messaggi che riassume.

• Una voce prefix_binding_mismatch: Confronta system, tools e messages fino al path della prima voce con la conversazione com’era quando quel blocco è stato prodotto. Se ogni blocco è elencato, inizia da system e tools.

  Se non differisce nulla, cerca un URL di immagine o documento il cui contenuto è cambiato, un elenco di strumenti di un server MCP modificato (vedi Fissa l’elenco degli strumenti di un server MCP), oppure un blocco di ragionamento omesso, spostato o reinserito. Senza log delle richieste, invia di nuovo la richiesta con "error" e leggi la frase che dice cosa differisce, se presente.

• Un proxy o una libreria non tuoi, nel mezzo: Confronta ciò che invia con ciò che hai inviato tu, e indirizza chi lo mantiene a Librerie, proxy e gateway.

• Solo un sospetto, e niente Claude Code: Cattura i corpi delle richieste di una conversazione, una con una compattazione o una modifica agli strumenti. Confronta ciascuno con il precedente, escludendo i suoi nuovi turni.

Cinque passaggi per un test che può fallire, e un programma che li esegue

1. Nel tuo codice, invia l’header beta e "drop_block" su ogni richiesta di una sessione, a un modello con ragionamento preservato.
2. Usa prompt che facciano ragionare Claude e verifica che la prima risposta abbia un blocco thinking. Con il ragionamento adattivo, Claude può saltare il ragionamento su un prompt facile.
3. Fai fallire il test solo su una voce input_transformations il cui motivo è prefix_binding_mismatch. Un test che si aspetta un array vuoto fallisce anche dopo un cambio di modello, perché in quel caso sono previste voci con model_binding_mismatch o organization_binding_mismatch.
4. Modifica qualcosa di proposito, ad esempio aggiungendo un prompt system solo alla terza richiesta.
5. Verifica che input_transformations elenchi i blocchi di ragionamento che si trovano dopo la modifica. Se non ne elenca nessuno, verifica che la cronologia contenga un blocco di ragionamento.

Questo programma esegue i passaggi 1, 2, 4 e 5. Stampa quanti blocchi di ragionamento e quante voci input_transformations ha ogni risposta, poi ogni voce, che è ciò che verifica il passaggio 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 l'ultima richiesta aggiunge un prompt di sistema, che modifica il prefisso di proposito
        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" al posto di "drop_block", la terza richiesta riceve l’errore 400.

Cosa significa ogni voce input_transformations e quali spetta a te correggere

Con l’header beta, una risposta da un modello che supporta il ragionamento ha l’array input_transformations accanto a usage. È vuoto quando non è stato scartato nulla e non è stato lasciato passare nulla di non valido. Quando usi lo streaming, si trova nel message dell’evento message_start; dopo un fallback a metà stream, l’evento message_delta finale contiene quello che conta. A differenza della posizione indicata nell’errore, path è sempre la posizione del blocco così come l’hai inviato:

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

Il type e il reason di ogni voce, e cosa significano:

• thinking_dropped, prefix_binding_mismatch: Ciò che precedeva questo blocco non è ciò che il blocco ha registrato. Spetta a te correggerlo: Trova cosa ha modificato il tuo codice.
• thinking_mismatch_allowed, prefix_binding_mismatch: Lo stesso, ma Claude ha letto il blocco invariato, e viene fatturato. Questa voce compare solo quando l’impostazione non è specificata, su alcuni modelli. Spetta a te correggerlo.
• thinking_dropped, model_binding_mismatch: Questo modello non può leggere i blocchi del modello che ha prodotto il blocco. Non spetta a te correggerlo: continua a inviare l’intera conversazione.
• thinking_dropped, organization_binding_mismatch: Un altro account ha prodotto il blocco, quindi l’API lo ha scartato. Non spetta a te correggerlo.

Ignora una voce il cui type o reason non riconosci.

Batch e conteggio dei token

• Message Batches: Un elemento che lascia prefix_mismatch_behavior non specificato non riceve mai l’errore 400. L’API scarta i blocchi non validi oppure, su alcuni modelli, può lasciarli passare. Un elemento che imposta "error" si risolve come errored quando un blocco non supera il controllo del prefisso. block_binding va nei params.thinking dell’elemento.
• Conteggio dei token: Sulla Claude API, il conteggio dei token può restituire lo stesso errore 400 e accetta prefix_mismatch_behavior con lo stesso header. Esclude dal conteggio i blocchi scartati e non restituisce input_transformations.

Passaggi successivi