Guide de prompting Fable 5.2 avec réglages et exemples de prompts

Avec Claude Fable 5.2, lancé par Anthropic le 9 novembre 2026, votre prompt définit la mission, mais ne configure pas tout. Pour obtenir un travail exploitable, vous devez aussi choisir l’effort, fournir les bonnes sources et encadrer les actions. Ce guide de prompting Fable 5.2 vous accompagne du premier réglage à la validation finale, avec des exemples pour le code, la recherche, les documents et les agents.

Votre agent peut modifier davantage de fichiers que prévu, interrompre une migration ou rendre un rapport convaincant sans avoir exécuté les tests. Dans ces situations, rallonger votre demande ne résout pas nécessairement le problème.

Pour guider Claude Fable 5.2, vous devez distinguer les instructions, la configuration et les capacités réellement disponibles. Une consigne peut demander une recherche, mais elle ne fournit pas un navigateur. Elle peut imposer une approbation, mais elle ne remplace pas les permissions de votre application.

Utilisez les exemples ci-dessous comme modèles de départ. Remplacez les champs entre accolades par vos informations et ne conservez que les règles utiles à votre tâche. Pour configurer Claude Code, vous trouverez également les commandes documentées par Anthropic.

Choisissez votre modèle et réglez l’effort de Fable 5.2

Commencez par le modèle adapté à votre difficulté

Avec Fable 5.2, vous pouvez aborder des travaux exigeants qui nécessitent plusieurs étapes, des outils et des décisions intermédiaires. Vous pouvez lui transmettre du texte et des images ; ses réponses restent textuelles. Pour l’appeler dans l’API Claude, utilisez l’identifiant claude-fable-5-2.

Vous disposez d’un contexte d’un million de jetons et jusqu’à 128 000 jetons de sortie. Les jetons sont les unités utilisées pour traiter et comptabiliser les informations. Distinguez toutefois la capacité de contexte de la longueur maximale de réponse : ces valeurs décrivent deux limites différentes.

Pour autant, Anthropic vous recommande de commencer avec Claude Opus 5.5 pour de nombreuses tâches de programmation et de travail intellectuel. Envisagez Fable lorsque vos évaluations avec Opus, y compris à effort supérieur, restent insuffisantes.

Avec Opus comme avec Fable, vous disposez de la même capacité de contexte et de la même sortie maximale. Passer à Fable ne vous donne donc pas une fenêtre plus grande.

Comparez plutôt les capacités recherchées, le réglage par défaut et le prix. Dans l’API, Opus 5.5 démarre à medium, contre high pour Fable 5.2. Ses tarifs standards sont de 4 dollars en entrée et 20 dollars en sortie par million de jetons, contre 8 et 40 dollars pour Fable. Un modèle plus coûteux au jeton doit apporter un bénéfice que vous pouvez mesurer.

Pour les tâches plus simples, vous pouvez également choisir Claude Sonnet 5.5 ou Haiku 5.5, comme le recommande Anthropic. Vous pouvez faire intervenir Fable ponctuellement comme conseiller d’un modèle plus léger, ou lui faire coordonner des tâches qu’il délègue. Vous n’êtes donc pas obligé de lui confier toute l’exécution.

Ne confondez pas Fable et Mythos avec deux méthodes de prompting

Lorsque vous comparez Fable 5.2 et Claude Mythos 5.2, vous comparez deux versions reposant sur le même modèle sous-jacent. Leur distinction principale concerne les protections et les conditions d’accès.

Avec Fable, vous utilisez un modèle conservant des protections renforcées dans les domaines cybernétiques et biologiques. Pour utiliser Mythos, votre organisation doit être vérifiée par les programmes correspondants.

Tenez compte de cette différence pour votre déploiement. Elle ne vous oblige pas à rédiger un prompt entièrement différent pour chaque demande généraliste. Une restriction d’accès ne se résout pas par une formulation plus insistante.

Comprenez les cinq niveaux d’effort

Le raisonnement adaptatif de Fable 5.2 reste actif. Vous ne le désactivez pas pour réduire la consommation : vous ajustez son niveau d’effort.

Choisissez low pour les tâches courtes et bien délimitées

Vous pouvez l’évaluer pour les échanges rapides ou les sous-agents exécutant des opérations répétitives. En revanche, surveillez l’achèvement des travaux complexes : Anthropic rapporte un risque accru d’arrêt prématuré à faible effort.

Utilisez medium pour le travail interactif

Vous pouvez l’évaluer pour la programmation accompagnée, les conversations et les tâches intellectuelles quotidiennes.

Commencez avec high dans l’API pour vos tâches exigeantes

Ce niveau vise la programmation difficile, la recherche approfondie et les tâches longues. Prévoyez une consommation et un délai potentiellement supérieurs à ceux de medium.

Réservez xhigh aux difficultés pour lesquelles vous avez mesuré un gain supplémentaire

Son intérêt dépend de votre travail. Ne le sélectionnez pas automatiquement uniquement parce qu’il se situe plus haut.

Avec max, vous recherchez les capacités les plus élevées du modèle

Réservez-le notamment aux problèmes techniques ou scientifiques ouverts, lorsque leur importance justifie une forte consommation et une attente plus longue.

Avant d’augmenter l’effort, tenez compte des évaluations internes d’Anthropic : une grande partie des gains apparaît déjà à high. Au-dessus, les bénéfices deviennent moins réguliers.

Demander une réponse immédiate ne remplace pas ce réglage. Anthropic indique qu’une instruction demandant de ne pas délibérer n’empêche pas de manière fiable le raisonnement à medium et au-delà. Pour réduire l’effort, utilisez le contrôle prévu par votre environnement.

Réglez l’effort dans l’API Messages

Dans l’API Claude, modifiez output_config.effort. Transmettez-lui une seule valeur parmi low, medium, high, xhigh et max. Sans valeur explicite, le niveau par défaut du modèle s’applique.

Pour exécuter l’exemple Python suivant, installez le SDK anthropic, définissez votre clé dans la variable d’environnement ANTHROPIC_API_KEY et placez les exigences à analyser dans un fichier exigences.txt.

from pathlib import Path
import os
import sys

import anthropic

MODEL = "claude-fable-5-2"
EFFORT = "high"  # Alternatives : low, medium, xhigh, max
MAX_TOKENS = 8192

if not os.environ.get("ANTHROPIC_API_KEY"):
    raise SystemExit("Définissez la variable ANTHROPIC_API_KEY.")

try:
    exigences = Path("exigences.txt").read_text(encoding="utf-8")
except (OSError, UnicodeError) as exc:
    raise SystemExit(f"Impossible de lire exigences.txt : {exc}")

if not exigences.strip():
    raise SystemExit("Le fichier exigences.txt est vide.")

prompt = f"""
Analyse les exigences techniques ci-dessous et propose
un plan d'implémentation limité au besoin décrit.

Sépare les exigences confirmées des hypothèses.
Présente les changements nécessaires, les dépendances,
les vérifications prévues et les incertitudes importantes.

Ne prétends pas avoir exécuté des tests.

DOCUMENT À ANALYSER
{exigences}
"""

client = anthropic.Anthropic()

try:
    response = client.messages.create(
        model=MODEL,
        max_tokens=MAX_TOKENS,
        output_config={"effort": EFFORT},
        messages=[{"role": "user", "content": prompt}],
    )
except anthropic.APIError as exc:
    raise SystemExit(f"Échec de la requête : {exc}")

texte = "\n".join(
    block.text
    for block in response.content
    if block.type == "text"
)

if texte:
    print(texte)
else:
    print("Aucun bloc de texte final reçu.", file=sys.stderr)

print(f"\nMotif d'arrêt : {response.stop_reason}")

if response.stop_reason == "max_tokens":
    print(
        "Le budget de sortie a été atteint. "
        "Vérifiez si la réponse est complète.",
        file=sys.stderr,
    )

Pour comparer medium et high, modifiez seulement la valeur de EFFORT. Conservez le même document et les autres paramètres.

max_tokens ne réserve pas toute son enveloppe au texte visible. Le raisonnement consomme également des jetons de sortie. Utilisez les 8 192 jetons de cet exemple comme un budget illustratif, pas comme une valeur universelle.

Avec cet exemple, vous réalisez une analyse textuelle. Vous n’ajoutez pas d’outils de navigation, d’exécution ou de modification de fichiers. Pour une véritable boucle d’agent, vous devez aussi gérer les appels d’outils et conserver les blocs nécessaires à la conversation.

Modifiez l’effort dans Claude Code

Pour configurer Claude Code, utilisez les commandes documentées par Anthropic.

Dans une session Claude Code, saisissez /effort pour ouvrir le sélecteur. Vous pouvez aussi indiquer directement le niveau :

/effort high

Pour passer ensuite à un effort moyen :

/effort medium

Vous pouvez également ajuster l’effort avec les flèches gauche et droite dans le sélecteur /model. Pour démarrer une session avec un choix explicite, utilisez :

claude --model claude-fable-5-2 --effort high

Avec --effort, vous réglez cette session. Les règles de votre organisation et certains réglages prioritaires peuvent limiter le niveau appliqué. Vérifiez donc le réglage affiché. Dans le terminal, après confirmation par /effort, le prochain message envoyé utilise le nouveau niveau.

Ne transposez pas automatiquement les valeurs par défaut entre produits. Au lancement, vous utilisez medium dans les applications Claude et Claude Code, alors que l’API utilise high. Les deux informations décrivent des environnements différents.

Évaluez l’effort avant de choisir votre configuration permanente

Testez séparément le choix du modèle et celui de l’effort. Ne supposez pas qu’un même libellé garantit une consommation ou un comportement identique entre deux générations.

Pour préparer votre évaluation, vous pouvez utiliser ce prompt :

Prépare un protocole de comparaison des niveaux d’effort de Claude Fable 5.2 sur {ensemble de tâches représentatives}.

Conserve les mêmes instructions, documents, outils et critères de réussite. Le travail doit être correct, rester dans le périmètre autorisé et satisfaire les tests existants.

Pour chaque configuration, relève l’achèvement réel, les erreurs, les appels d’outils, les jetons consommés, la durée totale et le coût estimé.

Conserve l’identifiant exact du modèle, les cas utilisés et les paramètres de chaque exécution. Présente les écarts et les jugements incertains.

Recommande le niveau le moins exigeant qui atteint régulièrement le seuil de qualité demandé. Ne privilégie pas le niveau maximal par principe.

Utilisez ce prompt pour préparer ou analyser le protocole. Vous devez organiser l’exécution des différents réglages dans votre application. Le modèle ne change pas automatiquement ses propres paramètres parce que vous lui demandez de comparer plusieurs efforts.

Calculez le coût du travail complet

Au tarif standard, vous payez 8 dollars par million de jetons d’entrée et 40 dollars par million de jetons de sortie.

Pour le cache, distinguez plusieurs opérations. Vous payez 10 dollars par million de jetons pour une écriture avec une durée de cinq minutes, contre 16 dollars pour une heure. La lecture d’un contenu déjà mis en cache est affichée à 0,20 dollar par million.

Avec l’API de traitement par lots, vous pouvez bénéficier d’une réduction de 50 % sur les tarifs standards d’entrée et de sortie. Ne supposez toutefois pas que chacune de vos requêtes bénéficie automatiquement du cache ou de la remise.

Pour estimer votre facture, calculez séparément le coût des entrées et celui des sorties. Avec 10 000 jetons d’entrée standard, vous obtenez :

Pour 20 000 jetons de sortie facturés :

Vous obtenez donc un total de 0,88 dollar, sans ajustement de cache ni autres frais. Ne le considérez pas comme le coût habituel d’un audit ou d’une migration : il s’agit d’un exemple arithmétique.

Votre tâche agentique peut multiplier les appels, les lectures, les reprises et les sous-agents. Pour maîtriser les coûts d’utilisation de l’IA agentique, mesurez le coût par tâche réussie, pas seulement celui d’une requête isolée.

Vous pouvez également utiliser un mode rapide à 16 dollars en entrée et 80 dollars en sortie par million de jetons, selon les conditions annoncées par Anthropic. Ne confondez pas ce mode avec un sixième niveau d’effort : vous choisissez une option de vitesse et de tarification distincte.

Construisez des prompts centrés sur le résultat et les preuves

Remplacez les injonctions vagues par des critères d’acceptation

Vous pouvez rédiger une demande qui paraît exigeante tout en restant imprécise :

Examine ce code avec une attention maximale et trouve la meilleure correction possible.

Vous n’indiquez ni le défaut, ni les informations disponibles, ni le résultat qui permettra de valider la correction.

Pour obtenir un travail plus exploitable, formulez plutôt votre demande ainsi :

Le test d’authentification fourni échoue. Corrige le comportement responsable de cet échec à partir du code, de la sortie du test et de la documentation associée.

Limite les modifications aux parties nécessaires. Après correction, relance le test concerné, recherche les régressions pertinentes et examine les différences finales.

Explique la cause identifiée, les fichiers modifiés et les résultats des contrôles. Lorsque la vérification reste impossible, indique précisément ce qui manque.

Vous décrivez le travail à produire, pas une procédure de pensée interne. Vous laissez au modèle de la latitude pour examiner le problème, mais vous définissez ce qui constitue une réussite.

Utilisez une trame générale sans transformer chaque demande en formulaire

Pour vos travaux importants, séparez les instructions et les documents. Précisez le résultat, les sources, le périmètre, les actions, les outils et la validation.

Vous pouvez partir du modèle suivant :

Prépare {livrable complet} pour {destinataire ou usage}. Le travail sera considéré comme terminé lorsque {critères d’acceptation}.

Appuie-toi sur {documents, fichiers et informations}. En cas de contradiction, {sources prioritaires} font autorité. Signale les désaccords non résolus.

Ton intervention couvre {périmètre autorisé}. Ne modifie pas {éléments protégés} et ne réalise pas {actions exclues}.

Tu peux effectuer {opérations autorisées sans confirmation}. Demande mon accord pour {opérations protégées}, en précisant leurs conséquences.

Utilise {outils disponibles} lorsque tu dois consulter, vérifier, calculer ou exécuter. Contrôle les chemins, les identifiants et les arguments plutôt que de les deviner.

Rattache les conclusions importantes aux preuves disponibles. Donne des nouvelles aux étapes significatives, puis effectue {tests et contrôles attendus}.

Remets {format final}, avec les résultats confirmés, les vérifications réalisées et les limites restantes. Ne présente pas une étape intermédiaire comme le livrable achevé.

Avec cette structure, vous travaillez aussi le context engineering : la qualité dépend des informations que vous rendez accessibles.

Pour une question courte, vous pouvez vous limiter à l’objectif et au format. N’ajoutez une contrainte que si elle protège un besoin réel ou corrige un échec observé.

Pour la recherche, définissez la hiérarchie des sources

Ne confondez pas la fenêtre de contexte avec une garantie de fraîcheur ou de fiabilité des documents. Pour vos recherches, tenez compte de la date limite des connaissances fiables du modèle, fixée à juin 2026. Fournissez des sources accessibles et datées lorsque votre question porte sur des informations ultérieures.

Vous pouvez formuler votre demande ainsi :

Étudie {question de recherche} en te plaçant à la date du {date de référence}. Utilise {documents et liens disponibles}.

Accorde la priorité aux spécifications officielles actuelles, puis aux recherches originales et aux données primaires. Utilise les analyses secondaires pour compléter ou confronter ces éléments.

Identifie les principaux résultats, les désaccords significatifs et les informations manquantes. Sépare les faits rapportés de ton interprétation et des hypothèses non confirmées.

Cite chaque affirmation factuelle importante. Conserve les dates exactes et signale les preuves devenues anciennes. Ne fonde pas une affirmation actuelle importante sur ta seule mémoire.

N’invente aucune référence et ne prétends pas avoir consulté un document inaccessible.

Présente une réponse directe, puis les preuves associées aux conclusions, les interprétations concurrentes, les limites, la recommandation et les recherches encore nécessaires.

Votre consigne ne donne pas accès aux sources. Sans navigateur ou outil de recherche, fournissez les documents directement. Vérifiez ensuite que les références importantes correspondent à des contenus réellement consultés.

Pour une image, séparez lecture et interprétation

Votre capture peut montrer un indicateur sans rendre sa valeur lisible. Vous pouvez aussi y percevoir une tendance sans en connaître la cause. Préservez ces différences dans votre demande.

Analyse la capture de tableau de bord jointe. Relève les indicateurs visibles et leurs valeurs lorsqu’elles sont lisibles.

Décris les axes, la structure des graphiques et les tendances soutenues par l’image. Signale les annotations ambiguës.

N’invente ni valeur, ni légende, ni période de mesure. Ne suppose pas l’existence de données masquées. Si des outils de zoom ou de recadrage sont disponibles, examine les zones incertaines.

Distingue ce que tu observes des explications possibles. Toute information restant illisible doit être marquée comme incertaine.

Termine par les limites de visibilité et les questions nécessitant le tableau de bord original ou ses données.

Pour un calcul important, revenez aux données originales. Ne traitez pas une interprétation visuelle comme une preuve numérique suffisante lorsque la précision conditionne votre décision.

Pour deux documents longs, demandez des changements localisables

Pour comparer deux versions, ne vous contentez pas d’un résumé de chacune. Vous devez pouvoir retrouver les passages modifiés et comprendre leurs conséquences.

Compare {document précédent} et {nouvelle version}, uniquement à partir de leur contenu.

Identifie les dispositions ajoutées, supprimées ou substantiellement modifiées. Examine également les définitions et les dates.

Pour chaque changement, indique la section ou la page correspondante. Sépare les citations exactes de tes reformulations. Ne reconstitue aucune clause absente.

Explique les conséquences opérationnelles étayées par les documents. Signale les contradictions et les passages dont le sens reste incertain.

Remets une synthèse, une comparaison détaillée par thème, les implications pratiques et les points précis à faire examiner avant validation.

En localisant les preuves, vous rendez la comparaison contrôlable. Pour des documents ayant des conséquences juridiques ou financières, faites également réaliser une revue spécialisée.

Pour la rédaction, privilégiez les objectifs de lecture

Vous risquez d’obtenir un texte artificiel si vous accumulez les règles stylistiques rigides. Fixer arbitrairement la longueur de chaque phrase ne vous assure pas une meilleure explication.

Pour personnaliser Claude selon votre ligne éditoriale, définissez plutôt le public, l’usage et les preuves attendues :

Rédige une explication de {sujet} pour {public}, en utilisant {sources vérifiées}.

Commence par la réponse essentielle, puis apporte le contexte nécessaire. Explique le fonctionnement pratique et développe un exemple soutenu par les documents.

Définis les notions techniques au moment où elles deviennent utiles. Relie les paragraphes et utilise des intertitres qui correspondent à de véritables étapes de compréhension.

Privilégie un français clair, des explications concrètes et des paragraphes cohérents. Évite le jargon inutile et les contraintes de style qui dégradent la fluidité.

Présente les limites et les éléments à retenir. N’invente ni citation, ni chiffre, ni évaluation. Ne fais pas référence à une source que tu n’as pas pu consulter.

Remets le texte complet au format demandé.

Avant publication, vérifiez les faits, les exemples et les attributions. Ne confondez pas la cohérence du style avec l’exactitude du contenu.

Encadrez le code du correctif minimal à la migration complète

Attribuez une responsabilité cohérente avec le périmètre

Dans un environnement comme Claude Code, vous pouvez influencer l’ampleur des modifications par la manière dont vous définissez le rôle du modèle.

D’après les essais d’Anthropic, vous pouvez encourager des améliorations connexes en lui attribuant une responsabilité générale. Utilisez cette possibilité pour une évolution autorisée, mais évitez-la lorsque vous attendez un correctif limité.

Pour une intervention étroite, formulez votre demande ainsi :

Interviens comme contributeur sur ce dépôt de production pour corriger {défaut précis}.

Les mainteneurs restent responsables de l’architecture et du périmètre. Préserve les comportements extérieurs au problème signalé.

Ne renomme pas les éléments sans rapport avec le défaut. N’ajoute pas de fonctionnalité annexe et ne redéfinis pas l’architecture. Toute modification d’interface externe doit être explicitement signalée.

Privilégie une correction localisée. Exécute les tests pertinents et examine les différences finales pour vérifier que le périmètre n’a pas dérivé.

Explique la correction et identifie tous les fichiers modifiés.

Pour une amélioration plus large, utilisez une autorisation différente :

Implémente {fonctionnalité} dans {sous-système approuvé}. Tu peux améliorer la structure du code lorsque cela est nécessaire à cette fonctionnalité.

Dans ce périmètre, tu peux regrouper les duplications, simplifier les interfaces concernées et actualiser les tests ainsi que la documentation.

Ne modifie pas les produits voisins ni les contrats externes. Soumets les transformations destructives et les migrations majeures à validation.

Enregistre les changements de comportement. Contrôle les tests, la compatibilité des interfaces et les différences finales.

Présente l’état de la fonctionnalité, les changements structurels, les résultats des contrôles et les risques de compatibilité.

Avec ces deux prompts, vous accordez des responsabilités différentes. Ne demandez pas implicitement une refonte en utilisant un rôle très large, puis n’attendez pas un correctif minimal.

Pour déboguer, exigez un diagnostic soutenu par les éléments disponibles

Rapprochez le défaut observé du comportement attendu. Fournissez les journaux, les tests et le code pour permettre au modèle d’examiner les causes possibles.

Analyse {comportement défaillant}. Le résultat attendu est {critères d’acceptation}.

Utilise le dépôt {contexte du dépôt}, les journaux {journaux} et les sorties d’erreur {traces}. Examine les parties concernées pour identifier une cause compatible avec ces éléments.

Explique la cause retenue, puis applique la correction minimale justifiée. Évite les remaniements, changements de présentation et dépendances sans rapport avec le problème.

Relance le test reproduisant le défaut, les tests de non-régression pertinents et les contrôles des interfaces affectées. Examine le correctif pour repérer ses effets secondaires.

Si un contrôle ne peut pas être réalisé, décris le blocage. N’annonce pas un test réussi sans résultat d’exécution.

Remets le diagnostic, les changements, les commandes ou contrôles effectués et les incertitudes restantes.

Si votre besoin se limite à un avis, remplacez l’autorisation de correction par une demande de diagnostic et de proposition. N’accordez pas le droit de modifier lorsque vous souhaitez uniquement une analyse.

Pour migrer un dépôt, fournissez les éléments de compatibilité

Pour préparer une migration, ne fournissez pas seulement le nom de la bibliothèque à remplacer. Ajoutez les versions actuelles des dépendances, les tests, les notes d’architecture et la documentation officielle de migration.

Migre {ancienne bibliothèque ou API} vers {nouvelle bibliothèque ou API} dans le dépôt fourni.

Appuie-toi sur le code actuel, les tests existants, les versions de dépendances, les notes d’architecture et la documentation officielle jointe.

Identifie les modules, interfaces et tests affectés. Effectue les changements nécessaires dans le périmètre approuvé, notamment les usages, imports, types et tests associés.

Préserve les autres comportements. Documente les décisions de compatibilité et poursuis les étapes réversibles autorisées. N’exécute aucune transformation irréversible en production sans accord.

Utilise les outils existants du dépôt et ses commandes de test prises en charge.

Recherche les anciens usages encore présents. Effectue les tests ciblés, les vérifications de types, la compilation et le contrôle des interfaces. Examine ensuite les différences finales.

Le livrable attendu est une migration implémentée et vérifiée, ou un état précis des obstacles empêchant sa réalisation.

Remets une synthèse, les fichiers concernés, les choix de compatibilité, les résultats des vérifications et les risques résiduels.

Avec ce modèle, vous reliez l’exécution à ses preuves. N’acceptez pas une liste de modifications envisagées comme une migration terminée.

Pilotez les tâches longues sans perdre le contrôle

Autorisez la poursuite après les incidents ordinaires

Pour vos tâches comportant plusieurs étapes, surveillez les arrêts prématurés rapportés par Anthropic, notamment à faible effort. Vous pouvez recevoir une explication de ce qu’il reste à faire alors que le modèle pourrait encore poursuivre.

Distinguez dans votre consigne une difficulté récupérable d’une limite qu’il ne faut pas franchir.

Ton objectif est de terminer {livrable}, et non de fournir uniquement une proposition de travail.

Poursuis les opérations autorisées et réversibles jusqu’à leur vérification. Lorsqu’une opération ordinaire échoue, examine l’erreur et détermine si une nouvelle tentative est sûre.

Réessaie ou utilise une autre méthode seulement lorsque cela reste autorisé. Continue les étapes indépendantes qui ne dépendent pas du blocage.

Ne contourne jamais un accès refusé, une zone protégée, une contrainte de sécurité ou une approbation obligatoire.

Donne des nouvelles aux étapes importantes, puis poursuis. Un message d’avancement ne remplace pas le livrable.

Termine lorsque le travail autorisé est achevé et vérifié, ou lorsqu’un obstacle réel empêche toute poursuite permise. Présente alors le travail effectué, les contrôles, les blocages et les risques.

Autoriser la poursuite ne signifie pas demander d’insister sans limite. Vous préservez les barrières intentionnelles tout en évitant qu’un incident banal interrompe toute la mission.

Séparez la préparation des actions qui vous engagent

Ne vous contentez pas de demander un accord pour toute opération importante. Vous devez nommer les actions protégées afin d’éviter les ambiguïtés.

Examine {incident ou situation} et prépare une résolution étayée.

Tu peux lire les fichiers autorisés, consulter les journaux, rechercher dans la documentation approuvée et exécuter des contrôles non destructifs. Tu peux préparer des changements et un plan de correction, puis renouveler une lecture sûre après un échec temporaire.

Demande mon accord avant de supprimer ou d’écraser des données de production, de modifier la facturation ou les droits, de déployer, d’envoyer une communication externe ou d’effectuer une migration irréversible.

Pour chaque demande d’accord, décris l’action exacte, son impact et les possibilités de retour en arrière.

Pendant l’attente, poursuis uniquement les tâches indépendantes déjà autorisées. Mon silence ne vaut pas approbation.

Dans ton compte rendu, distingue ce qui a été observé, vérifié, préparé et ce qui nécessite encore une décision.

Faites aussi appliquer les autorisations par votre logiciel. Votre prompt décrit la politique ; il ne remplace pas les contrôles d’accès de votre environnement.

Rendez la progression visible sans demander une narration permanente

Vous pouvez avoir l’impression que l’agent reste silencieux pendant une longue séquence d’outils. Définissez les informations utiles à afficher, puis vérifiez que votre client sait les présenter.

Avant de commencer, indique brièvement l’objectif immédiat.

Pendant le travail, signale les étapes franchies, les découvertes qui changent l’analyse et les obstacles significatifs. Garde ces messages courts et ne décris pas chaque manipulation.

Après une mise à jour, reprends le travail autorisé. Ne présente pas un compte rendu intermédiaire comme une conclusion.

À la fin, fournis un bilan compréhensible sans les messages précédents, avec les résultats, les vérifications, les décisions et les problèmes non résolus.

Dans l’API, vous pouvez recevoir certaines mises à jour dans des blocs thinking, plutôt que dans des blocs de texte ordinaires. Avec l’affichage omitted, ces blocs peuvent ne pas contenir de texte lisible.

Si votre application affiche uniquement le texte standard, elle peut donc sembler inactive. Vérifiez le rendu avant de modifier uniquement votre prompt.

Sur les configurations compatibles, vous pouvez utiliser les options thinking.display, notamment updates et summarized, avec les conditions bêta correspondantes. Vérifiez leur disponibilité et leurs en-têtes sur votre plateforme. Vous ne les activez pas par le seul texte du prompt.

Déléguez des travaux indépendants, pas chaque opération

Vous pouvez accélérer certaines investigations grâce à la collaboration entre plusieurs agents. Prévoyez toutefois les échanges et la consommation supplémentaires.

Vous pouvez notamment répartir l’examen de modules distincts, une recherche documentaire séparée ou l’analyse de tests indépendants. Évitez en revanche de déléguer une tâche dépendant étroitement du prochain résultat d’un autre agent.

Pour préparer {analyse ou plan de migration}, utilise uniquement les sous-agents autorisés dans {environnement}.

Délègue une partie du travail lorsqu’elle est suffisamment indépendante et que le gain attendu justifie les échanges et les jetons supplémentaires.

Tu peux séparer l’inspection de modules distincts, la recherche documentaire et l’investigation de tests autonomes.

Évite la délégation pour une opération simple ou fortement dépendante d’un résultat encore attendu.

Donne à chaque sous-agent une question précise, le contexte utile, un périmètre et une sortie attendue. Pendant son exécution, poursuis ton propre travail indépendant.

Compare les conclusions, résous les contradictions et vérifie les points importants avant de produire un rapport commun. Ne crée pas d’agents supplémentaires uniquement pour augmenter l’activité.

Anthropic rapporte que Fable peut déléguer facilement dans les environnements qui encouragent ce comportement. Lorsque vous augmentez l’effort, vous pouvez aussi voir apparaître des agents supplémentaires de révision.

Évaluez donc l’effort et la politique de délégation ensemble. Mesurez tous les jetons, la durée globale et les doublons. Vous pouvez également attribuer des modèles différents aux sous-agents lorsque votre environnement le permet.

Exigez un rapport final autonome

La personne à qui vous transmettez le rapport n’a pas nécessairement assisté aux appels d’outils. Demandez un document qui rappelle le problème et les preuves, au lieu d’annoncer seulement une réussite.

Rédige le rapport pour une personne compétente qui n’a pas suivi les étapes intermédiaires.

Commence par l’objectif initial, le résultat principal et l’état réel d’achèvement.

Explique les modifications, leurs raisons, les preuves importantes et les vérifications effectuées. Définis les termes techniques inhabituels.

Ne renvoie pas à un ancien résultat d’outil sans en rappeler les informations nécessaires.

Sépare les résultats confirmés des propositions et des prochaines étapes. Signale les limites, les décisions attendues et les contrôles impossibles à réaliser.

Ne masque pas un travail incomplet derrière une conclusion affirmative.

Intégrez la qualité de la passation à vos critères de validation. Vous devez permettre à une autre personne d’examiner le travail sans reconstituer toute la conversation.

Assemblez un prompt complet pour un agent de développement

Après les modèles ciblés, vous pouvez rassembler leurs contrôles pour une mission de développement importante.

Tu interviens comme ingénieur logiciel dans un environnement de développement autorisé. Ta mission est de livrer {tâche complète}, avec les preuves permettant de vérifier son achèvement.

Le projet est décrit dans {description du dépôt}. Consulte {code, documentation et tests faisant autorité}. Ton intervention couvre {changements permis} et exclut {zones protégées}.

Les mainteneurs restent responsables du dépôt de production. Préserve les comportements établis en dehors de la mission. Toute extension du périmètre doit être soumise à leur accord.

Examine les fichiers pertinents, définis une approche compatible avec les contraintes, puis réalise les étapes autorisées et réversibles. Une description du travail restant ne suffit pas lorsque tu peux encore l’effectuer.

Lorsqu’une opération échoue, examine sa cause. Reprends par une tentative sûre ou une autre méthode autorisée. Continue les tâches indépendantes sans contourner les restrictions.

Utilise les outils lorsqu’ils sont nécessaires. Vérifie les chemins, identifiants et arguments. Regroupe les opérations indépendantes lorsque ton environnement le permet ; conserve l’ordre requis pour celles qui dépendent d’un résultat précédent.

Demande une approbation avant une suppression destructive, un déploiement de production, une modification irréversible des données ou un dépassement de périmètre. Précise l’impact et le retour arrière possible. N’interprète pas l’absence de réponse comme un accord.

Délègue seulement les tâches indépendantes dont le bénéfice justifie le coût. Fournis un contexte limité à chaque sous-agent et vérifie ses conclusions avant de les intégrer.

Signale les étapes significatives sans raconter toutes les manipulations. Après une mise à jour, poursuis le travail permis.

Exécute les tests pertinents, contrôle les interfaces affectées et examine les différences finales. Vérifie chaque critère d’acceptation. Consigne aussi les tests qui n’ont pas pu être lancés et leur raison.

Remets un rapport autonome indiquant le résultat, les principales décisions d’implémentation, tous les fichiers modifiés, les tests et leurs résultats, les risques, les limites et les blocages.

Termine lorsque le livrable autorisé est achevé et vérifié, ou lorsqu’un obstacle réel empêche toute poursuite permise. Décris fidèlement ce qui reste incomplet.

Utilisez ce modèle comme point de départ pour un agent autorisé. Ne l’imposez pas à chaque conversation. Pour une mission simple, vous pouvez ne conserver qu’une partie de ces précautions.

Migrez vers Fable 5.2 sans fragiliser votre intégration

Auditez les règles héritées avant d’en ajouter

Vous pouvez accumuler des instructions dans les prompts système, les compétences, les notes et les fichiers de vos agents. Une précaution utile après un incident peut devenir excessive si vous l’appliquez partout.

Si vous interdisez toute nouvelle tentative après un échec, vous risquez par exemple d’empêcher une simple lecture après une panne temporaire. Examinez donc les règles existantes avant d’ajouter d’autres interdictions.

Pour auditer les instructions et la mémoire conservées dans votre projet, vous pouvez demander :

Examine {prompt système}, {descriptions d’outils}, {règles d’agent} et {notes de session}.

Repère les répétitions, contradictions, exigences d’approbation imprécises, précautions périmées et règles sans périmètre clair.

Pour chaque problème, identifie le passage concerné, explique son effet possible et reconstitue son objectif initial à partir des informations disponibles.

Propose une formulation mieux délimitée et indique si une validation humaine est nécessaire.

Ne supprime pas silencieusement une protection et n’affaiblis pas les contrôles d’accès.

Livre une version proposée ainsi qu’un plan de tests permettant de vérifier qu’elle conserve les comportements nécessaires.

Appliquez les révisions dans une nouvelle conversation ou via les mécanismes d’ajout pris en charge. En modifiant les anciens messages d’une session active, vous pouvez casser la conservation du raisonnement.

Changez l’identifiant, puis réévaluez le comportement

Pour migrer, remplacez claude-fable-5-1 par claude-fable-5-2. Ne considérez toutefois pas ce changement comme une validation de votre intégration.

Rejouez vos évaluations en conservant les tâches et les critères. Comparez la qualité, l’achèvement, la durée et les jetons. Ne supposez pas qu’un réglage high est équivalent entre deux versions.

Vérifiez aussi vos anciens prompts qui tentent de limiter la réflexion par des injonctions textuelles. Dans Fable 5.2, utilisez le contrôle d’effort pour remplir ce rôle.

Conservez le préfixe de conversation et les blocs requis

Le raisonnement conservé est lié au contenu précédent de votre conversation. Si vous modifiez system, tools ou d’anciens messages, puis renvoyez les blocs associés à l’ancien contexte, l’API peut rejeter votre requête.

Conservez les instructions et les outils initiaux, puis ajoutez les échanges successifs. Après une réponse de l’assistant, transmettez les résultats d’outils et les nouveaux messages sans réécrire arbitrairement le préfixe.

Préservez les blocs nécessaires et leur ordre. Dans votre boucle d’agent, ne reconstruisez pas l’historique à partir du seul texte visible.

Pour réutiliser les blocs d’un tour précédent, votre conversation doit satisfaire les contrôles du préfixe prévus par l’API.

Vous pouvez également examiner l’option drop_block pour certaines incompatibilités. Ne l’utilisez pas comme un remplacement d’une gestion correcte de l’historique : supprimer des blocs peut entraîner un raisonnement répété et une consommation supplémentaire.

🚨 Je crois qu’on ne se rend pas bien compte de ce qui vient de se passer cette nuit Anthropic vient de sortir Claude Fable 5.2 Alors, je vous ai résumé ce qu’il peut faire, c’est tout aussi magnifique que terrifiant 1. En ingénierie des système éléctronique c’est le choc À partir d’un seul paragraphe, il a conçu trois appareils électroniques qui marchent. Dont un assistant vocal pour la maison. Il a écrit les specs, choisi les composants, routé une carte à quatre couches, dessiné le boîtier pour l’impression 3D, et programmé le logiciel. Selon Anthropic, les trois ont fonctionné sans aucune modification. 2. Il a refait un Windows solo sans se baser sur rien Un ingénieur d’Anthropic lui a demandé de construire un système d’exploitation à partir d’un dossier vide. Plus de 1 000 agents, 8 jours, sans interruption. Le prototype, d’après eux, démarre sur un laptop : kernel, pilotes, fenêtres, écran de connexion, installeur. 3. En Mathématiques il a formalisé tout le théorème de Fermat 1 000 agents. 30 heures. Le théorème de Fermat, entièrement formalisé, traduit dans un langage qu’un ordinateur peut vérifier étape par étape. Avec le même protocole, Opus 5.5 était à 26 % au bout de 18 heures, et n’avançait presque plus après 30. 4. Sur les Jeux vidéo, c’est limite criminel Un ingénieur d’Anthropic lui a envoyé des prompts en une seule passe, sans aucune correction humaine. 8 heures plus tard : un FPS 3D jouable dans le navigateur. Modèles, sons, textures, tout créé de zéro. Environ 550 dollars de compute. On peut le lancer je vous en ai mis d’autres dans les commentaires 5. En imagerie et peinture ALors c’est un peu contre intuitif mais Il peint. Pas avec un modèle d’image mais avec du code. Des programmes Python de 1 000 à 2 000 lignes, qui placent chaque coup de pinceau un par un. Une des toiles, poussée jusqu’à ressembler à une photo, fait environ 700 000 coups de brosse 6. En physique théorique Selon Anthropic, il a résolu deux problèmes ouverts en physique des trous noirs. Sur le premier, il a terminé un calcul qui restait ouvert depuis 23 ans. Les preprints sont en ligne. 7. En robotique Il pilote des robots, y compris sur des tâches pour lesquelles il n’a jamais été entraîné. Sur RoboDojo, un benchmark avec un robot à deux bras en simulation, il devance les autres modèles et la plupart des systèmes conçus pour ça. Et sur le classement indépendant d’Artificial Analysis, il passe n°1, à 65. Devant Gemini 4 Carbon (60) et Opus 5.5 (59) C’est juste avant l’IPO, ils ont all in sur cette sortie, je vous avoue que c’est un gros tour de force. Evidemment, ça a vocation à pousser l’IPO, mais la lecture va au dela On vit dans une période incroyable

— Frenchie (@Frenchie_) November 10, 2026

Vérifiez les outils et les paramètres incompatibles

Sur les plateformes concernées, remplacez l’ancien outil computer_20251124 par computer_toolset_20260801.

Adaptez également la boucle qui traite les appels d’outils. Ne vous contentez pas de changer un nom dans la configuration. Pour Amazon Bedrock, vérifiez l’exception de compatibilité documentée et les exigences de votre déploiement.

Examinez ensuite la sélection forcée. Vous ne pouvez pas utiliser les valeurs any et tool de tool_choice dans la configuration décrite. Utilisez la sélection automatique et les mécanismes compatibles pour guider les appels.

Lorsque la validation de schéma est disponible, vous pouvez l’utiliser pour contrôler la structure attendue. Ne supposez toutefois pas qu’elle est accessible dans tous les environnements.

Enfin, omettez temperature, top_p et top_k dans les requêtes concernées. Ne cherchez pas à corriger ces incompatibilités avec un prompt plus détaillé : vous devez modifier les paramètres de la requête.

Testez le budget, le conseiller et le repli

Dans votre application, sélectionnez les blocs de réponse par leur type. Ne supposez pas que le premier bloc contient toujours du texte ordinaire.

Testez les réponses longues, mais aussi les petits budgets de sortie. Le raisonnement peut consommer votre enveloppe avant l’apparition d’un résultat substantiel.

Si vous utilisez l’outil de conseil avec un exécutant Fable 5.2, choisissez un conseiller compatible Fable 5.2 ou Mythos 5.2. Ne considérez pas les anciens conseillers comme automatiquement interchangeables.

Testez séparément le repli vers un autre modèle. Vérifiez que votre application sait traiter sa réponse, les refus et les éventuelles différences de structure. La compatibilité du conseiller ne vous garantit pas celle de tous les mécanismes de secours.

Examinez l’effort par message et ses effets sur le cache

Sur les plateformes compatibles, vous pouvez utiliser une option bêta pour modifier l’effort au cours d’une conversation.

Vous pouvez ainsi préserver la réutilisation du cache tout en adaptant l’effort à certaines étapes. En modifiant le réglage global entre les requêtes, vous pouvez au contraire réinitialiser le cache du préfixe concerné.

Pour utiliser ce mécanisme d’effort par message, vérifiez sa disponibilité et sa syntaxe sur votre plateforme, plutôt que de modifier arbitrairement les anciens échanges.

Vérifiez le traitement des données avant les tâches sensibles

Avant de transmettre des informations sensibles, vérifiez les conditions de conservation applicables. La conservation prévue est de 30 jours, avec une autorisation explicite nécessaire pour bénéficier d’autres conditions. Ne déduisez donc pas votre régime de confidentialité du seul accès au modèle.

Examinez séparément Enterprise Frontier Safeguards et les possibilités accordées aux clients éligibles par Anthropic. Vérifiez les conditions de votre organisation avant de migrer des données sensibles.

Contrôlez séparément les droits d’accès, la conservation, le chiffrement et les fonctions disponibles. Ne déduisez pas l’ensemble de ces garanties de la seule présence du modèle dans votre interface.

Évaluez vos résultats et corrigez les erreurs récurrentes

Comparez les prompts sur les mêmes tâches

En ajoutant des instructions, vous pouvez améliorer un cas et en dégrader un autre. Pour évaluer une IA sur votre propre projet, utilisez des situations ordinaires, difficiles et déjà échouées.

Évalue {prompt actuel} et {prompt révisé} sur {cas représentatifs}.

Conserve le même modèle, le même effort, les mêmes outils et les mêmes données pour les deux variantes.

Examine l’achèvement, l’exactitude, le respect du périmètre, le choix des outils, la qualité des vérifications, l’utilité du livrable et la reprise après erreur.

Mesure également les jetons, le coût et la durée totale. Utilise des tests déterministes lorsque le résultat peut être contrôlé automatiquement.

Inclus des tâches ordinaires, des cas difficiles et les échecs déjà observés. Signale les évaluations incertaines.

Présente les résultats de chaque version, les régressions, les différences de coût et de durée, puis ta recommandation et les tests encore nécessaires.

Ne changez qu’un levier à la fois. Pour tester l’effort, gardez le prompt constant. Pour tester le prompt, gardez l’effort constant. Sinon, vous ne pourrez pas attribuer clairement les différences observées.

Utilisez PrompTessor comme outil de conception, pas comme environnement d’exécution

Vous pouvez utiliser PrompTessor pour générer, analyser, optimiser, affiner et réutiliser vos prompts. Employez-le pour préparer les instructions, sans le confondre avec l’environnement qui exécutera votre tâche.

Pour partir d’une demande vague, décrivez le problème observé, les documents disponibles, les changements autorisés et le résultat attendu. Vous pouvez ensuite utiliser le générateur pour organiser ces éléments.

Pour améliorer un prompt existant, ciblez les défauts constatés. Si l’agent s’arrête trop tôt, clarifiez les conditions de fin. S’il modifie trop de fichiers, resserrez le périmètre. S’il multiplie les sous-agents, revoyez la délégation.

Reliez chaque révision à un comportement observé, plutôt qu’à une volonté abstraite de rendre votre prompt plus sophistiqué.

Préparez une variante, exécutez-la dans votre environnement réel, examinez les résultats, puis révisez et retestez. Ne remplacez pas les mesures et la comparaison par le seul usage d’un outil de conception.

Vous devez toujours configurer l’identifiant du modèle, l’effort, les permissions, les outils, le cache et l’historique dans l’application utilisant Claude. PrompTessor ne règle pas ces éléments à votre place.

Reconnaissez les quatorze erreurs fréquentes

Pour diagnostiquer un problème, examinez ces quatorze erreurs fréquentes, regroupées selon les symptômes que vous pouvez observer.

Ne déduisez pas d’une consommation élevée que votre tâche exige max

Vous commettez une première erreur en utilisant systématiquement ce niveau, puis une autre en essayant de réduire la réflexion par une simple instruction textuelle. Comparez les réglages réels plutôt que de faire lutter votre prompt contre la configuration.

Ne confondez pas un plan ou un point d’avancement avec un travail terminé

Si vous oubliez de définir l’achèvement, l’agent peut s’arrêter trop tôt. Si vous acceptez ensuite son message intermédiaire comme un résultat final, vous masquez ce défaut. Vérifiez le livrable et les contrôles attendus.

Définissez explicitement le rôle et les autorisations

En accordant une responsabilité architecturale trop large, vous favorisez les modifications non demandées. Avec une règle d’approbation vague, vous risquez au contraire de bloquer des opérations bénignes sans protéger clairement les actions sensibles.

Ne comptez pas sur le texte du prompt pour créer les outils ou leur affichage

Demander de naviguer ou d’interroger une base ne fournit pas ces accès. Si vous attendez des nouvelles sans gérer les blocs de progression, vous pouvez aussi avoir l’impression que l’agent reste silencieux.

N’associez pas automatiquement plus d’agents et plus de règles à un meilleur travail

En déléguant chaque petite opération, vous ajoutez des coûts de coordination. En réutilisant les anciennes instructions sans audit, vous pouvez imposer des précautions inutiles ou des actions répétitives.

Ne traitez pas chaque erreur API comme un problème de formulation

Si vous réécrivez l’historique tout en conservant les anciens blocs de raisonnement, vous pouvez invalider la conversation. Vérifiez également les paramètres incompatibles et les outils obsolètes qui empêcheraient votre requête d’aboutir.

Distinguez la capacité de votre modèle de votre méthode de mesure

Un grand contexte ne rend pas vos sources fiables. Si vous changez simultanément le modèle, le prompt et l’effort, vous ne pouvez ensuite plus comprendre l’origine d’une amélioration ou d’une régression.

https://t.co/AAWIZD1pNL

— Anatoli Kopadze (@AnatoliKopadze) May 22, 2026

Contrôlez votre configuration avant une utilisation importante

Avant un travail répétitif ou sensible, relisez la mission comme un ensemble. Avez-vous explicitement défini le livrable ? Vos critères d’acceptation permettent-ils de distinguer un résultat complet d’une réponse simplement rassurante ? Avez-vous évité de remplacer ces critères par des injonctions à réfléchir davantage ?

Examinez ensuite le contexte

Avez-vous identifié les sources qui font autorité ? Leur date et leur pertinence correspondent-elles à votre question ? Pourrez-vous vérifier les citations importantes ? Avez-vous demandé de signaler les informations manquantes plutôt que de les déduire ?

Vérifiez les limites d’intervention

La responsabilité que vous attribuez au modèle correspond-elle au périmètre ? Avez-vous identifié les fichiers et comportements protégés ? Avez-vous bloqué les actions destructives ou irréversibles par de véritables permissions et imposé un accord explicite ?

Contrôlez également l’exécution

Avez-vous fourni les outils nécessaires ? Avez-vous précisé quand l’agent peut reprendre après un incident ordinaire et quand il doit s’arrêter ? Attendez-vous un bénéfice réel de la délégation ? Vos utilisateurs verront-ils les mises à jour appropriées ?

Revenez au budget et à l’intégration

Avez-vous évalué l’effort sur ce modèle ? Un niveau inférieur satisfait-il déjà vos exigences ? Votre budget de sortie, votre cache, vos paramètres et votre gestion des blocs sont-ils compatibles avec l’application ?

Enfin, examinez la vérification finale

Avez-vous défini les tests ? Avez-vous inclus des cas ayant déjà échoué ? Votre rapport permettra-t-il de retrouver les changements, les preuves, les contrôles impossibles et les risques ?

Permettez à votre agent de signaler honnêtement un travail incomplet. En le poussant uniquement à annoncer une réussite, vous vous privez des informations nécessaires pour décider si le résultat peut être utilisé.

Votre objectif reste un résultat utilisable, pas une exécution impressionnante

Pour guider Fable 5.2, vous prenezz plusieurs décisions complémentaires. Vous définissez le résultat, fournissez les preuves, choisissez l’effort et limitez les actions. Votre application doit ensuite rendre ces choix effectifs.

Ne recherchez un raisonnement plus long, un contexte plus vaste ou davantage de sous-agents que s’ils améliorent le travail obtenu. Leur présence ne vous apporte pas, à elle seule, une preuve de qualité.

Retenez la configuration qui produit régulièrement un résultat vérifié, dans votre périmètre, avec des permissions maîtrisées et un coût acceptable. Appuyez vos prochaines modifications de prompts sur cette mesure.

FAQ sur le guide de prompting Fable 5.2

Faut-il utiliser un prompt long pour chaque demande ?

Non. Pour une tâche courte, vous pouvez vous limiter à un objectif clair, au contexte nécessaire et au format attendu. Utilisez les modèles développés surtout pour vos travaux complexes ou sensibles. Ajoutez des instructions lorsqu’elles répondent à une difficulté réelle : source incertaine, périmètre mal respecté, action protégée ou vérification insuffisante.

Pouvez-vous coller output_config.effort dans une conversation Claude ?

Ce paramètre appartient à la configuration de votre requête API. En le collant dans un message, vous ne garantissez donc pas son application. Dans Claude Code, vous disposez notamment de la commande /effort. Pour les autres interfaces, utilisez les contrôles effectivement proposés plutôt que de traiter un fragment JSON comme une instruction de configuration.

Peut-on désactiver complètement le raisonnement de Fable 5.2 ?

Non, vous utilisez un raisonnement adaptatif toujours actif. Pour réduire la durée ou la consommation, testez un effort inférieur. Vous pouvez demander une réponse courte pour en contrôler le format, mais cette consigne ne remplace pas le réglage. Évaluez séparément l’effort de raisonnement et la qualité du résultat obtenu.

Pourquoi une requête peut-elle finir sans réponse finale substantielle ?

Avec un budget de sortie trop faible, vous pouvez épuiser l’enveloppe pendant le raisonnement, avant la production d’un texte final développé. Examinez le motif d’arrêt et les blocs reçus. Distinguez leurs types dans votre application, puis ajustez le budget ou l’effort selon le problème constaté. Ne supposez pas que l’absence de texte signifie toujours une panne.

Pouvez-vous réutiliser vos prompts de Fable 5.1 ?

Oui, vous pouvez les conserver comme point de départ. Réévaluez toutefois les consignes relatives à l’effort, aux arrêts prématurés, à la propriété du code, aux approbations et à la délégation. Vérifiez également votre intégration technique. Une formulation encore pertinente ne garantit pas que vos anciens outils, paramètres et traitements de réponse restent compatibles.

Tous les sous-agents doivent-ils utiliser Fable 5.2 ?

Non, vous pouvez attribuer différents modèles aux sous-agents selon votre environnement. Vous pouvez aussi utiliser Fable comme conseiller ou orchestrateur travaillant avec des modèles plus légers, comme le présente Anthropic. Configurez et évaluez cette répartition : votre prompt seul ne garantit ni le modèle utilisé par chaque agent ni l’économie obtenue

Une fenêtre d’un million de jetons réduit-elle automatiquement les erreurs ?

Non. Vous disposez d’une capacité de contexte, pas d’une garantie sur la fiabilité des documents ou leur exploitation. Sélectionnez les sources pertinentes, précisez leur autorité et demandez des preuves. Pour les images, confrontez les calculs importants aux données originales. Pour vos recherches actuelles, fournissez des documents accessibles et datés. ^[1]

PrompTessor remplace-t-il les tests de vos prompts ?

Non. Utilisez-le pour concevoir et améliorer vos instructions, puis exécutez chaque variante dans l’environnement où vous comptez l’utiliser, avec ses outils et ses permissions. Mesurez l’exactitude, l’achèvement, le coût et la durée. Vérifiez ensuite les régressions avant de retenir une nouvelle version de votre prompt.

Partager l'article :
• Facebook
• Twitter
• LinkedIn