La documentation d’Anthropic consacre une section aux bibliothèques, proxys et passerelles. Elle y écrit que les réécritures d’une passerelle comptent comme des modifications, et que ses appelants ne peuvent ni les voir ni les corriger. Avec la réflexion préservée de Claude Fable 5.2, trois gestes courants d’une passerelle peuvent faire échouer la vérification : réécrire les messages, changer de modèle, répartir les conversations entre plusieurs comptes.

Quand une conversation est rejouée, chaque bloc de réflexion renvoyé à l’API est confronté à l’historique exact qui le précédait, au modèle qui le relit et au compte qui l’envoie ; sur l’API Claude, depuis cette version, la première de ces vérifications s’applique à tous les comptes, quel que soit leur âge. Ma réponse : une passerelle qui ajoute sans jamais réécrire, et qui choisit le modèle et le compte une fois par conversation. Ce qui suit s’appuie sur la documentation du 2026-11-09, jour de la sortie ; je n’ai pas fait tourner ce modèle derrière une passerelle.

Fable 5.2 réflexion préservée : que vérifie l’API ?

Un bloc de réflexion produit par Fable 5.2 n’est valide que s’il revient après le même prompt system de premier niveau, les mêmes tools et les mêmes messages antérieurs, vers un modèle capable de le lire, depuis le compte qui l’a produit. La page Preserved thinking d’Anthropic décrit ces trois liens, qui ne cèdent pas de la même façon.

Le bloc est lié à Ce qui rompt le lien Ce que fait l’API
Le préfixe : system, tools et tous les messages avant le bloc Toute modification entre deux requêtes Renvoie une erreur 400, sauf si la requête demande drop_block
Le modèle Un tour suivant envoyé à un autre modèle que Fable 5.2 ou Mythos 5.2 Écarte le bloc ; la requête aboutit
Le compte Un renvoi depuis un compte qui n’est pas lié au premier Écarte le bloc ; la requête aboutit

Chaque retrait apparaît dans input_transformations, un champ de la réponse envoyé seulement avec l’en-tête bêta thinking-binding-controls-2026-08-01, sous la raison prefix_binding_mismatch, model_binding_mismatch ou organization_binding_mismatch. Sans cet en-tête, les retraits liés au modèle et au compte se passent en silence.

Sur l’API Claude, ce qui change, c’est qui reçoit l’erreur. D’après What’s new in Claude Fable 5.2, Fable 5.1 ne la renvoyait par défaut qu’aux comptes créés à partir du 2026-08-31 ; Fable 5.2 la renvoie quel que soit l’âge du compte. Une passerelle installée sur un compte plus ancien, qui retouchait les historiques sous Fable 5.1 sans jamais recevoir de reproche, peut échouer après la migration. Le message dit « The block is bound to a different conversation », et le guide de migration précise que renvoyer la même requête ne sert à rien : l’erreur revient à chaque fois.

Amazon Bedrock est décrit autrement. La page d’AWS donne une erreur 400 par défaut, sans condition d’âge du compte, et range déjà Fable 5.1 parmi les modèles qui font cette vérification. Selon cette page, la nouveauté sur Bedrock tient aux deux autres lignes du tableau.

Je n’attendrais pas un assouplissement. L’annonce d’Anthropic présente la réflexion préservée comme une protection contre ceux qui modifient le contexte antérieur du modèle pour en extraire le raisonnement.

La vérification du préfixe ne joue que si des tours d’assistant contenant de la réflexion sont renvoyés. Un premier tour n’a rien à rejouer : la classification en un seul appel n’est pas concernée.

Qu’est-ce qui, dans une passerelle, compte comme une modification ?

L’API compare ce que la passerelle a envoyé en amont la fois précédente avec ce qu’elle envoie maintenant. Une passerelle qui insère la date ou une variable de prompt dans system ou dans le premier message utilisateur envoie un préfixe différent dès que la valeur bouge ; la page de LiteLLM sur la stabilité du préfixe classe une variable modifiée ou une nouvelle version de prompt parmi les ruptures inévitables. Un rappel de politique ajouté à un tour utilisateur, puis retiré ou reformulé, est une modification. Remonter un message role: "system" de milieu de conversation vers le champ system de premier niveau invalide tous les blocs de réflexion.

Ajouter, retirer, renommer ou modifier une entrée de tools compte aussi, sur tous les modèles qui font la vérification. Le filtrage des outils par tenant n’est sûr que si son résultat reste constant, et une passerelle qui recopie dans tools les outils d’un serveur MCP modifie le préfixe chaque fois que la liste du serveur change. La particularité de Fable 5.2 est plus étroite : avec le connecteur MCP de l’API Claude, dit le guide de migration, une liste d’outils non épinglée qui varie d’une requête à l’autre est une modification pour les blocs de Fable 5.2, pas pour ceux de Fable 5.1. Épinglez-la. Pour couper les outils sur une seule requête, envoyez tool_choice: {"type": "none"}.

Reste le ménage que personne ne tient pour une réécriture : résumer les anciens tours côté client en gardant les plus récents avec leur réflexion, reconstruire une session sauvegardée à partir de gabarits, laisser un sérialiseur écarter les types de blocs qu’il ne connaît pas ou changer l’ordre des blocs.

Un défaut de sérialiseur est pire, parce que rien n’échoue. Sur ces modèles, le texte d’un bloc de réflexion est vide par défaut et c’est sa signature qui porte le raisonnement. Avec ce réglage par défaut, un sérialiseur qui saute les blocs vides les retire tous ; la requête aboutit et le modèle perd son raisonnement à chaque tour.

Ajouter des messages est sans risque. Modifier effort, max_tokens, tool_choice, metadata ou les marqueurs cache_control aussi.

LiteLLM documente son masquage Presidio comme stable : chaque message est masqué séparément, avec des remplacements déterministes. L’architecture que j’ai publiée applique Guardrails à chaque appel de génération de texte, et rien, dans les pages que j’ai lues, ne dit si un masquage par Guardrails change ce que compare la vérification du préfixe. Je ne supposerais ni l’un ni l’autre : je le testerais.

Je ferais de chaque transformation appliquée par la passerelle une fonction du seul message, sans rien lire de l’horloge ni de la configuration au moment de l’appel. À défaut, on l’applique une fois et l’historique stocké conserve le résultat. Une consigne reformulée n’atteint alors plus les conversations déjà ouvertes, une perte pour qui la voulait en vigueur partout dans l’heure. Elle vaut pour la conversation suivante, ou arrive comme un message ajouté.

Que se passe-t-il quand la passerelle change de modèle ?

Seuls Fable 5.2 et Mythos 5.2 lisent les blocs de réflexion de Fable 5.2. Tout autre modèle, Fable 5.1 compris, répond au tour suivant sans ce raisonnement. L’API écarte les blocs sans erreur ; le guide de migration prévient que le tour suivant peut coûter plus cher et durer plus longtemps. Une bascule après refus est un changement de ce type : les cibles autorisées, Claude Opus 4.8 et Claude Opus 5, ne lisent pas ces blocs.

L’API ne modifie jamais vos messages. Les blocs écartés sont donc relus si la conversation revient à Fable 5.2, et ne sont perdus pour de bon que si la passerelle les retire. Ne les retirez pas.

Mon propre guide de passerelle dit que les produits demandent une capacité, jamais un modèle, et qu’un changement de modèle devient un changement de table. Avec Fable 5.2, le produit s’aperçoit du changement de table, au premier tour qui le suit.

Pour Fable 5.2, je résoudrais la capacité en modèle une seule fois, à l’ouverture de la conversation, et garderais ce choix avec elle. Une bascule en cours de route reste possible, comme une exception que la passerelle journalise avec son motif, parce que quelqu’un demandera pourquoi ce tour a ralenti. Épingler le modèle coûte deux choses. Les conversations en cours restent sur l’ancien modèle jusqu’à leur fin, ce qui allonge un déploiement. Et une passerelle qui ne gardait aucun état par conversation doit désormais en garder un.

Et d’un compte à l’autre ?

Les blocs de Fable 5.2 ne fonctionnent que dans le compte qui les a produits ou dans un compte qui lui est lié ; la page ne définit pas ce lien. Sur Amazon Bedrock, la page d’AWS nomme l’unité : le même compte AWS, ou un compte du même « customer group » (groupe de clients).

Rien, dans mes travaux publiés, ne répartit une même conversation entre plusieurs comptes. Les passerelles qui le font, pour la reprise sur panne ou parce que chaque produit a son compte, doivent renvoyer chaque conversation par son compte d’origine. Changer de compte en cours de conversation fait perdre le raisonnement aussi discrètement qu’un changement de modèle.

Comment trouver ces modifications avant la production ?

Transmettez sans y toucher les valeurs anthropic-beta de l’appelant et son thinking.block_binding, et renvoyez-lui input_transformations ; avec l’API Converse, AWS indique de passer les deux par additionalModelRequestFields. Sa page ne dit pas où une réponse Converse porte input_transformations : vérifiez que la vôtre le fait remonter. Anthropic prévient qu’un schéma d’options qui rejette les clés inconnues empêche l’appelant de choisir drop_block. Le contrat que j’ai publié comprend des schémas d’entrée et de sortie ; si la passerelle les valide strictement, je nommerais ce champ dans le contrat. Puis, en préproduction :

  1. Envoyez l’en-tête bêta avec prefix_mismatch_behavior: "error" et faites passer par la passerelle trois tours avec un appel d’outil. Chaque tour aboutit et input_transformations revient vide.
  2. Capturez ce que la passerelle envoie en amont pour le premier tour, puis la même portion dans la requête du troisième. Les deux sont identiques, marqueurs cache_control mis à part.
  3. Forcez une bascule vers un autre modèle en cours de conversation. Attendez des entrées model_binding_mismatch ; notez les tokens de sortie de ce tour.
  4. Rejouez une conversation stockée par un second compte. Attendez des entrées organization_binding_mismatch.
  5. Glissez une fausse adresse e-mail dans le premier tour, masquage Guardrails actif, et déroulez trois tours sous drop_block. Si une entrée prefix_binding_mismatch apparaît, masquez avant de stocker le message.

En production, je m’écarterais du réglage par défaut d’Anthropic. Anthropic conseille de garder "error" quand une discordance ne peut venir que d’un bug dans votre propre code, et documente une issue plus étroite que drop_block sur tout le trafic : après une erreur 400, réessayer une fois avec drop_block et conserver ce choix avec la session. Dans une passerelle, j’en ferais le comportement par défaut pour les appelants qui n’envoient pas de block_binding ; la valeur de l’appelant l’emporte. Une passerelle est placée devant du code qu’elle ne maîtrise pas, et un historique stocké qui contient une modification continue d’échouer une fois le bug corrigé.

Le conseil d’Anthropic, une alerte sur chaque entrée prefix_binding_mismatch, vaut tel quel, et je donnerais une date de fin à ce comportement par défaut. Le prix : davantage de tokens de sortie, un cache de prompt qui repart du premier bloc écarté et, prévient Anthropic, des réponses qui peuvent changer quand les tours suivants s’appuient sur le raisonnement antérieur. Mettez l’alerte en sourdine, et plus personne n’entend parler de la discordance. Quoi que la passerelle fasse à la place de l’appelant après une erreur 400, qu’elle le journalise.

En pratique

Sur la plateforme d’ENSO, j’ai conçu une passerelle IA centrale comme chemin d’accès unique à Amazon Bedrock, avec des profils d’inférence limités à l’UE imposés à toute l’organisation via une SCP, le filtrage des PII par Guardrails et un routage des modèles qui isole les produits de leur cycle de vie. La passerelle est un élément d’une plateforme partagée et multi-tenant qui alimente quatre capacités produit ; l’architecture complète est décrite dans l’étude de cas ENSO, et ce type de passerelle fait partie du service de plateforme LLM d’entreprise.

La table des capacités isole toujours les produits du cycle de vie des modèles d’une conversation à l’autre. À l’intérieur d’une conversation, ce n’est plus vrai : sous Fable 5.2, elle reste sur son modèle ou perd du raisonnement. La bascule prévue par le guide vise un autre profil ou un autre modèle UE ; le changement de modèle est un cas de ce type, et je le journaliserais comme une perte de raisonnement. L’effet sur les blocs d’un passage à un autre profil UE du même modèle, je ne l’ai vu documenté nulle part.

Compromis et limites

Cet article repose sur une documentation datée du 2026-11-09. Je n’ai pas fait tourner Fable 5.2 derrière une passerelle, et aucun des coûts cités ici n’est mesuré. Les pages changeront, et la vérification comme le lien au compte sont décrits plateforme par plateforme : lisez la vôtre.

Épingler le modèle n’apporte rien à une passerelle dont le trafic tient surtout en un seul tour, et drop_block peut cacher un bug aussi longtemps que personne ne lit l’alerte. L’ajout seul convient à une passerelle mince, mais il interdit de changer un prompt pour tout le monde d’un coup. Le jeu de référence qui conditionne un changement de modèle est fait de questions isolées : aucun cas ne contient de bascule en cours de conversation, et je ne compterais pas sur lui pour voir le raisonnement qui s’y perd.

Questions fréquentes

Fable 5.2 renvoie-t-il une erreur 400 sur un historique modifié, pour tous les comptes ?

Sur l’API Claude, oui, quand la requête rejoue un bloc de réflexion de Fable 5.2 et laisse prefix_mismatch_behavior non défini. L’âge du compte n’a plus d’effet, alors que Fable 5.1 ne renvoyait l’erreur par défaut qu’aux comptes créés à partir du 2026-08-31. Pour Amazon Bedrock, la page d’AWS donne une erreur 400 par défaut, sans condition d’âge.

Une passerelle IA peut-elle passer de Fable 5.2 à un autre modèle en cours de conversation ?

Elle le peut, et la requête aboutit. Seuls Fable 5.2 et Mythos 5.2 lisent les blocs de réflexion de Fable 5.2 : tout autre modèle répond aux tours suivants sans ce raisonnement. L’API écarte les blocs sans erreur et ne les facture pas.

Que fait drop_block, et faut-il le laisser activé ?

Avec l’en-tête bêta, prefix_mismatch_behavior: "drop_block" fait écarter par l’API le bloc fautif et tous les blocs de réflexion suivants, puis répondre, en listant chaque retrait dans input_transformations. Anthropic y voit un palliatif et conseille une alerte sur chaque entrée prefix_binding_mismatch. Dans une passerelle, je l’activerais par session, après une première erreur 400.

Sources

Toutes lues le 2026-11-09.