Migration Claude Fable 5.1 : corriger les 400 tool_choice

Migrer de Claude Fable 5 à Claude Fable 5.1 n'est pas toujours un simple changement de nom de modèle. Le nouveau modèle refuse la sélection d'outils forcée, lie les blocs de réflexion préservés au préfixe de conversation qui les a produits, et ne peut pas renvoyer ses blocs de réflexion aux modèles Claude plus anciens. Une intégration peut donc réussir un test de fumée à un seul tour et échouer lors de sa première requête de sortie structurée, de conversation compactée ou de basculement de secours.

La migration sécurisée compte trois volets : remplacer les appels d'outils forcés par une sélection automatique plus l'application du schéma, maintenir l'historique multi-tour en ajout uniquement, et tester chaque route susceptible de basculer la conversation vers un modèle plus ancien. Si vous utilisez la route compatible OpenAI, commencez par le guide des requêtes Claude Fable 5.1 ; les exemples natifs ci-dessous utilisent l'API Messages d'Anthropic pour que chaque changement de compatibilité soit visible.

Réponse rapide

• Remplacez l'ID de modèle natif par claude-fable-5-1, puis supprimez les modes tool_choice forcés ; any et les outils nommés retournent HTTP 400.^[1]
• Gardez le message système, les outils et le préfixe de messages antérieurs inchangés après un bloc de réflexion Fable 5.1. Ajoutez plutôt des instructions nouvelles au lieu de réécrire l'historique.^[1]
• Testez chaque basculement de secours : les modèles Claude plus anciens ne peuvent pas lire les blocs de réflexion de Fable 5.1, donc l'API les supprime avant de continuer.^[1]
• La réflexion adaptative reste active. Remplacez les budgets de jetons manuels par effort, et exercez les incompatibilités de préfixe dans l'intégration avant le déploiement.^[1]

D'abord, cataloguez le chemin de code que vous migrez réellement

Cherchez plus largement que l'ID de modèle littéral. Un adaptateur peut traduire un paramètre générique « outil requis » en tool_choice: {"type":"any"} d'Anthropic, conserver les blocs de réflexion dans un magasin de conversation, ou altérer le message système à chaque requête. Le problème OpenCode qui a émergé peu après la version est un exemple utile : son adaptateur de sortie structurée sélectionnait l'utilisation d'outils obligatoires, ce qui devient le mode any non pris en charge d'Anthropic et produit un 400.^[6] Ce problème démontre un vrai modèle d'intégration ; le guide de migration d'Anthropic fait autorité sur le comportement de l'API.

Auditez ces composants avant l'édition :

Faites l'inventaire à la limite de la requête sérialisée si possible. Les objets d'application peuvent sembler inchangés même quand un SDK ou un adaptateur de fournisseur les réécrit.

Étape 1 : mettez à jour l'ID du modèle, mais gardez le reste observable

L'ID natif est claude-fable-5-1. Fable 5.1 conserve la fenêtre de contexte d'un million de jetons, prend en charge jusqu'à 128 000 jetons de sortie, et utilise la réflexion adaptative toujours active.^[2] Commencez avec la même forme de trafic de production et enregistrez les ID de requête, les codes d'état, les raisons d'arrêt, l'utilisation des jetons, les appels d'outils et les basculements de secours.

N'utilisez pas cette migration pour changer l'effort, le compactage, la formulation des invites et le cadre d'outils en même temps. Un premier déploiement étroit rend un 400 ou un changement de comportement attribuable. Une fois la compatibilité établie, parcourez low, medium, high, xhigh et max sur la charge de travail plutôt que d'assumer que le paramètre ancien est optimal. Anthropic documente high comme valeur par défaut.^[1]

Supprimez également l'une de ces configurations si une intégration prédécesseur les fournit :

# Les deux sont invalides pour Claude Fable 5.1.
thinking={"type": "disabled"}

thinking={"type": "enabled", "budget_tokens": 12000}

Fable 5.1 décide quand et combien réfléchir. Un message assistant de queue utilisé comme préfixe retourne également un 400, donc exprimez les instructions de sortie dans le contenu du système ou de l'utilisateur.^[1]

Étape 2 : remplacez la sélection d'outils forcée

La limite de compatibilité est exacte :

La vérification s'applique aux Messages, aux lots de messages et au comptage de jetons. L'erreur rapportée dit que les types de sélection d'outils tool et any ne sont pas pris en charge pour ce modèle.^[1] Réessayer le même corps n'aide pas.

Voici le motif courant pré-migration :

response = client.messages.create(
    model="claude-fable-5",
    max_tokens=4096,
    tools=[record_summary_tool],
    tool_choice={"type": "tool", "name": "record_summary"},
    messages=[
        {"role": "user", "content": "Summarize the meeting notes."}
    ],
)

Pour Fable 5.1, utilisez la sélection automatique, mettez l'exigence dans l'instruction courante, et rendez l'outil strict :

record_summary_tool = {
    "name": "record_summary",
    "description": "Record the structured meeting summary.",
    "strict": True,
    "input_schema": {
        "type": "object",
        "properties": {
            "summary": {"type": "string"},
            "action_items": {
                "type": "array",
                "items": {"type": "string"},
            },
        },
        "required": ["summary", "action_items"],
        "additionalProperties": False,
    },
}

response = client.messages.create(
    model="claude-fable-5-1",
    max_tokens=4096,
    tools=[record_summary_tool],
    tool_choice={"type": "auto"},
    messages=[{
        "role": "user",
        "content": (
            "Summarize the meeting notes, then call record_summary "
            "with the summary and action items."
        ),
    }],
)

strict: true contraint les arguments si le modèle appelle l'outil ; il ne recrée pas une garantie au niveau du transport selon laquelle l'outil doit être appelé. Votre application doit toujours vérifier que la réponse contient le bloc d'utilisation d'outils requis. Anthropic recommande aussi les sorties JSON via output_config.format quand l'outil forcé existait uniquement pour obtenir du JSON conforme au schéma.^[1]

Si l'application doit exiger un outil nommé au milieu d'une conversation, ajoutez un message role: "system" après le dernier message utilisateur. Nommez l'outil, déclarez qu'il est requis pour ce tour, et dites au modèle de commencer par l'appel. Conservez ce message système dans l'historique ultérieur. Ceci préserve le préfixe antérieur ; réécrire le message système de haut niveau ne le ferait pas.^[1]

Traitez « le modèle a ignoré l'instruction » comme un résultat géré. Rejetez le tour, recommencez sous une politique bornée, ou échouez en toute sécurité. Ne décrivez pas l'instruction comme un mécanisme d'application absolue.

Étape 3 : préservez la réflexion dans la direction que l'API prend en charge

Chaque bloc de réflexion Fable 5.1 porte des informations de liaison du modèle et de la conversation. La compatibilité est unidirectionnelle :

Réflexion Fable 5  ───────► Fable 5.1 peut la lire
Réflexion Opus 5   ───────► Fable 5.1 peut la lire

Réflexion Fable 5.1 ──X──► Fable 5 ne peut pas la lire
Réflexion Fable 5.1 ──X──► Opus 5 ne peut pas la lire

Claude Mythos 5.1 est l'exception documentée qui peut lire les blocs Fable 5.1. Quand un routeur, un basculement de refus ou une nouvelle tentative client envoie la conversation à un modèle plus ancien, l'API supprime les blocs que la cible ne peut pas lire. La requête peut toujours réussir, et les jetons d'entrée supprimés ne sont pas facturés, mais la cible doit replanifier sans ce raisonnement.^[1]

C'est important pour l'évaluation du basculement de secours. Une première requête sur Fable 5 et une première requête sur Fable 5.1 ne sont pas équivalentes à un changement mi-conversation de 5.1 à 5. Mesurez les deux. Enregistrez input_transformations avec le bêta de liaison de réflexion activé ; model_binding_mismatch identifie les blocs supprimés parce que le modèle a changé.

Étape 4 : rendez le préfixe de conversation en ajout uniquement

Un bloc de réflexion Fable 5.1 est valide par rapport au message système exact, à l'ensemble d'outils et à l'historique des messages qui l'ont précédé. Changer l'un d'eux avant de rejouer le bloc peut produire un 400 pour une signature de réflexion invalide.^[1]

Les éditions accidentelles courantes incluent :

• reconstruire le message système avec un horodatage frais ;
• ajouter ou supprimer un outil du tableau tools de haut niveau ;
• supprimer un ancien résultat d'outil pour économiser des jetons ;
• insérer un résumé avant les tours récents tout en conservant leurs blocs de réflexion ;
• supprimer un rappel par tour sur la requête suivante ;
• récupérer des octets d'image ou de document différents de la même URL.

Le dernier cas est facile à manquer : la liaison couvre les octets du fichier plutôt que seulement la chaîne URL. Pour un fichier réutilisé entre les tours, Anthropic recommande un file_id stable de l'API Files ou du contenu base64.^[1]

Préférez ces motifs :

• ajoutez les nouveaux tours sans modifier les octets antérieurs ;
• ajoutez des messages système mi-conversation pour les instructions modifiées ;
• utilisez les blocs d'ajout d'outils et de suppression d'outils supportés pour les changements d'outils ;
• utilisez le compactage côté serveur ou l'édition de contexte ;
• si le compactage côté client, remplacez l'ensemble de l'historique par un résumé et le nouveau tour utilisateur, sans porter les anciens blocs de réflexion.

Cette dernière forme côté client est délibérément simple. Garder les tours récents derrière un nouveau résumé n'est sûr que si leurs blocs thinking et redacted_thinking sont supprimés, parce que ces blocs ont été créés contre l'historique pré-résumé.^[1]

Diagnostiquez les incompatibilités de préfixe avant vos utilisateurs

Anthropic impose la vérification du préfixe de conversation par défaut pour les comptes créés le 31 août 2026 ou après. Les comptes plus anciens peuvent ne pas échouer à moins qu'ils ne choisissent d'entrer dans le contrôle, ce qui crée une brèche dangereuse du test « fonctionne avec notre clé » pour les bibliothèques utilisées avec les clés clients.^[1]

Utilisez le contrôle bêta dans une session de préproduction :

response = client.beta.messages.create(
    model="claude-fable-5-1",
    max_tokens=4096,
    thinking={
        "type": "adaptive",
        "block_binding": {
            "prefix_mismatch_behavior": "drop_block"
        },
    },
    messages=conversation,
    betas=["thinking-binding-controls-2026-08-01"],
)

for change in response.input_transformations or []:
    print(change.path, change.reason)

Avec drop_block, l'API supprime le premier bloc de réflexion mal apparié et chaque bloc de réflexion ultérieur, puis rapporte prefix_binding_mismatch. Avec la valeur par défaut error, elle rejette la requête. Utilisez drop_block quand une continuation dégradée est préférable à l'échec ; utilisez error dans l'intégration pour exposer une mutation d'historique immédiatement.^[1]

Une nouvelle tentative automatique d'un corps invalide identique ne peut pas réparer l'incompatibilité. Soit restaurez le préfixe original, supprimez les blocs de réflexion affectés, soit demandez explicitement un comportement de suppression une fois.

Revérifiez les comportements qui ne produisent pas de 400

Les tests de compatibilité devraient aussi couvrir les changements plus discrets. Anthropic dit que Fable 5.1 peut émettre moins d'appels d'outils parallèles dans les boucles d'agent long, produire moins de messages de progrès, et appeler la recherche ou la récupération moins souvent à low effort.^[3] Aucun de ces éléments n'indique nécessairement un défaut, mais chacun peut modifier la latence ou le comportement du produit.

Construisez des assertions autour de ce dont l'application a besoin :

• Pour les lectures parallélisables, enregistrez les appels par tour et les allers-retours totaux.
• Pour une interface de progrès, exigez les mises à jour visibles aux utilisateurs à intervalles définis plutôt que d'assumer leur apparition.
• Pour les réponses basées sur la récupération, rendez les critères de récupération explicites et rejetez les réponses qui manquent de preuves requises.
• Pour les agents d'édition, vérifiez la liste des fichiers modifiés et découragez les réécritures de fichiers complets quand un petit correctif suffit.^[4]

Gardez aussi la gestion des refus. Fable 5.1 peut retourner stop_reason: "refusal" avec un stop_details.category ; ne traitez pas le texte de réponse vide comme un échec de transport. Tout basculement de secours doit tenir compte de la compatibilité de réflexion unidirectionnelle.^[2]

FAQ

Pourquoi Fable 5.1 retourne-t-il un 400 pour ma requête de sortie structurée ?

Inspectez la requête Anthropic sérialisée. Un cadre peut implémenter la sortie structurée en forçant un outil synthétique avec tool_choice: any. Fable 5.1 rejette à la fois any et un choix d'outil nommé forcé. Passez à la sélection automatique d'outils plus un schéma strict et une instruction explicite, ou utilisez le mécanisme de sortie JSON d'Anthropic.

strict: true garantit-il que Claude appelle l'outil ?

Non. Il garantit les arguments conformes au schéma lorsque l'outil est appelé. L'instruction peut exiger un appel, mais votre application doit toujours confirmer que le bloc d'utilisation d'outils attendu existe et gérer son absence.

Fable 5.1 peut-il continuer une conversation Fable 5 ?

Oui. Fable 5.1 peut lire la réflexion préservée de Fable 5 et des autres modèles Claude antérieurs documentés. La direction inverse n'est pas compatible : la cible plus ancienne reçoit la conversation après la suppression des blocs de réflexion Fable 5.1.

Puis-je changer le message système entre les tours ?

Pas en réécrivant le préfixe en rejouant les blocs de réflexion Fable 5.1 ultérieurs. Ajoutez un message système mi-conversation et conservez-le dans l'historique. Si l'application démarre délibérément une nouvelle conversation, elle peut utiliser un nouveau message système puisqu'il n'y a pas d'anciens blocs de réflexion à préserver.

Quelle est la stratégie de compactage côté client la plus sûre ?

Remplacez tout l'historique antérieur par un message de résumé plus le nouveau tour utilisateur, et ne rejouez pas les anciens blocs de réflexion. Si vous conservez une queue récente, supprimez les blocs de réflexion et de réflexion rédactée de cette queue ou utilisez le comportement de suppression documenté.

La migration réduit-elle chaque facture API ?

Non. Les prix de la liste d'entrée et de sortie restent à 10 $ et 50 $ par million de jetons. Les lectures en cache sont moins chères, mais le coût de la tâche dépend aussi de la sortie, du nombre de tours, de l'effort, des nouvelles tentatives et du maintien de la validité du cache.^[5] La ventilation des coûts de Fable 5.1 traite ce calcul séparément.

Portail de publication : ne déployez pas tant que chaque ligne ne passe

Une réponse monoetour verte prouve seulement que l'ID du modèle et les identifiants fonctionnent. Une migration verte exerce la conversation après un appel d'outil, après un changement d'historique, et après le basculement qui n'exécute généralement que lorsque la production est déjà en stress.

References

1. Anthropic, Migration vers Claude Fable 5.1 et Claude Mythos 5.1, accessed September 7, 2026.
2. Anthropic, Aperçu de Claude Fable 5.1, accessed September 7, 2026.
3. Anthropic, Nouveautés de Claude Fable 5.1, accessed September 7, 2026.
4. Anthropic, Incitation de Claude Fable 5.1, accessed September 7, 2026.
5. Anthropic, Tarification de l'API, accessed September 7, 2026.
6. OpenCode, Issue #46735 : Erreur de sélection d'outils de sortie structurée de Claude Fable 5.1, accessed September 7, 2026. The issue is cited as an integration example; API behavior is sourced from Anthropic.