Si vous avez migré un harnais d’agent vers Claude Fable 5.1 et rencontrez une erreur 400 indiquant qu’un bloc de réflexion « est lié à une conversation différente », votre code modifie l’historique entre deux requêtes. Fable 5.1 est le premier modèle Claude à bloquer ce comportement. Ce guide explique la vérification, les cas concernés, les déclencheurs, le contournement et les modèles à ajout seul qui corrigent l’erreur tout en conservant un cache de prompt chaud.
Essayez Apidog dès aujourd’hui
La vérification est documentée dans la section réflexion préservée et dans Nouveautés de Claude Fable 5.1. Il s’agit de la troisième modification majeure de Fable 5.1, et de la seule susceptible de dégrader silencieusement un harnais. Consultez le guide de migration pour les deux autres.
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
, générée avant toute sortie. Réessayer avec le même corps échoue de la même manière.
Le chemin messages.5.content.0
désigne le premier bloc de réflexion qui ne correspond plus. Le message peut aussi nommer le premier message modifié : c’est l’indication de diagnostic la plus utile. Le point de terminaison de comptage de jetons applique la même vérification.
Une erreur similaire, mais différente, peut commencer par la même clause. Si elle ne contient pas la phrase « lié à une conversation différente », la signature est probablement altérée ou illisible. Dans ce cas, prefix_mismatch_behavior
ne s’applique pas.
Chaque bloc de réflexion de Fable 5.1 contient une signature qui enregistre :
tools
;Les blocs sont également chaînés entre eux. Lorsque vous renvoyez la transcription, l’API vérifie que ce préfixe est identique octet par octet à celui qui a produit le bloc.
Anthropic cite deux raisons :
Les comptes créés le ou après le 31 août 2026 sont concernés, notamment :
Pour les comptes plus anciens, l’API enregistre les divergences sans bloquer la requête, sauf si celle-ci définit thinking.block_binding.prefix_mismatch_behavior
, y compris sur "error"
.
Anthropic indique que les futurs modèles appliqueront cette vérification à tous les comptes.
Ne sont pas concernés :
Ces surfaces conservent le préfixe intact pour vous. Claude Mythos 5.1 n’exécute pas cette vérification, même si les modifications de l’historique redémarrent toujours son cache.
Tout code qui construit lui-même le tableau messages
est concerné :
Si vous distribuez un outil utilisé avec les clés API de vos utilisateurs, testez avec la vérification activée. Votre compte peut être ancien, tandis que celui d’un utilisateur peut être soumis à l’application.
Les changements suivants invalident les blocs de réflexion ultérieurs :
system
ou tools
entre deux requêtes ;Les blocs initiaux peuvent uniquement être supprimés du plus ancien au plus récent. Un bloc situé au milieu de la transcription ne peut pas être supprimé seul.
Les pratiques suivantes maintiennent les blocs valides :
role: "system"
;system
, tools
et messages
, comme max_tokens
, output_config
, effort
, tool_choice
ou metadata
;cache_control
;Le compactage côté serveur est effectué après la vérification. Celle-ci compare la conversation envoyée par votre application, et non la copie modifiée par le serveur. Après un compactage, le préfixe vérifié commence au niveau du bloc de compactage.
drop_block
Pour continuer l’exécution malgré une divergence, envoyez l’en-tête bêta et définissez explicitement le comportement :
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 ainsi que tous les blocs de réflexion suivants. Elle poursuit ensuite la requête et signale chaque suppression dans input_transformations
:
{
"input_transformations": [
{
"type": "thinking_dropped",
"path": "messages.1.content.0",
"reason": "prefix_binding_mismatch"
}
]
}
À retenir :
drop_block
;block_binding
sans l’en-tête produit une erreur 400
: block_binding: Extra inputs are not permitted
.Le champ reason
distingue deux situations :
prefix_binding_mismatch
: l’historique a changé ;model_binding_mismatch
: la conversation a changé de modèle, par exemple à cause d’un routeur, d’un réessai ou d’un mécanisme de repli.Le second cas ne provient pas d’un bug dans votre code.
drop_block
doit être utilisé comme diagnostic et filet de sécurité, pas comme solution permanente. Supprimer des blocs occasionnellement coûte peu. En revanche, les supprimer à chaque requête fait perdre le raisonnement du modèle et redémarre le cache de prompt à chaque tour.
Sur une plateforme qui ne prend pas encore en charge ces contrôles — Microsoft Foundry au lancement, par exemple — supprimez de l’historique tous les blocs thinking
et redacted_thinking
.
Conservez les blocs text
et tool_use
, puis réessayez une seule fois. Le modèle répondra sans le raisonnement contenu dans les blocs supprimés.
Cette procédure est une récupération ponctuelle, pas un modèle d’architecture.
Effectuez cet audit avant de basculer le trafic.
Capturez les corps exacts envoyés par votre harnais sur plusieurs tours normaux, notamment après :
Pour chaque paire de requêtes consécutives, comparez :
tools
;Ces éléments doivent rester identiques octet par octet jusqu’aux nouveaux tours.
drop_block
en environnement de test
Exécutez une session multi-tours avec claude-fable-5-1
, l’en-tête bêta et prefix_mismatch_behavior: "drop_block"
.
Enregistrez input_transformations
à chaque réponse :
prefix_binding_mismatch
indique qu’un élément précédent a changé.En CI, utilisez "error"
à la place de "drop_block"
afin que toute modification fasse échouer le test.
Définissez explicitement le comportement sous l’en-tête bêta :
"error"
si toute divergence indique nécessairement un bug ;"drop_block"
si vous préférez dégrader la réponse plutôt que faire échouer la requête.Surveillez les erreurs 400 et les entrées input_transformations
dans les deux cas. Ne laissez pas le champ non défini sur un compte ancien : la divergence serait enregistrée côté serveur sans signal exploitable par votre application.
Dans Apidog, créez un test à deux requêtes :
input_transformations
.Conservez ce test dans la collection afin de le rejouer après chaque modification du harnais. Vous pouvez télécharger Apidog pour le créer.
| Ce que vous faisiez | Faites plutôt ceci |
|---|---|
| Modifier le prompt système en cours de session, par exemple pour changer la date ou le mode. | Figez system au début de la session. Lorsque le changement devient effectif, ajoutez {"role": "system", "content": "La date actuelle est 2026-09-14."} . Les messages système ajoutés en cours de conversation deviennent une partie du préfixe. |
Modifier le tableau tools en cours de session. |
|
Déclarez l’ensemble complet au début, en utilisant defer_: true pour les outils initialement masqués. Envoyez ensuite des blocs tool_addition et tool_removal dans un message role: "system" avec la bêta mid-conversation-tool-changes-2026-07-01 . |
|
| Injecter un rappel par tour puis le supprimer à la requête suivante. | Envoyez-le comme message système à portée de tour : {"role": "system", "clear_at": "next_user_message", "content": "..."} avec la bêta mid-conversation-system-clear-at-2026-08-21 . Placez-le après le résultat d’outil et laissez les copies précédentes dans l’historique. Sans la bêta, ajoutez le rappel dans un bloc de texte après les blocs tool_result du même message utilisateur. |
| Supprimer côté client d’anciens résultats d’outils. | Utilisez l’édition de contexte côté serveur avec effacement des résultats d’outils. |
| Effectuer un compactage côté client en conservant les tours récents mot pour mot. | Préférez le |
compact-2026-01-12 et son paramètre instructions . Si vous devez compacter côté client, remplacez tout l’historique par un message de résumé et le nouveau tour utilisateur. |
file_id
, ou utilisez le base64.Deux formes de compactage côté client échouent sous cette vérification :
La coupure de tours individuels au milieu de la transcription invalide également tous les blocs suivants. Pour une modification d’instruction, utilisez un message système en cours de conversation. Pour une suppression sélective, utilisez l’édition de contexte côté serveur.
Les éléments qui invalident les signatures sont aussi ceux qui redémarrent le cache de prompt.
Fable 5.1 rend les lectures de cache quatre fois moins chères que Fable 5 et rend les échecs proportionnellement plus coûteux. Un harnais à ajout seul offre donc un double avantage :
Consultez la ventilation des prix, la visite guidée de l’API, le guide de prompting et le guide Claude Code pour approfondir les formats de requête et les coûts.
Comme les lectures de cache sont moins chères, compacter tôt pour économiser de l’argent n’est peut-être plus le meilleur compromis avec Fable 5.1. Testez des points de compactage plus tardifs.
Un bloc de réflexion Claude Fable 5.1 a été rejoué après la modification d’un élément précédent : prompt système, tableau d’outils ou message antérieur. Sur les comptes soumis à la vérification, l’API rejette la requête avec une erreur 400.
Les comptes créés le ou après le 31 août 2026, sur toutes les plateformes concernées. Les comptes plus anciens l’appliquent uniquement lorsqu’une requête définit thinking.block_binding.prefix_mismatch_behavior
. Anthropic prévoit une application globale sur les futurs modèles.
Envoyez thinking-binding-controls-2026-08-01
dans l’en-tête bêta et définissez prefix_mismatch_behavior
sur "drop_block"
. L’API supprimera les blocs concernés et poursuivra l’exécution.
Corrigez ensuite la modification de l’historique : supprimer des blocs à chaque tour fait perdre du raisonnement et redémarre le cache.
effort
ou max_tokens
invalide-t-il les blocs ?
Non. Les paramètres situés en dehors de system
, tools
et messages
peuvent être modifiés librement, tout comme les marqueurs cache_control
.
Non. Le compactage et l’édition de contexte ont lieu après la vérification, qui compare la conversation envoyée. En revanche, un compactage côté client qui conserve les tours récents mot pour mot la rompt.
Non. Mythos 5.1 n’exécute pas la vérification de conversation. Il lie toutefois toujours les blocs de réflexion au modèle producteur, et les modifications de l’historique redémarrent son cache.