Introduction
Anthropic a récemment présenté une transformation majeure dans la façon dont Claude Code fournit le contexte à ses modèles les plus récents.
Pour Claude Opus 5, Claude Fable 5 et les autres modèles avancés Claude 5, la société indique avoir supprimé plus de 80 % des instructions système qui guidaient auparavant les anciens modèles vers un fonctionnement correct. Anthropic précise également que cette simplification n’a entraîné aucune perte de performance mesurable dans ses évaluations de codage.
Cela ressemble à une histoire simple : des modèles plus puissants nécessitent moins de règles détaillées.
Pourtant, un développeur indépendant, Chen Cheng (@chenchengpro), a capturé le contexte de sortie généré par Claude Code pour plusieurs versions de modèles et a rapporté une séquence surprenante :
| Modèle | Nombre de caractères des instructions système rapportées |
|---|---|
| Claude Opus 4.7 | 15 225 |
| Claude Opus 4.8 | 4 467 |
| Claude Opus 5 | 7 694 |
D’Opus 4.8 à Opus 5, le contenu mesuré des instructions a augmenté d’environ 72 %.
À première vue, l’affirmation d’Anthropic de « supprimer plus de 80 % » semble contredire la « croissance de 72 % » constatée par le développeur.
Ce n’est pas le cas.
Ces deux chiffres utilisent des références différentes et décrivent des aspects distincts de la transformation de Claude Code. Anthropic décrit la rupture avec une architecture d’instructions ancienne et très prescriptive. Le développeur, quant à lui, compare Opus 5 avec les instructions exceptionnellement compactes utilisées par Opus 4.8 dans un paramétrage de capture spécifique.
Claude Code a bien supprimé une grande partie de l’ancien cadre instructionnel. Opus 5 a ensuite reçu un ensemble plus réduit de nouvelles contraintes ciblées, destinées à encadrer des comportements devenus plus marqués à mesure que l’autonomie du modèle augmentait.
Anthropic a supprimé plus de 80 % de l’ancien contenu des instructions
L’explication officielle d’Anthropic part d’un problème bien connu des développeurs d’agents : l’accumulation des instructions.
Lorsqu’un modèle refaisait la même erreur, l’équipe produit ajoutait une règle. S’il écrivait des commentaires superflus, on ajoutait une règle sur les commentaires. S’il créait des documents de planification inutiles, on ajoutait une règle sur la documentation. S’il utilisait mal un outil, on ajoutait des exemples d’utilisation. S’il ne vérifiait pas ses résultats, on ajoutait encore une instruction de validation.
Avec le temps, les instructions système ont commencé à ressembler à un manuel de l’employé constitué incident après incident.
Cette approche a aidé les premiers modèles, mais a aussi introduit de nouveaux problèmes.
Les chevauchements d’instructions créent des frictions
Claude Code ne reçoit pas qu’une seule instruction. Son contexte de travail peut inclure :
- Les instructions système du produit
- Les définitions des outils
- Le fichier
CLAUDE.md - Les règles
- Les compétences
- La mémoire
- Les instructions de l’utilisateur
- Les fichiers du dépôt de code
- Les sorties des commandes et des outils
Lorsque plusieurs couches d’instructions se répètent ou se contredisent légèrement, le modèle doit dépenser de l’énergie de raisonnement pour décider quelle instruction doit primer.
Par exemple, une couche peut dire « ajouter de la documentation quand c’est approprié », tandis qu’une autre dit « ne pas créer de commentaires ni de documentation sauf demande explicite ». Puis un fichier du projet peut ajouter une troisième règle couvrant le même comportement.
Le modèle peut tout de même obtenir le bon résultat, mais le contexte effectue un travail inutile avant même que la tâche de codage ne commence.

Les modèles mis à jour peuvent davantage s’appuyer sur le jugement local
Anthropic donne un exemple clair concernant les commentaires et la documentation.
L’ancienne version de Claude Code utilisait des restrictions strictes et détaillées visant à empêcher les commentaires de faible qualité et les fichiers de planification inutiles. Les instructions mises à jour sont bien plus concises : écrire un code cohérent avec le style du projet environnant, y compris ses conventions de nommage, son style idiomatique et sa densité de commentaires.
Ce changement fait passer la prise de décision d’une règle globale à une preuve locale.
Le système ne dit plus à Claude que les commentaires sont toujours à éviter, mais lui demande d’examiner comment le code existant dans le dépôt communique les intentions.
C’est le schéma plus large derrière cette simplification des instructions :
Méthode ancienne :
Décrire toutes les erreurs possibles et les interdire à l’avance.
Nouvelle méthode :
Fournir le rôle produit, les outils, les limites et les preuves pertinentes,
puis laisser le modèle juger par lui-même dans ces contraintes.
Anthropic rapporte que la suppression de plus de 80 % de l’ancien contenu des instructions système n’a entraîné aucune baisse mesurable dans ses évaluations de codage.
Ce résultat ne signifie pas que les instructions ne sont plus importantes. Il signifie que les instructions efficaces ont changé.
Les nouvelles règles de l’ingénierie du contexte
La refonte d’Anthropic peut se résumer par quelques transitions « avant / après ».
| Ancienne approche | Nouvelle approche |
|---|---|
| Donner à Claude de nombreuses règles détaillées | Laisser Claude juger en fonction du contexte environnant |
| Enseigner les outils avec des exemples répétés | Concevoir des interfaces d’outils claires et expressives |
| Mettre toutes les instructions opérationnelles dans le contexte initial | Charger des instructions spécialisées uniquement quand nécessaire |
| Répéter les consignes sur les outils à plusieurs endroits | Conserver chaque instruction au niveau le plus approprié |
| Décrire les sorties attendues avec un texte long | Fournir des exemples de référence riches et exécutables |
Ces changements ne s’appliquent pas uniquement aux instructions système internes d’Anthropic. Ils influencent aussi la manière dont les développeurs doivent maintenir CLAUDE.md, les compétences, les outils et les frameworks d’agents personnalisés.
Garder CLAUDE.md centré sur les faits propres au projet
Le fichier CLAUDE.md est chargé au début d’une session Claude Code. Il est donc idéal pour placer les informations du dépôt que Claude doit connaître en permanence.
Un bon contenu inclut :
- Les décisions architecturales qui ne peuvent pas être déduites du code.
- Les commandes de construction et de test requises.
- Les conventions propres au dépôt.
- Les répertoires importants et les limites de propriété.
- Les bibliothèques que le projet exige ou interdit.
- Les contraintes de sécurité ou de déploiement non évidentes.
Un contenu moins utile inclut :
- Des conseils généraux que Claude connaît déjà.
- Des étapes opérationnelles longues utilisées seulement occasionnellement.
- Des faits directement visibles dans les fichiers de package ou le code source.
- Les mêmes instructions répétées dans les outils, les compétences et les instructions utilisateur.
- De grands exemples qui consomment du contexte à chaque requête.
La documentation actuelle de Claude Code recommande de garder CLAUDE.md concis et de déplacer le matériel procédural ou dense en références dans des fichiers de compétences chargés à la demande.
Un fichier centralisé pourrait ressembler à ceci :
# Guide du projet
- Toutes les commandes de gestion des paquets utilisent pnpm.
- Avant de signaler la fin d’une modification de code, exécuter `pnpm test` et `pnpm lint`.
- Les API publiques sont définies sous `packages/sdk` ; éviter les changements cassants.
- Les migrations de base de données doivent inclure un fichier de rollback correspondant.
- Ne pas modifier directement les fichiers générés sous `src/generated`.
Pas besoin d’expliquer en détail les comportements génériques du génie logiciel.
Transférer les longues procédures vers les compétences
Les compétences encapsulent des instructions réutilisables dans des fichiers SKILL.md. Leur contenu complet n’est chargé que lorsqu’on utilise cette compétence, sans consommer du contexte pour chaque tâche sans rapport.
Cela rend les compétences bien plus adaptées pour porter des flux de travail tels que :
- La relecture de demandes de tirage (pull requests).
- La préparation de versions.
- Les vérifications de sécurité.
- La validation frontale.
- Les migrations de base de données.
- L’investigation d’incidents.
- La publication de documentation.
Une compétence de relecture minimale pourrait être structurée ainsi :
description : Relire les demandes de tirage pour en vérifier l’exactitude, les régressions et les tests manquants.
Nom : relecture-pr
# Révision de la demande de tirage
1. Lisez la totalité de la différence et les tests concernés.
2. Identifiez d'abord les défauts spécifiques, plutôt que les préférences stylistiques.
3. Exécutez la suite de tests pertinente la plus réduite.
4. Vérifiez si le comportement public ou la compatibilité a changé.
5. Signalez les constatations par gravité, avec référence aux fichiers.
Cette étape n'est disponible qu'au début du travail de révision, mais n'alourdit pas une demande qui demanderait simplement à Claude de renommer une variable.
Il s'agit d'une divulgation progressive : fournir le contexte approprié aux moments clés.
## Supprimer les instructions redondantes
En règle générale, chaque instruction ne devrait exister que dans un seul endroit faisant autorité.
Par exemple :
- Le comportement au niveau du produit relève de la consigne système.
- Les faits au niveau du projet relèvent de `CLAUDE.md`.
- Les étapes réutilisables relèvent des compétences.
- Les exigences spécifiques aux outils relèvent de la définition de l'outil.
- L'exécution déterministe relève des hooks, des autorisations, des tests ou des scripts.
Répéter la même règle à chaque niveau ne renforce pas nécessairement son efficacité, mais peut augmenter la taille du contexte, introduire des variations de formulation et accroître la difficulté de maintenance ultérieure.
Avant d'ajouter une autre instruction, demandez-vous :
1. Ce point est-il déjà exprimé ailleurs ?
2. Claude peut-il le déduire de la base de code ?
3. S'agit-il d'un fait, d'une étape ou d'une exigence d'exécution stricte ?
4. Est-il nécessaire de le charger à chaque requête ?
5. Un test ou un hook exécute-t-il cette règle de manière plus fiable qu'une description textuelle ?
## Concevoir de meilleurs outils, plutôt que d'écrire plus d'exemples
Les premiers guides d'ingénierie des consignes recommandaient souvent de fournir plusieurs exemples d'utilisation d'outils.
Anthropic estime que les exemples peuvent limiter la capacité des modèles avancés à suivre des chemins démontrés. Le modèle peut imiter l'échantillon, plutôt que de choisir des paramètres ou des combinaisons d'outils plus optimaux pour la tâche en cours.
Un outil bien conçu doit communiquer clairement son utilisation à travers son interface :
- Des noms de paramètres explicites.
- Des descriptions précises.
- Des champs optionnels explicites.
- Des valeurs d'énumération utiles.
- Des sorties prévisibles.
- Des messages d'erreur exploitables.
Par exemple, la valeur d'énumération suivante :
```JSON
{
"statut": "en_attente | en_cours | terminé"
}
transmet plus directement les règles de transition d'état valides qu'un long paragraphe.
Incluez quelques exemples fixes.
Les exemples restent utiles lorsque le format ou le comportement aux limites peut être ambigu. Ce changement ne signifie pas « jamais d'exemples », mais « ne pas utiliser d'exemples pour remplacer une interface bien conçue. »
Fournir des références exécutables
Les nouveaux modèles Claude peuvent travailler directement à partir de références plus riches.
Les développeurs n'ont pas besoin de décrire chaque exigence avec du texte, mais peuvent fournir :
- Du code existant.
- Des cas de test.
- Une commande qui échoue.
- Un prototype HTML.
- Une capture d'écran.
- Un schéma.
- Un artefact de conception.
- Un script de benchmark.
- Un exemple d'entrée et la sortie attendue.
Un test exécutable définit souvent le critère de succès plus clairement que plusieurs paragraphes expliquant que « l'implémentation doit être correcte ».
Cela fait passer l'ingénierie du contexte de la rédaction de manuels volumineux à la conception d'un meilleur environnement de travail.
Une capture indépendante révèle un rebond de 72 %
Après l'annonce par Anthropic d'une réduction de 80 %, le développeur Chen Cheng a signalé avoir testé ce que Claude Code envoie réellement pour plusieurs modèles Opus.
Il a redirigé le CLI vers un serveur local et enregistré le contenu des requêtes sortantes. Les nombres de caractères qu'il a publiés sont les suivants :
Opus 4.7 : 15 225 caractères
Opus 4.8 : 4 467 caractères
Opus 5 : 7 694 caractères

Ces chiffres montrent trois comparaisons différentes :
| Comparaison | Variation approximative |
|---|---|
| Opus 4.7 → Opus 4.8 | Réduction de 70,7 % |
| Opus 4.8 → Opus 5 | Augmentation de 72,2 % |
| Opus 4.7 → Opus 5 | Réduction de 49,5 % |
Par conséquent, la consigne d'Opus 5 capturée cette fois est beaucoup plus longue que celle d'Opus 4.8, mais environ deux fois plus courte que celle d'Opus 4.7.
Il s'agit de nombres de caractères, et non de nombres de jetons. Ils ne représentent également qu'une configuration capturée de Claude Code, et non une spécification universelle pour chaque requête.
Claude Code peut composer dynamiquement le contexte en fonction des outils, de la configuration, des fonctionnalités et de l'état du produit. Le contenu exact transmis peut varier selon la version et l'environnement.
Pourquoi les chiffres de 80 % et 72 % peuvent tous deux être corrects
Une fois que l'on distingue les différentes bases de référence, cette contradiction apparente disparaît.
Le chiffre d'Anthropic décrit un nettoyage architectural
Anthropic indique avoir supprimé plus de 80 % du contenu de la consigne système utilisée par le modèle avancé Claude 5, par rapport à la conception ancienne riche en instructions.
Ce chiffre concerne la quantité de consignes existantes supprimées lors de la transition vers une architecture d'ingénierie du contexte plus récente.
Il ne prétend pas que chaque requête Opus 5 est 80 % plus courte en nombre de caractères que chaque requête Opus 4.8.
Le chiffre du développeur compare deux captures adjacentes
Le chiffre de 72 % compare la requête Opus 5 enregistrée avec la requête Opus 4.8 exceptionnellement petite capturée par le développeur.
Opus 4.8 semble être le point le plus bas dans cette comparaison de trois modèles. Quant à Opus 5, il
a ajouté des orientations ciblées, tout en restant beaucoup plus court que l'ancien chemin Opus 4.7.
Ainsi, les deux affirmations peuvent coexister :
Ancienne architecture de consigne → Consigne du modèle avancé :
Réduction globale importante.
Capture Opus 4.8 → Capture Opus 5 :
Augmentation partielle par rapport à la version mesurée la plus réduite.
Claude Code semble maintenir différents chemins de consignes
L'examen du développeur a également rapporté que l'implémentation de Claude Code contient deux ensembles de chemins de consignes.
Une fonction de routage sélectionne la consigne existante plus détaillée pour les identifiants de modèles plus anciens, et la consigne simplifiée pour les modèles plus récents.
Selon la logique rapportée, les modèles comme Opus, Sonnet, Haiku et la série Claude 3 se trouvent sur le chemin détaillé, tandis qu'Opus 4.8, Opus 5, Fable 5 et d'autres modèles plus récents utilisent une architecture plus courte.

Ce détail de routage provient d'un examen tiers, et non de la documentation d'architecture officielle d'Anthropic.
Cependant, cela correspond à l'explication publique d'Anthropic : les modèles plus forts peuvent fonctionner avec un cadre normatif plus léger, tandis que les modèles plus anciens peuvent encore avoir besoin de contraintes explicites que les nouveaux modèles peuvent déduire du contexte.
Pourquoi Opus 5 a besoin de nouvelles orientations ciblées
Claude Opus 5 est bien plus performant que les premiers modèles Opus dans le travail autonome de longue durée.
Cette capacité introduit des comportements utiles pour les grandes tâches, mais coûteux ou distrayants pour les petites tâches.
Le guide officiel des invites Opus 5 d'Anthropic met en évidence plusieurs aspects pouvant nécessiter des ajustements :
Creez un site vitrine et genere des leads en quelques minutes
Decrivez votre idee une fois, et We0 AI peut generer un site vitrine, des pages et un CMS, puis vous aider a attirer clients et trafic apres le lancement.
Une génération de projet complète pour une inscription gratuite
Idéal pour essayer un flux de génération complet et voir rapidement une première ébauche de projet.
- Longueur et verbosité des réponses.
- Mises à jour de progression destinées à l'utilisateur.
- Longueur des livrables écrits.
- Périmètre des tâches.
- Vérification excessive.
- Délégation à des sous-agents.
- Auto-correction.
Selon l'analyse des différences de développement rapportée, une grande quantité de nouveau contenu est apparue autour de la réalisation du travail et de la gestion des corrections.
Le texte privé exact ne doit pas être considéré comme une norme publique officielle, mais ces catégories correspondent étroitement aux directives Opus 5 déjà publiées par Anthropic.
Les mises à jour de progression peuvent devenir trop fréquentes
Pour les migrations de longue durée ou les investigations à l'échelle du dépôt, les rapports de progression sont utiles.
Pour les petites modifications, des récits fréquents augmentent la latence et la consommation de jetons sans améliorer le code.
Une stratégie d'agent utile doit distinguer ces deux cas :
Signaler la progression lors de travaux longs et en plusieurs étapes, lorsque les mises à jour aident l'utilisateur à comprendre l'état ou à prendre des décisions.
Ne pas décrire chaque appel d'outil de routine.
L'objectif n'est pas le silence, mais une communication proportionnée.
Les modèles plus puissants peuvent étendre excessivement le périmètre des tâches
Un agent de codage avancé, tout en effectuant la modification demandée, peut remarquer des problèmes connexes.
Parfois, cette initiative est précieuse. D'autres fois, elle peut transformer une simple demande en une refonte extensive non approuvée par l'utilisateur.
Pour Opus 5, les limites des tâches deviennent plus importantes, précisément parce que le modèle est plus capable.
Il est meilleur pour trouver du travail supplémentaire.
Une demande claire peut être formulée ainsi :
Corriger le problème signalé et les tests directement impactés.
Ne pas refactoriser les modules non pertinents ni étendre l'API publique.
Les conditions limites définissent ce que signifie « terminé », sans prescrire chaque étape de mise en œuvre.
Les sous-agents peuvent augmenter les coûts
Anthropic indique qu'Opus 5 est plus enclin à utiliser des sous-agents que les modèles précédents.
La délégation est précieuse lorsque le travail est véritablement indépendant et d'une échelle suffisante pour un traitement parallèle. Elle est inefficace lorsque la tâche peut être accomplie directement avec quelques appels d'outils.
Le guide officiel recommande de fournir des conditions claires ou des limites déterministes.
Des instructions pratiques sont les suivantes :
N'utiliser les sous-agents que pour des flux de travail volumineux et indépendants.
Ne pas créer de sous-agents pour répéter ou vérifier un travail que tu peux effectuer directement.
Maintenir un nombre réduit d'agents simultanés.
Cela permet de contrôler les coûts et le temps sans désactiver les fonctionnalités utiles.
Les auto-corrections répétées peuvent être un gaspillage
Opus 5 est conçu pour découvrir et corriger lui-même nombre de ses erreurs.
Les invites qui demandent de façon répétée « revérifie tout », « vérifie à nouveau » ou « utilise un autre agent pour revérifier » s'ajoutent au comportement inné du modèle.
Anthropic indique que la suppression des instructions de vérification redondantes peut réduire la consommation de jetons inutiles sans diminuer la qualité.
La vérification reste essentielle, mais doit être basée sur des preuves concrètes :
- Exécuter les tests pertinents.
- Compiler le projet.
- Vérifier la page rendue.
- Comparer la sortie avec les spécifications.
- Inspecter le diff final.
Un schéma inefficace consiste à exiger une réflexion abstraite supplémentaire après que les vérifications objectives ont déjà réussi.
Comment les développeurs devraient-ils s'adapter maintenant
Les directives officielles et les tests indépendants pointent vers les mêmes leçons pratiques : le contexte doit être organisé autour de la fonctionnalité, et non empilé en raison de préoccupations.
- Examiner la pile de contexte complète
Vérifier tous les éléments susceptibles d'influencer Claude :
CLAUDE.md- Règles
- Compétences
- Descriptions des outils
- Hooks
- Instructions du serveur MCP
- Invites utilisateur
- Invites système personnalisées dans les cadres d'agents
Rechercher les instructions dupliquées, conflictuelles, obsolètes ou trop générales.
- Ne conserver dans
CLAUDE.mdque les règles de projet non évidentes
Supprimer les informations que Claude peut obtenir directement des fichiers sources, des manifestes de paquets ou des spécifications standard.
Ne conserver que le contenu des décisions qui ne sont pas autrement visibles.
- Transférer les processus dans des compétences
Si une partie décrit une séquence reproductible plutôt qu'un fait fixe, la transformer en compétence.
Cela réduit la taille du contexte par défaut et rend les flux de travail réutilisables.
- Placer les descriptions des outils dans les outils eux-mêmes
Ne pas répéter les règles des paramètres des outils dans l'invite système, CLAUDE.md et chaque demande utilisateur.
Fournir aux outils une architecture clairement exprimée et des descriptions précises.
- Remplacer les longues descriptions par des tests et des références
Dans la mesure du possible, fournir des artefacts réels qui définissent le succès.
Des tests échoués, des prototypes, une architecture ou une sortie attendue sont plus précis que de longs discours décrivant « à quoi le résultat devrait ressembler ».
- Définir des limites pour le comportement proactif d'Opus 5
Pour les petites tâches, préciser clairement :
- Le périmètre autorisé.
- Si l'utilisation de sous-agents est raisonnable.
- Comment la
progression est utile à raconter.
- Quelle vérification est nécessaire.
- Quand l'agent doit s'arrêter.
Ne pas compenser en restaurant un énorme manuel générique.
- Exécuter les outils de diagnostic de Claude Code
Anthropic indique que les meilleures pratiques actuelles sont intégrées dans le flux de travail du docteur de Claude Code.
Dans le shell, exécuter :
claude doctor
Dans Claude Code, exécuter :
/doctor
Le diagnostic peut vérifier l'installation, la configuration, les serveurs MCP et l'utilisation du contexte. La version actuelle peut également aider à identifier les configurations de contexte trop volumineuses ou invalides.
Ses recommandations doivent être examinées, et non supprimer aveuglément les instructions du projet.
Un exemple de contexte avant/après
Configuration surchargée
## CLAUDE.md
Avant d'éditer, toujours vérifier le dépôt.
Toujours écrire un code propre.
Toujours tester chaque modification.
Ne jamais ajouter de commentaires superflus.
Ne jamais ajouter de fichiers superflus.
Utiliser l'outil de test exactement comme indiqué dans l'exemple ci-dessous...
[Plusieurs pages d'explications sur la révision, la publication, les tests et les outils]
Ce fichier contient des attentes générales, des processus reproductibles et une documentation d'outils dont l'utilité varie selon les tâches.
Configuration ciblée
## CLAUDE.md
- Utiliser pnpm ; ce dépôt ne prend pas en charge npm ou yarn.
- Nécessité de compatibilité de l'API publique sous `packages/sdk`.
- Exécuter `pnpm test` et `pnpm lint` avant de terminer les modifications de code.
- Les étapes de publication se trouvent dans la compétence `/release-check`.
- Les étapes de révision de sécurité se trouvent dans la compétence `/security-review`.
Le fichier plus petit conserve les informations spécifiques au projet et délègue les processus conditionnels aux compétences.
C'est ainsi que se traduit concrètement la réduction des invites : moins d'instructions permanentes, un contexte mieux structuré.
Les mesures ne prouvent rien
Le nombre de caractères dans les rapports est utile, mais ne doit pas être surinterprété.
Ils ne prouvent pas :
- Que chaque requête Opus 5 contient toujours exactement 7 694 caractères.
- Que la longueur de l'invite système prédit directement la qualité du codage.
- Qu'une invite plus courte est automatiquement meilleure.
- Que les données des 80 % d'Anthropic sont fausses.
- Qu'Opus 5 nécessite 72 % de contexte total en plus par session qu'Opus 4.8.
- Que le texte capturé inclut chaque instruction dynamique de l'utilisation du produit.
La longueur de l'invite n'est qu'une variable parmi d'autres.
La qualité des instructions, l'ordre du contexte, la mise en cache des invites, la conception des outils, les compétences, les preuves du dépôt et les capacités du modèle influencent tous les résultats.
Une invite concise peut être vague ; une invite plus longue peut être précise. L'objectif n'est pas le nombre minimal de caractères, mais le contexte minimal qui fournit de manière fiable au modèle les informations et les limites nécessaires.
Leçons plus larges pour les constructeurs d'agents
À mesure que les modèles s'améliorent, la conception des instructions passe de la micro-gestion à la gouvernance.
Les agents plus anciens nécessitaient généralement des descriptions détaillées sur la façon d'exécuter chaque étape. Les modèles plus puissants peuvent découvrir davantage de méthodes à partir des outils et des preuves.
Cela n'élimine pas le rôle humain. Cela change l'endroit où l'effort humain est le plus précieux.
Les constructeurs d'agents devraient passer moins de temps à énumérer chaque comportement souhaité, et davantage à définir :
-
Les outils disponibles.
-
Les limites des autorisations.
-
Les sources de vérité.
-
Les critères de succès.
-
Les limites de périmètre.
-
Le contrôle des coûts.
-
Les chemins d'escalade.
-
Les vérifications déterminantes.
Le modèle a besoin de moins de conseils sur chaque action, tout en ayant besoin de permissions plus claires sur ce qu'il peut faire, ce qu'il doit prouver et quand s'arrêter.
Questions fréquentes
Anthropic a-t-il vraiment supprimé plus de 80 % des invites système de Claude Code ?
Anthropic a officiellement indiqué avoir supprimé plus de 80 % du contenu des invites système pour les modèles avancés tels que Claude Opus 5 et Claude Fable 5.
L'entreprise a également indiqué que cette modification n'avait pas entraîné de perte mesurable dans son évaluation du codage.
Pourquoi l'invite d'Opus 5 capturée est-elle 72 % plus longue que celle d'Opus 4.8 ?
Le chiffre de 72 % se base sur Opus 4.8. Dans les captures des développeurs, l'invite d'Opus 4.8 était exceptionnellement concise, avec seulement 4 467 caractères, tandis qu'Opus 5, après avoir reçu des instructions ciblées supplémentaires, en mesurait 7 694.
Les chiffres 15 225, 4 467 et 7 694 sont-ils des données officielles d'Anthropic ?
Non. Ces données proviennent d'un développeur indépendant qui a redirigé l'interface en ligne de commande Claude Code vers un serveur local et examiné les requêtes sortantes. Anthropic n'a pas publié ces nombres de caractères en tant que totaux fixes ou standards.
L'invite d'Opus 5 est-elle toujours plus courte que celle d'Opus 4.7 ?
Dans les captures rapportées, oui. Bien que l'invite d'Opus 5, avec ses 7 694 caractères, soit plus longue que celle d'Opus 4.8, elle reste environ 49,5 % plus courte que celle d'Opus 4.7, qui en comptait 15 225.
Que doit-on conserver dans CLAUDE.md ?
Conservez les faits et règles spécifiques au projet que le modèle ne peut pas déduire de manière fiable du dépôt. Déplacez les processus longs et conditionnels vers les compétences, et supprimez les instructions génériques ou répétitives.
Pourquoi les flux de travail longs devraient-ils devenir des compétences ?
Le contenu détaillé des compétences est chargé en cas de besoin, et non pas à chaque requête. Cela permet une divulgation progressive et évite que des sessions non concernées transportent des processus de révision, de publication ou de déploiement dans leur contexte par défaut.
Opus 5 nécessite-t-il des invites plus strictes que les anciens modèles ?
Il nécessite des invites différentes. Anthropic recommande de contrôler la verbosité, les mises à jour de progression, la portée des tâches, la validation excessive, la génération de sous-agents et l'autocorrection, lorsque ces comportements augmentent les coûts ou le temps inutilement.
Comment vérifier si le contexte de mon Claude Code est trop volumineux ?
Exécutez claude doctor dans le shell, ou /doctor dans Claude Code. Vérifiez également manuellement CLAUDE.md, les compétences, les descriptions d'outils et les instructions redondantes, car le diagnostic automatique ne peut pas déterminer toutes les exigences spécifiques au projet.
Outils connexes
- Claude Code : L'environnement de codage intelligent d'Anthropic pour l'exploration, l'édition, les tests et l'automatisation des dépôts.
- Compétences Claude Code : Regroupez les flux de travail et les références réutilisables dans des fichiers
SKILL.md, chargés en cas de besoin. - Débogueur de configuration Claude Code : Aide à diagnostiquer pourquoi les instructions, compétences, hooks, paramètres ou serveurs MCP ne fonctionnent pas.
- Guide d'invite Claude Opus 5 : Conseils officiels spécifiques au modèle concernant la portée, la verbosité, la progression, les sous-agents, la validation, etc.
Corrections.
- Model Context Protocol : Une norme ouverte pour connecter les systèmes d'agents à des outils et sources de données externes.
Liens connexes
- Les nouvelles règles de l'ingénierie de contexte pour les modèles Claude 5 : Annonce officielle d'Anthropic sur la réduction de 80 % et ses principes d'ingénierie de contexte mis à jour.
- Inviter Claude Opus 5 : Guide officiel pour contrôler la proactivité et le comportement d'agent du nouveau modèle.
- Meilleures pratiques d'invite : Référence complète d'Anthropic sur les instructions, les outils, le raisonnement, les systèmes d'agents et la migration.
- Étendre Claude Code avec des compétences : Créez et organisez des contextes réutilisables à la demande.
- Guide des fonctionnalités de Claude Code : Explique quand utiliser
CLAUDE.md, les compétences, les hooks, les sous-agents et les contrôles associés. - Publication de mesure d'un développeur : Capture d'écran tierce citée pour le nombre de caractères de l'invite système dans le rapport.
Résumé
La réduction de 80 % d'Anthropic et le rebond de 72 % rapporté par les développeurs décrivent des comparaisons différentes. Claude Code a supprimé une grande partie des instructions héritées et hautement prescriptives destinées aux anciens modèles avancés. L'invite d'Opus 5 capturée a ensuite reçu des instructions ciblées supplémentaires par rapport à la version extrêmement concise d'Opus 4.8.
La longueur de l'invite d'Opus 5 rapportée reste environ la moitié de celle de l'invite d'Opus 4.7 capturée. Ses instructions supplémentaires sont cohérentes avec le comportement d'Opus 5 publiquement indiqué par Anthropic : plus de narration de progression, une portée de tâche plus large, une délégation plus fréquente à des sous-agents, des livrables plus longs et une autocorrection répétée.
Pour les développeurs, la réponse utile n'est pas de rechercher l'invite la plus courte. Gardez CLAUDE.md ciblé, déplacez les flux de travail conditionnels vers les compétences, éliminez les redondances, améliorez les interfaces des outils, fournissez des références exécutables et établissez des limites claires pour la portée, les coûts et l'achèvement.
La nouvelle règle de l'ingénierie de contexte n'est pas « dire moins à tout prix », mais « au niveau approprié, ne charger que les instructions nécessaires au modèle. »



