Claude Code et Codex avec /goal : travailler en autonomie

Vous trouverez des informations sur l’utilisation d’Ailoot dans la documentation.

Qu’est-ce que /goal et pourquoi cette commande est-elle apparue en 2026 ?#

Voici le scénario que nous avons tous connu avant avril 2026 : je confie à Claude la tâche suivante : « migre le projet de Pydantic v1 vers v2 ». Il commence, s’arrête au bout de 30 secondes, je regarde ce qu’il a fait, j’écris « continue », il passe à l’étape suivante, s’arrête, et j’écris de nouveau « continue ». Pour une migration importante, cela signifie 200–300 « continue » manuels. En pratique, je surveille l’agent au lieu d’écrire en parallèle d’autres lignes de code.

Selon l’analyse d’OpenAI, le problème ne venait pas de la « bêtise » du modèle, mais de l’architecture de la boucle. Le modèle ne savait pas quand s’arrêter et levait donc le pied à chaque tour. Donnez-lui un critère de fin, et il décidera lui-même.

C’est ainsi qu’est né /goal : un mécanisme intégré au harness, et non au modèle.

Cette remarque a été faite lors de la conférence Code with Claude, à Londres, les 19 et 20 mai 2026. Elle décrit ce qui s’est réellement passé au cours du mois qui a suivi le lancement de /goal dans les deux outils.

Comment configurer le mode Goal dans Claude Code ?#

Un exemple minimal tiré de la documentation officielle d’Anthropic :

claude -p "/goal CHANGELOG.md has an entry for every PR merged this week"

Cette commande lance l’agent en arrière-plan avec un seul objectif. Claude trouve les PR, les compare à CHANGELOG.md, ajoute les lignes manquantes et s’arrête lorsque le critère est rempli.

En mode interactif, saisissez simplement /goal, suivi de la condition :

/goal all pytest tests pass and mypy strict reports zero errors

Voici ce que Claude fait ensuite :

• Après chaque tour, un modèle rapide distinct (Haiku par défaut) reçoit la condition actuelle et l’historique de la conversation
• Ce modèle répond « oui » ou « non », avec une brève justification
• Si la réponse est « non », Claude effectue automatiquement un nouveau tour sans vous rendre la main
• Si la réponse est « oui », l’objectif est effacé et vous reprenez la main

Les limites strictes dont on ne vous parle que lorsqu’on les rencontre :

• /goal ne fonctionne que dans les répertoires de travail pour lesquels la boîte de dialogue de confiance a été validée. Sur une nouvelle machine, la commande échouera si Claude n’a pas encore mémorisé ce répertoire
• Dans les environnements d’entreprise utilisant disableAllHooks ou allowManagedHooksOnly, la commande n’est pas disponible
• La condition peut compter jusqu’à 4 000 caractères
• Un seul objectif peut être actif par session. Une nouvelle commande /goal réinitialise l’ancien objectif
• Avec --resume, la condition est conservée, mais les compteurs de tours, de temps et de tokens sont réinitialisés

Commandes de contrôle :

• /goal sans argument — afficher l’état actuel
• /goal clear (ou stop, off, reset, none, cancel) — effacer l’objectif

Selon Anthropic, le coût de l’évaluateur est « généralement négligeable par rapport à celui du tour principal ». Haiku évalue le critère et le texte de la conversation sans appeler d’outils, donc cette vérification est peu coûteuse ; les tours du modèle principal constituent la partie onéreuse.

Comment configurer /goal dans Codex CLI ?#

La commande ressemble à celle de Claude :

codex
> /goal all vitest tests pass and there are no eslint errors

Codex offre davantage de commandes de gestion des objectifs :

La principale différence avec Claude est que Codex vérifie lui-même s’il a « terminé », au lieu de faire appel à un modèle distinct. Après chaque tour, Codex insère automatiquement dans le contexte le modèle continuation.md du dépôt openai/codex. Traduction littérale :

« Continue à travailler en direction de l’objectif actif du thread. Ne répète pas les tâches déjà effectuées. Choisis la prochaine action concrète qui rapproche de l’objectif. Ne considère l’objectif comme atteint que lorsqu’un audit montre qu’il l’est réellement et qu’il ne reste aucune tâche nécessaire. »

Lorsque les tokens approchent de leur limite, un second modèle, budget_limit.md, est inséré :

« L’objectif a atteint sa limite de tokens. Ne commence pas de travail conséquent. Termine ce tour dès que possible : résume les progrès utiles, indique le travail restant et les blocages, puis donne à l’utilisateur une prochaine étape claire. »

La logique est la même : « ne mens pas sur ce que tu as fait ». La continuation impose de continuer uniquement si l’objectif n’a pas réellement été atteint. budget_limit impose de s’arrêter, tout en décrivant honnêtement ce qu’il reste à faire.

Contrairement à Claude, Codex associe l’objectif au thread, et non à la session. Par exemple, vous pouvez fermer le terminal puis le rouvrir le matin, et /goal resume reprend le même objectif avec les mêmes informations en mémoire. Cette fonction est utile pour répartir les sessions selon son propre emploi du temps.

Quelle est la différence entre /goal dans Claude Code et /goal dans Codex ?#

C’est la différence la plus souvent négligée dans les comparaisons. Examinons-la en détail.

La différence conceptuelle est que Claude traite la boucle comme un contrat de qualité (un évaluateur externe), tandis que Codex la traite comme un mécanisme d’exécution (l’agent se gère lui-même).

En pratique, si vous voulez que le critère de fin soit évalué de façon impartiale, choisissez Claude. Si vous voulez que l’agent puisse examiner les fichiers et les logs pendant l’évaluation, choisissez Codex.

Pour en savoir plus sur les outils eux-mêmes, consultez le guide Codex vs Claude Code.

Exemple réel : migrer de Pydantic v1 à v2 en 31 heures#

La tâche était formulée ainsi : « migre de Pydantic v1 à v2 ; tous les tests pytest doivent réussir et mypy strict doit signaler zéro erreur. »

Voici ce qui s’est passé :

• Session 1 (8 heures) — Codex a analysé les imports, réécrit les déclarations BaseModel et configuré mypy
• Session 2 (10 heures) — il a réécrit les validateurs et fait échouer environ 200 tests
• Session 3 (7 heures) — il a corrigé les tests et découvert des dépendances circulaires
• Session 4 (6 heures) — il a résolu les erreurs mypy restantes et les régressions

Coût en tokens :

« Temps total écoulé : environ 31 heures réparties sur quatre sessions. Coût total des tokens Codex aux tarifs de gpt-5.3-codex : environ $44. »

Le prix est principalement dû aux tokens de sortie de gpt-5.3-codex, facturés 14 $ par million. Ainsi, 31 heures de travail autonome coûtent à peu près autant que plusieurs semaines d’abonnement ChatGPT Plus.

Ce que l’agent n’a pas fait de lui-même :

• Il n’a pas rédigé la documentation de migration pour l’équipe (Codex n’a pas compris que cela faisait partie de la « migration »)
• Il n’a pas mis à jour les fichiers de configuration pour publier avec la nouvelle version de Pydantic
• Il a manqué une régression en production, découverte seulement un jour plus tard

Autrement dit, /goal a effectué 95 % du travail ; les 5 % restants doivent toujours être faits à la main. C’est normal pour la génération actuelle et ce n’est pas une raison de ne pas l’utiliser.

14 heures pendant la nuit sur un pilote macOS#

Quelles tâches se prêtent aux longues exécutions nocturnes#

Les types de tâches pour lesquels cette approche est la plus avantageuse :

• Le travail de bas niveau où une itération et sa vérification prennent quelques minutes (compilation, exécution des tests)
• Les migrations avec des critères formels clairs (types, tests, lint)
• Les benchmarks et optimisations aux résultats mesurables
• La documentation et les journaux des modifications à la structure claire

Claude /goal fait tout aussi bien le travail, mais Codex est plus souvent choisi pour les pilotes parce qu’il vérifie lui-même les fichiers et les logs au lieu de s’en remettre à un juge externe.

Combien cela coûte-t-il et comment éviter de brûler ses tokens pendant la nuit ?#

Chiffres tirés de témoignages publics :

L’essentiel à comprendre : ni Claude Code ni Codex ne proposent de limite stricte du type « arrête de dépenser à N $ ». Il existe trois protections :

1. Limites de l’abonnement — Pro, Max ou Enterprise. Avec le forfait Max d’Anthropic (100 $/mois), une session nocturne de 14 heures reste dans le quota hebdomadaire, avec une bonne marge
2. Limite de texte dans la condition — écrivez « ou arrête-toi après 20 tours » directement dans /goal. Le juge de Claude le lira et clôturera l’objectif
3. Limite de tokens dans Codex — mécanisme intégré qui insère budget_limit.md lorsque les tokens sont épuisés

Ce qui fait grimper la facture pendant la nuit :

• Un critère vague comme « rends-le plus pratique » : l’agent ne s’arrêtera jamais, car l’évaluateur ne sait pas ce que signifie « mieux »
• L’accès à des API externes sans stubs : chaque nouvelle tentative consomme des tokens
• Un contexte long : après 6,7 millions de tokens, la compaction du contexte se déclenche et une partie de la mémoire est perdue

Pour en savoir plus sur la maîtrise des coûts, consultez les guides où vont les tokens de Claude Code et comment ne pas épuiser ses limites.

Quand NE PAS lancer /goal : 5 situations#

La documentation d’OpenAI indique explicitement ce qu’il NE faut PAS faire :

1. Modifications d’une seule ligne — utiliser /goal pour renommer une variable coûte plus cher que de le faire à la main
2. Objectifs vagues — « améliorer les performances », « rendre le code plus propre », « rendre ça plus pratique ». L’évaluateur n’a aucun critère, l’agent tournera donc indéfiniment en rond
3. Bases de données de production contenant des données utilisateur — l’agent pourrait compromettre une migration, et une restauration depuis une sauvegarde coûterait plus que les économies réalisées
4. Modifications liées à la sécurité — authentification, chiffrement, traitement des paiements. Une personne doit examiner chaque commit
5. API externes sans stubs — chaque panne réseau consomme des tokens et échappe à votre contrôle

Que faire si l’agent reste bloqué ?#

Comment repérer rapidement une boucle :

• L’agent touche les mêmes fichiers pendant au moins 3 tours et les rétablit ensuite dans leur état précédent
• Les mêmes erreurs apparaissent dans le log, alors qu’il y a déjà répondu
• La condition vous semble remplie, mais l’agent indique « non remplie »
• La consommation de tokens par tour augmente, mais le code ne progresse pas

Que faire ensuite :

• Dans Claude Code : /goal clear, puis précisez davantage la condition
• Dans Codex : /goal pause, examinez le thread actuel, modifiez la condition avec /goal edit, puis /goal resume
• Dans les deux outils : vérifiez que le critère est réellement vérifiable (une commande renvoie le code de sortie 0 ou produit un résultat spécifique)

Souvent, la cause de la boucle tient à la tâche elle-même plutôt qu’à l’agent. La condition « tous les tests réussissent » suppose que les tests puissent réussir. Si le code présente un problème d’architecture profond, l’agent continuera à tourner autour du symptôme.

Critères de fin : la discipline de tâche pour /goal#

OpenAI énonce clairement cette règle dans son Codex Cookbook officiel :

Modèles de critères qui fonctionnent vraiment :

La ligne Combo utilise une combinaison de vérifications : tests, mypy et lint. Si une seule vérification reste rouge, l’objectif n’est pas clôturé. L’évaluateur ne peut pas tricher.

Anti-modèles :

• « Le code est meilleur »
• « La facilité d’utilisation s’est améliorée »
• « Les performances se sont améliorées »
• « La documentation est complète »

La différence entre « ça marche » et « ça ne marche pas » tient à la vérifiabilité. Si un critère ne peut pas être vérifié avec une commande, il ne peut pas être vérifié du tout. C’est aussi ce qu’OpenAI entend par « cohérence à long horizon » : un agent peut réfléchir longtemps, mais ne peut pas décider par lui-même de ce qui est « suffisamment bien ».

Vous pouvez essayer l’idée « un prompt, un résultat » sur un vrai projet : définissez /goal, formulez un critère, lancez la tâche et analysez ce qui n’a pas fonctionné.

Découvrez Ailoot.