Rédiger des prompts pour Claude Sonnet 5.5

Ce guide présente les modèles de prompts spécifiques à Claude Sonnet 5.5. Pour les changements d'API du modèle, consultez Nouveautés de Claude Sonnet 5.5. Pour les techniques qui s'appliquent à tous les modèles Claude actuels, consultez Bonnes pratiques de rédaction de prompts.

Les prompts existants pour Claude Sonnet 5 devraient bien fonctionner sans modification, et les modèles présentés dans Rédiger des prompts pour Claude Sonnet 5 restent un point de départ raisonnable. Pour les travaux de longue haleine les plus difficiles, un modèle Opus est le meilleur choix. Commencez par la section qui correspond à ce que vous observez :

• Vous ne savez pas quel niveau d'effort utiliser, ou les tours durent plus longtemps ou moins longtemps qu'avec Claude Sonnet 5 : Calibrer l'effort
• Le modèle s'arrête pour vous consulter avant qu'une tâche de code soit terminée, ou en fait plus que ce que vous avez demandé : Orienter l'initiative et le périmètre
• Votre intégration fonctionne aujourd'hui avec la réflexion désactivée : Exécution sans réflexion préalable
• Les réponses JSON à des tâches qui nécessitent quelques étapes de raisonnement sont fausses ou ne peuvent pas être analysées : Tâches de raisonnement avec sortie JSON
• Les longs tours agentiques semblent silencieux : Mises à jour de progression destinées à l'utilisateur
• Le modèle répond à partir de ses connaissances d'entraînement alors qu'une recherche permettrait de repérer des détails qui ont changé : Utilisation d'outils dans le chat et le travail intellectuel
• Les messages que les utilisateurs envoient en cours de tâche sont ignorés ou traités comme du texte injecté : Messages utilisateur en cours de tour
• Des modifications de code sont signalées comme terminées sans exécution de tests ni de build : Vérification sur les tâches de code
• Le modèle appelle un outil avec une casse incorrecte ou transmet un paramètre sous un nom légèrement différent : Gestion tolérante des appels d'outils
• Les réponses concernant des graphiques denses ou des dessins techniques manquent de détails : Outils pour les entrées visuelles complexes
• Les requêtes renvoient stop_reason: "refusal" : Refus des mesures de protection

Calibrer l'effort

L'« effort » (niveau d'effort) est le principal levier qui détermine la quantité de réflexion de Claude Sonnet 5.5, et avec elle la qualité, la « latency » (latence) et le coût. Ses niveaux ont été recalibrés : un niveau ne produit pas la même quantité de réflexion que le même niveau sur Claude Sonnet 5. Effectuez un nouveau balayage sur vos propres évaluations plutôt que de reprendre le réglage que vous utilisiez sur Claude Sonnet 5. Commencez à high, la valeur par défaut sur l'API Claude, sauf si votre charge de travail est agentique ou sensible à la latence. Pour le code agentique et l'utilisation d'outils en plusieurs étapes, commencez à medium pour les tâches bien spécifiées et passez à high pour les tâches plus difficiles ou plus longues. Pour le chat et les autres travaux sensibles à la latence, commencez à medium ou low, car un effort plus élevé signifie une attente plus longue avant le début de la réponse. Augmentez l'effort si la qualité l'exige.

Un effort plus faible modifie également la façon dont le modèle termine le travail agentique. À low, il garde sa réflexion courte et peut omettre de vérifier une modification. Consultez Vérification sur les tâches de code. À low et medium, sur les longues tâches agentiques, il est plus susceptible de s'arrêter pour consulter l'utilisateur avant d'avoir terminé. Consultez Orienter l'initiative et le périmètre.

Trois ajustements sont utiles :

• Définissez max_tokens avec une marge suffisante pour la réflexion et la réponse attendue. La réflexion est comptabilisée dans max_tokens même lorsque le contenu de la réflexion ne vous est pas renvoyé. Une limite dimensionnée pour une requête sans réflexion peut tronquer la réponse. Pour le code agentique, définissez max_tokens à 128 000, le maximum du modèle, et diffusez la réponse en « streaming » (diffusion progressive).
• Réservez xhigh et max aux travaux pour lesquels vous avez mesuré un gain de qualité, car la réflexion et les réponses y deviennent beaucoup plus longues. À ces niveaux, between_tools n'est pas accepté, de sorte que la réflexion préalable ne peut pas être désactivée.
• Pour obtenir moins de réflexion, abaissez le niveau d'effort. À partir de medium, le modèle réfléchit brièvement avant presque chaque réponse, même une salutation, ce qui allonge le délai avant le premier token visible. Lui demander dans l'invite système de moins réfléchir ne réduit pas de manière fiable sa réflexion. À low, il omet la réflexion sur la plupart des requêtes simples.

Modifier la valeur effort de premier niveau entre les requêtes invalide le cache des prompts. Pour exécuter des tours individuels à un niveau différent, utilisez plutôt un changement d'effort par message (bêta), qui préserve le cache. Par exemple, exécutez une session interactive à low et augmentez l'effort à high lorsque l'utilisateur soumet un problème difficile. Les changements d'effort par message nécessitent l'« adaptive thinking » (réflexion adaptative). Avec between_tools, ils renvoient une erreur 400, comme l'explique Exécution sans réflexion préalable.

Orienter l'initiative et le périmètre

Le degré d'autonomie de Claude Sonnet 5.5 dépend du niveau d'effort et de la requête. À un effort plus faible, il vous consulte parfois avant qu'une tâche de code soit terminée. À un effort plus élevé, ou face à une requête ouverte, il peut en faire plus que ce que vous avez demandé. Orientez-le avec le niveau d'effort et avec des instructions dans votre invite système.

Mener le travail à terme. Sur les tâches de code agentiques à un effort low et medium, le modèle vous consulte parfois avant que le travail soit terminé. Il peut s'arrêter pour confirmer un plan, poser une question à laquelle il pourrait répondre lui-même, ou s'arrêter après une partie d'une tâche en plusieurs parties pour demander s'il doit continuer. Essayez d'abord un niveau d'effort plus élevé. Pour que le modèle continue à travailler sans modifier l'effort, ajoutez ceci à votre invite système :

Keep working until everything the user asked for is done, and only stop to ask when you can't go on without the user or before a risky step.

When the work the user asked for is done and checked, stop and report. Don't add features, tests, files, docs or refactors that weren't asked for. If you think one would help, mention it at the end instead of doing it.

Avec ce prompt, le modèle mène une plus grande partie du travail à terme à un effort low et medium, de sorte que les sessions à ces niveaux durent plus longtemps et coûtent plus cher. Le prompt ne remplace pas vos propres règles concernant les actions risquées ou irréversibles. Conservez ces règles dans votre invite système.

Ajouts non demandés lors du codage. Le modèle a tendance à ajouter des tests, de la documentation et de petits fichiers de support conformes aux conventions de votre dépôt, même lorsque vous ne les demandez pas. Il le fait à tous les niveaux d'effort, et davantage à un effort plus élevé. La modification demandée elle-même reste proche de ce qui a été demandé. La plupart des équipes apprécieront ce comportement. Si vous préférez des modifications limitées à ce qui a été explicitement demandé, ajoutez uniquement le second paragraphe de ce prompt, qui commence par « When the work the user asked for is done ». À un effort xhigh et max, ce paragraphe réduit ces ajouts et rend les modifications globalement plus petites.

Minutie à un effort xhigh et max. À ces niveaux, le modèle est particulièrement minutieux. Après avoir terminé une tâche, il peut lancer ses propres cycles de revue et de vérification, parfois avec des « subagents » (sous-agents) si votre « harness » (environnement d'exécution) en fournit. Il peut également apporter des corrections connexes qu'il a remarquées en cours de route. Cela prend plus de temps et de tokens ; exécutez donc le travail courant à high ou en dessous, où ce comportement est rare. Si vous souhaitez bénéficier de cette minutie supplémentaire propre à ces niveaux d'effort, tout en la concentrant sur la tâche elle-même, ajoutez ceci à votre invite système :

When the work the user asked for is done and its checks pass, stop and report. Don't start extra rounds of review or hardening on your own, and don't launch reviewer sub-agents unless the user asked for a review. If you think a deeper review is worth doing, say so at the end.

Lors de tests sur des tâches de code à un effort max, ce prompt a empêché le modèle de lancer des sous-agents de revue et a réduit le coût des sessions d'environ un tiers, sans changement de qualité. Il rend moins fréquents les cycles de revue lancés d'eux-mêmes par l'agent principal, mais ne les supprime pas entièrement.

Requêtes ouvertes. Lorsqu'une requête est ouverte, par exemple « montre-moi ce que tu peux faire avec ceci », le modèle peut commencer à créer une présentation, un rapport ou une vidéo alors que vous vouliez seulement des idées. Si vous souhaitez d'abord des idées ou un plan, indiquez-le dans la requête, ou ajoutez ceci à votre invite système :

When the user asks for ideas, options or a plan, give them that and stop. Don't start building or changing anything until they say to go ahead.

Exécution sans réflexion préalable

Pour exécuter Claude Sonnet 5.5 sans réflexion préalable, envoyez thinking: {"type": "between_tools"}. C'est le réglage de réflexion le plus bas sur ce modèle, et il est accepté à un effort high ou inférieur. Si votre intégration fonctionne aujourd'hui avec la réflexion désactivée, passez-la à between_tools et vérifiez les points suivants :

• Envoyez between_tools à un effort high ou inférieur. À un effort xhigh ou max, une requête avec between_tools renvoie une erreur 400. Avec between_tools, l'effort ne peut pas non plus changer en cours de conversation : un output_config.effort par message qui diffère du niveau en vigueur renvoie une erreur 400. Pour faire varier l'effort d'un tour à l'autre, utilisez la réflexion adaptative. Avec between_tools, supprimez toute instruction demandant au modèle de ne pas réfléchir. De telles instructions augmentent la probabilité que le modèle écrive des balises XML internes dans sa sortie visible.
• Lisez la réponse par type de bloc. Avec la réflexion adaptative, une réponse peut commencer par un bloc thinking, dont le champ thinking est vide avec la valeur par défaut display: "omitted". Avec between_tools, une réponse peut commencer par un bloc thinking de mise à jour de progression. Ne supposez pas que le premier bloc de contenu est du texte.
• Renvoyez les blocs thinking sans modification. Avec between_tools, les notes que le modèle écrit entre les appels d'outils reviennent toujours sous forme de blocs thinking lorsqu'elles dépassent une phrase ou deux. Chaque bloc contient un résumé de la note. Renvoyez-les sans modification avec le reste du tour de l'assistant. Un bloc que vous renvoyez donne au modèle la note complète qu'il a écrite, et non le résumé.
• Utilisez la réflexion adaptative pour les tâches de raisonnement sans outils. Dans une requête sans outils, between_tools signifie que le modèle répond sans réfléchir au préalable. Pour les tâches qui nécessitent quelques étapes de raisonnement, utilisez plutôt la réflexion adaptative. Consultez Tâches de raisonnement avec sortie JSON.

Tâches de raisonnement avec sortie JSON

Cette section s'applique lorsque vous demandez à Claude Sonnet 5.5 une réponse JSON à une tâche qui nécessite quelques étapes de raisonnement. Par exemple : additionner des chiffres issus d'un document, appliquer une règle ou classer des éléments. Sur ce type de tâches, le modèle répond souvent sans réfléchir au préalable, en particulier à un effort low et medium. Ce qui aide dépend de la façon dont vous demandez le JSON. Utilisez les « structured outputs » (sorties structurées) lorsqu'elles sont disponibles. Le texte de la réponse est alors du JSON conforme à votre schéma, il n'y a donc rien à analyser.

Avec les sorties structurées, le texte de la réponse ne contient que le JSON, de sorte que le modèle ne peut raisonner sur le problème que dans sa réflexion. Lorsqu'il omet la réflexion, il peut être moins précis sur ces tâches. Les modifications suivantes aident à maintenir une précision élevée.

Demandez au modèle de réfléchir d'abord. Avec la réflexion adaptative, ajoutez cette ligne à la fin de votre invite système :

Think the problem through before you answer.

Avec cette ligne, le modèle réfléchit plus souvent avant de répondre. À un effort high, la ligne rapproche la précision de celle que le modèle atteint à xhigh, pour une augmentation modeste des tokens de sortie. À un effort low et medium, elle améliore la précision, sans toutefois atteindre celle du modèle à high, et l'augmentation des tokens de sortie est plus importante.

Ou utilisez un effort xhigh. Avec la réflexion adaptative, xhigh offre la meilleure précision sur ces tâches, même sans la ligne. Il utilise plus de tokens de sortie que high.

Utilisez la réflexion adaptative plutôt que between_tools. Dans une requête sans outils, le modèle ne réfléchit pas avant de répondre avec between_tools. La ligne n'a alors aucun effet, et la précision sur ces tâches est plus faible. Utilisez la réflexion adaptative pour ces requêtes, avec les étapes de cette section. Lors des tests, scinder la requête en deux, une requête pour la réponse et une pour le JSON, a permis d'obtenir une précision des réponses et une conformité JSON élevées, mais avec un coût et une latence très élevés.

Avec les sorties structurées à un effort low et medium, le modèle continue parfois à réfléchir jusqu'à atteindre max_tokens. À un effort high et au-delà, cela n'arrive presque jamais. Considérez toute réponse dont le stop_reason est "max_tokens" comme un échec, même si son texte contient du JSON valide, et réessayez. Définissez max_tokens suffisamment haut pour la réflexion et le JSON, comme le décrit Calibrer l'effort, mais pas plus haut que ce que vous êtes prêt à dépenser pour une tentative.

Si vous ne pouvez pas utiliser les sorties structurées, demandez plutôt du JSON dans le prompt. Le modèle raisonne alors souvent sur le problème dans le texte de la réponse et écrit le JSON à la fin. Le JSON contient généralement la bonne réponse, mais un analyseur qui s'attend à ce que toute la réponse soit du JSON échoue. Deux choses aident :

• Analysez la dernière valeur JSON de la réponse. Lisez uniquement les blocs text, et considérez une réponse dont le stop_reason est "max_tokens" comme un échec. En partant de chaque { ou [, essayez d'analyser une valeur JSON. Lorsqu'une valeur est analysée avec succès, reprenez à partir de la fin de cette valeur, afin que les valeurs imbriquées à l'intérieur ne soient pas comptées séparément. Conservez la dernière valeur trouvée. Ne prenez pas tout ce qui se trouve entre le premier { et le dernier }. Le modèle écrit parfois un brouillon avant son JSON final, et cette plage inclurait les deux. Si votre réponse se compose de plusieurs valeurs JSON consécutives, par exemple un enregistrement par ligne, conservez la dernière série de valeurs séparées uniquement par des espaces, des virgules ou des sauts de ligne. Vérifiez que le résultat contient les champs attendus, et réessayez une fois si ce n'est pas le cas. Lors des tests, cette méthode a rendu presque toutes les réponses exploitables sans modifier leur précision.
• Envisagez également un effort xhigh avec la réflexion adaptative. Le modèle raisonne alors sur le problème dans sa réflexion et renvoie presque toujours le JSON seul. Le total des tokens de sortie reste à peu près le même qu'à high, car le raisonnement passe du texte de la réponse à la réflexion.

Mises à jour de progression destinées à l'utilisateur

Entre les appels d'outils, Claude Sonnet 5.5 écrit des notes destinées à l'utilisateur sur ce qu'il vient de trouver et sur ce qu'il fait ensuite. Les notes de plus d'une phrase ou deux reviennent sous forme de blocs thinking de « progress updates » (mises à jour de progression). Les remarques plus courtes restent des blocs text. Avec la valeur par défaut de thinking.display, le texte d'un bloc de mise à jour de progression est vide, de sorte qu'un client qui n'affiche que les blocs text peut sembler silencieux pendant un long tour agentique. Cela compte surtout dans les interfaces de chat et les autres produits où l'utilisateur suit le travail du modèle en temps réel.

Pour afficher ces notes, définissez display: "updates" (bêta, en-tête thinking-display-updates-2026-08-18). Avec between_tools, les notes reviennent avec leur texte de résumé, aucun champ display n'est donc nécessaire. between_tools n'accepte aucun autre champ : display, budget_tokens ou block_binding envoyé avec lui renvoie une erreur 400. Le guide de migration montre comment afficher les notes. Il arrive que le modèle doive montrer à l'utilisateur un texte exact au milieu d'un long tour, comme un extrait de code ou une question à laquelle il a besoin d'une réponse. Dans ce cas, donnez-lui un outil simple pour envoyer un message à l'utilisateur. Indiquez au modèle de n'utiliser cet outil que pour ce type de contenu. Déclarez l'outil dans la première requête de la session, afin que la liste tools ne change pas par la suite.

Ensuite, supprimez les anciennes instructions telles que « conserve toutes les conclusions pour la réponse finale ». Si vous souhaitez ensuite des mises à jour à des moments prévisibles, par exemple une ligne sur ce que le modèle s'apprête à faire avant son premier appel d'outil et un bref récapitulatif à la fin, indiquez-le dans l'invite système. Le modèle suit ce type d'instructions. Les mises à jour à des moments définis sont surtout utiles dans les travaux avec intervention humaine.

Si les longs tours d'appels d'outils restent silencieux plus longtemps que vous ne le souhaitez, votre harness peut solliciter une mise à jour. Faites-lui compter les étapes consécutives d'appels d'outils qui n'envoient à l'utilisateur ni texte ni mise à jour de progression. Après plusieurs étapes consécutives, par exemple cinq, ajoutez un rappel valable pour un tour après les derniers résultats d'outils. Envoyez-le sous forme de message système limité au tour (bêta), avec un texte comme celui-ci :

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

Si le tour reste silencieux, cessez d'envoyer des rappels après le deuxième ou le troisième. Un texte fréquent du harness après les résultats d'outils peut amener le modèle à soupçonner une « prompt injection » (injection de prompt), comme l'explique Messages utilisateur en cours de tour. Laissez chaque rappel dans messages lors des requêtes suivantes. Comme le rappel est ajouté à la suite plutôt qu'inséré puis supprimé, le cache des prompts et la réflexion préservée restent intacts. À un effort high, avec un outil disponible pour envoyer un message à l'utilisateur, le rappel amène le modèle à informer l'utilisateur plus souvent et raccourcit ses plus longues périodes de silence, sans changement mesurable de la qualité des tâches.

Utilisation d'outils dans le chat et le travail intellectuel

Sur les tâches de chat et de travail intellectuel, Claude Sonnet 5.5 répond parfois à partir de ses connaissances d'entraînement alors qu'une recherche web permettrait de repérer des détails qui ont changé. Par exemple, ce qui est autorisé, exigé ou facturé.

Commencez par vérifier si votre prompt contient des formulations qui découragent l'utilisation d'outils, comme « n'utilise les outils qu'en cas de stricte nécessité » ou « minimise les appels d'outils », et supprimez-les. Ensuite, si votre produit fournit au modèle un outil de recherche, ajoutez ceci à votre invite système :

Use the search tool to check specifics that may have changed since your training, such as what is allowed, required or charged, even when you feel confident. For researched work such as a report or a comparison, gather current sources rather than writing from your training knowledge.

Cela compte surtout pour les produits de recherche et d'assistance, où les réponses dépendent de détails à jour.

Messages utilisateur en cours de tour

Claude Sonnet 5.5 est entraîné à résister à l'injection de prompt indirecte, c'est-à-dire aux instructions malveillantes qui arrivent via les résultats d'outils et d'autres contenus qu'il lit pendant une tâche. Il lui arrive de traiter un véritable message de l'utilisateur comme une injection possible. Supposons qu'un message saisi par l'utilisateur en cours de tâche parvienne au modèle sous forme de message système en cours de conversation placé directement après un résultat d'outil, ou à l'intérieur d'un bloc tool_result. Le modèle peut alors indiquer à l'utilisateur que le résultat de l'outil contenait un texte se faisant passer pour un message de sa part, et ignorer le message ou demander à l'utilisateur de le confirmer.

Un compte à rebours de tokens que votre harness ajoute après chaque résultat d'outil peut provoquer ce comportement. Il en va de même si vous permettez aux utilisateurs d'envoyer des messages pendant que le modèle est au milieu d'un tour en plusieurs étapes, ou si votre harness ajoute des instructions ou du contexte après les résultats d'outils à chaque étape. Dans chaque cas, du texte arrive juste après les résultats d'outils. Avec un compte à rebours ou des instructions à chaque étape, cela peut se produire à chaque appel d'outil. Un rappel occasionnel valable pour un tour, comme celui de Mises à jour de progression destinées à l'utilisateur, arrive beaucoup moins souvent. Si vous observez cette réaction à l'un de vos propres rappels, envoyez le rappel moins souvent. Pour éviter cette mauvaise interprétation :

• Ne placez jamais de texte utilisateur à l'intérieur d'un bloc tool_result. C'est l'emplacement que le modèle interprète le plus souvent de travers.
• Transmettez les saisies de l'utilisateur en cours de tour sous forme de tour utilisateur. Ajoutez les mots de l'utilisateur sous forme de bloc de texte dans le message utilisateur qui contient les blocs tool_result, après le dernier tool_result.
• Placez les notifications du harness, comme les rappels, dans un message système en cours de conversation distinct, après les mots de l'utilisateur. Ne placez jamais une notification et les mots de l'utilisateur dans le même bloc.
• Dans les sessions interactives où les utilisateurs peuvent écrire en cours de tour, n'ajoutez pas votre propre compte à rebours de tokens ou de budget après les résultats d'outils. Les budgets de tâche (bêta) ajoutent un compte à rebours similaire, mais il n'a pas été observé qu'ils provoquent cette mauvaise interprétation. Si vous l'observez alors qu'un budget de tâche est défini, essayez la session sans budget.

Vérification sur les tâches de code

Sur les tâches de code agentiques, Claude Sonnet 5.5 vérifie généralement son travail avant de signaler une modification comme terminée. À un effort low, cependant, il signale parfois une modification comme terminée sans exécuter de vérification qui la met à l'épreuve. Par exemple, il peut ignorer les tests du projet parce que les dépendances du projet ne sont pas installées.

Si vous constatez que des modifications sont signalées comme terminées sans sortie de tests ou de build dans la transcription, ajoutez ce paragraphe, ou un paragraphe similaire, à l'invite système. À un effort low, il rend rares les vérifications omises ou superficielles, sans changement mesurable de la qualité des tâches et avec un coût par tâche à peine plus élevé :

When you change code that can be run, built, or type-checked, run a real check that exercises the change before reporting it done: the project's tests, type-checker, or build, or the changed command itself. A syntax-only check, or a check command that failed to start, does not count; if all that is missing is the project's declared dependencies, install them with its own package manager and lockfile (e.g. npm install, pip install -r requirements.txt), never via sudo or the system package manager, unless told not to. Only if no real check can run here, say which one you did not run and why instead of reporting the change as done.

Gestion tolérante des appels d'outils

Claude Sonnet 5.5 appelle parfois un outil déclaré sous un nom qui ne diffère que par la casse, comme bash pour Bash. Il peut également transmettre un paramètre connu sous un nom légèrement différent. Plutôt que de traiter un tel appel comme une erreur fatale, faites en sorte que votre harness le gère de l'une des deux manières suivantes :

• Acceptez l'appel lorsque la correspondance est sans ambiguïté, même si la casse est incorrecte.
• Renvoyez un tool_result avec is_error: true qui indique le nom exact attendu. Le modèle corrige généralement l'appel lors de son tour suivant. Consultez Gérer les erreurs avec is_error.

Outils pour les entrées visuelles complexes

Pour les graphiques denses et les dessins techniques, donnez à Claude Sonnet 5.5 un moyen de recadrer l'image, de zoomer ou d'exécuter du code sur celle-ci. Avec de tels outils, le modèle lit ces entrées avec une précision nettement supérieure. Sur les graphiques, les outils aident à tous les niveaux d'effort. Sur les dessins techniques, ils n'aident qu'à partir d'un effort high, et surtout à xhigh et max. Pour les graphiques, ajouter des outils aide davantage qu'augmenter l'effort : lors des tests, avec des outils à un effort high, le modèle a lu les graphiques avec plus de précision que sans outils à un effort max, pour une fraction du coût. La recette de l'outil de recadrage contient une définition d'outil fonctionnelle.

Refus des mesures de protection

Claude Sonnet 5.5 exécute des classificateurs de sécurité qui peuvent refuser une requête. Un refus arrive sous forme de réponse normale avec stop_reason: "refusal", et stop_details.category indique la catégorie de refus :

• cyber : la requête pourrait faciliter des dommages informatiques, comme le développement de logiciels malveillants ou d'exploits. La recherche de vulnérabilités dans le code source est autorisée. Les travaux de cybersécurité à double usage à haut risque ne sont pas autorisés.
• bio : la requête pourrait faciliter des dommages biologiques, comme des méthodes de laboratoire dangereuses. Les questions courantes de santé et les questions éducatives ne sont pas concernées.
• frontier_llm : la requête pourrait contribuer 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. Des travaux inoffensifs peuvent également déclencher cette catégorie.

Si le classificateur bio bloque les travaux en sciences de la vie de votre organisation, vous pouvez postuler au Life Sciences Verification Program.

Si vous activez le repli côté serveur (bêta), il relance les refus cyber et frontier_llm sur Claude Sonnet 5. Il ne relance pas les refus bio, reasoning_extraction ou general_harms. Consultez Refus, repli et facturation.

Si vos prompts demandent au modèle d'inclure son raisonnement dans la réponse, supprimez ces instructions, car elles provoquent des refus reasoning_extraction. Avec la réflexion adaptative, lisez plutôt le raisonnement à partir des blocs de réflexion résumée (display: "summarized").