La plupart des guides de migration vous disent ce qui casse dans votre code. Celui-ci porte sur ce qui casse dans vos invites.
Claude Opus 5 a été lancé le 24 juillet 2026, et Anthropic a publié un guide de prompt dédié en même temps. Ce guide documente quelque chose qui mérite d'être noté : plusieurs instructions qui amélioraient Opus 4.8 rendent Opus 5 pire. Pas subtilement pire. Mesurablement plus coûteux, mesurablement plus verbeux, et dans un cas carrément défectueux.
La raison est simple. Opus 5 fait déjà, de lui-même, plusieurs choses que vous deviez auparavant demander. Lorsque votre ancienne invite le demande quand même, l'instruction se cumule avec le comportement que le modèle a déjà. Vous obtenez le double des passes de vérification, pas le double de la précision.
Ce guide passe en revue chaque changement de comportement documenté avec un extrait de prompt prêt à copier-coller que vous pouvez insérer dans votre prompt système dès aujourd'hui. Il couvre également les deux modes de défaillance qui apparaissent lorsque vous désactivez la réflexion, ce qui est le seul cas où un prompt Opus 5 peut produire une sortie qui semble correcte et corrompre silencieusement une boucle d'agent. Si vous travaillez toujours sur les changements au niveau du code, le guide de migration d'Opus 4.8 vers Opus 5 les couvre séparément. Et si vous voulez observer ces comportements changer dans les requêtes et réponses réelles, Apidog est un moyen simple d'envoyer la même invite avec différents paramètres et de comparer les résultats.
Le résumé en une ligne
Opus 5 vérifie plus, écrit plus, délègue plus et s'explique plus qu'Opus 4.8. Votre invite Opus 4.8 était ajustée pour pousser un modèle vers ces comportements. Maintenant, elle les dépasse.
Le travail est donc soustractif. Vous supprimez principalement des instructions, au lieu d'en ajouter. Les ajouts que vous faites sont des contraintes : soyez plus bref, restez dans le cadre, ne générez pas d'assistants.
1. Supprimez vos instructions de vérification
C'est le point principal, et c'est la raison du titre.
Anthropic affirme qu'Opus 5 vérifie son propre travail sans y être invité. Il relit ce qu'il a écrit, vérifie son arithmétique, réexécute un test et recherche les cas limites que vous n'avez pas mentionnés. C'était exactement le comportement que tout le monde forçait manuellement dans Opus 4.8 avec des lignes comme « vérifiez votre travail avant de répondre » ou « vérifiez chaque étape ».
Si vous conservez ces lignes, vous obtiendrez une sur-vérification. Le modèle effectue les passes de vérification qu'il aurait effectuées de toute façon, plus celles que vous avez demandées, et vous payez pour chaque jeton. Sur les longues exécutions d'agents, c'est une facture réelle, pas une erreur d'arrondi.
La solution est une suppression. Recherchez ces motifs dans vos invites système et supprimez-les :
Vérifiez votre travail avant de répondre.
Vérifiez chaque étape avant de passer à la suivante.
Passez en revue votre réponse pour les erreurs, puis révisez-la.
Vérifiez attentivement votre raisonnement.
Assurez-vous que la sortie est correcte avant de la retourner.
Si vous avez une étape réellement cruciale où vous souhaitez une passe de vérification explicite, limitez-la à cette étape plutôt que d'en faire une règle globale :
N'ajoutez pas de passes de vérification générales ; vous vérifiez déjà par défaut.
La seule exception : après avoir écrit le SQL de migration, exécutez-le une fois
sur le schéma dump et signalez toute non-concordance. Ne vérifiez rien d'autre.
Cette forme est importante. Une instruction globale « tout vérifier » sur Opus 5 est un multiplicateur de coûts. Une seule exception circonscrite est un contrôle.
Si vous suivez les dépenses API au cours de cette migration, les leviers de cache et de lot dans la répartition des prix d'Opus 5 s'empilent avec celui-ci, et notre guide pour réduire une facture API Claude couvre les leviers généraux.
2. Demandez explicitement la concision, car l'effort ne suffira pas
Les réponses par défaut d'Opus 5 sont plus longues que celles d'Opus 4.8. Il en va de même pour ses livrables écrits : les rapports, les résumés, les documents de conception et les READMEs qu'il produit lorsque vous demandez un document.
Voici ce qui déroute les gens. Réduire le paramètre effort ne résout pas ce problème. L'effort contrôle la quantité de réflexion du modèle. Il ne contrôle pas la quantité de texte que le modèle écrit. Passez de xhigh à medium et vous réduirez les jetons de réflexion tandis que la réponse visible restera à peu près la même longueur. Si vous avez supposé que l'effort était un curseur de verbosité, votre facture ne diminuera pas comme prévu. Le guide des paramètres d'effort d'Opus 5 couvre ce que chaque niveau modifie réellement.
La longueur est un problème d'invite, alors résolvez-le dans l'invite. Soyez précis sur la limite plutôt que de dire « soyez bref », ce que les modèles interprètent généreusement :
Format de réponse : 150 mots maximum, sauf si je demande plus.
Pas de préambule, pas de reformulation de ma question, pas de résumé à la fin.
Commencez par la réponse, puis le raisonnement si nécessaire.
Pour les livrables écrits, mettez la limite sur l'artefact et nommez ce qu'il faut supprimer :
Rédigez le document de migration en 800 mots maximum.
Incluez : les changements disruptifs, la correction pour chacun, et une étape de restauration.
Excluez : le contexte de l'ancien système, un glossaire et une section de conclusion.
Si une section devait dépasser sa part, coupez les exemples avant de couper les étapes.
Pour les travaux lourds en code, la contrainte équivalente concerne les commentaires, pas le code :
Retournez le diff et rien d'autre.
Pas d'explication de ce que vous avez changé, sauf si le changement n'est pas évident,
auquel cas une phrase au-dessus du bloc.
3. Limitez la délégation aux sous-agents
Opus 5 délègue plus facilement aux sous-agents qu'Opus 4.8. Étant donné une tâche en plusieurs parties et un harnais qui prend en charge la génération, il se ramifiera.
C'est souvent la bonne approche. C'est aussi une décision de coût que le modèle prend en votre nom, et chaque sous-agent a son propre contexte et sa propre facture de jetons. Pour les charges de travail sensibles aux coûts ou à la latence, fixez une limite plutôt que de laisser le modèle juger :
Ne générez pas de sous-agents pour cette tâche. Gérez-la dans cette conversation.
Ou, lorsque l'éparpillement est réellement utile mais doit être borné :
Vous pouvez déléguer à 2 sous-agents maximum, et uniquement pour un travail
indépendant au niveau des fichiers qui peut s'exécuter en parallèle.
Effectuez la recherche, la planification et la synthèse finale vous-même dans ce fil.
Le schéma à éviter est la délégation pour elle-même : un sous-agent généré pour lire un fichier, ou pour prendre une décision pour laquelle le thread principal avait déjà le contexte. Si vous construisez délibérément avec des sous-agents, notre guide sur la création de sous-agents de code Claude couvre l'aspect du harnais pour leur portée.
4. Limitez explicitement la portée sur les tâches étroites
Opus 5 élargit la portée des tâches. Demandez-lui de corriger un test défaillant et il pourrait également refactoriser la fonction d'aide que le test appelle, mettre à jour la signature de type et ajouter deux autres cas de test. Demandez-lui de renommer une variable et il pourrait ranger la fonction environnante.
Parfois, c'est une fonctionnalité. Pour une tâche étroite et chirurgicale, ce n'est pas le cas : un refactoring non demandé signifie un diff plus grand à lire pour un relecteur et un rayon d'action plus important pour un changement qui était censé être d'une seule ligne.
Définissez la limite comme une limite, et nommez ce qui est interdit :
Portée : modifiez uniquement la constante de nombre de tentatives dans src/client/http.ts.
Ne refactorisez pas le code environnant, ne renommez rien, n'ajoutez pas
de tests, ne mettez pas à jour la documentation. Si vous pensez qu'un autre changement est nécessaire,
arrêtez-vous et dites-le-moi au lieu de le faire.
Cette dernière clause est la moitié utile. Sans elle, le modèle n'a aucun moyen autorisé de soulever un vrai problème, il effectue donc le changement de toute façon ou abandonne l'observation. Avec elle, vous obtenez une préoccupation signalée et un diff inchangé.
5. Attendez-vous à plus de narration de correction, et désactivez-la si vous ne la voulez pas
Opus 5 narre ses corrections plus qu'Opus 4.8. Lorsqu'il change d'avis en cours de réponse, il vous le dit : il signale qu'une approche antérieure était erronée, explique pourquoi et décrit le changement.
Pour un travail interactif, c'est utile. Pour un pipeline où la réponse alimente un analyseur, une interface utilisateur ou un autre modèle, cette narration est du bruit dans un champ censé contenir une réponse.
L'instruction est courte :
Ne narrez pas les corrections ou les changements d'approche.
Ne retournez que la réponse finale. Si vous avez révisé votre pensée, cette
révision appartient à votre raisonnement, pas à la réponse.
Si vous dirigez les réponses vers un stockage structuré, associez-le à des sorties structurées afin que la forme soit appliquée plutôt que demandée.
Les modes de défaillance avec la réflexion désactivée
Tout ce qui précède est un problème d'ajustement. Cette partie est un problème de correction.
Anthropic documente deux artefacts qui apparaissent occasionnellement sur Opus 5 lorsque la réflexion est désactivée via thinking: {type: "disabled"}. Il est important de connaître les deux avant de déployer un agent.
Appels d'outils écrits en texte brut. Le modèle émet quelque chose qui ressemble à un appel d'outil, mais sous forme de texte dans le corps de la réponse plutôt que comme un bloc structuré tool_use. Rien ne s'exécute. Dans un chat à un seul tour, vous le remarqueriez. Dans une boucle d'agent, vous ne le faites souvent pas : la boucle ne voit aucun appel d'outil, donc elle n'agit pas, et le texte divulgué reste dans l'historique de la conversation. Les tours suivants lisent alors ce texte comme si un appel avait eu lieu. La défaillance se propage sur plusieurs tours, et au moment où la sortie semble erronée, la cause remonte à plusieurs tours précédents.
Balises XML internes dans la sortie visible. Des balises comme <thinking> apparaissent dans la réponse que l'utilisateur voit. Mauvais d'un point de vue esthétique en soi, et pire si vous affichez les réponses en HTML ou si vous les analysez pour leur structure.
Le paradoxe : nommer les balises dans votre invite aggrave la fuite, au lieu de l'améliorer. Une instruction comme « ne jamais afficher les balises <thinking> » place la séquence de jetons dans le contexte et augmente les chances qu'elle apparaisse. N'écrivez pas cette instruction.
La mitigation recommandée par Anthropic n'est pas du tout une invite. Il s'agit de maintenir la réflexion activée et de contrôler les coûts avec un niveau d'effort inférieur à la place :
{
"model": "claude-opus-5",
"max_tokens": 4096,
"output_config": { "effort": "low" },
"messages": [
{ "role": "user", "content": "..." }
]
}
Cela vous donne l'extrémité économique de la gamme sans les artefacts de réflexion désactivée. Cela évite également un piège connexe : sur Opus 5, combiner thinking: {type: "disabled"} avec un effort xhigh ou max renvoie une erreur 400, car la désactivation de la réflexion est plafonnée à un effort high. Notez également que la réflexion est désormais activée par défaut, donc une requête qui omet simplement le champ thinking s'exécute avec une réflexion adaptative plutôt que sans, comme cela aurait été le cas sur Opus 4.8.
Si vous avez une exigence stricte de désactiver la réflexion, ajoutez une vérification défensive dans votre boucle plutôt qu'une instruction de prompt : rejetez toute intervention de l'assistant dont le corps de texte contient une chaîne de caractères ressemblant à un appel non exécuté avant de l'ajouter à l'historique. Échouez bruyamment au lieu de laisser un appel fantôme dans la transcription.
Testez les changements au lieu de deviner
Les changements de prompt sont difficiles à évaluer en les lisant. Les comportements ici (longueur de réponse, passes de vérification, nombre de sous-agents) apparaissent sous forme de décomptes de jetons et de structure de charge utile, ce qui signifie que la meilleure façon de vérifier votre travail est d'envoyer les requêtes et de comparer.
C'est simple à configurer dans Apidog, une plateforme tout-en-un de développement et de test d'API :
- Créez une requête contre le point de terminaison Anthropic Messages avec
"model": "claude-opus-5", et stockez votre clé API comme variable d'environnement plutôt que de la coller dans le corps. - Enregistrez votre ancien prompt système Opus 4.8 et votre version Opus 5 allégée comme deux requêtes enregistrées pour la même entrée.
- Comparez le bloc
usagesur chaque réponse. Les jetons de sortie vous indiquent si la contrainte de concision a été appliquée ; les jetons d'entrée et les champs de cache vous indiquent si vos modifications de prompt ont rompu un préfixe de cache. - Dupliquez la requête sur différents niveaux d'effort pour constater par vous-même que les jetons de réflexion diminuent tandis que la longueur visible reste stable.
- Inspectez la réponse en streaming pour confirmer que les appels d'outils arrivent comme des blocs structurés
tool_useet non comme du texte.
L'étape cinq est celle qui détecte la défaillance d'appel d'outil en texte brut avant qu'elle n'atteigne la production. Téléchargez Apidog si vous souhaitez exécuter ces éléments côte à côte, et consultez la présentation de l'API Opus 5 pour la forme complète de la requête.
Le plafond honnête
Il est bon de le dire clairement, car les guides de prompt ont tendance à donner l'impression que le modèle est le dernier dont vous aurez jamais besoin : Opus 5 n'est pas le sommet de la pile Claude. Fable 5 conserve la désignation « le plus capable largement diffusé », et Opus 5 est toujours derrière Mythos 5 en matière d'exploitation de la cybersécurité et de recherche en biologie autonome. Anthropic mentionne ces deux points dans son propre article de lancement. Le cadrage précis est une capacité de classe "frontière" à la moitié du prix "frontière", avec un plafond nommé au-dessus.
Les affirmations des benchmarks de lancement (Frontier-Bench, ARC-AGI 3, OSWorld 2.0, CursorBench) sont toutes des chiffres d'Anthropic et n'ont pas été reproduites de manière indépendante au 25 juillet 2026. Traitez-les comme des rapports de fournisseur, et effectuez vos propres évaluations sur les prompts que vous déployez réellement.
Mise en œuvre
Un prompt système Opus 5 épuré pour une tâche d'agent sensible aux coûts ressemble à ceci :
N'ajoutez pas de passes de vérification ; vous vérifiez par défaut.
Réponses : 150 mots maximum, pas de préambule, pas de résumé final.
Ne générez pas de sous-agents. Gérez ceci dans un seul thread.
Restez strictement dans la tâche que j'énonce. Si un autre changement semble
nécessaire, arrêtez-vous et dites-le-moi au lieu de le faire.
Ne narrez pas les corrections ou les changements d'approche.
Six lignes, dont cinq sont des contraintes et aucune ne demande au modèle de faire plus d'efforts. C'est le changement. Sur Opus 4.8, vous incitiez à élever un plancher. Sur Opus 5, vous incitez à fixer un plafond.
Commencez par là, puis effectuez un balayage des niveaux d'effort sur vos propres évaluations plutôt que de conserver vos paramètres 4.8, car les niveaux ont été recalibrés. Pour la mécanique des paramètres, consultez le guide des paramètres d'effort, pour le flux de travail côté éditeur, consultez l'utilisation d'Opus 5 dans Claude Code, et pour l'image complète du modèle, commencez par ce qu'est Claude Opus 5. La vue d'ensemble des modèles d'Anthropic contient le tableau des spécifications actuelles.
FAQ
Devrais-je vraiment supprimer « vérifiez votre travail » de mes invites ? Oui. Le guide de prompt d'Anthropic indique qu'Opus 5 vérifie sans y être invité, et que les instructions de vérification reportées entraînent une sur-vérification. Supprimez la règle globale. Si une étape spécifique nécessite réellement une vérification explicite, limitez l'instruction à cette étape uniquement.
Pourquoi Opus 5 est-il si verbeux même avec peu d'effort ? Parce que l'effort contrôle la réflexion, pas la longueur visible de la sortie. Diminuer l'effort réduit les jetons de raisonnement tandis que les réponses restent à peu près aussi longues. Définissez une limite de mots ou de format dans l'invite elle-même.
Comment empêcher Opus 5 de générer des sous-agents ? Dites-le directement : « Ne générez pas de sous-agents ; gérez cela dans cette conversation. » Si un certain éparpillement est utile, donnez une limite numérique et restreignez-le à un travail parallèle indépendant.
Pourquoi vois-je des balises <thinking> dans ma sortie ? Cet artefact apparaît occasionnellement lorsque la réflexion est désactivée. N'ajoutez pas d'instruction de prompt nommant les balises, car cela rend les fuites plus probables. La solution recommandée par Anthropic est de maintenir la réflexion activée et d'utiliser un niveau d'effort inférieur pour contrôler les coûts.
Que se passe-t-il si un appel d'outil est renvoyé en texte brut ? Rien ne s'exécute, et le texte divulgué reste dans l'historique de la conversation où les tours ultérieurs le traitent comme une action terminée. Validez les interventions de l'assistant avant de les ajouter à l'historique, et préférez maintenir la réflexion activée plutôt que de la désactiver.