Anthropic affirme que vos invites Fable 5 existantes devraient bien fonctionner sur Claude Fable 5.1 sans modifications. C'est vrai pour les réponses. C'est moins vrai pour tout ce qui les entoure : le nombre d'appels d'outils que le modèle regroupe par tour, la quantité de narration, la densité de sa prose, la façon dont il formate le chat, s'il réécrit un fichier entier pour modifier une seule ligne, et s'il s'arrête pour demander la permission pour un travail que vous avez déjà demandé. Chacun de ces points a changé entre Fable 5 et Fable 5.1, et chacun a une solution spécifique dans le guide de prompt engineering pour Claude Fable 5.1 d'Anthropic.
Ce guide rassemble chaque modification avec sa solution, citant les extraits officiels où la formulation exacte est importante, ainsi que la règle de placement qui compte plus sur ce modèle que sur tout autre précédent : l'endroit où vous placez une instruction par tour détermine désormais si elle invalide vos blocs de réflexion et redémarre votre cache. Pour un aperçu du modèle, consultez ce qu'est Claude Fable 5.1.
Commencez par l'effort, pas par les prompts
L'Effort est le principal levier pour équilibrer l'intelligence, la latence et le coût sur Fable 5.1, et il doit être ajusté avant toute modification de prompt. Commencez par la valeur par défaut, high, puis testez les quatre autres niveaux avec vos propres évaluations. Refaites le balayage même si vous en avez fait un sur Fable 5 : les noms de niveaux ne correspondent pas à la même quantité de réflexion d'un modèle à l'autre.

Les affirmations d'Anthropic à tester : à medium, les résultats correspondent à peu près à Fable 5 à un coût inférieur ; à low, Fable 5.1 est souvent compétitif avec Opus et Sonnet en termes de coût par tâche tout en obtenant des scores plus élevés ; les gains par rapport à Fable 5 sont les plus importants à xhigh et max. Sur Fable 5.1, vous pouvez modifier l'effort en cours de conversation sans réinitialisation du cache, en utilisant un message `role: "system"` au contenu vide avec `output_config` (en-tête bêta `mid-conversation-output-config-2026-07-01`). Le guide pas à pas de l'API montre la forme de la requête.
Le placement compte plus que la formulation
Les blocs de réflexion de Fable 5.1 ne sont valides que dans la conversation exacte qui les a produits (pensée préservée). Injecter un rappel dans un tour précédent et le supprimer lors de la requête suivante est une modification de l'historique : cela redémarre le cache de prompt et, sur les comptes créés le ou après le 31 août 2026, invalide chaque bloc de réflexion ultérieur.
Les instructions par tour vont donc à l'un des deux endroits. Avec la version bêta `mid-conversation-system-clear-at-2026-08-21`, ajoutez-les comme message système à portée de tour : `{"role": "system", "clear_at": "next_user_message", "content": "..."}` après le message de résultat d'outil, et laissez toutes les copies précédentes dans le tableau. Une fois qu'un message utilisateur ultérieur existe, l'API efface les copies précédentes, de sorte que le modèle ne lit que la plus récente, et les copies effacées ne coûtent pas de tokens. Sans la version bêta, placez la phrase dans un bloc de texte après les blocs `tool_result` dans le même message utilisateur, en conservant les copies précédentes. Ne jamais supprimer ou réécrire une copie déjà envoyée. Le guide de la pensée préservée explique pourquoi.
Les instructions de niveau session vont dans le prompt système ou le premier tour utilisateur. Anthropic note que les instructions de style dans le premier tour utilisateur sont mieux retenues que le même texte dans le prompt système.
Un appel d'outil par tour dans les boucles d'agent
Le changement. Lorsqu'une requête nomme plusieurs éléments à récupérer, Fable 5.1 émet les appels en parallèle. Dans les boucles de codage et d'utilisation informatique où les prochaines lectures indépendantes ne sont qu'implicites, il peut en émettre une par tour là où Fable 5 en regroupait plusieurs. Les réponses ne sont pas affectées ; chaque tour supplémentaire coûte des tokens, un aller-retour et du temps réel.
Mesurez d'abord. Suivez la proportion de tours d'assistant avec plus d'un appel d'outil, et n'ajoutez la solution que si cette proportion a diminué. La solution, ajoutée après chaque message de résultat d'outil comme message système à portée de tour :
First privately list what you need next; then request every item that doesn't depend on another's result in this one response.
Gardez le mot « privately ». Sans lui, le modèle répond parfois au rappel au lieu de l'utilisateur. Une phrase près de la fin de la requête actuelle fait bouger le chiffre bien plus que le même texte dans le prompt système.
Peu ou pas de texte entre les appels d'outils
Le changement. Fable 5.1 écrit moins de mises à jour visibles par l'utilisateur pendant les longs tours d'appel d'outils que Fable 5, d'autant plus à un effort plus élevé. Les utilisateurs voient l'agent rester silencieux pendant des minutes, ou un message final qui ne couvre que la dernière étape.
Trois solutions, dans l'ordre. Premièrement, vérifiez que vous recevez des mises à jour de progression : les notes inter-outils du modèle reviennent sous forme de blocs `thinking` qui sont vides sous la valeur par défaut `display: "omitted"`. Définissez `display: "updates"` (en-tête bêta `thinking-display-updates-2026-08-18`) et affichez chaque bloc de réflexion non vide comme une ligne de statut. Deuxièmement, supprimez les lignes de prompt écrites pour les anciens modèles avides de mises à jour, telles que « conservez toutes les découvertes pour la réponse finale ». Troisièmement, si vous en voulez plus, ajoutez une ligne au prompt système :
Before you start, say in a line what you're about to do; brief updates while you work help the user follow along. Close with a short recap that stands on its own, covering what you found, what you did, and what's next, so a reader who only sees the last message has the full picture.
Si votre produit masque la sortie des outils, indiquez-le au modèle sous forme de message système à portée de tour, sinon il pourrait exécuter des commandes pour « montrer » à l'utilisateur des sorties qu'il ne voit jamais : « Seul vous voyez la sortie de cette commande. Si l'utilisateur doit en lire une partie, incluez-la dans votre réponse. »
Le tour se termine avant que le travail ne soit terminé
Le changement. Sur les charges de travail asynchrones complexes, Fable 5.1 décrit parfois ce qu'il ferait ensuite au lieu de le faire, ou demande la permission pour une étape que la requête couvrait déjà. Les utilisateurs doivent répondre « continuer », ce qui limite la capacité du modèle à anticiper sur le long terme.
La solution est un bloc de prompt système dont la phrase d'ouverture porte la majeure partie de l'effet :
You are operating autonomously. The user is not watching in real time and cannot answer questions mid-task, so asking 'Want me to...?' or 'Shall I...?' will block the work. For reversible actions that follow from the original request, proceed without asking. Stop only for destructive actions or genuine scope changes the user must decide. Offering follow-ups after the task is done is fine; asking permission before doing the work is not.
Before ending your turn, check your last paragraph. If it is a plan, an analysis, a question, a list of next steps, or a promise about work you have not done, do that work now with tool calls. End your turn only when the task is complete or you are blocked on input only the user can provide.
Anthropic l'associe à un deuxième bloc qui définit la requête de l'utilisateur comme la portée du livrable : ne la réduisez pas, ne l'élargissez pas, ne l'échangez pas ; terminez chaque partie qui n'est pas bloquée et dites ce qui a été omis ; traitez ce que vous avez remarqué mais qui n'a pas été demandé comme une suggestion, pas un changement. Cette paire peut rendre le modèle moins susceptible de poser des questions sur des requêtes ambiguës, alors ajoutez une ligne listant les confirmations que vous souhaitez toujours. Une différence avec Opus 5 : si votre prompt demande au modèle de vérifier son travail avant de le rapporter, conservez-le. Le conseil d'Opus 5 de supprimer les instructions de vérification ne s'applique pas.
Correctifs non demandés et fichiers de test supplémentaires
Le changement. Demandé pour une fonctionnalité ouverte, Fable 5.1 la fournit et parfois plus : des correctifs à proximité, un comportement étendu, plus de fichiers de test engagés que le changement ne le justifie.
La solution, qui, selon Anthropic, a réduit considérablement les extras sans changement dans la réussite de la tâche :
If, while working or testing, you find a pre-existing bug, a performance concern, or behavior the task doesn't mention, don't fix, optimize or extend it in this change unless the requested behavior cannot work without it; report it as a follow-up in your summary. Verify your work however you like; scratch scripts and quick checks need not be kept. Commit tests only where the task asks for them or this repository already keeps tests for this kind of change, sized like the neighboring test files. This is about extras only: implement every behavior the task asks for, completely.
Fichiers entiers réécrits pour de petits changements
Le changement. Fable 5.1 est plus susceptible que Fable 5 de réécrire un fichier entier plutôt que d'effectuer une édition ciblée. Même résultat, plus de tokens en sortie.
La solution, dans le prompt système ou le premier message utilisateur :
The number of tokens used to edit files is best minimized, all else being equal. Therefore, when it will not affect the end result, try to surgically edit a file rather than rewrite the entire thing.
La prose est longue et dense
Le changement. L'écriture de Fable 5.1 est généralement un progrès, avec moins de phrases toutes faites, mais dans certains cas, elle est plus dense que celle de Fable 5 : des phrases plus longues, moins de sauts de paragraphe.
La solution consiste à définir l'anti-pattern. L'extrait d'Anthropic décrit la « prose maniérée » comme une écriture qui substitue la métaphore et l'ornementation à l'affirmation directe et qui existe pour montrer l'écrivain plutôt que de transmettre l'idée ; l'instruction est de dire ce que l'on veut dire et d'utiliser la phrase littérale lorsqu'elle est disponible. La forme courte fonctionne également : « Veuillez supprimer toute prose maniérée. »
Les réponses de chat sont moins structurées que le contenu ne l'exige
Le changement. Les modèles précédents abusaient des puces et du gras, de sorte que de nombreux prompts contiennent des règles anti-formatage. Fable 5.1 penche dans l'autre sens : moins de gras, moins d'en-têtes et de listes. Ces anciennes règles suppriment désormais la structure dont le contenu a besoin.
La solution. Supprimez le langage anti-formatage, ou remplacez-le par une règle qui indique quand le formatage aide : utilisez des listes lorsqu'elles sont demandées ou lorsque le contenu est suffisamment multifacette pour qu'elles améliorent la clarté ; respectez une demande explicite de formatage minimal ; utilisez une prose simple dans les échanges conversationnels ou émotionnels.
Les résumés reproduisent la formulation de la source sans la marquer
Le changement. Lors de la synthèse de documents, Fable 5.1 est plus susceptible que Fable 5 de reproduire des passages de la source sans les marquer comme des citations.
La solution. Ajoutez un exemple complet au prompt système : la requête de l'utilisateur, une réponse correcte qui transmet chaque source dans le discours indirect de l'assistant avec au maximum une courte citation marquée, et une justification d'une phrase expliquant pourquoi elle est correcte. Remplacez les espaces réservés aux appels d'outils dans l'exemple d'Anthropic par le nom de votre propre outil.
Réponses de mémoire au lieu de rechercher à faible effort
Le changement. À un effort `low`, Fable 5.1 appelle les outils de recherche et de récupération moins souvent que Fable 5, le plus visiblement pour les produits et modèles nommés qu'il reconnaît mais dont il a des connaissances obsolètes.
Deux solutions. Augmentez l'effort pour les tours affectés avec un effort par message. Ou dites au modèle dans le prompt système que reconnaître un nom dans un domaine en évolution rapide n'est pas la même chose que de connaître son état actuel, qu'il doit rechercher avant de répondre, et qu'il doit inclure le nom tel que l'utilisateur l'a écrit dans au moins une requête.
Les livrables longs à xhigh et max prennent trop de temps
Le changement. À `xhigh` et surtout `max`, Fable 5.1 peut rédiger une grande partie d'un livrable long dans sa phase de réflexion, puis le réécrire en tant que réponse, doublant le temps d'attente et les tokens de sortie.
Deux solutions. Exécutez ces requêtes à `high` et n'augmentez l'effort que là où vous avez mesuré un gain. Si vous restez à `xhigh` ou `max`, définissez `max_tokens` pour laisser de la place à la réflexion et à la réponse, et ajoutez une note au message utilisateur indiquant que tout ce qui est produit dans une seule réponse, raisonnement inclus, compte pour une seule limite d'environ vos `max_tokens` réels, et que composer le livrable en entier comme raisonnement et à nouveau comme réponse double le tour sans l'améliorer. Laissez les copies précédentes de cette note en place lors des requêtes ultérieures.
Les requêtes de codage bénignes renvoient un refus
Le changement. Les classificateurs de Fable 5.1 produisent moins de faux positifs que ceux de Fable 5 lors de son lancement, et la recherche de vulnérabilités dans le code source est désormais autorisée. Des faux positifs se produisent toujours.
Trois reformulations à changer. Demandez « Y a-t-il des bugs dans ce programme ? » plutôt que « Ce programme compile-t-il sans erreurs ? » Donnez au modèle la documentation pour les langages moins connus. Supprimez les outils qui renvoient des données encodées en base64 dans le contexte. Gardez `fallbacks` configurés quoi qu'il arrive ; le guide de gestion des refus le couvre.
Les résumés de compaction côté client omettent des détails
Fable 5.1 répond bien au fait qu'on lui dise exactement ce qu'un résumé de compaction doit retenir. La compaction côté serveur le fait déjà. Si vous compactez côté client, demandez au modèle de résumer à l'intérieur des balises `
` et de conserver, dans l'ordre : les difficultés rencontrées et comment elles ont été résolues ; les approches soulevées ou écartées et pourquoi ; tout ce qui a été demandé ou décidé, énoncé exactement ; où en sont les choses maintenant ; tout ce qui est encore en suspens ; et les détails difficiles à reconstituer comme les noms, les numéros et les liens. Terminez par « N'appelez aucun outil lors de la rédaction de ce résumé ; répondez avec du texte uniquement », ce qui est important lorsque la requête de résumé contient toujours les outils de la conversation.
Sous-agents et vision
Deux solutions sont architecturales plutôt que des prompts. Pour les tâches de codage, laissez l'agent principal continuer à travailler pendant que les sous-agents s'exécutent : faites en sorte que l'outil qui démarre un sous-agent retourne immédiatement, délivrez chaque résultat dans un message utilisateur ultérieur, et donnez à l'agent principal un outil séparé qu'il peut appeler lorsqu'il veut attendre. Pour les graphiques denses et les tableaux imbriqués, donnez au modèle un outil de recadrage qui renvoie une région choisie agrandie, ou un conteneur avec des bibliothèques d'images de base ; à un effort `low`, il peut ignorer le recadrage, alors vérifiez les logs pour l'appel.
Tester les changements de prompts dans Apidog
Chaque solution ci-dessus est un candidat pour un test avant-après. Dans Apidog, enregistrez les trois premiers tours de votre boucle d'agent comme une séquence de requêtes, paramétrez le prompt système, et exécutez-le avec et sans chaque extrait au même effort. Affirmez sur le compte des blocs `tool_use` par tour d'assistant pour la solution de regroupement, sur `usage.output_tokens` pour les solutions d'édition ciblée et de densité, et sur l'absence d'un paragraphe final commençant par « Next, I » pour la solution d'autonomie. Téléchargez Apidog pour le construire ; le guide Claude Code montre quelles de ces lignes appartiennent à un `CLAUDE.md`.

FAQ
Mes prompts Fable 5 fonctionnent-ils sur Fable 5.1 ? Anthropic affirme qu'ils devraient bien fonctionner sans modifications. Les différences sont comportementales : moins d'appels d'outils regroupés, moins de mises à jour de progression, une prose plus dense, moins de formatage de chat, des réécritures de fichiers entiers et un élargissement de la portée des tâches ouvertes.
À quel niveau d'effort dois-je inviter Fable 5.1 ? Commencez à `high` et balayez les options. Anthropic affirme que `medium` correspond à peu près à Fable 5 à un coût inférieur et que `low` est souvent compétitif avec Opus et Sonnet en termes de coût par tâche.
Où dois-je placer une instruction par tour sur Fable 5.1 ? En tant que message système à portée de tour avec `clear_at: "next_user_message"` après les résultats d'outils, en laissant les copies précédentes en place. Injecter et supprimer du texte des tours précédents invalide les blocs de réflexion ultérieurs et redémarre le cache.
Dois-je supprimer les instructions « vérifier votre travail » comme sur Opus 5 ? Non. Cette directive était spécifique à la sur-vérification d'Opus 5. Conservez-les sur Fable 5.1.
Comment empêcher Fable 5.1 de réécrire des fichiers entiers ? Une ligne dans le prompt système ou le premier message utilisateur : minimisez les tokens utilisés pour éditer les fichiers et éditez de manière chirurgicale plutôt que de réécrire lorsque cela n'affecte pas le résultat.
