Claude Fable 5.1 Pensée Conservée : Résoudre l'erreur 'Le bloc est lié à une conversation différente'

Si vous avez déplacé un harnais d'agent vers Claude Fable 5.1 et avez commencé à voir une erreur 400 dont le message indique qu'un bloc de réflexion «est lié à une conversation différente», votre code modifie l'historique de conversation entre les requêtes, et Fable 5.1 est le premier modèle Claude qui s'y oppose. Ce guide explique ce qu'est cette vérification, à qui elle s'applique, ce qui la déclenche exactement, l'échappatoire et les modèles d'ajout seul qui font disparaître l'erreur tout en maintenant votre cache de prompt chaud.

La vérification est documentée sous réflexion préservée et dans Nouveautés de Claude Fable 5.1. C'est la troisième des trois modifications majeures de Fable 5.1, et la seule qui peut dégrader un harnais silencieusement. Pour les deux autres, consultez le guide de migration.

bouton

L'erreur

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.

Il s'agit d'une erreur 400 invalid_request_error, décidée avant toute sortie. Réessayer avec le même corps échoue de la même manière. Le chemin (messages.5.content.0) pointe vers le premier bloc de réflexion qui ne correspond plus, et le message peut se terminer par une phrase supplémentaire nommant le premier message qui a changé, ce qui est le diagnostic que vous souhaitez. Le point de terminaison de comptage de jetons exécute la même vérification.

Un échec différent semble similaire mais n'est pas celui-ci : la même clause introductive sans la phrase « lié à une conversation différente » signifie que la signature elle-même est altérée ou indéchiffrable, et prefix_mismatch_behavior ne s'applique pas.

Ce que fait la vérification

Chaque bloc de réflexion Fable 5.1 porte une signature qui enregistre deux choses : quel modèle l'a produit, et le préfixe exact de la conversation qui l'a précédé, c'est-à-dire le prompt system de niveau supérieur, le tableau tools, et chaque message avant le bloc. Chaque bloc s'enchaîne également au bloc de réflexion précédent. Lorsque vous renvoyez la transcription, l'API vérifie que ce préfixe est identique au byte près à ce qui a produit le bloc.

Anthropic donne deux raisons. La raison déclarée est l'anti-distillation : le message de lancement indique que les nouveaux comptes API ne peuvent plus modifier manuellement le contexte antérieur de Claude dans une conversation à plusieurs tours tout en préservant la transcription de la réflexion antérieure, ce qui met fin à une technique de distillation documentée. La raison pratique est que les mêmes modifications qui rompent la vérification redémarrent également la cache de prompt, de sorte que le code qui passe la vérification est aussi un code qui obtient les lectures de cache à 0,25 $ par million à chaque tour.

À qui cela s'applique

Appliqué par défaut : comptes créés le ou après le 31 août 2026. Cela couvre les organisations Claude API, les comptes Amazon Bedrock, les projets Google Cloud et les ressources Microsoft Foundry.

Enregistré mais non appliqué : comptes créés antérieurement. L'API note la non-concordance mais n'agit que lorsque la requête définit thinking.block_binding.prefix_mismatch_behavior à n'importe quelle valeur, y compris "error". Anthropic déclare que les futurs modèles l'appliqueront à tout le monde.

Non affecté : Claude Code, claude.ai, Claude Managed Agents et le SDK Claude Agent, qui maintiennent le préfixe intact pour vous. Claude Mythos 5.1 n'exécute pas du tout la vérification, bien que les modifications d'historique redémarrent toujours sa cache.

Affecté : tout code qui construit lui-même le tableau messages. C'est chaque boucle d'agent personnalisée, chaque backend de chat et chaque framework qui enveloppe l'API Messages.

Le piège pour les auteurs d'outils : si vous distribuez quelque chose que les gens exécutent avec leurs propres clés API, votre clé est probablement sur un compte plus ancien et la leur pourrait ne pas l'être. Testez avec le champ défini, afin de rencontrer la vérification avant vos utilisateurs. Pour savoir si votre propre compte est soumis à l'application, envoyez une requête qui modifie l'historique sans l'en-tête bêta ; une erreur 400 nommant l'en-tête signifie que c'est le cas.

Ce qui invalide chaque bloc de réflexion ultérieur

Modifier, réorganiser ou supprimer un tour précédent. Cela inclut la suppression d'anciens résultats d'outils, la coupure de tours au milieu de la transcription et le compactage côté client qui conserve les tours récents mot pour mot derrière un résumé.
Injecter du contenu que vous ne persistez pas. Un rappel par tour ajouté après les résultats d'outils et supprimé lors de la requête suivante. Une ligne d'état. Un compte de jetons restants qui change à chaque tour.
Reconstruire system ou tools entre les requêtes. Mettre à jour la date actuelle dans le prompt système. Ajouter ou supprimer un outil en cours de session.
Une URL d'image ou de document qui sert des octets différents plus tard. Les octets sont liés, pas la chaîne d'URL, donc une URL signée rotative pour le même fichier est acceptable.
Supprimer un bloc de réflexion de n'importe où ailleurs que le début de l'exécution. Les blocs initiaux peuvent être supprimés, du plus ancien au plus récent. Un bloc du milieu ne le peut pas.

Ce qui les maintient valides

Historiques à ajout seul, y compris les messages role: "system" ajoutés et les messages à portée de tour effacés laissés en place.
Supprimer une série initiale de blocs de réflexion, du plus ancien au plus récent.
Modifier n'importe quel paramètre en dehors de system, tools et messages : max_tokens, output_config y compris effort, tool_choice, metadata.
Ajouter, déplacer ou supprimer des marqueurs cache_control.
Compactage côté serveur et édition de contexte, y compris l'effacement des blocs de réflexion. Ils ne sont pas considérés comme des modifications car la vérification compare la conversation telle que vous l'avez envoyée, et non la copie modifiée du serveur. Après un compactage, le préfixe vérifié commence à partir du bloc de compactage.

L'échappatoire : drop_block

Envoyez l'en-tête bêta thinking-binding-controls-2026-08-01 et définissez le champ explicitement :

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)

Avec "drop_block", l'API supprime le premier bloc non concordant et tous les blocs de réflexion qui le suivent, procède à la requête et signale chaque suppression dans un tableau input_transformations de niveau supérieur :

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

Trois choses à savoir sur ce champ. Il ne s'applique qu'à cette requête, alors continuez à l'envoyer pour le reste de la session. Les valeurs par défaut diffèrent selon la surface : sans l'en-tête, un compte soumis à application génère des erreurs ; l'envoi de l'en-tête seul bascule vers la valeur par défaut de la bêta, qui est drop_block ; définissez-le donc explicitement et ne vous fiez jamais à l'une ou l'autre des valeurs par défaut. Et l'envoi de block_binding sans l'en-tête est une erreur 400 se terminant par block_binding: Extra inputs are not permitted.

Le champ reason distingue deux cas. prefix_binding_mismatch signifie que votre historique a changé. model_binding_mismatch signifie que la conversation a changé de modèle (un routeur, un réessai, un repli en cas de refus) et que la cible n'a pas pu lire un bloc Fable 5.1. Le second n'est pas un bug dans votre code. Avec l'en-tête, chaque réponse contient le tableau, vide si rien n'a été supprimé.

Supprimer des blocs une fois, à une limite de compactage, coûte peu. Un harnais qui invalide son propre historique à chaque requête perd le raisonnement du modèle à chaque tour et redémarre la cache de prompt à chaque tour, et Anthropic avertit que cela augmente le coût par tâche. Traitez drop_block comme un diagnostic et un filet de sécurité, pas un état stable.

La récupération sans bêta

Sur une plateforme sans les contrôles (Microsoft Foundry ne les proposait pas au lancement ; Bedrock et Google Cloud les ajoutaient par modèle), supprimez tous les blocs thinking et redacted_thinking de l'historique, conservez les blocs text et tool_use de chaque tour, et réessayez une fois. Le modèle répond à ce tour sans le raisonnement que ces blocs contenaient. Il s'agit d'une récupération unique, pas d'un modèle.

L'audit en trois étapes

Exécutez ceci avant de basculer le trafic, pas après.

Capturez les corps de requêtes exacts que votre harnais envoie sur quelques tours normaux, y compris un compactage ou un changement d'outil si votre produit en a. Pour chaque paire de requêtes consécutives, comparez le prompt system, le tableau tools et le préfixe partagé des messages. Ils doivent être identiques au byte près jusqu'aux tours nouvellement ajoutés.
Exécutez une session multi-tours normale contre claude-fable-5-1 avec l'en-tête bêta et prefix_mismatch_behavior: "drop_block", en enregistrant les input_transformations à chaque réponse. Un tableau vide à chaque tour signifie que l'historique est intact. Une entrée prefix_binding_mismatch signifie que quelque chose avant le bloc au path a changé. Cela fonctionne depuis n'importe quel compte, car la définition du champ active l'application du contrôle pour la requête. En CI, définissez "error" à la place pour qu'une modification fasse échouer l'exécution.
Choisissez un paramètre de production et définissez-le explicitement sous l'en-tête : "error" si une non-concordance ne peut signifier qu'un bug, "drop_block" pour dégrader au lieu d'échouer. Surveillez les erreurs 400 ou les entrées input_transformations dans tous les cas. Ne laissez pas le champ non défini sur un compte plus ancien, car la vérification ne serait alors enregistrée que côté serveur et vous n'auriez rien à surveiller.

Dans Apidog, l'étape 2 est un test à deux requêtes : envoyez un tour, modifiez le prompt système, envoyez le tour suivant avec l'en-tête défini, et vérifiez les input_transformations. Gardez-le dans la collection pour que chaque modification du harnais le ré-exécute. Téléchargez Apidog pour le construire.

Rendre un harnais à ajout seul

Chaque ligne remplace une modification d'historique par quelque chose qui maintient le préfixe intact et garde le cache chaud.

Ce que vous faisiez	Faites plutôt ceci
Modification du prompt système en cours de session (nouvelle date, nouveau mode)	Figez `system` au début de la session. Ajoutez `{"role": "system", "content": "La date actuelle est 2026-09-14."}` au moment où le changement devient effectif (messages système en cours de conversation). Pas d'en-tête bêta ; cela obtient l'autorité de prompt système et devient une partie du préfixe auquel les blocs ultérieurs sont liés.
Modification du tableau `tools` en cours de session	Déclarez l'ensemble complet au début de la session (`defer_loading: true` sur ceux qui commencent cachés). Envoyez des blocs `tool_addition` et `tool_removal` dans un message `role: "system"` (bêta `mid-conversation-tool-changes-2026-07-01`).
Injection d'un rappel par tour et suppression à la requête suivante	Envoyez-le comme un message système à portée de tour : `{"role": "system", "clear_at": "next_user_message", "content": "..."}` (bêta `mid-conversation-system-clear-at-2026-08-21`) après le message de résultat d'outil, et laissez chaque copie antérieure en place. Les copies effacées ne rendent rien et ne coûtent rien. Sans la bêta, placez le rappel dans un bloc de texte après les blocs `tool_result` dans le même message utilisateur, les copies antérieures étant conservées.
Suppression des anciens résultats d'outils côté client	Édition de contexte côté serveur avec effacement des résultats d'outils.
Compactage côté client	Préférez le compactage côté serveur (bêta `compact-2026-01-12` ; son paramètre `instructions` prend votre propre prompt de résumé). Si vous restez côté client, utilisez un compactage simple : remplacez tout l'historique par un message de résumé plus le nouveau tour utilisateur et ne rejouez rien d'autre.
Référencer une image ou un document par URL à travers les tours	Téléchargez une fois vers l'API Files et envoyez l'`file_id`, ou envoyez en base64.

Deux formes de compactage côté client échouent sous la vérification et nécessitent drop_block ou des blocs de réflexion supprimés sur les tours conservés. Le compactage par conservation de la queue (résumer les tours plus anciens, conserver les plus récents mot pour mot) échoue sur les tours conservés, car leur réflexion a été produite à partir de l'historique complet. Le compactage en arrière-plan (construire le résumé en dehors du chemin critique et l'échanger plus tard) échoue sur chaque tour produit entre le début du résumé et l'échange. La coupure de tours individuels au milieu de la transcription invalide chaque bloc ultérieur, et aucune forme côté client ne l'évite. Utilisez un message système en cours de conversation pour le changement d'instruction que vous faisiez, ou l'édition de contexte côté serveur pour une suppression sélective.

Une autre considération de coût : parce que les lectures de cache coûtent maintenant 0,25 $ par million, compacter tôt pour économiser de l'argent pourrait ne plus être le bon compromis sur Fable 5.1. Anthropic suggère d'expérimenter des points de compactage plus tardifs.

Pourquoi c'est aussi l'histoire du cache

Tout ce qui figure dans le tableau ci-dessus est aussi la liste des éléments qui redémarrent une cache de prompt. Fable 5.1 a rendu les hits de cache quatre fois moins chers que Fable 5 et a rendu les échecs proportionnellement plus coûteux, de sorte qu'un harnais à ajout seul est récompensé deux fois : la réflexion survit, et chaque tour lit le préfixe à 0,25 $ au lieu de le réécrire à 12,50 $. La ventilation des prix contient les chiffres ; la visite guidée de l'API montre les formes de requête à portée de tour et à effort par message en contexte, le guide de prompting couvre les instructions par tour qui valent la peine d'être envoyées de cette manière, et le guide Claude Code explique pourquoi les utilisateurs de Claude Code ne voient jamais cette erreur.

FAQ

Que signifie « Le bloc est lié à une conversation différente » ? Un bloc de réflexion Claude Fable 5.1 a été rejoué après que quelque chose le précédant ait changé : le prompt système, le tableau d'outils ou un message antérieur. L'API rejette la requête avec une erreur 400 sur les comptes soumis à application.

Quels comptes appliquent la vérification d'historique Fable 5.1 ? Les comptes créés le ou après le 31 août 2026, sur toutes les plateformes. Les comptes plus anciens l'appliquent uniquement lorsqu'une requête définit thinking.block_binding.prefix_mismatch_behavior. Anthropic prévoit de l'appliquer à tout le monde sur les futurs modèles.

Comment faire disparaître rapidement l'erreur ? Envoyez l'en-tête bêta thinking-binding-controls-2026-08-01 avec prefix_mismatch_behavior: "drop_block". L'API supprime les blocs affectés et continue. Ensuite, corrigez la modification de l'historique, car la suppression de blocs à chaque tour coûte en raisonnement et redémarre votre cache.

Le changement d'effort ou de max_tokens invalide-t-il les blocs de réflexion ? Non. Tout paramètre en dehors de system, tools et messages peut changer librement, de même que les marqueurs cache_control.

Le compactage côté serveur rompt-il la vérification ? Non. Le compactage et l'édition de contexte se produisent après la vérification, qui compare la conversation telle que vous l'avez envoyée. Le compactage côté client qui conserve les tours récents mot pour mot le rompt.

Claude Mythos 5.1 a-t-il la même vérification ? Non. Mythos 5.1 n'exécute pas la vérification de conversation, bien qu'il lie toujours les blocs de réflexion au modèle producteur et que les modifications d'historique redémarrent toujours sa cache.