DEV Community

Cover image for Prompter Claude Fable 5.1 : Corriger les changements de comportement avec le bon prompt
Antoine Laurent
Antoine Laurent

Posted on Originally published at apidog.com

Prompter Claude Fable 5.1 : Corriger les changements de comportement avec le bon prompt

Adapter vos prompts de Claude Fable 5 à Fable 5.1 : guide pratique

Anthropic affirme que vos invites Fable 5 existantes devraient fonctionner sur Claude Fable 5.1 sans modifications. C'est vrai pour les réponses, mais moins pour ce qui les entoure : appels d'outils regroupés par tour, quantité de narration, densité de la prose, formatage du chat, réécriture des fichiers et demandes de permission inutiles. Consultez le guide de prompt engineering pour Claude Fable 5.1 et découvrez ce qu'est Claude Fable 5.1.

Essayez Apidog dès aujourd’hui

Le changement le plus important concerne le placement des instructions par tour : il peut invalider les blocs de réflexion et redémarrer le cache. Voici les ajustements à tester, avec les formulations recommandées par Anthropic.

Commencez par l'effort, pas par les prompts

L'Effort est le principal levier pour équilibrer intelligence, latence et coût sur Fable 5.1. Commencez par high, la valeur par défaut, puis évaluez les quatre autres niveaux avec vos propres jeux de tests.

Refaites ce balayage même si vous l'avez déjà effectué sur Fable 5 : les niveaux ne correspondent pas à la même quantité de réflexion selon le modèle.

Anthropic recommande notamment de tester les hypothèses suivantes :

  • medium produirait des résultats proches de Fable 5, à moindre coût ;
  • à low, Fable 5.1 serait souvent compétitif avec Opus et Sonnet en coût par tâche, avec de meilleurs scores ;
  • les gains par rapport à Fable 5 seraient les plus importants à xhigh et max.

Sur Fable 5.1, l'effort peut être modifié en cours de conversation sans réinitialiser le cache, via un message role: "system" vide avec output_config et l'en-tête bêta mid-conversation-output-config-2026-07-01. Consultez le guide pas à pas de l'API pour la forme exacte 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. Ajouter un rappel dans un tour précédent puis le supprimer dans la requête suivante modifie l'historique :

  • le cache de prompt redémarre ;
  • pour les comptes créés le ou après le 31 août 2026, chaque bloc de réflexion ultérieur est invalidé.

Instructions à portée de tour

Avec la version bêta mid-conversation-system-clear-at-2026-08-21, ajoutez l'instruction après le message de résultat d'outil :

{
  "role": "system",
  "clear_at": "next_user_message",
  "content": "..."
}
Enter fullscreen mode Exit fullscreen mode

Conservez toutes les copies précédentes dans le tableau. Lorsqu'un message utilisateur ultérieur existe, l'API efface les anciennes copies : le modèle ne lit alors que la plus récente et les copies effacées ne consomment pas de tokens.

Sans cette version bêta, placez l'instruction dans un bloc de texte situé après les blocs tool_result du même message utilisateur. Là encore, conservez les copies précédentes. Ne supprimez ni ne réécrivez jamais une copie déjà envoyée.

La documentation officielle sur la pensée préservée et le guide de la pensée préservée expliquent ce comportement.

Les instructions de niveau session doivent rester dans le prompt système ou le premier tour utilisateur. Anthropic indique que les instructions de style placées dans le premier tour utilisateur sont mieux retenues que le même texte dans le prompt système.

Placement des instructions et pensée préservée

Obtenir plusieurs appels d'outils par tour

Le problème

Quand une requête nomme plusieurs éléments à récupérer, Fable 5.1 peut émettre les appels en parallèle. En revanche, dans les boucles de codage ou d'utilisation informatique où les lectures indépendantes sont seulement implicites, il peut n'en émettre qu'une par tour alors que Fable 5 en regroupait plusieurs.

Les réponses restent correctes, mais chaque tour supplémentaire ajoute :

  • des tokens ;
  • un aller-retour réseau ;
  • du temps d'exécution.

Mesurer avant de modifier

Suivez la proportion de tours assistant contenant plusieurs appels d'outils. N'ajoutez la solution que si cette proportion a diminué.

Après chaque message de résultat d'outil, ajoutez cette instruction 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.
Enter fullscreen mode Exit fullscreen mode

Conservez impérativement le mot privately. Sans lui, le modèle peut répondre au rappel au lieu de traiter la demande utilisateur. Une phrase placée vers la fin de la requête actuelle a généralement plus d'effet que la même phrase dans le prompt système.

Réduire le silence entre les appels d'outils

Le problème

Fable 5.1 produit moins de mises à jour visibles pendant les longues séquences d'appels d'outils que Fable 5, surtout avec un effort élevé. L'utilisateur peut voir l'agent rester silencieux pendant plusieurs minutes, puis recevoir un message final qui ne couvre que la dernière étape.

Trois solutions, dans l'ordre

  1. Afficher les mises à jour de réflexion.

    Les notes inter-outils reviennent sous forme de blocs thinking, mais sont vides avec display: "omitted". Utilisez display: "updates" avec l'en-tête bêta thinking-display-updates-2026-08-18, puis affichez chaque bloc non vide comme une ligne de statut.

  2. Supprimer les anciennes consignes.

    Retirez les formulations conçues pour les modèles qui produisaient trop de mises à jour, par exemple : « conservez toutes les découvertes pour la réponse finale ».

  3. Ajouter une consigne explicite si nécessaire.

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.
Enter fullscreen mode Exit fullscreen mode

Si votre produit masque la sortie des outils, indiquez-le également au modèle avec un message système à portée de tour :

Seul vous voyez la sortie de cette commande. Si l'utilisateur doit en lire une partie, incluez-la dans votre réponse.
Enter fullscreen mode Exit fullscreen mode

Sinon, le modèle pourrait exécuter des commandes uniquement pour « montrer » des sorties que l'utilisateur ne verra jamais.

Empêcher le modèle de terminer trop tôt

Le problème

Sur les tâches asynchrones complexes, Fable 5.1 peut décrire l'étape suivante au lieu de l'exécuter, ou demander la permission pour une action déjà couverte par la requête. L'utilisateur doit alors répondre « continuer ».

Le bloc d'autonomie

Ajoutez ce bloc au prompt système :

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.
Enter fullscreen mode Exit fullscreen mode

Anthropic associe ce bloc à une seconde règle qui définit la requête comme la portée du livrable :

  • ne réduisez pas la portée ;
  • ne l'élargissez pas ;
  • ne remplacez pas la tâche par une autre ;
  • terminez chaque partie qui n'est pas bloquée ;
  • indiquez ce qui a été omis ;
  • traitez les problèmes non demandés comme des suggestions, pas comme des changements.

Cette combinaison réduit les demandes de clarification sur les requêtes ambiguës. Ajoutez toutefois une ligne listant les confirmations qui doivent toujours être demandées dans votre produit.

Contrairement au conseil donné pour Opus 5, conservez les instructions demandant au modèle de vérifier son travail avant de le rapporter. Consultez le conseil d'Opus 5 sur les instructions de vérification.

Éviter les correctifs non demandés

Le problème

Pour une fonctionnalité ouverte, Fable 5.1 peut effectuer des modifications supplémentaires :

  • correctifs à proximité ;
  • changement de comportement non demandé ;
  • fichiers de test supplémentaires ;
  • extensions de portée.

La consigne

Anthropic recommande cette formulation :

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.
Enter fullscreen mode Exit fullscreen mode

La règle concerne uniquement les extras : chaque comportement demandé doit être implémenté complètement.

Éditer une seule ligne sans réécrire tout le fichier

Fable 5.1 réécrit plus souvent un fichier entier pour une petite modification. Le résultat peut être correct, mais la sortie consomme davantage de tokens.

Ajoutez cette instruction au prompt système ou au 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.
Enter fullscreen mode Exit fullscreen mode

Réduire la densité de la prose

Fable 5.1 produit généralement une meilleure écriture, avec moins de phrases toutes faites. Dans certains cas, ses phrases sont toutefois plus longues et ses paragraphes plus denses.

Définissez explicitement l'anti-pattern :

Veuillez supprimer toute prose maniérée.
Enter fullscreen mode Exit fullscreen mode

Anthropic décrit la prose maniérée comme une écriture qui remplace l'affirmation directe par la métaphore et l'ornementation, et qui cherche davantage à mettre en valeur l'écrivain qu'à transmettre l'idée. Demandez au modèle de dire directement ce qu'il veut dire et d'utiliser la formulation littérale lorsqu'elle est disponible.

Restaurer la structure des réponses de chat

Le problème

Les modèles précédents abusaient des puces et du gras. Beaucoup de prompts contiennent donc des règles anti-formatage. Fable 5.1 penche davantage vers l'autre extrême :

  • moins de gras ;
  • moins d'en-têtes ;
  • moins de listes.

Ces anciennes règles peuvent supprimer la structure dont le contenu a besoin.

La solution

Supprimez le langage anti-formatage et remplacez-le par une règle contextuelle :

  • utilisez des listes lorsqu'elles sont demandées ou qu'elles améliorent la clarté d'un contenu multifacette ;
  • respectez une demande explicite de formatage minimal ;
  • utilisez une prose simple dans les échanges conversationnels ou émotionnels.

Marquer les citations dans les résumés

Lors de la synthèse de documents, Fable 5.1 reproduit plus souvent des passages de la source sans les signaler comme citations.

Ajoutez au prompt système un exemple complet comprenant :

  1. la requête utilisateur ;
  2. une réponse correcte transmettant chaque source au discours indirect ;
  3. au maximum une courte citation explicitement marquée ;
  4. une justification d'une phrase expliquant pourquoi la réponse est correcte.

Dans l'exemple d'Anthropic, remplacez les espaces réservés aux appels d'outils par le nom de votre propre outil.

Forcer la recherche avec un faible effort

À low, Fable 5.1 appelle moins souvent les outils de recherche et de récupération que Fable 5. Le phénomène est particulièrement visible pour les produits et modèles nommés qu'il reconnaît, mais dont les informations peuvent être obsolètes.

Deux solutions sont possibles :

  • augmentez l'effort pour les tours concernés avec un effort par message ;
  • indiquez au modèle que reconnaître un nom dans un domaine en évolution rapide ne signifie pas connaître son état actuel.

Ajoutez alors une règle lui demandant de rechercher l'information avant de répondre et d'inclure le nom tel que l'utilisateur l'a écrit dans au moins une requête.

Accélérer les livrables longs à xhigh et max

À xhigh, et surtout à max, Fable 5.1 peut rédiger une grande partie d'un livrable pendant sa réflexion, puis le réécrire dans la réponse finale. Le temps d'attente et les tokens de sortie augmentent sans amélioration proportionnelle.

Deux approches :

  1. exécutez ces requêtes à high et n'augmentez l'effort qu'après avoir mesuré un gain ;
  2. si vous utilisez xhigh ou max, définissez max_tokens avec suffisamment de place pour la réflexion et la réponse.

Ajoutez également une note au message utilisateur indiquant que tout ce qui est produit dans une réponse, raisonnement compris, compte pour une seule limite d'environ vos max_tokens réels. Composer le livrable dans le raisonnement puis le reproduire dans la réponse double le travail sans l'améliorer.

Conservez les copies précédentes de cette note dans les requêtes suivantes.

Limiter les refus sur les tâches de codage bénignes

Les classificateurs de Fable 5.1 produisent moins de faux positifs que ceux de Fable 5 à son lancement, et la recherche de vulnérabilités dans le code source est désormais autorisée. Des faux positifs restent toutefois possibles.

Testez ces reformulations :

  • demandez « Y a-t-il des bugs dans ce programme ? » plutôt que « Ce programme compile-t-il sans erreurs ? » ;
  • fournissez la documentation nécessaire pour les langages moins connus ;
  • supprimez les outils qui renvoient des données encodées en base64 dans le contexte ;
  • conservez fallbacks configuré dans tous les cas.

Consultez le guide de gestion des refus.

Préserver les détails lors de la compaction côté client

Fable 5.1 suit bien une consigne détaillée sur les éléments à conserver dans un résumé de compaction. La compaction côté serveur applique déjà ce comportement.

Pour une compaction côté client, demandez au modèle de produire le résumé entre des balises <summary> et </summary>, en conservant dans cet ordre :

  1. les difficultés rencontrées et leur résolution ;
  2. les approches envisagées ou écartées, avec leurs raisons ;
  3. chaque élément demandé ou décidé, énoncé exactement ;
  4. l'état actuel ;
  5. les éléments encore en suspens ;
  6. les détails difficiles à reconstituer, comme les noms, numéros et liens.

Terminez par cette instruction :

N'appelez aucun outil lors de la rédaction de ce résumé ; répondez avec du texte uniquement
Enter fullscreen mode Exit fullscreen mode

Elle est importante lorsque les outils de la conversation figurent encore dans la requête de résumé.

Sous-agents et vision : deux changements architecturaux

Certaines améliorations ne relèvent pas du prompt.

Tâches de codage

Laissez l'agent principal continuer à travailler pendant l'exécution des sous-agents :

  • l'outil qui démarre un sous-agent doit retourner immédiatement ;
  • chaque résultat doit être livré dans un message utilisateur ultérieur ;
  • l'agent principal doit disposer d'un outil séparé pour attendre les résultats lorsqu'il le souhaite.

Graphiques denses et tableaux imbriqués

Fournissez au modèle un outil de recadrage qui renvoie une région choisie et agrandie, ou un conteneur avec des bibliothèques d'images de base. À low, le modèle peut ignorer le recadrage : vérifiez donc les logs pour confirmer que l'outil est appelé.

Recadrage et analyse de contenu visuel

Tester les changements dans Apidog

Chaque solution doit faire l'objet d'un test avant/après.

Dans Apidog :

  1. enregistrez les trois premiers tours de votre boucle d'agent comme une séquence de requêtes ;
  2. paramétrez le prompt système ;
  3. exécutez la séquence avec et sans chaque extrait, au même niveau d'effort ;
  4. comparez les métriques pertinentes.

Mesurez notamment :

  • le nombre de blocs tool_use par tour assistant pour la solution de regroupement ;
  • usage.output_tokens pour les solutions d'édition ciblée et de densité ;
  • l'absence d'un paragraphe final commençant par « Next, I » pour la solution d'autonomie.

Téléchargez Apidog pour construire ces tests. Le guide Claude Code indique quelles consignes placer dans CLAUDE.md.

FAQ

Mes prompts Fable 5 fonctionnent-ils sur Fable 5.1 ?

Anthropic affirme qu'ils devraient fonctionner sans modification. Les différences sont surtout comportementales : moins d'appels d'outils regroupés, moins de mises à jour de progression, une prose plus dense, moins de formatage de chat, davantage de réécritures complètes de fichiers et une portée plus large pour les tâches ouvertes.

Quel niveau d'effort utiliser avec Fable 5.1 ?

Commencez par high, puis testez les autres niveaux. Anthropic affirme que medium offre des résultats proches de Fable 5 à moindre coût et que low est souvent compétitif avec Opus et Sonnet en coût par tâche.

Où placer une instruction par tour ?

Utilisez un message système à portée de tour avec clear_at: "next_user_message", après les résultats d'outils, en conservant les copies précédentes. Ajouter puis supprimer du texte dans 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 avec Opus 5 ?

Non. Cette recommandation concernait la sur-vérification spécifique à Opus 5. Conservez ces instructions sur Fable 5.1.

Comment empêcher la réécriture complète des fichiers ?

Ajoutez une instruction au prompt système ou au premier message utilisateur demandant de minimiser les tokens d'édition et de modifier chirurgicalement les fichiers lorsque cela ne change pas le résultat.

Top comments (0)