Avant une longue tâche dans Claude Code : quand lancer compact et comment maîtriser les sous-agents et la consommation

Avant de demander à Claude Code d’enchaîner lecture de code, modifications et tests, ne vous précipitez pas pour vider le contexte. Mais il n’est pas non plus nécessaire de conserver toutes les anciennes discussions simplement pour « utiliser tout le 1M ».

Commencez par des questions plus utiles : de quels détails d’origine la prochaine étape aura-t-elle encore besoin ? Le travail que vous comptez déléguer peut-il être mené à bien de façon indépendante ? Et une fois la tâche terminée, comment saurez-vous si votre changement a vraiment été bénéfique, au-delà d’un chiffre de consommation plus faible ?

Le 19 septembre, ZryMiller a expliqué avoir changé de méthode. Il compactait auparavant très souvent, puis est revenu à ce qu’il appelait la fenêtre de 1M par défaut. Selon lui, l’expérience s’était nettement améliorée, et il préparait la publication de sa première application. Mais son message ne contenait ni tâches comparables, ni mesures de consommation avant et après, ni résultat confirmant que l’application avait finalement été publiée. C’est un retour personnel intéressant, pas une preuve que « ne jamais compacter améliore toutes les tâches longues ».

Plutôt que de choisir entre « compacter souvent » et « ne jamais compacter », prenez cette décision à une étape précise du travail.

Commencez par vérifier ce que vous utilisez

Exécutez claude --version dans le terminal et notez la version du client. Dans la session, utilisez /status pour vérifier le compte et le modèle actuel, /model pour voir les modèles disponibles et leurs réglages, puis /context pour examiner l’occupation du contexte. Pour consulter la consommation, lancez /usage. Ces commandes donnent des informations différentes : elles ne mesurent pas toutes la même chose. Référence officielle des commandes · Documentation sur la consommation

Le nom officiel du modèle dont il est question ici est Claude Fable 5.1. Son ID dans Claude API est claude-fable-5-1, et sa fiche officielle indique une fenêtre de contexte de 1M de tokens. Le modèle, la version de Claude Code et le réglage effort sont des informations distinctes. Ne les résumez pas à « j’ai utilisé Fable » ou « j’ai utilisé Ultra ». Spécifications officielles du modèle

La prise en charge de 1M par un modèle ne signifie pas que tous les comptes, modèles et modes d’accès bénéficient automatiquement des mêmes conditions. Par exemple, la documentation officielle distingue l’accès à 1M d’Opus inclus dans Max, Team et Enterprise de l’accès sur Pro, qui nécessite des usage credits. La fenêtre de 1M de Sonnet 4.6 nécessite elle aussi des usage credits avec les abonnements. Ne transposez pas directement ces règles à d’autres modèles. La configuration du client, la correspondance des modèles et la prise en charge par la passerelle doivent également être vérifiées : ajouter [1m] dans le sélecteur ne peut pas, à lui seul, étendre les capacités du modèle côté serveur. Conditions d’accès à 1M et configuration des modèles

Distinguez aussi trois chiffres faciles à confondre. L’occupation du contexte indique la quantité de contenu que la requête actuelle doit pouvoir contenir. La consommation cumulée de tokens enregistre le volume d’entrée, de sortie et de contenu en cache traité par les requêtes. Le quota de l’abonnement correspond à la limite du compte sur la période d’utilisation concernée. Cinq heures ou une semaine désignent une fenêtre de quota, pas la garantie qu’une tâche puisse tourner sans interruption pendant cinq heures ou une semaine. Le contenu trouvé dans le cache occupe toujours du contexte, même si la facturation de l’API peut lui appliquer un tarif spécifique. « 30 % du contexte utilisé » ne se convertit donc pas en « 30 % du quota de cinq heures consommé », et 1M n’est pas une allocation de tokens que l’on peut retraiter gratuitement à volonté. Contexte et cache · Structure tarifaire de l’API

Avant de compacter, regardez de quoi dépend encore la prochaine étape

Supposons que vous cherchiez l’origine d’un bug qui touche le frontend, une API et la base de données. Vous venez de lire plusieurs fragments de code, d’examiner une requête en échec et de repérer un cas limite, mais vous n’avez pas encore de conclusions vérifiables. Compacter simplement parce que « la conversation est déjà longue » risque de supprimer précisément les détails qu’il faudra confronter ensuite.

À l’inverse, si la cause est claire, que les fichiers concernés et l’emplacement des éléments probants sont consignés, et qu’il ne reste qu’une petite modification à réaliser selon un plan validé, une grande partie des recherches précédentes n’a peut-être plus besoin de rester dans la fenêtre actuelle.

Le bon moment pour compacter n’est pas défini par un pourcentage universel. C’est la fin d’une étape à partir de laquelle des notes fiables permettent de continuer. Il s’agit d’une recommandation d’organisation du travail, pas d’un seuil fixe du modèle.

Demandez d’abord à Claude d’écrire l’état nécessaire dans le suivi de tâche que vous lui indiquez : faits confirmés et emplacement des preuves, fichiers réellement modifiés, vérifications effectuées et résultats réels, questions non résolues et prochaine étape. Inutile de recopier toute la conversation ou de transformer des hypothèses non vérifiées en conclusions.

Vous pouvez ensuite utiliser la commande native /compact en précisant ce qu’il faut conserver : Fonctionnement de la compaction

/compact Conserve l’objectif actuel, les conclusions confirmées et l’emplacement des preuves, les fichiers modifiés, les vérifications effectuées et leurs résultats réels, les questions non résolues et la prochaine étape. Supprime les recherches répétées et les discussions sur les pistes déjà écartées.

Ce texte donne des consignes pour le résumé ; il ne garantit pas qu’aucune information ne sera perdue. Avant de poursuivre les modifications, demandez à Claude d’expliquer la prochaine étape à partir du contexte compacté, puis comparez les contraintes essentielles aux fichiers réels et au suivi de tâche. Si un cas limite a disparu, rétablissez-le avant que l’implémentation ne dévie et doive être reprise.

Si le travail suivant n’a plus de rapport avec le précédent, il est généralement plus simple d’enregistrer les résultats et les informations nécessaires à une reprise, puis d’ouvrir une nouvelle session avec /clear. Utilisez /resume pour revenir à la conversation d’origine si nécessaire. Vider une session ne rembourse pas la consommation déjà engagée et ne réinitialise pas le quota de l’abonnement. Commandes de session · Ce qui est réinitialisé dans l’affichage de la consommation

Claude Code dispose déjà d’une compaction automatique : aucun plugin n’est nécessaire pour adopter cette méthode. Les versions v2.1.221 et ultérieures proposent aussi /autocompact. Sans argument, cette commande affiche la fenêtre actuelle de compaction automatique ; /autocompact auto rétablit le réglage de fenêtre adapté au modèle. Cette dernière commande enregistre un réglage, elle ne se contente pas d’exprimer une préférence au modèle. La fenêtre maximale du modèle et la fenêtre de compaction automatique ne sont pas la même chose. Commande de compaction automatique

HKTECH_AI a estimé qu’une seule compaction pouvait consommer environ 15 % du quota de cinq heures. Le message ne fournissait ni facture ni méthode de calcul : ce pourcentage ne doit pas devenir une règle d’utilisation. Ce qu’il faut comparer, c’est la quantité de contenu que la compaction évite de transmettre à répétition dans les requêtes suivantes, mais aussi les relectures, explications supplémentaires et corrections qu’elle peut entraîner.

Les sous-agents peuvent se répartir le travail, mais « un à la fois » dépend de la façon de l’imposer

SHCH a présenté une répartition des rôles : Fable planifie et prend les décisions, un Scout utilisant Sonnet effectue les recherches, et un Builder utilisant Opus exécute des tâches bien définies. Il recommandait expressément de n’appeler qu’un sous-agent à la fois.

Sa capture d’écran du Builder insiste sur le respect du plan existant, l’arrêt avec signalement si ce plan pose problème, l’interdiction de lancer d’autres sous-agents et la présentation des résultats des vérifications. L’intérêt de ces consignes est de clarifier les responsabilités. Mais « ne lance pas d’autres sous-agents » dans une image reste une contrainte formulée dans un prompt, pas une limite imposée par le logiciel. L’auteur mentionne aussi plusieurs sessions principales en parallèle et n’a pas publié de consommation vérifiable avant et après. On ne peut donc pas interpréter ce montage comme « un seul agent sur tout le compte », encore moins promettre un pourcentage fixe d’économies.

Un sous-agent ordinaire démarre avec un contexte indépendant. Il reçoit la tâche déléguée et la configuration correspondante, mais pas automatiquement tout l’historique de la session principale ; un sous-agent fork, lui, hérite de la conversation existante. Confier une recherche riche en détails intermédiaires à un sous-agent peut alléger les informations de travail conservées directement dans la session principale. Mais les requêtes du sous-agent traitent toujours des tokens, et son résultat rejoint aussi la session principale. Périmètre du contexte des sous-agents

Posez donc d’abord la question « Cette tâche mérite-t-elle d’être déléguée ? », puis « Combien faut-il en lancer simultanément ? ». Une recherche simple ne nécessite pas toute une chaîne de planification, de recherche et d’exécution. Deux tâches qui modifieront sans cesse le même fichier ne sont pas forcément de bonnes candidates au travail simultané. Des recherches réellement indépendantes, avec des livrables clairs, se prêtent mieux à une comparaison en parallèle.

Vous pouvez rendre les consignes de travail plus concrètes, par exemple :

Objectif : Réaliser les modifications convenues et réussir les vérifications directement liées.
Périmètre autorisé : L’implémentation et les tests correspondants concernés par cette demande.
Exécution : Effectue directement les recherches simples. Si la délégation est nécessaire, fournis uniquement le contexte et les exigences de livraison utiles à la sous-tâche, et affecte un sous-agent à la fois. Ne consulte pas le même statut à répétition pendant l’attente.
Critères de fin : Livre selon les critères d’acceptation et arrête-toi dès que les vérifications pertinentes réussissent. En cas de blocage, indique ce qui est terminé et la cause du blocage ; ne relance pas la même tâche.

Ce sont toujours des consignes de comportement. Pour restreindre réellement la création de sous-agents natifs, utilisez les contrôles du client. Claude Code v2.1.217 et les versions ultérieures permettent de limiter la concurrence et la profondeur de délégation. L’exemple de lancement suivant, en Bash/Zsh pour macOS et Linux, constitue un point de départ prudent pour examiner un parallélisme inutile : Référence des variables d’environnement

CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS=1 \
CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH=1 \
claude

La première variable définit un contrôle de concurrence par session lors de la création de nouveaux sous-agents via l’outil Agent. La seconde limite les sous-agents à un niveau et empêche de poursuivre la délégation de façon imbriquée. Ce ne sont pas des prompts, et ces réglages ne modifient pas rétroactivement les autres sessions déjà lancées. Référence des variables d’environnement

Ce n’est toutefois pas un verrou global garantissant « jamais plus d’un agent, partout et à tout moment ». La documentation officielle énumère des exceptions : les sessions ultracode n’appliquent pas cette limite de concurrence ; les appels manuels à /subtask et la reprise de sous-agents déjà terminés ne sont pas bloqués par le même contrôle de création ; les workflows et les agent teams ont leurs propres limites. Ce seul réglage ne contrôle pas non plus collectivement plusieurs sessions principales ou des processus lancés à l’extérieur. Limites de concurrence et exceptions

Si votre propre ordonnanceur a besoin d’une véritable limite globale, une file d’attente ou un verrou de concurrence doit gérer ensemble les démarrages, les reprises et les nouvelles tentatives. Écrire « un à la fois » dans le prompt ne suffit pas. Cela relève de votre propre implémentation d’ordonnancement, pas d’un autre réglage non documenté de Claude Code.

Attendre un résultat ne signifie pas demander au modèle de vérifier sans cesse l’avancement

LeeLeepenkman ne se plaignait pas simplement de « l’utilisation de sous-agents ». Il décrivait Fable 5.1 envoyant un gros prompt à muse, puis interrogeant son état environ toutes les cinq secondes, ce qui faisait rapidement grossir le contexte. Le message original ne précisait pas l’implémentation de muse et ne fournissait ni traces de requêtes ni résultat après résolution. On ne peut donc pas présenter cinq secondes comme l’intervalle de sondage fixe de Claude Code.

Les sous-agents natifs en arrière-plan disposent actuellement de notifications de fin, et leurs résultats sont renvoyés à la session principale lors des tours suivants. La commande /tasks permet de consulter le travail en cours. C’est différent de demander au modèle d’émettre sans arrêt de nouvelles requêtes « Est-ce terminé ? ». Sous-agents en arrière-plan et notifications de résultat

Pour examiner le problème, développez les traces d’outils de la session et suivez une même tâche : les vérifications répétées apportent-elles de nouvelles informations ? Une tâche déjà terminée a-t-elle été relancée ? La consultation de statut a-t-elle réellement déclenché un nouvel appel au modèle ? Ctrl+O ouvre une vue plus détaillée de la conversation, mais le nombre de rafraîchissements de l’interface ne peut pas être assimilé au nombre de requêtes au modèle. Pour connaître la consommation par requête, vérifiez aussi les relevés du fournisseur que vous utilisez effectivement. Interactions et affichage de la session

Avec les notifications natives, il est généralement inutile d’ajouter une boucle de vérification très fréquente exécutée par le modèle. Si un outil externe ne propose que du sondage, laissez le programme vérifier les changements d’état à intervalles raisonnables, fixez un délai maximal et transmettez les informations au modèle seulement en cas de nouveau résultat ou d’anomalie. L’objectif est de réduire les appels au modèle qui n’apportent rien de nouveau, pas d’interdire le suivi nécessaire de l’avancement.

Après le rétablissement du quota, vérifiez d’abord ce qu’il reste à faire

intwerpret a relaté une expérience plus marquée. Après avoir atteint une limite d’utilisation, il a choisi d’attendre puis de continuer automatiquement. Il affirme ensuite que 39 agents sont apparus, ont de nouveau épuisé son quota, et qu’il est finalement retourné sur Codex. Les éléments disponibles ne donnent ni version du client, ni contenu de la tâche, ni configuration complète, ni origine du mécanisme de reprise. On ignore également si la tâche a finalement été achevée.

Ce témoignage invite à examiner la procédure de reprise, mais ne prouve pas que « la reprise automatique de Claude Code lance forcément 39 agents ». L’emploi du mot « Ultra » par l’auteur ne suffit pas non plus à établir qu’il utilisait le mode ultracode évoqué plus haut.

À l’inverse, on ne peut plus attribuer toute continuation automatique à des scripts tiers. La documentation officielle des interactions décrit une fonction native de continuation après rétablissement de la limite d’utilisation : depuis v2.1.234, les sessions interactives sur abonnement qui remplissent les conditions peuvent attendre le rétablissement du quota puis reprendre le travail. Ce comportement ne doit pas être assimilé à celui des sessions avec clé API, de -p ou de tous les modes en arrière-plan. Une reprise ne consiste pas non plus à renvoyer simplement la dernière tâche originale de l’utilisateur. Attente native et continuation automatique

Si vous ne souhaitez pas que la tâche reprenne sans surveillance, désactivez Continue automatically at usage limit (continuer automatiquement après rétablissement de la limite d’utilisation) dans /config. Sur les versions qui prennent ce réglage en charge, vous pouvez aussi exécuter :

/config autoContinueAtUsageLimit=false

Si la session est déjà en attente, annulez également cette attente précise : appuyez sur Esc dans une zone de saisie vide, ou choisissez Don’t continue automatically (ne pas continuer automatiquement) dans /rate-limit-options. Modifier le réglage par défaut et annuler une attente déjà choisie sont deux actions distinctes. Annulation et réglage de la continuation automatique

Vérifiez ensuite /tasks et l’état réel des fichiers. Quelles tâches tournent encore, lesquelles sont terminées, et lesquelles n’ont besoin que d’une vérification supplémentaire ? Réutilisez les résultats existants et indiquez clairement quelle partie inachevée doit être reprise, au lieu de renvoyer toute la demande pour qu’elle soit à nouveau découpée en tâches.

Avant un commit, un déploiement, l’envoi d’un message ou toute autre action ayant un effet externe, assurez-vous en particulier que la tentative précédente n’a pas déjà réussi. Le rétablissement du quota répond seulement à la question « Peut-on continuer à envoyer des requêtes ? ». Il ne garantit pas que les actions suivantes ne répéteront pas quelque chose de déjà exécuté.

Regardez le résultat avant de conclure que la consommation s’est améliorée

chasemdev expliquait qu’il ne faisait pas écrire tout le code directement par Fable, mais lui faisait orchestrer des sous-agents Opus. Il prévoyait pourtant d’atteindre bientôt la limite hebdomadaire. Ce « bientôt » était sa prévision à cet instant, pas un résultat final de consommation vérifié. Cela rappelle néanmoins un élément facile à oublier dans les relevés : comptez aussi les modèles et le travail des sous-agents, pas seulement le modèle principal.

La section Session de /usage affiche actuellement les tokens consommés dans la session et une estimation du coût calculée localement. Les abonnés voient également l’utilisation de leur forfait dans la même interface. Le montant en dollars de Session n’est pas une facture d’abonnement et ne correspond pas nécessairement au débit final du fournisseur d’API. En paiement à l’usage, référez-vous à la facture de votre fournisseur réel. Ce que signifie actuellement /usage

L’attribution locale de la consommation de l’abonnement n’est elle aussi qu’un indice. La répartition entre sous-agents, plugins, skills et autres composants provient de l’historique récent de cette machine. Elle ne couvre pas tout l’usage sur les autres appareils et sur le Web, et ne prouve pas une relation de cause à effet du type « ce plugin a généré tant de gaspillage ». Si vous voyez Showing last-known usage, notez l’heure des données affichées et rafraîchissez-les avant toute comparaison. Périmètre d’attribution et données en cache

Inutile de construire un système d’évaluation complexe. Choisissez une tâche au périmètre clair, reproductible sans risque, écrivez ses critères d’acceptation, puis relevez les éléments suivants au début et à la fin :

Quoi noter	Questions à se poser
Tâche, version initiale du code, modèle, effort, version du client	Comparez-vous le même type de travail et les mêmes réglages avant et après ?
/context et le processus de compaction	Des contraintes ont-elles été perdues ? A-t-il fallu relire ou réexpliquer ?
Sous-agents et comportement pendant l’attente	Quelles tâches ont été créées ou reprises, quel a été le pic d’exécution simultanée, et y a-t-il eu des vérifications répétées sans information nouvelle ?
Relevés de consommation, heures et limites de réinitialisation	Un quota a-t-il été rétabli entre-temps, l’activité d’autres sessions s’est-elle mêlée aux relevés, et tous les modèles concernés ont-ils été comptés côté API ?
Livrables réels et résultats des vérifications	Les exigences sont-elles remplies, les vérifications pertinentes ont-elles réussi et combien de reprises manuelles restent nécessaires ?

Ne changez qu’une pratique à la fois : attendre la fin de l’investigation avant de compacter, par exemple, ou limiter la concurrence à la création de nouveaux sous-agents. Conservez les critères d’acceptation d’origine ; ne réduisez pas discrètement la tâche pour obtenir une consommation plus basse. Notez aussi si l’état du cache diffère. Si les deux exécutions utilisent des modèles, des versions de code ou des tailles de tâche différents, n’attribuez pas tout l’écart à la compaction.

Consommer moins de tokens en oubliant des exigences ou en laissant la vérification à une personne n’est pas une amélioration. À l’inverse, si conserver plus de contexte permet de terminer d’un seul passage sans refaire l’investigation, une fenêtre plus remplie ne suffit pas à parler de gaspillage.

Tenez des comptes séparés pour l’API indépendante et l’abonnement. Changer la source de facturation ne réinitialise pas le quota de l’abonnement d’origine et ne modifie pas automatiquement la façon dont le client délègue, attend et compacte. Pour juger de l’intérêt du changement, comparez la consommation totale et les reprises nécessaires pour terminer la même tâche, pas seulement le prix unitaire d’un modèle. Différences entre modes de facturation · Facturation des tokens de l’API

Avant de confier le choix du moment de compaction à un plugin, vérifiez ce qu’il envoie à l’extérieur

Kun Chen est parti d’une question pratique : « when should i /compact my session », autrement dit, quand faut-il compacter la session actuelle ? Son compact-adviser utilise Jev de TypeSafe pour estimer si le travail a atteint une étape propice à la compaction. Il propose un mode de suggestion et un mode automatique qu’il faut activer explicitement. Présentation du projet

La vérification pour cet article a été fixée au commit d1655faa16a22b68bff60c3d7deb0123e1e52a53, dans lequel le manifeste du plugin Claude Code indique la version 0.1.4. Le projet exige Node.js 22 ou ultérieur et Claude Code 2.1.274 ou ultérieur, et déclare une vérification sur 2.1.275. L’intégration Claude Code dépend de hooks de fonction expérimentaux et nécessite CLAUDE_CODE_ENABLE_FUNCTION_HOOKS=1. Ce sont les conditions de compatibilité annoncées par le projet, pas les résultats d’un essai d’installation réalisé pour cet article. Manifeste de la version fixée · Versions et prérequis d’intégration

Surtout, le mode hint signifie seulement que la compaction n’est pas exécutée automatiquement. Il ne signifie pas que l’évaluation est locale ou que le contexte reste sur la machine. La documentation de sécurité précise qu’après installation, si une clé est disponible dans l’environnement de lancement, les réglages enregistrés ou un fichier .env du répertoire de travail, et que les conditions d’appel sont remplies, des extraits de la session sont envoyés à TypeSafe. Ils comprennent les contraintes de l’utilisateur, les réponses visibles récentes et les résultats d’outils, un résumé existant et les noms des artefacts produits. Il n’y a pas de réglage distinct de confirmation du partage. Ces extraits peuvent encore contenir du code ou des informations métier ; un masquage au mieux des possibilités ne garantit pas l’absence de données sensibles. Périmètre d’envoi du contexte

Si le plugin est déjà installé, vous pouvez le désactiver avec /compact-adviser off, ou lancer ainsi :

COMPACT_ADVISER_DISABLE=1 claude

Selon le projet, cela arrête les requêtes, les suggestions et la compaction automatique du plugin. Cela désactive le plugin, pas la compaction automatique propre à Claude Code. Si l’envoi supplémentaire de contenu de travail à TypeSafe n’est pas autorisé, désactivez ou désinstallez le plugin plutôt que de simplement passer de auto à hint. Méthodes de désactivation

L’évaluation sur 40 sessions mentionnée par l’auteur est celle du projet lui-même, et le jeu de données n’est pas public. Elle ne garantit pas que les détails de vos propres tâches seront préservés. Même si le plugin juge un point « adapté à la compaction », la question décisive reste de savoir si le travail peut continuer correctement après. Limites de l’évaluation

Tout cela peut déjà se faire sans plugin : enregistrer l’état à la fin des étapes et conserver les détails réellement nécessaires à la suivante ; confier aux sous-agents un travail clair et indépendant ; éviter les démarrages en double pendant l’attente et la reprise ; puis juger du résultat à partir des livrables comme des relevés de consommation.

Gérer une tâche longue ne consiste ni à remplir la fenêtre ni à faire paraître chaque requête la moins chère possible. Il s’agit de réduire le travail qui ne fait pas avancer la tâche et de terminer de façon fiable ce qui a été commencé.