Claude Platform Docs
Modèles et tarifsClaude Fable 5.1

Migration vers Claude Fable 5.1 et Claude Mythos 5.1

Migrez vers Claude Fable 5.1 et Claude Mythos 5.1 depuis Claude Fable 5, Claude Mythos 5, Claude Opus 5 ou Claude Opus 4.8 : identifiants de modèle, changements incompatibles et listes de contrôle de migration.

Claude Fable 5.1 succède à Claude Fable 5 aux mêmes prix d'entrée et de sortie, avec des lectures de cache à un quart du coût. Il est disponible sur la Claude API, Amazon Bedrock, Claude Platform on AWS, Google Cloud et Microsoft Foundry. Claude Mythos 5.1 partage les mêmes capacités et n'est proposé qu'aux clients approuvés dans le cadre de Project Glasswing. Pour les différences de comportement et les modèles de prompts, consultez Prompting de Claude Fable 5.1.

Les paramètres de base partagés par claude-fable-5-1 et claude-mythos-5-1 :

  • Réflexion : l'« adaptive thinking » (réflexion adaptative) est toujours activée, sans changement par rapport à Claude Fable 5. Le modèle décide quand et combien réfléchir. Aucune configuration thinking n'est requise. thinking: {type: "disabled"} et la réflexion étendue manuelle (thinking: {type: "enabled", budget_tokens: N}) renvoient tous deux une erreur 400. Consultez Réflexion adaptative.
  • Préremplissage : le préremplissage du message de l'assistant renvoie une erreur 400, sans changement par rapport à Claude Fable 5. Utilisez plutôt des instructions dans l'invite système.
  • Choix d'outil : {type: "auto"} (la valeur par défaut) et {type: "none"} sont pris en charge. Forcer un appel d'outil avec {type: "any"} ou {type: "tool", name: "..."} renvoie une erreur 400. Consultez Changements incompatibles.
  • Réflexion préservée entre modèles : Claude Fable 5.1 lit les blocs de réflexion de Claude Opus 5, Claude Fable 5, Claude Mythos 5 et des modèles Claude antérieurs. Aucun de ces modèles ne peut lire les blocs de Claude Fable 5.1. Consultez Changements incompatibles.
  • Fenêtre de contexte et sortie : une « context window » (fenêtre de contexte) de 1M de tokens par défaut, et jusqu'à 128k tokens de sortie par requête.
  • Tarification : 10 $ USD par million de tokens d'entrée et 50 $ USD par million de tokens de sortie, comme pour Claude Fable 5. Les lectures du cache de prompts coûtent 0,25 $ USD par million de tokens, soit un quart du tarif de Claude Fable 5. Consultez Tarification de Claude.
  • Conservation des données : les deux modèles exigent une conservation des données de 30 jours, ne sont pas disponibles dans le cadre d'accords de « zero data retention » (conservation zéro des données), ou ZDR, sauf autorisation expresse d'Anthropic, et sont désignés comme Covered Models (modèles couverts), comme Claude Fable 5 et Claude Mythos 5. Sur la Claude API, une requête provenant d'une organisation ou d'un espace de travail sans conservation de 30 jours renvoie une erreur 400 invalid_request_error. Les organisations disposant d'un accord ZDR doivent contacter leur équipe de compte Anthropic, ou configurer la conservation par espace de travail. Consultez Exigences de conservation des données spécifiques aux modèles pour les détails par plateforme.

Là où les deux modèles divergent :

  • Disponibilité : Claude Fable 5.1 ne nécessite pas d'approbation d'accès. Claude Mythos 5.1 n'est disponible que pour les clients approuvés dans le cadre de Project Glasswing. Contactez votre équipe de compte Anthropic pour obtenir l'accès.
  • Classificateurs de sécurité : Claude Fable 5.1 exécute des classificateurs de sécurité couvrant les mêmes catégories stop_details que Claude Fable 5. Une requête refusée renvoie stop_reason: "refusal" avec un stop_details.category, et peut basculer vers un autre modèle avec le paramètre fallbacks ou une nouvelle tentative côté client. Consultez Refus et repli.
  • Priority Tier : aucun des deux modèles n'est pris en charge sur Priority Tier. Claude Fable 5 l'est.

Migration vers Claude Fable 5.1 depuis Claude Fable 5

La migration est en grande partie transparente. La surface de l'API, les limites, la tarification par token, le tokenizer, la réflexion adaptative toujours activée, la gestion des refus et les catégories stop_details correspondent tous à Claude Fable 5. Ce qui change : le choix d'outil forcé renvoie une erreur 400, les blocs de réflexion ne sont préservés que pour le modèle qui les a produits ou un modèle plus récent et uniquement dans la conversation qui les a produits, les lectures de cache coûtent moins cher, et le comportement en boucle d'agent diffère de trois manières. Les mêmes changements s'appliquent à Claude Mythos 5.1, à l'exception de la vérification de conversation sur les blocs de réflexion, que Claude Mythos 5.1 n'exécute pas.

Mettre à jour le nom de votre modèle

model = "claude-fable-5"  # Before
model = "claude-fable-5-1"  # After

# Ou, pour le modèle Project Glasswing avec les mêmes capacités :
model = "claude-mythos-5-1"  # After

Changements incompatibles

  1. Le choix d'outil forcé n'est pas pris en charge : Claude Fable 5 accepte les valeurs tool_choice auto, none, any et tool. Sur claude-fable-5-1, {type: "any"} et {type: "tool", name: "..."} renvoient une erreur 400 invalid_request_error :

    tool_choice: type "tool" and "any" are not supported for this model.

    La vérification s'applique sur l'API Messages, l'API Message Batches et le point de terminaison de comptage de tokens.

    Avant (Claude Fable 5) :

    client = anthropic.Anthropic()
    
    record_summary_tool = {
        "name": "record_summary",
        "description": "Record the structured summary of the document.",
        "input_schema": {
            "type": "object",
            "properties": {"summary": {"type": "string"}},
            "required": ["summary"],
        },
    }
    
    response = client.messages.create(
        model="claude-fable-5",
        max_tokens=16000,
        tools=[record_summary_tool],
        tool_choice={"type": "tool", "name": "record_summary"},
        messages=[{"role": "user", "content": "Summarize: The meeting moved to Thursday."}],
    )
    print(response.content)

    Après (Claude Fable 5.1) : laissez tool_choice sur auto, nommez l'outil dans l'instruction et définissez strict: true pour que l'appel corresponde à votre schéma. (Dans une organisation CMEK, où les sorties structurées, y compris strict: true, ne sont pas disponibles sur les modèles Claude Fable, appuyez-vous uniquement sur l'instruction.) Par exemple :

    client = anthropic.Anthropic()
    
    record_summary_tool = {
        "name": "record_summary",
        "description": "Record the structured summary of the document.",
        "strict": True,
        "input_schema": {
            "type": "object",
            "properties": {"summary": {"type": "string"}},
            "required": ["summary"],
            "additionalProperties": False,
        },
    }
    
    response = client.messages.create(
        model="claude-fable-5-1",
        max_tokens=16000,
        tools=[record_summary_tool],
        tool_choice={"type": "auto"},
        messages=[
            {
                "role": "user",
                "content": "Summarize: The meeting moved to Thursday. Call the record_summary tool with your result.",
            }
        ],
    )
    print(response.content)

    Consultez Utilisation d'outils stricte et Forcer l'utilisation d'outils. Si vous forciez un outil uniquement pour obtenir du JSON conforme à un schéma, utilisez plutôt les sorties JSON (output_config.format).

    Si votre application, plutôt que l'utilisateur, exige un appel d'outil spécifique au tour actuel d'une conversation multi-tours, ajoutez un message système en cours de conversation après le dernier tour user. Nommez l'outil, indiquez que l'appel est requis pour ce tour et demandez à Claude d'ouvrir sa réponse avec celui-ci. Comme le message est ajouté plutôt qu'écrit dans le prompt system de niveau supérieur, les tours précédents restent identiques à l'octet près et conservent leurs succès de cache de prompts :

    client = anthropic.Anthropic()
    
    search_help_center_tool = {
        "name": "search_help_center",
        "description": "Search the help center for policy and troubleshooting articles.",
        "strict": True,
        "input_schema": {
            "type": "object",
            "properties": {"query": {"type": "string"}},
            "required": ["query"],
            "additionalProperties": False,
        },
    }
    
    response = client.messages.create(
        model="claude-fable-5-1",
        max_tokens=16000,
        system="You are a customer support assistant for an online electronics store.",
        tools=[search_help_center_tool],
        messages=[
            {
                "role": "user",
                "content": "My headphones from order A1234 arrived yesterday.",
            },
            {
                "role": "assistant",
                "content": "Thanks for confirming. How can I help with order A1234?",
            },
            {"role": "user", "content": "I opened the box. Can I still return them?"},
            # L'application exige une recherche dans le centre d'aide avant toute
            # réponse sur les politiques. Ajouter l'exigence comme message système laisse
            # les tours précédents inchangés.
            {
                "role": "system",
                "content": "Tool-use requirement for the current turn: the application requires a call to the search_help_center tool in your response to the user's latest message. Begin your response with the search_help_center tool call. Do not reply with text only.",
            },
        ],
    )
    print(response.content)

    Conservez le message role: "system" dans l'historique lors des requêtes ultérieures, comme pour tout autre tour. Les messages système en cours de conversation ne nécessitent aucun en-tête bêta. tool_choice: {"type": "none"} fonctionne toujours pour un tour qui ne doit pas appeler d'outils.

  2. Les blocs de réflexion ne sont préservés que pour le modèle qui les a produits, ou un modèle plus récent : chaque bloc thinking enregistre le modèle qui l'a produit. Claude Fable 5.1 lit ses propres blocs et ceux de Claude Mythos 5.1, Claude Opus 5, Claude Fable 5, Claude Mythos 5 et des modèles Claude antérieurs. Une conversation passant sur claude-fable-5-1 depuis l'un de ces modèles conserve son raisonnement antérieur. La condition est unidirectionnelle : à l'exception de Claude Mythos 5.1, aucun de ces modèles ne peut lire les blocs de Claude Fable 5.1.

    Une conversation qui s'est déroulée sur Claude Fable 5.1 peut aboutir sur un modèle plus ancien via un changement de routeur, une nouvelle tentative côté client ou un repli sur refus de classificateur, y compris un repli côté serveur. L'API supprime les blocs que ce modèle ne peut pas lire avant qu'il ne les voie, la requête réussit et les tokens d'entrée supprimés ne vous sont pas facturés. Le modèle cible replanifie sans ce raisonnement, ce qui peut augmenter le coût et la latence au premier tour après le changement. Pour voir ce qui a été supprimé, envoyez l'en-tête bêta thinking-binding-controls-2026-08-01 : les réponses contiennent alors un tableau input_transformations nommant chaque bloc supprimé avec reason: "model_binding_mismatch". Consultez Réflexion préservée.

  3. La modification des tours précédents invalide les blocs de réflexion : chaque bloc thinking de Claude Fable 5.1 n'est valide que par rapport au prompt system, aux tools et à l'historique de conversation qui l'ont précédé. Si Claude Code, claude.ai, Claude Managed Agents ou le Claude Agent SDK gère votre historique de conversation, il conserve déjà ce préfixe intact. Si votre code construit lui-même le tableau messages, ce point vous concerne, et Réflexion préservée constitue le guide d'intégration complet. Là où la vérification est appliquée, une requête qui renvoie le bloc après que l'un de ces éléments a changé est rejetée avec une erreur 400 :

    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.

    L'API applique la vérification pour les nouveaux comptes créés à partir du 31 août 2026. Pour les comptes créés antérieurement, l'API enregistre la non-correspondance mais n'agit pas en conséquence, sauf si la requête définit thinking.block_binding.prefix_mismatch_behavior, ce qui active l'application. Anthropic prévoit d'appliquer la vérification à tous les comptes sur les futurs modèles, alors rendez votre application compatible dès maintenant : les mêmes modèles maintiennent le cache de prompts chaud, et vous pouvez tester la vérification depuis n'importe quel compte en envoyant prefix_mismatch_behavior. Si vous distribuez un outil ou un framework que les gens exécutent avec leur propre clé API, testez de cette manière avant le lancement : votre clé se trouve probablement sur un compte plus ancien, et vos utilisateurs sur de nouveaux comptes rencontreront la vérification avant vous. Pour savoir si votre propre compte est soumis à l'application par défaut, envoyez une requête qui modifie l'historique sans l'en-tête bêta : une erreur 400 qui nomme l'en-tête signifie que c'est le cas.

    L'erreur est permanente pour ce corps de requête : une boucle de nouvelles tentatives automatiques ne la résoudra pas. Pour continuer sans le raisonnement invalidé au lieu d'échouer, retirez les blocs thinking de l'historique et réessayez une fois, ou envoyez l'en-tête bêta thinking-binding-controls-2026-08-01 et définissez prefix_mismatch_behavior sur "drop_block" (la valeur par défaut est "error"). Avec "drop_block", l'API supprime le bloc non correspondant et tous les blocs de réflexion qui le suivent dans la conversation, et signale chacun avec reason: "prefix_binding_mismatch" dans le tableau input_transformations de la réponse :

    client = anthropic.Anthropic()
    
    response = client.beta.messages.create(
        model="claude-fable-5-1",
        max_tokens=16000,
        thinking={
            "type": "adaptive",
            "block_binding": {"prefix_mismatch_behavior": "drop_block"},
        },
        messages=[
            {
                "role": "user",
                "content": "What is the greatest common divisor of 1071 and 462?",
            }
        ],
        betas=["thinking-binding-controls-2026-08-01"],
    )
    
    for block in response.content:
        if block.type == "text":
            print(block.text)
    
    print(f"Input transformations: {len(response.input_transformations or [])}")

    Le point de terminaison de comptage de tokens exécute la même vérification. Consultez Contrôles pour les blocs qui ne sont pas préservés (bêta) pour la forme de la réponse et le placement en streaming.

    Modèles qui invalident les blocs de réflexion ultérieurs, et ce qu'il faut faire à la place :

    • Modifier, réordonner ou supprimer des tours précédents. Cela inclut la suppression d'anciens résultats d'outils, le retrait de tours au milieu de la transcription, et la compaction côté client qui conserve les tours récents et leurs blocs de réflexion tels quels derrière un résumé (y compris la compaction en arrière-plan qui insère son résumé quelques tours plus tard). Utilisez plutôt la compaction côté serveur ou l'édition de contexte (l'effacement des résultats d'outils pour les anciens résultats d'outils), ou l'une des formes de compaction côté client décrites dans Réduire le contexte sur le serveur.
    • Injecter du contenu que vous ne conservez pas, par exemple un rappel par tour ajouté après les blocs tool_result et retiré à la requête suivante. Envoyez plutôt le rappel sous forme de message système limité au tour et laissez-le dans l'historique.
    • Reconstruire le prompt system de niveau supérieur ou le tableau tools entre les requêtes d'une même conversation, par exemple pour mettre à jour la date actuelle ou pour ajouter ou retirer un outil. Ajoutez plutôt un message système en cours de conversation qui porte la nouvelle instruction (« The current date is 2026-09-14. ») ou des blocs tool_addition et tool_removal.
    • Une URL d'image ou de document qui sert des octets différents lors d'une requête ultérieure. La vérification porte sur les octets, pas sur la chaîne de l'URL, donc une URL signée rotative pour le même fichier convient. Pour le contenu que vous référencez sur plusieurs tours, téléversez-le une fois avec l'API Files et envoyez le file_id, ou envoyez du base64.

    Chaque remplacement maintient également les tours précédents identiques à l'octet près et préserve les succès de cache de prompts que la modification de l'historique, du prompt system ou du tableau tools ferait perdre.

    Modèles qui continuent de fonctionner :

    • Historiques en ajout seul : ajouter des tours et renvoyer les tours précédents exactement tels qu'envoyés et reçus, y compris les messages role: "system" ajoutés.
    • Retirer les blocs de réflexion des tours d'assistant précédents, les plus anciens en premier.
    • Modifier effort, max_tokens ou tout autre paramètre de requête en dehors de system, tools et messages, et ajouter ou déplacer des marqueurs cache_control.
    • La compaction côté serveur et l'édition de contexte, y compris l'effacement des blocs de réflexion. Elles ne comptent pas comme des modifications, car la vérification compare la conversation telle que vous l'avez envoyée.

    Pour vérifier une intégration existante :

    1. Capturez les corps de requête exacts qu'elle envoie sur quelques tours normaux, y compris une compaction ou un changement d'outil si votre produit en comporte. Pour chaque paire de requêtes consécutives, comparez le prompt system, le tableau tools et le préfixe partagé de messages. Ils doivent être identiques à l'octet près jusqu'aux tours nouvellement ajoutés.
    2. Exécutez une session multi-tours normale sur claude-fable-5-1 avec l'en-tête bêta thinking-binding-controls-2026-08-01 et prefix_mismatch_behavior: "drop_block", et journalisez input_transformations sur chaque réponse. Un tableau vide à chaque tour signifie que l'historique est intact. Une entrée avec reason: "prefix_binding_mismatch" signifie que quelque chose avant le bloc situé à path a changé depuis la requête précédente. Une entrée avec reason: "model_binding_mismatch" signifie que la conversation a changé de modèle, ce qui n'est pas un bogue dans votre code. Cela fonctionne depuis n'importe quel compte, car définir le champ active l'application pour la requête. En CI, définissez plutôt "error" afin qu'une modification fasse échouer l'exécution.
    3. Choisissez un paramètre de production. Laissez la valeur par défaut "error" si une non-correspondance de préfixe ne peut signifier qu'un bogue dans votre code, ou définissez "drop_block" pour supprimer les blocs concernés au lieu d'échouer, et surveillez les erreurs 400 ou les entrées input_transformations dans les deux cas.

    Supprimer les blocs de réflexion une seule fois, à une frontière de compaction par exemple, a peu d'effet. Une intégration qui invalide la réflexion antérieure à chaque requête redémarre le cache de prompts à chaque fois, ce qui peut augmenter le coût par tâche (consultez Conserver l'historique de conversation en ajout seul).

Changements de comportement

  1. Moins d'appels d'outils parallèles dans les longues boucles d'agent : dans les boucles de longue durée où les prochaines lectures indépendantes ne sont qu'implicites dans la tâche (agents de codage personnalisés, harnais bash-et-éditeur, utilisation de l'ordinateur), Claude Fable 5.1 peut émettre un seul appel d'outil par tour. Chaque tour supplémentaire coûte des tokens, un aller-retour et du temps réel. Ajoutez une instruction de regroupement d'une phrase après chaque message utilisateur sous forme de message système limité au tour (clear_at: "next_user_message", bêta), ou, sans la bêta, dans un bloc de texte après les blocs tool_result, et laissez les copies précédentes dans l'historique lors des requêtes ultérieures. Consultez Regrouper les appels d'outils indépendants dans les boucles d'agent.

  2. Moins de messages de progression entre les appels d'outils : Claude Fable 5.1 écrit moins de mises à jour d'état pendant les longues séquences d'outils que Claude Fable 5, et ses résumés de codage agentique sont plus courts. Si votre interface affiche ces mises à jour, définissez thinking.display sur "updates" (bêta, Claude API) ou "summarized" et demandez-les explicitement dans le prompt. Consultez Mises à jour de progression entre les appels d'outils et Demander des mises à jour de progression destinées à l'utilisateur.

  3. Moins d'appels de recherche et de récupération à faible effort : à l'effort low, Claude Fable 5.1 répond de mémoire plus souvent que Claude Fable 5 au lieu d'appeler un outil de recherche ou de récupération. Si votre produit repose sur la récupération à faible effort, augmentez l'effort pour ces requêtes ou indiquez au modèle quand effectuer une recherche. Consultez Déclenchement de la recherche à faible effort.

Pour les différences de densité de prose, de formatage en chat, de citation dans les résumés et de modifications de fichiers, qui n'affectent pas l'intégration de l'API, consultez Changements par rapport à Claude Fable 5.

Ces changements ne sont pas obligatoires, mais chacun réduit le coût ou la latence, ou élimine un mode de défaillance :

  1. Modifier l'effort en cours de conversation (bêta) : sur Claude Fable 5, output_config.effort est défini au niveau de la requête, et le modifier entre les requêtes fait perdre les préfixes mis en cache des tours précédents. Sur claude-fable-5-1, un message role: "system" ne portant que output_config augmente l'effort pour une étape difficile ou le réduit pour les étapes routinières sans invalider le cache de prompts :

    client = anthropic.Anthropic()
    
    response = client.beta.messages.create(
        model="claude-fable-5-1",
        max_tokens=4096,
        output_config={"effort": "high"},
        messages=[
            {
                "role": "user",
                "content": "Plan a migration from SQLite to PostgreSQL in three short steps.",
            },
            {
                "role": "assistant",
                "content": "1. Export the SQLite data. 2. Create the PostgreSQL schema. 3. Import the data and verify row counts.",
            },
            # Message système d'effort uniquement : le nouveau niveau prend effet au prochain tour utilisateur.
            {"role": "system", "content": [], "output_config": {"effort": "low"}},
            {"role": "user", "content": "Summarize the plan in one sentence."},
        ],
        betas=["mid-conversation-output-config-2026-07-01"],
    )
    
    for block in response.content:
        if block.type == "text":
            print(block.text)

    La valeur s'applique au tour utilisateur suivant et à chaque tour ultérieur jusqu'à ce qu'un autre message role: "system" la modifie. Seuls les niveaux nommés sont acceptés (low, medium, high, xhigh, max), et l'en-tête bêta mid-conversation-output-config-2026-07-01 est requis. Consultez Effort par message.

  2. Modifier les instructions et les outils avec des messages système en cours de conversation : pour modifier les instructions ou les outils au cours d'une session, ajoutez un message role: "system", avec des blocs tool_addition et tool_removal pour les changements d'outils (en-tête bêta mid-conversation-tool-changes-2026-07-01, avec l'ensemble complet des outils déclaré dans tools au début de la session). Cela préserve les succès de cache de prompts sur les tours précédents et maintient l'historique de conversation en ajout seul. Le même message remplace le tool_choice forcé lorsqu'un outil spécifique doit s'exécuter au tour actuel (consultez Changements incompatibles). Pour un rappel qui ne s'applique qu'à un seul tour, envoyez-le sous forme de message role: "system" distinct contenant uniquement du texte avec clear_at: "next_user_message" (messages système limités au tour, en-tête bêta mid-conversation-system-clear-at-2026-08-21) et laissez-le dans l'historique : il cesse d'être rendu après le message utilisateur suivant et ne coûte aucun token une fois effacé. Un message qui porte des blocs tool_addition ou tool_removal ne peut pas être limité au tour.

  3. Utiliser fallbacks: "default" pour les refus : continuez à gérer stop_reason: "refusal" et à lire stop_details.category avant le contenu de la réponse. Pour réexécuter automatiquement les requêtes refusées sur un autre modèle, définissez fallbacks: "default" (bêta, en-tête server-side-fallback-2026-07-01). "default" relance une requête refusée sur le modèle qu'Anthropic recommande pour cette catégorie. Les cibles de repli autorisées pour Claude Fable 5.1 sont Claude Opus 4.8 (claude-opus-4-8) et Claude Opus 5 (claude-opus-5). Une liste fallbacks explicite peut nommer l'un ou l'autre. Le modèle de repli ne reçoit pas les blocs de réflexion de Claude Fable 5.1. Si vous construisez vous-même la nouvelle tentative, le crédit de repli s'applique dans les mêmes conditions que pour Claude Fable 5. Consultez Refus et repli.

  4. Commencer à l'effort high et balayer : la valeur par défaut du paramètre effort est high, et les cinq niveaux sont pris en charge. Conservez les recommandations de Claude Fable 5 : high pour la plupart des travaux, et medium comme contrôle des coûts qui mérite d'être testé. Les gains de Claude Fable 5.1 par rapport à Claude Fable 5 sont les plus importants à xhigh et max, mais ces niveaux ajoutent également du temps de réflexion et du temps avant la première réponse, alors passez à ces niveaux pour les tâches les plus sensibles aux capacités et là où vos évaluations montrent le gain. Effectuez un nouveau balayage sur vos propres évaluations plutôt que de reprendre un réglage ajusté pour Claude Fable 5. Consultez Niveaux d'effort recommandés pour Claude Fable 5.1.

  5. Réduire le contexte sur le serveur, ou compacter sous une forme qui ne transporte aucune réflexion obsolète : si votre code tronque ou résume les tours plus anciens côté client, la solution la plus simple consiste à déplacer ce travail vers la compaction côté serveur ou l'édition de contexte. Aucune des deux ne compte comme une modification, car la vérification de l'historique compare la conversation telle que vous l'avez envoyée, donc rien de ce qu'elles retirent n'invalide les blocs de réflexion ultérieurs, et le paramètre instructions de la compaction accepte votre propre prompt de résumé. Si vous conservez la compaction côté client, choisissez l'une des trois formes suivantes :

    • Compaction simple (recommandée) : remplacez l'historique entier par un seul message de résumé plus le nouveau tour utilisateur et ne rejouez rien d'autre. Aucun bloc de réflexion n'est reporté, donc rien n'échoue. Les modèles Claude sont entraînés sur des tâches à long horizon avec ce schéma, et il offre des performances comparables à des schémas plus élaborés pour la plupart des charges de travail.
    • Compaction avec conservation de la fin : si vous conservez les tours les plus récents tels quels derrière un résumé, retirez les blocs thinking et redacted_thinking de ces tours (le texte et les appels d'outils peuvent rester), ou définissez prefix_mismatch_behavior: "drop_block". Leur réflexion a été produite par rapport à l'historique complet et échoue derrière le résumé dans le cas contraire.
    • Compaction en arrière-plan : si vous construisez le résumé hors du chemin critique et l'insérez plus tard, chaque tour produit entre-temps porte une réflexion antérieure à l'insertion. Envoyez "drop_block" sur chaque requête qui porte encore des blocs de réflexion produits avant l'insertion (ou retirez ces blocs vous-même ; input_transformations sur la première réponse après l'insertion liste exactement lesquels), ou compactez de manière synchrone.

    Ne retirez pas de tours individuels au milieu de la transcription : cela invalide tous les blocs de réflexion ultérieurs 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 effectuiez, ou l'édition de contexte côté serveur pour une suppression sélective. Consultez Renvoyer les blocs de compaction.

Liste de contrôle de migration

  • Mettez à jour le nom du modèle de claude-fable-5 vers claude-fable-5-1 (ou de claude-mythos-5 vers claude-mythos-5-1).
  • Remplacez le tool_choice forcé ({type: "any"} ou {type: "tool", ...}). Il renvoie une erreur 400. Utilisez {type: "auto"} accompagné d'une instruction explicite et d'outils strict: true, ou des sorties JSON. Placez l'instruction dans le tour user, ou dans un message role: "system" en milieu de conversation lorsque votre application exige l'appel.
  • Continuez à renvoyer les blocs thinking inchangés à chaque tour, y compris les blocs vides. Claude Fable 5.1 lit les blocs de Claude Opus 5, Claude Fable 5, Claude Mythos 5 et des modèles antérieurs. Déplacer une conversation de Claude Fable 5.1 vers un modèle antérieur supprime ses blocs (Claude Mythos 5.1 les lit).
  • Si votre code construit lui-même le tableau messages, vérifiez s'il modifie des tours antérieurs : exécutez une session avec l'en-tête bêta thinking-binding-controls-2026-08-01 et prefix_mismatch_behavior: "drop_block", journalisez input_transformations et corrigez chaque prefix_binding_mismatch. Les entrées model_binding_mismatch après un changement de modèle sont attendues.
  • Conservez un historique de conversation en ajout seul (append-only) : figez system et tools au début de la session et déplacez les modifications en cours de session vers des messages role: "system" et des blocs tool_addition / tool_removal, envoyez les rappels par tour sous forme de messages système limités au tour que vous ne supprimez jamais, réduisez le contexte côté serveur ou retirez les blocs de réflexion de tous les tours que vous conservez à travers un résumé côté client, et référencez les fichiers utilisés sur plusieurs tours par file_id.
  • Choisissez un prefix_mismatch_behavior de production ("error" par défaut, ou "drop_block") et surveillez-le. Si vous maintenez un outil que d'autres exécutent avec leur propre clé API, testez avec le champ défini : les nouveaux comptes sont soumis à l'application par défaut même si le vôtre ne l'est pas.
  • Examinez les boucles d'agent pour détecter un comportement d'un seul appel d'outil par tour et ajoutez l'instruction de regroupement (batching).
  • Si votre interface affiche du texte de progression entre les appels d'outils, définissez thinking.display sur "updates" (bêta) ou "summarized" et demandez des mises à jour dans le prompt.
  • Si vous modifiez l'effort entre les requêtes, déplacez la modification vers un message role: "system" d'effort par message (bêta) afin de conserver les succès de cache.
  • Gérez stop_reason: "refusal" et lisez stop_details.category. Envisagez fallbacks: "default" (bêta).
  • Réévaluez effort avec un nouveau balayage, en commençant à high, et réétablissez une référence de coût et de latence sur vos propres charges de travail. Les nombres de tokens sont à peu près inchangés. Les lectures du cache de prompts coûtent un quart du tarif de Claude Fable 5.

Migration vers Claude Fable 5.1 depuis Claude Opus 5

Claude Fable 5.1 utilise les mêmes modèles d'API Messages et d'utilisation d'outils que Claude Opus 5. Il conserve par défaut la fenêtre de contexte de 1M de tokens, les 128k tokens de sortie maximum, le minimum de 512 tokens pour la mise en cache des prompts et la prise en charge des messages système en milieu de conversation. La restriction sur le préremplissage, la restriction sur les paramètres d'échantillonnage et la valeur par défaut "omitted" pour thinking.display sont également conservées. Appliquez tout ce qui figure dans Migration vers Claude Fable 5.1 depuis Claude Fable 5, plus ce qui suit.

Mettez à jour le nom de votre modèle

model = "claude-opus-5"  # Before
model = "claude-fable-5-1"  # After

# Ou, pour le modèle Project Glasswing avec les mêmes capacités :
model = "claude-mythos-5-1"  # After

Ce qui a changé

  1. La réflexion ne peut plus être désactivée : Claude Opus 5 accepte thinking: {type: "disabled"} à un niveau d'effort de high ou inférieur. Sur claude-fable-5-1 et claude-mythos-5-1, la réflexion adaptative est toujours activée, et thinking: {type: "disabled"} renvoie une erreur 400 à n'importe quel niveau d'effort. Supprimez le champ, contrôlez la dépense de tokens avec des niveaux d'effort inférieurs et réexaminez max_tokens pour les charges de travail qui s'exécutaient avec la réflexion désactivée.

  2. Le choix d'outil forcé n'est pas pris en charge : Claude Opus 5 accepte tool_choice any et tool. claude-fable-5-1 renvoie une erreur 400. Consultez Changements incompatibles.

  3. Réflexion préservée entre les modèles : Claude Fable 5.1 lit les blocs de réflexion de Claude Opus 5 : les conversations passant de claude-opus-5 à claude-fable-5-1 conservent leur raisonnement. Claude Opus 5 ne peut pas lire les blocs de Claude Fable 5.1. Les blocs de Claude Fable 5.1 cessent également d'être valides lorsque des tours antérieurs changent : si votre code modifie des messages antérieurs, reconstruit system ou tools, ou compacte côté client entre les requêtes, Claude Opus 5 ne s'y opposait pas, mais claude-fable-5-1 rejette ou supprime chaque bloc de réflexion ultérieur. Exécutez la vérification en trois étapes de cette section avant de basculer le trafic. Consultez Changements incompatibles.

  4. Le texte entre les appels d'outils est renvoyé dans des blocs de réflexion : Sur Claude Opus 5, le texte que le modèle écrit entre les appels d'outils revient sous forme de blocs text. Sur claude-fable-5-1, comme sur Claude Fable 5, cette narration revient sous forme de blocs thinking de mise à jour de progression, un avant chaque appel d'outil. Avec la valeur par défaut "omitted" de thinking.display, ils ne contiennent aucun texte lisible. Si votre interface affiche cette narration, définissez display: "updates" (bêta, Claude API) pour recevoir les mises à jour de progression sous forme de texte tandis que le raisonnement reste masqué, ou "summarized" pour recevoir les deux. Affichez ensuite les blocs thinking non vides entre les blocs tool_use. Consultez Mises à jour de progression entre les appels d'outils.

  5. Classificateurs de sécurité et routage de repli : Claude Fable 5.1 exécute des classificateurs de sécurité couvrant les mêmes catégories stop_details que Claude Fable 5, un ensemble plus large que les classificateurs de Claude Opus 5 limités à la cybersécurité. Attendez-vous à des valeurs stop_details.category au-delà de "cyber", telles que "bio" et "reasoning_extraction" ; consultez le tableau des catégories de refus pour l'ensemble complet. Pour la configuration de fallbacks et les cibles autorisées, consultez Utiliser fallbacks: "default" pour les refus.

  6. Tarification : 10 $ USD par million de tokens d'entrée et 50 $ USD par million de tokens de sortie, contre 5 $ USD et 25 $ USD pour Claude Opus 5. Les lectures du cache de prompts coûtent 0,25 $ USD par million de tokens, soit la moitié du tarif de Claude Opus 5. Consultez Tarification de Claude.

  7. Conservation des données : Claude Fable 5.1 et Claude Mythos 5.1 exigent une conservation des données de 30 jours, ne sont pas disponibles dans le cadre d'accords de « zero data retention » (conservation zéro des données), ou ZDR, sauf autorisation expresse d'Anthropic, et sont désignés comme Modèles Couverts. Claude Opus 5 est disponible sous ZDR. Consultez Exigences de conservation des données spécifiques aux modèles.

Liste de contrôle de migration

  • Si votre organisation dispose d'un accord de conservation zéro des données (ZDR), confirmez d'abord votre éligibilité : ces modèles ne sont pas disponibles sous ZDR sauf autorisation expresse d'Anthropic. Consultez Exigences de conservation des données spécifiques aux modèles.
  • Mettez à jour le nom du modèle de claude-opus-5 vers claude-fable-5-1 (ou claude-mythos-5-1).
  • Supprimez toute configuration thinking: {type: "disabled"} : elle renvoie une erreur 400 sur claude-fable-5-1. Contrôlez la dépense de tokens avec des niveaux d'effort inférieurs et réexaminez max_tokens.
  • Remplacez le tool_choice forcé (any ou tool) par auto accompagné d'une instruction explicite (tour user ou message système en milieu de conversation) et d'outils strict: true, ou par des sorties JSON.
  • Si votre interface affiche du texte entre les appels d'outils, définissez display: "updates" (bêta) ou "summarized" et affichez les blocs thinking non vides.
  • Appliquez les éléments relatifs à la réflexion préservée, à la modification de l'historique, au comportement, à l'effort et au repli de la liste de contrôle Claude Fable 5.
  • Réétablissez une référence de coût sur vos propres charges de travail. Les nombres de tokens sont à peu près inchangés. La tarification par token diffère.

Migration vers Claude Fable 5.1 depuis Claude Opus 4.8 ou antérieur

Appliquez d'abord Migration vers Claude Mythos 5 et Claude Fable 5 depuis Claude Opus 4.8 pour les changements au niveau de l'API depuis Claude Opus 4.8. Cette section couvre la réflexion adaptative, la sortie de réflexion, les refus, l'effort, le minimum de mise en cache, la tarification et la conservation des données. Appliquez ensuite le delta restant dans Migration vers Claude Fable 5.1 depuis Claude Fable 5. Sur Claude Opus 4.7 ou antérieur, commencez par la section correspondante de Migration vers Claude Opus 5.

Mettez à jour le nom de votre modèle

model = "claude-opus-4-8"  # Before
model = "claude-fable-5-1"  # After

# Ou, pour le modèle Project Glasswing avec les mêmes capacités :
model = "claude-mythos-5-1"  # After

Liste de contrôle de migration

  • Si votre organisation dispose d'un accord de conservation zéro des données (ZDR), confirmez d'abord votre éligibilité : ces modèles ne sont pas disponibles sous ZDR sauf autorisation expresse d'Anthropic. Claude Opus 4.8 est disponible sous ZDR.
  • Mettez à jour le nom du modèle de claude-opus-4-8 vers claude-fable-5-1 (ou claude-mythos-5-1).
  • Supprimez toute configuration thinking: {type: "disabled"} et réexaminez max_tokens. Les requêtes sans champ thinking s'exécutent avec la réflexion adaptative.
  • Remplacez le tool_choice forcé (any ou tool) par auto accompagné d'une instruction explicite (tour user ou message système en milieu de conversation) et d'outils strict: true, ou par des sorties JSON.
  • Renvoyez les blocs thinking inchangés et traitez leur texte comme destiné uniquement à l'affichage. Claude Fable 5.1 lit les blocs de réflexion de Claude Opus 4.8 : une conversation qui passe sur claude-fable-5-1 conserve son raisonnement antérieur. Claude Opus 4.8 ne peut pas lire les blocs de Claude Fable 5.1.
  • Si votre code construit lui-même le tableau messages, vérifiez s'il modifie des tours antérieurs. Les intégrations écrites pour Claude Opus 4.8 et antérieur tronquent souvent les anciens tours, retirent ou reconstruisent des messages antérieurs, ou actualisent le prompt system à chaque requête, et Claude Opus 4.8 ne s'y est jamais opposé. Sur claude-fable-5-1, chacune de ces opérations invalide les blocs de réflexion ultérieurs.
  • Gérez stop_reason: "refusal", lisez stop_details.category et envisagez fallbacks: "default" (bêta).
  • Appliquez les éléments relatifs à la réflexion préservée, à la modification de l'historique, au comportement, à l'effort par message et aux mises à jour de progression de la liste de contrôle Claude Fable 5.
  • Réévaluez effort (commencez à high), examinez les prompts proches du minimum de mise en cache de 512 tokens et réétablissez une référence de coût et de latence. La tarification par token diffère.

Migration vers Claude Mythos 5.1 depuis Claude Mythos 5

Claude Mythos 5.1 est l'équivalent à accès restreint de Claude Fable 5.1. Confirmez l'accès de votre organisation auprès de votre équipe de compte Anthropic avant de changer d'identifiants de modèle.

Le delta au niveau de l'API correspond à Migration vers Claude Fable 5.1 depuis Claude Fable 5 : le choix d'outil forcé renvoie une erreur 400, et les blocs de réflexion ne sont préservés que pour le modèle qui les a produits ou un modèle plus récent (Claude Mythos 5.1 lit les blocs de Claude Mythos 5, et non l'inverse). Contrairement à Claude Fable 5.1, Claude Mythos 5.1 n'exécute pas la vérification de conversation, de sorte que la modification de tours antérieurs n'invalide pas les blocs de réflexion, bien qu'elle redémarre tout de même le cache de prompts.

Mettez à jour le nom de votre modèle

model = "claude-mythos-5"  # Before
model = "claude-mythos-5-1"  # After

Liste de contrôle de migration

  • Mettez à jour le nom du modèle de claude-mythos-5 vers claude-mythos-5-1.
  • Remplacez le tool_choice forcé (any ou tool) par auto accompagné d'une instruction explicite (tour user ou message système en milieu de conversation) et d'outils strict: true, ou par des sorties JSON.
  • Gérez stop_reason: "refusal" et lisez stop_details.category avant le contenu de la réponse. Consultez Refus et repli.
  • Continuez à renvoyer les blocs thinking inchangés à chaque tour, y compris les blocs vides.
  • Si votre code construit lui-même le tableau messages, conservez un historique de conversation en ajout seul afin de garder le cache de prompts chaud. Claude Mythos 5.1 n'exécute pas la vérification de conversation, de sorte que les modifications n'invalident pas ses blocs de réflexion.
  • Appliquez les changements de comportement et les changements recommandés de la section Claude Fable 5, à l'exception des éléments relatifs à la modification de l'historique, qui ne s'appliquent pas à Claude Mythos 5.1.
  • Réévaluez effort avec un nouveau balayage et réétablissez une référence de coût et de latence. Les lectures du cache de prompts coûtent un quart du tarif de Claude Mythos 5.

Was this page helpful?