/goal dans Claude Code : mode autonome et Agent View en 2026

Documentation de référence Ailoot : ailoot.ai/docs/.

Qu'est-ce que /goal dans Claude Code ?#

Auparavant, Claude Code s'arrêtait après chaque réponse et attendait votre prochain prompt. Cela fonctionnait pour les tâches courtes, mais montrait ses limites pour les longues : une migration d'API, la correction de 12 tests en échec, la refactorisation d'un fichier de 800 lignes — ces tâches demandent 20–30 itérations, et chacune vous ramenait au terminal.

/goal résout ce problème grâce à une idée simple : séparer « celui qui fait le travail » de « celui qui décide quand c'est terminé ». L'agent principal écrit le code. Un évaluateur distinct (le modèle rapide Haiku) lit la conversation après chaque tour et répond à une question : « La condition est-elle remplie ? » Sinon, l'agent démarre un nouveau tour. Si oui, le contrôle vous est rendu.

La documentation officielle d'Anthropic le définit ainsi :

La commande /goal et Agent View ont été introduits dans la même version le 11 mai 2026 :

Des milliers d'agents la nuit depuis un téléphone : ce n'est pas du marketing, mais la pratique actuelle d'un ingénieur d'Anthropic. Le mécanisme qui le rend possible est la combinaison de /goal et d'Agent View, introduite dans la même version le 11 mai 2026.

Pourquoi le mode autonome est-il nécessaire : qu'y avait-il avant et après le 11 mai 2026 ?#

L'idée de « laisser l'IA travailler toute la nuit » existait depuis l'automne 2025, lorsque Cursor Composer et le mode automatique de Cline pouvaient déjà fonctionner en arrière-plan. Mais avant le 11 mai 2026, Claude Code exigeait un wrapper manuel : une tâche cron qui appelait claude -p toutes les N minutes, ou un wrapper qui surveillait l'état Git et lançait le prompt suivant.

Cette approche faite maison a régulièrement mené à des catastrophes. Le 22 mai 2026, un développeur a laissé un tel script tourner toute la nuit et s'est réveillé avec une facture de 6 000 $. La cause première : Anthropic a modifié silencieusement la durée de vie du cache de Claude Code, la faisant passer d'une heure à cinq minutes, sans annonce. Cron appelait la production toutes les 30 minutes — le cache avait le temps d'expirer entre les exécutions. À chaque exécution, un historique de 800 000 tokens était reconstruit depuis zéro. L'écriture de nouvelles données dans le cache coûte bien plus cher que la lecture d'un cache actif.

Le développeur ne faisait rien d'exotique : il utilisait l'outil exactement comme Anthropic le présentait.

/goal résout ce problème grâce à une architecture intégrée :

1. Processus superviseur qui maintient la session en dehors de votre terminal et survit à la fermeture de la fenêtre ainsi qu'à la mise en veille de l'ordinateur portable.
2. Évaluateur Haiku — un modèle peu coûteux vérifie chaque tour ; les tokens de l'évaluateur ne coûtent que quelques centimes.
3. Limite stricte de tours dans la condition — vous pouvez écrire explicitement or stop after 20 turns, et la session s'arrêtera à coup sûr.
4. Isolation par worktree pour les sessions en arrière-plan — les modifications vont dans une branche distincte sans toucher à votre copie de travail.

La différence avec l'approche « écrivez votre propre script bash », c'est qu'Anthropic fait de tous ces mécanismes des éléments natifs de l'outil, plutôt que des bricolages tiers.

Comment activer /goal en 3 étapes#

Étape 1. Mettez à jour Claude Code vers la version 2.1.139 ou une version ultérieure.

Vérifiez la version :

claude --version

Si elle est antérieure à 2.1.139, mettez à jour :

claude update
# or force it through npm
npm install -g @anthropic-ai/claude-code@latest

Les versions publiées entre le 12 et le 19 mai 2026 ont corrigé des bogues importants de la première version. Dans la version 2.1.140, un blocage silencieux a été corrigé : disableAllHooks empêchait l'évaluateur de fonctionner. La version 2.1.143 a apporté worktree.bgIsolation: "none" et un correctif aux boucles de hooks d'arrêt. Dans la version 2.1.144 (19 mai), --resume pour les sessions en arrière-plan et --json pour les agents utilisés en script ont été ajoutés. La version minimale est 2.1.143.

Étape 2. Saisissez /goal avec une condition.

Ouvrez une session Claude Code normale et entrez la commande :

/goal all tests in test/auth pass and the linter is clean, or stop after 15 turns

Vous n'avez pas besoin d'envoyer un prompt séparé ensuite : la commande démarre immédiatement le premier tour. La condition peut être rédigée en russe, en anglais ou dans un mélange des deux ; le modèle comprend les deux langues. La limite de longueur est de 4 000 caractères.

Étape 3. Suivez la progression avec l'affichage en direct.

Après le démarrage de /goal, un panneau en direct apparaît en bas du terminal :

/goal active · 3 turns · 12m elapsed · 18,400 tokens · last: tests in test/auth/login.test.ts still fail

Il affiche :

• Tours — le nombre de tours terminés
• Temps écoulé — le temps écoulé depuis le lancement
• Tokens — le nombre total de tokens dépensés (le principal indicateur de suivi du budget)
• Dernier motif — la dernière raison pour laquelle l'évaluateur a répondu « pas encore »

Une astuce utile : si l'évaluateur donne la même raison trois tours de suite, cela indique que vous êtes dans une boucle. Appuyez alors sur Ctrl+C ou saisissez /goal clear (synonymes : stop, off, reset, cancel), reformulez la condition et relancez la commande. Les guides communautaires sur /goal présentent cette règle comme le principal signe d'une boucle : « bloqué trois fois sur la même raison : c'est une boucle, quittez-la ».

Comment rédiger une bonne condition : 5 règles + 5 exemples#

La documentation d'Anthropic décrit trois éléments requis pour une bonne condition :

Un modèle prêt à l'emploi réunit ces trois éléments sur une seule ligne :

\n/goal [effectuer le travail] jusqu'à [état final mesurable] sans [enfreindre les contraintes]\n

Cinq règles qui piègent le plus de monde :

Règle 1. L'état final doit pouvoir être vérifié par une commande, et non par le goût.

Pas « fais en sorte que ce soit joli », mais npm test exits 0. Pas « améliore l'UX », mais Lighthouse Performance score above 90. L'évaluateur ne lit que la transcription : il n'exécute pas de commandes et ne regarde pas les captures d'écran. Si le résultat ne peut pas être consigné par écrit, l'évaluateur ne dira jamais « oui ».

Règle 2. Les contraintes doivent être explicites et précises.

Sans contraintes, Claude pourrait corriger les tests en supprimant les tests eux-mêmes ou en commentant les assertions en échec. Précisez : without modifying any file outside /auth, without removing existing assertions, without bumping major versions of dependencies.

Règle 3. Une limite stricte de tours est indispensable.

Ajoutez or stop after N turns à chaque condition. C'est une protection contre les boucles sans fin. Sans limite, une boucle qui tourne pendant une heure consomme plus de tokens que l'exécution manuelle de la même tâche. Prévoyez le budget nécessaire.

Règle 4. Décrivez QUOI, pas seulement COMMENT.

Si vous ne mentionnez pas les visuels dans la condition, Claude ne les créera pas. Si la condition exige seulement que « les tests passent », Claude pourrait commenter des tests complexes. Décrivez CE QUE vous voulez, et pas seulement COMMENT vous le vérifierez.

Règle 5. Demandez à Claude de montrer les preuves dans le chat.

L'évaluateur n'exécute pas de commandes : il lit seulement ce que Claude a déjà montré. Si la condition exige que « npm test réussisse », mais que Claude n'a pas affiché le résultat de npm test dans la transcription, l'évaluateur répondra « pas encore » indéfiniment. Ajoutez à la condition la phrase « affiche la sortie de <command> dans la conversation ».

Cinq exemples qui fonctionnent pour les tâches courantes :

1. Migration d'API :
/goal remplacer chaque appel à getUser() par fetchUser(), npm test réussit, npm run build est vert, aucun autre nom d'API n'a été touché, ou arrêter après 30 tours

2. Correction de tests :
/goal tous les tests en échec dans test/auth sont maintenant réussis (npm test affiche 0 échec dans le chat), sans modifier les assertions ni supprimer de tests, ou arrêter après 20 tours

3. Qualité du code (taille des fichiers) :
/goal découper src/legacy/UserService.ts en fichiers de moins de 200 lignes chacun, mettre à jour tous les imports, npm run build est vert, ou arrêter après 25 tours

4. Résorption du backlog :
/goal traiter chaque issue étiquetée 'good-first-issue' : lire sa description, implémenter une correction dans une branche de worktree, ouvrir une PR. Continuer jusqu'à ce que la file soit vide ou que 6 issues aient été traitées

5. Audit de sécurité :
/goal corriger chaque vulnérabilité npm audit de gravité >= high, tous les tests existants réussissent, aucune modification cassant l'API, ou arrêter après 15 tours

Vous voulez faire plus que simplement lancer /goal et créer un environnement où le mode autonome fonctionne vraiment dans votre projet ? /goal n'est que le dernier maillon. Il faut d'abord mettre en place trois piliers : un clone IA (votre méthodologie dans Skills et Subagents), un second cerveau (CLAUDE.md et un dossier plans/) et l'ingénierie de contexte (Plan Mode et /compact). Ces trois composants doivent être conçus ensemble : c'est leur combinaison qui permet de travailler avec le contexte.

5 exemples où /goal fonctionne vraiment#

La documentation d'Anthropic donne quatre types de tâches pour lesquelles /goal convient bien :

Voici cinq exemples avec des conditions prêtes à l'emploi : prenez-les et adaptez-les à votre projet.

Exemple 1. Migrer un module vers une nouvelle API.

Scénario : vous passez de REST à GraphQL, ou remplacez l'ancienne fonction getUser() par la nouvelle fonction fetchUser(). La tâche est mécanique, mais concerne 30–50 fichiers.

Condition :

/goal remplacer chaque getUser() dans src/ par fetchUser(), mettre à jour tous les appels pour la nouvelle interface (id au lieu de userId), npm test réussit, aucun fichier en dehors de src/ n'a été touché, ou arrêter après 30 tours

Pourquoi ça fonctionne : l'état final peut être vérifié avec grep -r getUser src/ | wc -l (le résultat doit être 0) et npm test exits 0. La contrainte protège les fichiers de test.

Exemple 2. Corriger les tests en échec.

Scénario : après une mise à jour de bibliothèque, 15 tests ont échoué. Vous savez que la correction est mécanique : mettre à jour les mocks et adapter les assertions au nouveau format. Vous ne voulez pas le faire à la main.

Condition :

/goal tous les tests en échec dans test/ sont maintenant réussis, npm test affiche les résultats dans le chat avec 0 échec, sans supprimer de tests ni commenter d'assertions, ou arrêter après 25 tours

Un autre exemple de ce type de condition :

\nCorriger tous les tests en échec jusqu'à ce que npm test renvoie 0, sans modifier de fichier en dehors du répertoire /auth\n

Exemple 3. Découper une classe monolithique.

Scénario : un fichier de 1 200 lignes contient tout — modèle, service, utilitaires et client d'API. Vous voulez le découper selon le principe « un fichier, une responsabilité », mettre à jour tous les imports et faire en sorte que les tests continuent de réussir.

Condition :

/goal découper src/legacy/UserService.ts en fichiers de moins de 200 lignes, chaque fichier remplissant une seule responsabilité (model, repository, api-client, validator), mettre à jour tous les imports, npm run build est vert, les tests existants réussissent, ou arrêter après 25 tours

Exemple 4. Résorber le backlog d'issues pendant la nuit.

Scénario : vous avez un dépôt open source contenant 20 issues étiquetées good-first-issue. Vous voulez que Claude les traite pendant la nuit.

Condition :

/goal traiter chaque issue étiquetée 'good-first-issue' : lire sa description, implémenter une correction dans une branche worktree distincte worktree-issue-N, ouvrir une PR avec une description. Continuer jusqu'à ce que la file soit vide ou que 6 issues aient été traitées, ou arrêter après 80 tours

Le nombre 6 n'a pas été choisi au hasard : c'est une limite réaliste pour une nuit avec un abonnement Pro. Une personne fait tourner des « milliers » d'agents, mais c'est un cas particulier, pas un réglage par défaut reproductible.

Exemple 5. Audit de sécurité.

Scénario : npm audit révèle 8 vulnérabilités de gravité élevée. Vous voulez que Claude les corrige sans mettre à jour les versions majeures.

Condition :

/goal corriger chaque vulnérabilité npm audit de gravité high+, npm audit affiche 0 vulnérabilité high dans le chat, tous les tests existants réussissent, aucune modification cassant l'API, aucune mise à jour de version majeure des paquets, ou arrêter après 15 tours

À ne PAS faire avec /goal :

Dans son guide pratique, Croucher énonce avec force la règle générale : n'utilisez pas /goal pour les tâches où « terminé » signifie « a l'air bien », « semble juste », « est bien conçu » ou « est amusant ». L'évaluateur ne lit que la transcription : il n'exécute pas d'outils et ne peut pas évaluer le fonctionnement du résultat. Cette règle exclut 80 % des tâches subjectives pour lesquelles /goal tourne en boucle sans produire de résultat utile.

Quand /goal fait perdre de l'argent : 3 anti-patterns#

Anti-pattern 1. Condition vague sans limite stricte de tours.

L'erreur la plus fréquente consiste à écrire une condition comme « améliore le code » / « rends-le bien » / « optimise-le ». Sans limite de tours, l'agent continuera jusqu'à épuiser votre quota.

Findskill a décrit un cas réel :

200 $ en 14 heures pour une condition vague, c'est tout le quota hebdomadaire de l'abonnement Max. Vous vous réveillez le matin sans quota et sans résultat utile.

Protection : terminez chaque condition par or stop after N turns (15 pour les tâches faciles, 50 pour les difficiles et 100 au maximum pour les exécutions nocturnes).

Anti-pattern 2. Boucle récursive avec mise en cache défectueuse.

L'histoire du 22 mai 2026 : 6 000 $ dépensés pendant la nuit, car Anthropic a discrètement fait passer la durée de vie du cache d'une heure à 5 minutes. Le développeur n'utilisait pas directement /goal, mais la logique était la même : une boucle autonome avec un minuteur cron de 30 minutes reconstruisait à chaque fois un historique de 800 000 tokens depuis zéro.

Le problème fondamental était que l'automatisation externe ignorait les changements internes du fournisseur. La même chose pourrait se produire avec /goal si vous le laissez tourner 8 heures sans surveillance : l'utilisation des tokens augmente de manière non linéaire et le cache de prompt ne fonctionne pas forcément comme vous le pensez.

Protections :

1. Ne faites pas tourner /goal pendant 8 heures ou plus sans contrôles intermédiaires.
2. Activez les limites d'utilisation dans Paramètres → Utilisation (une nouvelle protection après l'incident des 6 000 $).
3. Ouvrez claude agents deux fois pendant la nuit — jetez un coup d'œil avec Space et vérifiez que le nombre de tours n'augmente pas plus vite que prévu.
4. Pour les chaînes de modèles coûteuses (Opus 4.7), définissez une limite de tours plus stricte : 30 au maximum.

Anti-pattern 3. La créativité avec /goal.

Croucher a utilisé /goal pour créer un jeu. La condition comprenait le déterminisme, des invariants et la vérification que le niveau pouvait être terminé. Le jeu a été créé, les tests ont réussi et l'évaluateur a déclaré l'objectif « atteint ». Le jeu n'avait pas de visuels : la condition ne mentionnait pas les graphismes.

Cela illustre la règle générale : l'évaluateur optimise précisément ce que vous mesurez. Si la condition ne mentionne pas les visuels, il n'y en aura pas. Si elle ne mentionne que les tests, Claude pourrait commenter les assertions.

Protection : n'utilisez pas /goal pour les tâches qui reposent sur le goût (design, rédaction, UX). Revenez à une session normale ou au Plan Mode : vous restez ainsi dans la boucle de décision.

Qu'est-ce qu'Agent View et comment ouvrir le tableau de bord ?#

Si /goal est la commande « travaille jusqu'à ce que ce soit terminé », Agent View est la salle de contrôle où vous pouvez voir toutes ces tâches à la fois. Anthropic le décrit ainsi :

Commande pour l'ouvrir :

claude agents

Une TUI s'ouvre : un tableau de bord textuel dans le terminal. La liste des sessions se trouve à gauche et le volet d'aperçu, qui affiche le dernier message de la ligne sélectionnée, à droite.

Les six états d'une session :

Raccourcis principaux :

↑ / ↓             parcourir la liste des sessions
Space             volet d'aperçu (afficher sans s'attacher)
Enter / →         s'attacher à une session (y entrer)
←                 se détacher (quitter sans l'arrêter)
Ctrl+T            épingler (protéger la session contre l'arrêt automatique)
Ctrl+X            arrêter la session ; appuyer de nouveau dans les 2 sec pour la supprimer
Ctrl+R            renommer
Ctrl+S            basculer le regroupement (état ↔ répertoire)

Comment démarrer une session en arrière-plan :

Depuis Claude Code en mode interactif :

/bg fix the failing test test/auth/login.test.ts

Ou directement depuis le shell :

claude --bg "fix the failing test test/auth/login.test.ts"

Ou avec un nom (pour qu'elle apparaisse dans Agent View sous une étiquette reconnaissable) :

claude --bg --name "flaky-test-fix" "fix test/auth/login.test.ts"

La session en arrière-plan est automatiquement ajoutée à Agent View : lancez-la avec --bg, ouvrez claude agents et vous la verrez dans la liste.

La fonctionnalité principale : les sessions survivent à la mise en veille de l'ordinateur portable et à la fermeture de la fenêtre :

Mais éteignez l'ordinateur portable ou redémarrez-le manuellement, et les sessions en arrière-plan se terminent avec l'état Failed. Les sessions nocturnes avec de nombreux agents d'arrière-plan ne fonctionnent que si l'ordinateur portable reste allumé.

Worktrees : comment Claude isole les sessions parallèles#

Les worktrees résolvent le principal problème du travail autonome en parallèle : que se passe-t-il si deux sessions tentent de modifier src/auth.ts en même temps ? Avant la version 2.1.139, ces sessions pouvaient littéralement écraser leurs modifications mutuelles. Avec Agent View, Anthropic a introduit l'isolation automatique :

Comment cela fonctionne en pratique :

# Launched three background sessions:
claude --bg --name "fix-tests" "fix the failing tests in test/"
claude --bg --name "add-oauth" "add Google OAuth according to the plan in plans/oauth.md"
claude --bg --name "split-userservice" "split UserService.ts into modules"

# File structure after launch:
.claude/worktrees/
├── fix-tests/             # separate repo copy on branch worktree-fix-tests
├── add-oauth/             # separate copy on branch worktree-add-oauth
└── split-userservice/     # separate repo copy on branch worktree-split-userservice

Chaque session travaille dans sa propre copie. Une fois la tâche terminée, fusionnez dans main les branches nécessaires.

Piège dangereux : supprimer une session supprime son worktree.

Si vous arrêtez une session dans Agent View (appuyez deux fois sur Ctrl+X), son worktree disparaît. Toutes les modifications non validées sont perdues. Avant de supprimer une session dans Agent View, pensez toujours à créer un commit ou à pousser les modifications.

Désactivation (pour les cas rares) :

Si vous avez un dépôt où les worktrees Git ne fonctionnent pas (par exemple, une configuration avec des liens symboliques ou un grand monorepo dont le checkout est lent), vous pouvez désactiver l'isolation :

// .claude/settings.json
{
  "worktree": {
    "bgIsolation": "none"
  }
}

Les sessions en arrière-plan modifieront alors directement votre copie de travail. Cette option de désactivation est arrivée dans la version 2.1.143 après les plaintes d'équipes travaillant avec de grands monorepos.

Le parallélisme consomme le quota :

Cela signifie qu'un abonnement Pro (20 $/mois) suffit pour 1–2 sessions parallèles pendant la nuit, et non pour dix. Pour exécuter de nombreux agents en parallèle, il vous faut Max ou Enterprise.

Combiner /goal, Plan Mode et les sous-agents pour les tâches longues#

Une erreur fréquente consiste à saisir immédiatement /goal build a new feature. Cela ne fonctionne pas, car l'évaluateur ne sait pas à quoi ressemble une « fonctionnalité terminée ». Il vous faut un plan avec des cases à cocher que l'évaluateur peut vérifier une par une.

Niveau 1. Plan Mode rédige un plan par phases.

Dans Plan Mode, demandez à Claude de créer un plan détaillé de modifications réparti en 5–7 phases et comprenant des cases à cocher vérifiables. Enregistrez-le sous plans/2026-05-24-google-oauth.md. Chaque phase comporte 3–7 cases à cocher décrivant des actions concrètes.

Niveau 2. Les sous-agents répartissent le travail par phase.

Si le plan peut être parallélisé (par exemple, si les phases sont indépendantes : un point de terminaison backend, un formulaire frontend et une migration de base de données), vous pouvez lancer chaque phase dans une session distincte en arrière-plan avec claude --bg --name "<phase>". Chaque session dispose de son propre worktree.

Niveau 3. /goal exécute le cycle jusqu'à ce que les cases soient cochées.

/goal toutes les phases 1–7 de plans/2026-05-24-google-oauth.md sont terminées et marquées [x], tous les tests dans test/auth réussissent (npm test affiche 0 échec), npm run build est vert, ou arrêter après 50 tours

Après chaque tour, l'évaluateur lit le plan, vérifie quelles cases sont cochées et, s'il en reste, l'agent continue.

Cette combinaison repose sur trois composants :

• ingénierie de contexte : le bon contexte dans plans/ — l'évaluateur le lit
• second cerveau : le dossier plans/ conserve le plan entre les sessions
• clone IA : CLAUDE.md définit les règles que l'agent suit

Sans CLAUDE.md, /goal peut suggérer une solution qui brise l'architecture. Sans plan dans plans/, l'évaluateur ne connaît pas les critères de réussite. Sans sous-agents, il n'y a pas de phases parallèles : tout est séquentiel.

Comment comparer /goal avec Codex, Cursor et les autres modes d’agent#

/goal ajoute une vérification d’achèvement distincte après chaque tour. Les autres produits ont plusieurs modes : CLI local, tâche cloud hébergée et session d’éditeur supervisée ne sont pas interchangeables. Ne présentez pas tout Codex CLI comme un conteneur cloud avec un validateur et une facturation uniques.

Utilisez le même état du dépôt, la même tâche et les mêmes critères d’acceptation. Relevez pour chaque candidat :

Un multiplicateur de tokens exige ces conditions et les comptes mesurés pour le même résultat réussi. Un pourcentage de benchmark exige aussi version, modèle, harnais et réglages ; les chiffres Terminal-Bench dépourvus de ces informations ne remplacent pas ces preuves. Cet article ne fournit aucun benchmark indépendant entre outils.

Choisissez selon votre besoin : édition supervisée, tâche bornée en arrière-plan ou travail sur plusieurs tours avec condition explicite. Testez le mode pris en charge par le produit installé, sans supposer qu’un concurrent entier manque d’autonomie. Distinguez approbation des outils et poursuite de la tâche : autoriser automatiquement un appel ne prouve pas l’objectif atteint.

/goal et /loop :

/loop est une autre commande de la même version ; elle lance des tâches périodiques à intervalle défini (toutes les N minutes). /goal fonctionne selon une condition (jusqu'à ce qu'elle soit remplie). Utilisez /loop pour les tâches de type cron et /goal pour atteindre un objectif ponctuel.

D'après la documentation d'Anthropic :

Liste de vérification avant de lancer /goal : 7 points#

Liste de vérification avant chaque exécution de /goal :

1. Claude Code version 2.1.139+ — vérifiez avec claude --version et mettez à jour si la version est inférieure. La version minimale recommandée est 2.1.143 (15 mai 2026), qui corrige les boucles de hooks d'arrêt.

2. La condition comprend un état final vérifiable — au lieu de « améliore-le », précisez npm test exits 0. Si vous ne trouvez pas de commande bash pour vérifier le résultat, /goal ne convient pas à cette tâche.

3. Une limite stricte de tours est définie — chaque condition précise or stop after N turns. Utilisez 15 pour les tâches faciles, 50 pour les difficiles et 100 au maximum pour les exécutions nocturnes.

4. Les contraintes sont explicites et précises — without modifying files outside /auth, without removing existing assertions, without bumping major versions. Sans ces contraintes, Claude pourrait corriger les tests en supprimant les tests eux-mêmes.

5. Toutes les modifications importantes ont été enregistrées dans des commits ou poussées — si vous ne travaillez pas dans un worktree (par exemple, avec worktree.bgIsolation: "none"), Claude modifie votre copie de travail. Une erreur pourrait vous faire perdre du travail non enregistré.

6. Les limites d'utilisation sont activées dans Paramètres → Utilisation — une nouvelle protection après l'incident des 6 000 $. Définissez une limite par jour, par session et par mois.

7. Agent View claude agents est ouvert dans une fenêtre distincte — pour les tâches longues, jetez un coup d'œil avec Space une fois par heure. Si le nombre de tours augmente plus vite que prévu ou si l'évaluateur répète la même raison pendant trois tours, appuyez sur Ctrl+C et reformulez la condition.

Un point supplémentaire : n'exécutez jamais /goal avec --dangerously-skip-permissions sur du code appartenant à quelqu'un d'autre ou que vous ne connaissez pas. Cette combinaison désactive toutes les vérifications et permet à l'agent de faire ce qu'il veut dans votre projet. L'auteur de cette analyse ne l'utilise que dans un worktree neuf où il n'y a rien à perdre.

/goal est une fonctionnalité puissante, mais ce n'est pas magique. Son efficacité dépend exactement de la façon dont vous formulez la condition. Si vous pouvez décrire « terminé » avec des mots de sorte qu'une commande puisse le vérifier, /goal se charge du reste. Sinon, revenez à une session normale ou au Plan Mode.

Pour continuer à découvrir Ailoot, rendez-vous sur ailoot.ai.