Claude Platform Docs
Bonnes pratiquesIngénierie de prompts

Rédiger des prompts pour Claude Fable 5.2

Modèles de prompting propres à Claude Fable 5.2 et Claude Mythos 5.2 : effort, arrêt prématuré, approbations, propriété du code, mises à jour de progression, sous-agents, prudence qui s’accumule, instructions rédigées pour des modèles antérieurs, rapports finaux et refus.

Ce guide couvre les modèles de prompting propres à Claude Fable 5.2. Pour les capacités du modèle et les changements de l’API, consultez Nouveautés de Claude Fable 5.2. Pour les techniques qui s’appliquent à tous les modèles Claude actuels, consultez Bonnes pratiques de prompting.

Claude Fable 5.2 se comporte différemment des modèles antérieurs sur quelques points. Commencez par la section qui correspond à ce que vous observez :

Calibrer l’effort

Commencez à high, la valeur par défaut sur l’API Claude. Si votre cas d’usage l’exige, augmentez ou diminuez l’effort, et testez chaque changement avec vos propres évaluations. Le niveau d’« effort » (effort de raisonnement) détermine à quel point Claude Fable 5.2 réfléchit, la durée d’un tour et le nombre de tokens qu’il utilise. Ajustez l’effort en même temps que votre prompt, car le niveau modifie aussi la façon dont le modèle réfléchit et le nombre d’appels d’outils qu’il effectue.

En général, les niveaux d’effort suivent le même ordre d’un modèle Claude à l’autre, mais la quantité de réflexion derrière chaque niveau peut varier selon le modèle. Relancez donc votre balayage des niveaux d’effort au lieu de reprendre un réglage que vous aviez ajusté sur Claude Fable 5.1 ou Claude Opus 5.5.

Choisissez un niveau selon le type de travail :

  • low convient aux échanges rapides, aux tâches bien spécifiées et aux charges de travail à fort volume, comme des sous-agents rapides et intelligents. Lors des tests d’Anthropic, les scores du modèle à low étaient proches de ceux de Claude Fable 5.1 à des niveaux d’effort plus élevés.
  • medium convient au codage interactif, au chat et au travail intellectuel quotidien.
  • high convient au codage difficile, à la recherche, au travail agentique et aux longues exécutions sans surveillance. Les tours prennent nettement plus de temps à se terminer qu’à medium.
  • xhigh est destiné à vos travaux de codage et agentiques de longue durée les plus difficiles, pour lesquels vous avez mesuré un gain. Sur les évaluations de codage internes d’Anthropic, il a légèrement amélioré les scores et utilisé beaucoup plus de tokens.
  • max sert à mesurer le plafond du modèle, ou pour la tâche rare où le temps et les tokens n’ont pas d’importance. Il convient surtout aux problèmes ouverts, comme la découverte scientifique et les mathématiques. Les tours sont lents et utilisent beaucoup plus de tokens qu’à xhigh.

L’essentiel du gain de capacité est déjà présent à high. Le passage de medium à high a amélioré les scores sur la plupart des évaluations de codage et de travail intellectuel suivies par Anthropic. Ce passage utilise aussi plus de tokens et plus de temps ; descendez donc à medium partout où vos évaluations montrent que la qualité se maintient. Au-dessus de high, les gains sont inégaux et dépendent de la tâche.

Lorsque vous choisissez un niveau, notez trois comportements :

  • Le modèle est plus susceptible de s’arrêter prématurément à des niveaux d’effort plus bas. Pour le travail agentique à low ou medium, ajoutez le texte de Terminer la tâche entière.
  • À high et au-dessus, le modèle réfléchit avant presque chaque réponse, y compris une réponse à une salutation. Si les requêtes simples prennent trop de temps ou coûtent trop cher, utilisez un niveau d’effort plus bas pour ces tours. Lors des tests d’Anthropic, une instruction demandant de répondre directement sans délibérer n’a pas empêché le modèle de réfléchir à medium et au-dessus.
  • L’effort ne modifie guère la longueur des réponses du modèle. Pour modifier la longueur et le ton d’une réponse, utilisez votre prompt.

Vous pouvez aussi combiner plusieurs niveaux dans un même flux de travail. Par exemple, vous pouvez planifier et itérer avec le modèle à medium, puis augmenter l’effort pour la longue partie sans surveillance. Pour changer de niveau au sein d’une conversation tout en conservant le cache des prompts, utilisez un changement d’effort par message (bêta, en-tête mid-conversation-output-config-2026-07-01) ; cette section liste les plateformes où il est disponible. Un changement reste en vigueur jusqu’à ce qu’un autre le remplace. Là où l’effort par message n’est pas disponible, définissez une nouvelle valeur effort de premier niveau dans la requête suivante, ce qui réinitialise le cache.

Terminer la tâche entière

Sur les tâches longues en plusieurs étapes, Claude Fable 5.2 termine parfois un tour avant que le travail soit fait. Le tour se clôt sur une liste de ce qui reste, une proposition de continuer, ou un arrêt face à un obstacle ordinaire comme un délai d’expiration. Cela se produit plus souvent à un effort low et medium.

Si vous observez ces arrêts dans votre agent, ajoutez un texte comme celui-ci à votre invite système :

# Finishing work
Please avoid stopping while you still owe work the user asked for. Be persistent and do not stop unless needed.

While status notes are welcome, as is clarifying with the user on open decisions, carry on with work that does not depend on the user's answer without unnecessary stops.

If you notice yourself inviting the user to redirect you or offering to wait, instead proceed on the next part of the task. You may meet ordinary obstacles like errors, timeouts, locked files, empty results or failing tools. Diagnose them first, and when they are not real blockers, work through them with the access you have (wait and retry, fix the request, use another tool or source) rather than stopping unnecessarily.

If someone clearly decided something is a hard blocker, such as a file marked not to be touched, access that was intentionally withheld, or a safety guardrail, leave it alone, say plainly what you found, and look for another safe way to finish the task. Stopping before the task is complete is very rarely merited, as in when the task can't move forward without user input, or where the blocker is deliberate and should not be worked past. This does not override the need for confirmation on risky or destructive actions.

Ce texte distingue deux types d’obstacles. Il indique au modèle de diagnostiquer et de surmonter les obstacles ordinaires, tels que les erreurs, les délais d’expiration et les outils défaillants. Il lui indique de laisser de côté les blocages délibérés, comme un fichier marqué comme ne devant pas être modifié, et de les signaler. Considérez ce texte comme un point de départ, et conservez cette distinction lorsque vous l’adaptez à votre application.

Anthropic a rejoué des sessions enregistrées d’un produit de codage agentique à un effort medium. Avec une version de ce texte, environ deux fois moins de sessions se sont terminées en laissant du travail réalisable. Le texte a supprimé la plupart des fins qui demandent la permission ou proposent de continuer, mais pas les fins qui listent ce qui reste puis s’arrêtent. Les tokens de sortie ont augmenté d’environ 30 pour cent.

Comme le modèle demande moins souvent avec ce texte, conservez votre propre étape de confirmation pour les actions risquées ou irréversibles.

Approbations

Lorsque vous dites au modèle de continuer, indiquez clairement ce que vous attendez de lui au lieu d’envoyer un simple « continue ». Par exemple, répondez « Oui, lance la migration sur la base de données de préproduction » là où vous auriez envoyé « vas-y » ou un pouce levé.

Si votre invite système contient des règles d’approbation, nommez les actions exactes qu’elles couvrent, car le modèle les applique telles qu’elles sont écrites. Lors des tests d’Anthropic sur des tâches simulées sans personne pour approuver, une règle listait « envoyer des messages à des personnes extérieures à cette conversation » parmi les étapes nécessitant une approbation. Avec cette règle, le modèle a retenu environ la moitié de ses demandes de routine adressées à des collègues et à d’autres équipes.

Indiquer à qui appartient le code

Claude Fable 5.2 réagit étroitement à ce que le prompt dit de qui possède le code sur lequel il travaille. Lors des tests d’Anthropic sur de petites tâches de codage, lorsqu’un prompt ne disait rien de la propriété ou présentait la base de code comme appartenant à quelqu’un d’autre, le modèle avait tendance à ajouter à la structure existante, même lorsque cela dupliquait du code existant. Il avait aussi tendance à signaler les problèmes voisins au lieu de les corriger. Lorsque le prompt indique que la base de code appartient au modèle, celui-ci fusionne souvent le code dupliqué et effectue des corrections connexes sans qu’on le lui demande.

Si vous voulez que le modèle améliore la structure au fil de son travail, indiquez que le code lui appartient :

This codebase is yours: what it's for and how it's built are your call, and you'll keep building on it.

Lors des tests d’Anthropic sur de petites tâches de codage, le modèle a fusionné le code dupliqué dans environ la moitié des essais avec cette phrase, et dans moins d’un dixième des essais sans elle. Le taux variait selon la tâche. Le résultat s’est maintenu lorsque la phrase figurait dans une longue invite système. La fonctionnalité demandée a fonctionné dans presque tous les essais dans les deux cas.

Lors des mêmes tests, le modèle a aussi utilisé environ 1,5 fois plus de tokens de sortie avec la phrase et a effectué plusieurs modifications que personne n’avait demandées, dont beaucoup de nouveaux tests et de la documentation. Hors corrections de bugs, il a modifié le comportement d’une fonctionnalité existante dans un essai sur six à dix, et plus souvent à un effort plus élevé. Son résumé final mentionnait les modifications importantes mais omettait souvent les petites ; examinez donc le diff et pas seulement le résumé.

Omettez la phrase sur la propriété lorsque le code appartient à l’utilisateur et qu’il souhaite qu’il soit modifié le moins possible. Une règle ailleurs dans le prompt qui limite le périmètre n’annule pas la phrase sur la propriété. Lors des tests d’Anthropic, avec « No drive-by refactors, renames or cleanups » plus haut dans le même prompt, le modèle a tout de même fusionné le code dupliqué dans environ un tiers des essais.

Tenir les utilisateurs informés pendant les longs tours

Claude Fable 5.2 écrit parfois peu de texte destiné à l’utilisateur pendant les longues séries d’appels d’outils. Le modèle peut aussi effectuer son premier appel d’outil sans dire ce qu’il s’apprête à faire.

Vérifiez d’abord que votre client reçoit les mises à jour du modèle. Sur Claude Fable 5.2, les mises à jour que le modèle écrit entre les appels d’outils sont renvoyées sous forme de blocs thinking de mise à jour de progression. Ces mises à jour indiquent ce que le modèle a trouvé et ce qu’il fait ensuite. Leur texte est vide avec la valeur par défaut "omitted" de thinking.display. Ainsi, un client qui n’affiche que les blocs text peut sembler silencieux pendant un long tour agentique. Définissez display: "updates" (bêta, en-tête thinking-display-updates-2026-08-18) pour recevoir un court résumé de chaque mise à jour, ou "summarized" pour recevoir les mises à jour accompagnées d’un raisonnement résumé. Affichez ensuite les blocs thinking non vides entre les appels d’outils.

Des mises à jour fréquentes comptent surtout lorsqu’un utilisateur suit le travail en temps réel, comme en codage interactif. Si vos utilisateurs suivent le travail et reçoivent encore trop peu de mises à jour, utilisez une ou plusieurs de ces options.

Si vous pouvez modifier votre « harness » (environnement d’exécution de l’agent), une option efficace consiste à lui faire compter les étapes consécutives d’appel d’outils qui ne donnent rien à lire à l’utilisateur : aucun bloc text et aucun bloc thinking contenant du texte. Comptez avec display défini sur "updates" ou "summarized", car avec "omitted" chaque bloc thinking est vide. Cette option fonctionne là où votre plateforme prend en charge les messages système en cours de conversation. Après plusieurs étapes consécutives de ce type, faites ajouter par le harness ce rappel après les derniers résultats d’outils sous forme de message système limité au tour (clear_at: "next_user_message", bêta, en-tête mid-conversation-system-clear-at-2026-08-21) :

The user hasn't heard from you in a while: say in a few words what you're doing, then continue.

Lors des tests d’Anthropic sur des tâches de codage à plusieurs tours, le rappel a réduit de moitié environ la plus longue période silencieuse, sans augmentation notable des tokens ni du temps.

Laissez chaque rappel dans messages lors des requêtes suivantes. En supprimer ou en reformuler un modifie un tour antérieur, ce qui invalide les blocs de réflexion qui le suivent. Consultez Envoyer les rappels par tour sous forme de messages système limités au tour.

Pour obtenir également une phrase d’introduction avant le premier appel d’outil, de brèves mises à jour et un récapitulatif final, ajoutez ce texte à votre invite 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 (what you found, what you did, and what's next), so a reader who only sees the last message has the full picture.

Lors des tests d’Anthropic sur des tâches de codage, le modèle s’est exprimé avant son premier appel d’outil à chaque fois avec ce texte. Le texte a aussi augmenté les tokens de sortie par tâche d’environ 20 pour cent. Utilisez ce texte lorsqu’un humain est directement impliqué dans la boucle. Pour obtenir le plus de mises à jour, associez-le au rappel que votre harness ajoute.

Si vous ne pouvez pas modifier le harness, ou si votre plateforme ne propose pas de messages système en cours de conversation, ajoutez cette phrase à votre invite système :

Every few tool calls, give the user a one-line update on where things stand.

Lors des tests d’Anthropic sur des tâches d’automatisation de flux de travail, cette phrase a supprimé la plupart des longues périodes silencieuses.

Même avec le rappel et le texte d’introduction et de récapitulatif combinés, attendez-vous à des séries de plusieurs appels d’outils entre les mises à jour. Claude Fable 5.2 fonctionne bien sur les tâches asynchrones de longue durée, où l’utilisateur revient chercher le résultat au lieu de suivre chaque étape. Les intervalles entre les mises à jour y comptent moins.

Fixer des attentes pour les sous-agents

La quantité de travail que Claude Fable 5.2 délègue aux « subagents » (sous-agents) dépend de votre harness et de vos tâches. Lors des tests d’Anthropic sur des tâches courtes avec un outil minimal pour lancer des sous-agents, il en lançait rarement. Dans un produit de codage agentique dont les prompts invitent à la délégation, il délègue volontiers.

Si votre invite système, vos skills ou vos fichiers d’agent demandent au modèle de déléguer, examinez d’abord ces lignes. Ne modifiez la description de l’outil qui lance des sous-agents que si Claude Fable 5.2 lance toujours plus de sous-agents que vos tâches n’en nécessitent. Si l’outil a une description simple et que rien d’autre dans vos prompts ne demande de délégation, vous n’avez probablement pas besoin d’une nouvelle description.

Dans la nouvelle description, indiquez ce qu’un sous-agent ajoute au coût d’une session, dites quand la délégation en vaut la peine et quand elle ne la vaut pas, et indiquez au modèle comment briefer un sous-agent qu’il lance. La description testée par Anthropic fait ces trois choses et place le coût en premier. Une description de ce type est surtout utile lorsque votre harness invite déjà à la délégation et que les sous-agents représentent une part importante de votre utilisation de tokens.

Lors des tests d’Anthropic sur des tâches courtes, le modèle a délégué moins souvent d’environ un tiers avec la description testée qu’avec une description qui énumérait principalement des raisons de déléguer. Le taux de réussite des tâches était le même.

Dans la description testée, les phrases d’ouverture sur le coût freinent la délégation. Parlez moins du coût si le modèle délègue trop peu. S’il délègue encore trop, détaillez davantage ce que coûte un sous-agent dans votre harness, et testez le changement.

Anthropic a aussi observé Claude Fable 5.2 utiliser des sous-agents pour relire son propre travail dans un produit de codage agentique à des niveaux d’effort plus élevés, comme xhigh et max. Claude Fable 5.1 ne le faisait pas sur les mêmes tâches. Les premiers testeurs ont obtenu de bons résultats avec Claude Fable 5.2 comme planificateur et orchestrateur d’autres modèles. La délégation peut accélérer le travail qui se parallélise bien. Cependant, les sous-agents peuvent représenter une grande part du coût d’une session ; vérifiez donc sur quel modèle votre harness exécute les sous-agents par défaut.

Empêcher la prudence de s’accumuler

Les instructions prudentes s’accumulent partout où le contexte est reporté : mémoire, notes, fichiers d’instructions et messages entre agents. Claude Fable 5.2 suit ces instructions de près ; il peut donc demander des approbations dont il n’a pas besoin ou retenir du travail de routine. Quelques premiers testeurs ont observé ce comportement, surtout là où plusieurs agents travaillent ensemble. Les modèles antérieurs suivent aussi de telles instructions, mais dans l’une des configurations décrites ici, seul Claude Fable 5.2 s’est retenu.

Si vous observez ce comportement, nettoyez ce que vos agents transportent :

  • Supprimez les notes dont vous n’avez plus besoin. Lors des tests d’Anthropic sur des tâches simulées, l’une d’une douzaine de notes issues de sessions antérieures disait de ne jamais réessayer. Avec ces notes dans le contexte, et sans rien dans le prompt autorisant les nouvelles tentatives, le modèle a réessayé après qu’un outil était occupé dans environ quatre essais sur dix, contre presque tous sans ces notes.
  • Nommez les étapes qui ne nécessitent aucune approbation. Lors des tests d’Anthropic sur des tâches simulées, le contexte contenait des règles « jamais », des notes et les conditions d’un relecteur. Une ligne à la fin des règles, listant les nouvelles tentatives parmi les étapes ne nécessitant aucune approbation, a fait passer les nouvelles tentatives de presque aucune à environ la moitié des essais. Dans la même configuration, une instruction générale invitant à agir plus librement n’a rien changé. Ne nommez les nouvelles tentatives que pour les appels qu’il est sûr de répéter.
  • Vérifiez ce que les agents relecteurs ajoutent. Lors des tests d’Anthropic sur des tâches simulées, une configuration comportait une ligne dans le prompt listant les nouvelles tentatives parmi les étapes ne nécessitant aucune approbation, et un « arrête-toi à la première erreur » d’un relecteur dans le contexte. Claude Fable 5.2 n’a pas réessayé dans environ un tiers des essais. Claude Fable 5.1 et Claude Opus 5.5 ont réessayé.
  • Intégrez l’exception dans la règle. Lors des tests d’Anthropic sur des tâches simulées, la personne responsable avait approuvé une étape. Sous une règle « jamais », le modèle a effectué cette étape dans environ un essai sur dix. Une ligne distincte indiquant qu’une étape approuvée a reçu son feu vert n’a guère modifié ce taux. Lorsque la règle elle-même disait d’obtenir d’abord un feu vert, le modèle a effectué l’étape dans environ neuf essais sur dix. Consultez Approbations.

Conservez aussi votre propre étape de confirmation pour les actions risquées ou irréversibles.

Revoir les instructions rédigées pour des modèles antérieurs

Lorsque vous migrez vers Claude Fable 5.2, revoyez vos prompts. Lors des tests d’Anthropic, certaines instructions rédigées pour des modèles antérieurs ont augmenté le coût, provoqué des effets secondaires ou n’avaient plus d’effet. Reconsidérez ces instructions :

  • Instructions permanentes de délégation : des lignes qui poussent le travail vers des sous-agents peuvent se trouver dans les invites système, les skills et les fichiers d’agent. Lisez ces fichiers avant de migrer. Si, lors de vos tests, le modèle lance plus de sous-agents que vos tâches n’en nécessitent, supprimez les lignes dont vous n’avez plus besoin. Consultez Fixer des attentes pour les sous-agents.
  • Un budget de tokens que votre harness écrit dans le prompt : certains harness indiquent au modèle, dans le prompt, combien de tokens la tâche peut utiliser et combien il en reste. La taille de ce budget modifie la quantité que Claude Fable 5.2 dépense. Lors des tests d’Anthropic sur des tâches de codage à un effort high et xhigh, supprimer un budget important a réduit le coût, avec des performances équivalentes. Testez vos tâches sans le budget. Ce constat concerne du texte dans le prompt, pas les budgets de tâche de l’API, une fonctionnalité bêta que les tests n’ont pas couverte.
  • Code de harness qui modifie des tours antérieurs : Claude Fable 5.2 utilise la réflexion préservée. Si votre harness modifie l’invite système, les outils ou un message antérieur entre les requêtes, les blocs de réflexion qui suivent le point modifié dans l’historique deviennent invalides. Par défaut, la Messages API rejette alors la requête, et la Message Batches API supprime ces blocs. Pour raccourcir l’historique sans cette erreur, utilisez l’édition du contexte, ou une compaction qui ne conserve aucun tour antérieur après le résumé. Pour que la Messages API supprime aussi les blocs, définissez thinking.block_binding.prefix_mismatch_behavior sur "drop_block" (bêta, en-tête thinking-binding-controls-2026-08-01). Lors des tests d’Anthropic, lorsque la réflexion antérieure était supprimée à chaque tour, le modèle réfléchissait de nouveau et utilisait plus de tokens de sortie. C’est le pire cas, et l’augmentation dépend de la fréquence à laquelle votre harness modifie les tours antérieurs. En dehors de la compaction et de l’édition du contexte, conservez un historique en ajout seul. Cela maintient un taux de succès du cache élevé, et aucune réflexion n’est supprimée. Mesurez les tokens de sortie sur vos propres tâches avant de vous appuyer sur "drop_block". Consultez Ce que fait l’API avec un bloc invalide et Effectuer des changements sans modifier le préfixe.
  • Les lignes « considérez cette réponse comme terminée » : Rédiger des prompts pour Claude Opus 5.5 propose deux phrases pour les invites système de chat. Elles indiquent au modèle de considérer une réponse antérieure comme terminée et de concentrer sa réflexion sur le nouveau message. Lors des tests d’Anthropic à un effort high, ces phrases ont réduit la réflexion de Claude Fable 5.2 sur les questions de suivi, mais le modèle est aussi devenu beaucoup moins susceptible de signaler des erreurs dans ses réponses antérieures. Omettez ces lignes là où vous voulez que le modèle continue de réexaminer ses réponses antérieures. Ailleurs, vérifiez que le modèle signale toujours ses propres erreurs avant d’adopter ces lignes.
  • Instructions pour réfléchir moins : Claude Fable 5.1 suit généralement une ligne telle que « réponds directement sans délibérer ». Lors des tests d’Anthropic, une telle ligne n’a pas empêché Claude Fable 5.2 de réfléchir à medium et au-dessus. Supprimez ces lignes et baissez le niveau d’effort, comme décrit dans Calibrer l’effort.
  • Règles de style rédactionnel : Claude Fable 5.2 suit de près les règles de style ; une limite stricte telle que « une instruction par phrase, en 20 mots maximum » peut donc rendre sa prose hachée. Supprimez les règles dont vous n’avez plus besoin avant d’ajouter le texte de Rendre les rapports faciles à suivre.
  • Règles, notes et mémoires accumulées : les fichiers de mémoire, les notes et les fichiers d’instructions accumulent des mises en garde au fil du temps, et le modèle peut en avoir écrit certaines lui-même. Avant de migrer, supprimez les mises en garde dont la raison ne tient plus, et réécrivez les règles absolues pour qu’elles précisent leur périmètre et leur raison. Si un système est déjà bloqué, envisagez de le redémarrer avec sa mémoire et ses notes élaguées, et conservez une copie des originaux. Consultez Empêcher la prudence de s’accumuler.

Rendre les rapports faciles à suivre

Après un long travail agentique, les personnes qui lisent le rapport final de Claude Fable 5.2 n’ont généralement pas vu les appels d’outils ni les fichiers qui le sous-tendent. Le rapport doit être compréhensible par lui-même.

Si vous demandez à Claude Fable 5.2 de rédiger des rapports finaux ou des passations, ajoutez ce texte à votre invite système, et adaptez-le à vos lecteurs et à votre produit :

# Communicating clearly
Write for an intelligent but low-context reader. The person reading has not seen your tool calls, your reasoning or the files you opened, and may be switching in from other work. Messages should generally be self-contained: the reader should understand what you mean without having to dig for other context. Put the key points in the first few sentences. Practice progressive disclosure in your sentence order, and do not use undefined references and ideas in line 1 that won't make sense until the reader reaches line 12.

Use plain words, and write in clear, understandable full sentences. Do not use a term or abbreviation that you made up during the work. Say what the thing is in a way any reader would understand. Write mostly in the style of ASD-STE100 Simplified Technical English: short sentences, one idea per sentence, active voice, and consistently using the same word for the same thing. Use a paragraph of flowing prose where ideas connect, and keep bullets for lists of separate items. Leave out unnecessary details unless the reader asks and practice concision, but do ensure that your messages have the key context. Aim to make your user-facing text as human-readable and clear as possible.

Lors des tests d’Anthropic sur des tâches agentiques, ce texte a rendu les rapports finaux moins denses, avec moins de points-virgules. Sur les tâches d’automatisation de flux de travail, il a aussi raccourci les phrases. Vous pouvez aussi ajouter des instructions sur la longueur ou demander au modèle d’inclure des détails spécifiques.

Refus des mécanismes de protection

Claude Fable 5.2 exécute des classificateurs de sécurité qui peuvent refuser une requête. Une requête refusée renvoie stop_reason: "refusal", et stop_details.category indique la catégorie de refus :

  • cyber : la requête pourrait permettre des dommages cyber, comme le développement de logiciels malveillants ou d’exploits.
  • bio : la requête pourrait permettre des dommages biologiques, comme des méthodes de laboratoire dangereuses.
  • frontier_llm : la requête pourrait aider au développement de modèles d’IA concurrents.
  • reasoning_extraction : la requête demande au modèle de reproduire son raisonnement interne dans le texte de la réponse.
  • general_harms : la requête relève d’un autre domaine de la politique d’utilisation.

Un travail bénin en cybersécurité et en sciences de la vie peut aussi déclencher les classificateurs cyber et bio. S’ils bloquent le travail légitime de votre organisation, consultez le Cyber Verification Program et le Life Sciences Verification Program d’Anthropic. Claude Mythos 5.2 offre les mêmes capacités que Claude Fable 5.2, uniquement aux organisations vérifiées par ces programmes.

Si vos prompts, skills ou descriptions d’outils demandent au modèle d’écrire son raisonnement dans la réponse, supprimez ces instructions. Pour voir comment le modèle a raisonné, définissez display: "summarized" et lisez les blocs de réflexion. Consultez Conserver le raisonnement dans les blocs de réflexion.

Pour réessayer une requête refusée sur un autre modèle, consultez Refus, repli et facturation.

Par où commencer

Lors de votre migration, suivez ces étapes dans l’ordre :

  1. Définissez explicitement effort sur high, puis exécutez aussi vos évaluations à medium et xhigh.
  2. Lisez les invites système, skills, fichiers d’agent, fichiers de mémoire, notes et textes de harness que vous reprenez. Supprimez ou testez les instructions listées dans Revoir les instructions rédigées pour des modèles antérieurs.
  3. Exécutez vos tâches agentiques les plus longues. Notez où le modèle s’arrête prématurément, demande des approbations dont il n’a pas besoin, devient silencieux, délègue plus que la tâche ne le nécessite, ou ajoute au code existant là où vous vouliez qu’il soit restructuré.
  4. Appliquez les recommandations pour chaque comportement observé, une à la fois, et mesurez leur effet et leur coût en tokens sur vos propres tâches.

Cette page vous a-t-elle été utile ?