La plupart des guides de migration expliquent ce qui casse dans votre code. Celui-ci se concentre sur ce qui casse dans vos prompts.
Essayez Apidog dès aujourd'hui
Claude Opus 5 a été lancé le 24 juillet 2026, avec un guide de prompt dédié d’Anthropic. Point important : plusieurs instructions qui amélioraient Opus 4.8 dégradent Opus 5. Elles peuvent augmenter les coûts, allonger les réponses et, lorsque la réflexion est désactivée, introduire des sorties défectueuses dans une boucle d’agent.
La raison est simple : Opus 5 effectue déjà par défaut plusieurs comportements que vous deviez explicitement demander à Opus 4.8. Si votre ancien prompt les exige encore, les comportements s’additionnent. Vous obtenez deux passes de vérification, pas deux fois plus de précision.
Ce guide liste les changements documentés, avec des extraits prêts à intégrer dans votre prompt système. Il couvre aussi les deux modes de défaillance liés à la désactivation de la réflexion. Pour les changements côté code, consultez le guide de migration d’Opus 4.8 vers Opus 5. Pour comparer les requêtes et réponses avec différents paramètres, vous pouvez utiliser Apidog.
Le résumé en une ligne
Opus 5 vérifie davantage, écrit davantage, délègue davantage et explique davantage qu’Opus 4.8.
Votre prompt Opus 4.8 poussait le modèle vers ces comportements. Avec Opus 5, il faut surtout poser des limites :
- supprimer les vérifications globales ;
- fixer une longueur de réponse ;
- borner les sous-agents ;
- limiter strictement la portée ;
- empêcher la narration des corrections dans les sorties machine.
1. Supprimez les instructions de vérification globales
Anthropic indique qu’Opus 5 vérifie son travail sans y être invité. Il peut relire sa réponse, vérifier des calculs, rejouer un test ou chercher des cas limites.
Sur Opus 4.8, on ajoutait souvent des instructions comme :
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.
Sur Opus 5, ces instructions déclenchent une sur-vérification. Le modèle effectue ses contrôles par défaut, puis ceux que vous avez demandés. Sur une longue boucle d’agent, cela augmente directement les jetons et la latence.
Action : recherchez ces formulations dans vos prompts système et supprimez-les.
Si une seule étape doit être vérifiée explicitement, ciblez uniquement cette étape :
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.
Une règle globale comme « vérifiez tout » multiplie les coûts. Une exception limitée reste contrôlable.
Pour suivre l’impact sur votre budget API, combinez cette modification avec les recommandations de la répartition des prix d’Opus 5 et du guide pour réduire une facture API Claude.
2. Demandez explicitement des réponses concises
Les réponses par défaut d’Opus 5 sont plus longues que celles d’Opus 4.8. Cela concerne aussi les rapports, résumés, documents de conception et README générés par le modèle.
Ne comptez pas sur le paramètre effort pour résoudre ce problème.
effort contrôle la quantité de réflexion du modèle, pas la longueur de la sortie visible. Passer de xhigh à medium peut réduire les jetons de raisonnement sans raccourcir significativement la réponse.
Consultez le guide des paramètres d’effort d’Opus 5 pour le détail des niveaux.
Action : définissez des contraintes de format mesurables dans le prompt.
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 un livrable écrit, contraignez directement l’artefact :
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 une tâche de code, limitez plutôt les commentaires périphériques :
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. Sur une tâche multi-parties, un harnais compatible peut entraîner la création de branches de travail.
Cela peut être utile, mais chaque sous-agent possède son propre contexte et consomme ses propres jetons.
Pour une tâche sensible au coût ou à la latence, interdisez la délégation :
Ne générez pas de sous-agents pour cette tâche. Gérez-la dans cette conversation.
Si la parallélisation est nécessaire, imposez une limite explicite :
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.
Évitez la délégation sans valeur ajoutée : un sous-agent pour lire un fichier, ou pour prendre une décision alors que le thread principal possède déjà le contexte.
Si vous construisez volontairement une architecture multi-agent, consultez le guide sur la création de sous-agents de code Claude.
4. Verrouillez la portée des tâches étroites
Opus 5 peut élargir la portée d’une demande. Demandez une correction de test et il peut aussi refactoriser une fonction, modifier une signature de type ou ajouter des cas de test.
Pour un changement chirurgical, cela produit un diff plus difficile à relire et augmente le rayon d’action du changement.
Action : indiquez ce qui est autorisé et 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.
La dernière phrase est essentielle : elle permet au modèle de signaler un problème réel sans modifier silencieusement d’autres parties du projet.
5. Désactivez la narration des corrections si votre sortie est consommée par une machine
Opus 5 explique davantage ses changements d’approche qu’Opus 4.8. Dans une conversation interactive, cela peut être utile.
Dans un pipeline où la réponse est envoyée vers un parseur, une interface ou un autre modèle, cette narration devient du bruit.
Utilisez cette contrainte :
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 stockez les réponses dans un format structuré, associez cette instruction à des sorties structurées. La forme de réponse doit être appliquée par le schéma, pas uniquement demandée par le prompt.
Modes de défaillance lorsque la réflexion est désactivée
Les sections précédentes concernent surtout l’ajustement des coûts et du comportement. Cette section concerne la correction fonctionnelle.
Anthropic documente deux artefacts possibles lorsque la réflexion est désactivée avec :
{
"thinking": {
"type": "disabled"
}
}
Appels d’outils renvoyés en texte brut
Le modèle peut produire un contenu qui ressemble à un appel d’outil, mais l’émettre comme texte dans la réponse au lieu d’un bloc structuré tool_use.
Dans ce cas :
- aucun outil ne s’exécute ;
- la boucle d’agent ne détecte pas d’appel d’outil ;
- le texte est ajouté à l’historique ;
- les tours suivants peuvent interpréter ce texte comme une action déjà réalisée.
Dans un chat isolé, vous le verrez probablement. Dans une boucle multi-tour, le problème peut se propager avant d’être détecté.
Balises XML internes dans la sortie visible
Des balises telles que <thinking> peuvent parfois apparaître dans la réponse utilisateur.
C’est gênant visuellement, et potentiellement dangereux si vous rendez la réponse en HTML ou si vous analysez sa structure.
N’ajoutez pas une instruction telle que « ne jamais afficher les balises <thinking> ». Nommer les balises dans le contexte augmente le risque qu’elles soient reproduites.
Mitigation recommandée
La recommandation n’est pas d’ajouter un prompt. Conservez la réflexion activée et réduisez le coût via effort :
{
"model": "claude-opus-5",
"max_tokens": 4096,
"output_config": { "effort": "low" },
"messages": [
{ "role": "user", "content": "..." }
]
}
Cette configuration utilise l’extrémité économique de la gamme tout en évitant les artefacts associés à la réflexion désactivée.
Attention également : combiner thinking: {type: "disabled"} avec un effort xhigh ou max retourne une erreur 400. Lorsque la réflexion est désactivée, l’effort est plafonné à high.
La réflexion est maintenant activée par défaut. Une requête qui omet le champ thinking utilise donc une réflexion adaptative, contrairement au comportement attendu sur Opus 4.8.
Si vous devez absolument désactiver la réflexion, protégez votre boucle d’agent côté application :
- validez chaque message assistant avant de l’ajouter à l’historique ;
- détectez les chaînes qui ressemblent à un appel d’outil non exécuté ;
- rejetez la réponse et échouez explicitement au lieu de conserver un appel fantôme dans la transcription.
Testez les changements au lieu de les supposer
Les modifications de prompt sont difficiles à évaluer à la lecture. Ici, les effets se mesurent dans les jetons, les champs usage, les préfixes de cache et la structure des blocs de réponse.
Vous pouvez mettre en place ce test dans Apidog, une plateforme de développement et de test d’API :
- Créez une requête vers l’endpoint Anthropic Messages avec
"model": "claude-opus-5". - Stockez la clé API dans une variable d’environnement, jamais directement dans le corps de requête.
- Enregistrez votre ancien prompt système Opus 4.8 et la version simplifiée pour Opus 5 comme deux requêtes distinctes.
- Envoyez les deux requêtes avec la même entrée.
- Comparez le bloc
usagede chaque réponse :- les jetons de sortie indiquent si la contrainte de concision fonctionne ;
- les jetons d’entrée et les champs de cache montrent si le préfixe de cache a changé.
- Dupliquez les requêtes avec plusieurs niveaux d’effort pour observer la baisse des jetons de réflexion.
- Inspectez les réponses en streaming pour vérifier que les appels d’outils arrivent sous forme de blocs
tool_use, et non comme texte brut.
L’étape 7 est celle qui permet de détecter un appel d’outil en texte brut avant la production.
Téléchargez Apidog pour exécuter les requêtes côte à côte, puis consultez la présentation de l’API Opus 5 pour la forme complète des requêtes.
Le plafond honnête
Opus 5 n’est pas le sommet de la pile Claude. Fable 5 conserve la désignation de modèle « le plus capable largement diffusé », tandis qu’Opus 5 reste derrière Mythos 5 pour l’exploitation de la cybersécurité et la recherche en biologie autonome.
Anthropic mentionne ces éléments dans son article de lancement.
Le positionnement précis est donc : une capacité de classe « frontière » à la moitié du prix « frontière », avec un plafond explicitement identifié au-dessus.
Les chiffres annoncés lors du lancement pour Frontier-Bench, ARC-AGI 3, OSWorld 2.0 et CursorBench proviennent d’Anthropic et n’avaient pas été reproduits indépendamment au 25 juillet 2026. Traitez-les comme des données fournisseur et exécutez vos propres évaluations sur les prompts réellement déployés.
Mise en œuvre : prompt système minimal pour un agent sensible aux coûts
Voici une base de prompt système Opus 5 :
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.
Ces lignes posent principalement des contraintes. Elles ne demandent pas au modèle de « travailler plus ».
Avec Opus 4.8, les prompts servaient souvent à relever le niveau de comportement du modèle. Avec Opus 5, ils servent surtout à fixer un plafond.
Commencez par ce prompt, puis testez les niveaux d’effort sur vos propres évaluations : les niveaux ont été recalibrés.
Pour aller plus loin :
- Guide des paramètres d’effort
- Utiliser Opus 5 dans Claude Code
- Qu’est-ce que Claude Opus 5 ?
- Vue d’ensemble des modèles Anthropic
FAQ
Dois-je vraiment supprimer « vérifiez votre travail » de mes prompts ?
Oui. Le guide de prompt d’Anthropic indique qu’Opus 5 vérifie déjà son travail sans instruction explicite. Supprimez la règle globale et ne conservez une vérification explicite que pour une étape critique clairement définie.
Pourquoi Opus 5 reste-t-il verbeux avec un effort faible ?
Parce que effort contrôle la réflexion, pas la longueur de la sortie visible. Pour raccourcir une réponse, définissez une limite de mots, une structure attendue et les sections à exclure directement dans le prompt.
Comment empêcher Opus 5 de créer des sous-agents ?
Indiquez-le explicitement :
Ne générez pas de sous-agents. Gérez cette tâche dans cette conversation.
Si vous autorisez une délégation limitée, fixez un nombre maximal de sous-agents et restreignez-la aux tâches indépendantes exécutables en parallèle.
Pourquoi vois-je des balises <thinking> dans la sortie ?
Cet artefact peut apparaître lorsque la réflexion est désactivée. N’ajoutez pas de consigne qui nomme ces balises. Maintenez plutôt la réflexion activée et utilisez un niveau d’effort inférieur pour réduire les coûts.
Que faire si un appel d’outil est renvoyé en texte brut ?
Aucun outil ne s’exécute, mais le texte peut contaminer l’historique de la conversation et être interprété comme une action terminée aux tours suivants. Validez les messages assistant avant de les ajouter à l’historique et préférez conserver la réflexion activée.
Top comments (0)