Les agents IA de programmation deviennent progressivement capables de poursuivre un objectif sans attendre une nouvelle instruction après chaque étape. Avec l'arrivée de /goal dans OpenCode 2.2.1, les trois grands environnements OpenCode, Codex CLI et Claude Code proposent désormais une approche comparable.
Mais derrière cette commande commune se cachent des mécanismes différents. Comment chaque outil décide-t-il qu'une tâche est terminée ? Quelles limites empêchent un agent de tourner indéfiniment ? Et surtout, comment contrôler les coûts de ces nouvelles boucles autonomes ?
D'une instruction ponctuelle à un objectif persistant
Un agent de programmation peut aujourd'hui analyser un dépôt, modifier des fichiers, exécuter des commandes et corriger des erreurs.
Pourtant, une difficulté subsiste : la fin d'un tour de conversation ne correspond pas nécessairement à la fin du travail.
Prenons une migration d'API. L'agent modifie les principaux fichiers et annonce son intervention terminée. Mais certains tests échouent encore, le lint relève des erreurs et plusieurs appels à l'ancienne API subsistent.
Dans une interaction classique, le développeur doit demander à l'agent de poursuivre.
La commande /goal modifie cette logique. Au lieu de définir simplement la prochaine action, l'utilisateur fixe une condition de réussite qui reste active pendant plusieurs tours.
L'agent peut alors travailler, examiner les résultats, corriger les problèmes et recommencer tant que son mécanisme de contrôle estime que l'objectif n'est pas atteint.
Il ne s'agit pas d'une intelligence totalement autonome, mais d'une boucle de travail pilotée par un objectif mesurable.
OpenCode 2.2.1 : comment fonctionne /goal ?
Publiée le 29 octobre 2026, la version 2.2.1 d'OpenCode introduit officiellement la commande /goal dans son interface terminal interactive (TUI) et son application Desktop.
Son utilisation est simple :
/goal Corriger les erreurs TypeScript, faire réussir
tous les tests et obtenir un build sans erreur.
OpenCode enregistre l'objectif dans la session. Lorsque l'agent termine normalement un tour et s'apprête à devenir inactif, un mécanisme de revue intervient.
Ce mécanisme examine l'avancement de la session et détermine si le travail peut être considéré comme terminé ou s'il faut poursuivre.
Lorsque des actions restent nécessaires, OpenCode peut déclencher automatiquement une nouvelle continuation.
Plusieurs commandes permettent de garder le contrôle :
| Commande | Fonction |
|---|---|
/goal <objectif> | Définir un objectif |
/goal | Consulter son état |
/goal pause | Suspendre l'exécution |
/goal resume | Reprendre l'objectif |
/goal clear | Supprimer l'objectif |
L'implémentation s'appuie sur un nouveau hook expérimental intervenant avant qu'une session ne devienne inactive.
Dans cette première version, la revue utilise le modèle de la session et son historique. Elle consomme donc des ressources supplémentaires. L'implémentation prévoit aussi une mise en pause après trois tours sans progrès ou 50 tours, ainsi que dans certaines situations de blocage. Ces garde-fous ne constituent pas un plafond de tokens ou de dépenses.
Une limite importante : cette première intégration est disponible dans la TUI et Desktop. La commande /goal n'est pas directement utilisable comme slash command dans opencode run.
Codex : l'objectif comme contrat vérifiable
Les Goals sont disponibles dans Codex à partir de la version 0.128.0.
Son approche repose sur un objectif persistant, associé au fil de travail et accompagné de critères de validation.
Codex ne doit pas simplement poursuivre jusqu'à produire une réponse satisfaisante. Il doit examiner les preuves disponibles : fichiers modifiés, résultats de tests, journaux d'exécution, benchmarks ou autres éléments vérifiables.
Un objectif peut notamment définir :
- Le résultat attendu et les éléments qui prouvent sa réussite.
- Les contraintes à respecter pendant les modifications.
- Les limites d'exécution et les ressources autorisées.
- Les conditions nécessitant un arrêt ou une intervention humaine.
Codex distingue ainsi la réussite effective de la tâche, l'impossibilité de poursuivre dans les conditions prévues et l'épuisement du budget.
Cette séparation est essentielle pour les travaux complexes. Un agent qui atteint sa limite de ressources n'a pas nécessairement terminé son travail.
Claude Code : un évaluateur distinct
Dans Claude Code, /goal repose sur un Stop hook associé à la session.
Chaque fois que Claude termine un tour, un modèle distinct, généralement un modèle rapide de la famille Haiku sur l'API Anthropic, évalue la condition de réussite.
Trois issues principales sont possibles : l'objectif est atteint, il reste du travail, ou l'objectif est jugé impossible.
Si le travail n'est pas terminé, une nouvelle itération peut commencer.
Cette architecture sépare l'agent chargé de produire le code du modèle chargé d'évaluer l'état d'avancement.
Elle présente un intérêt économique : utiliser un modèle rapide pour les contrôles intermédiaires peut être moins coûteux que solliciter systématiquement le modèle principal.
Il existe toutefois une limite importante. L'évaluateur de Claude Code n'exécute pas indépendamment les commandes et n'inspecte pas directement les fichiers. Son jugement repose sur les éléments que l'agent principal a déjà présentés dans la conversation.
Une évaluation séparée ne remplace donc pas une vérification technique indépendante.
OpenCode, Codex et Claude Code : les différences essentielles
| Critère | OpenCode | Codex | Claude Code |
|---|---|---|---|
| Poursuite automatique d'un objectif | Oui | Oui | Oui |
| Mécanisme | Plugin et hook d'inactivité | État persistant du fil et continuation contrôlée | Stop hook avec modèle évaluateur |
| Évaluation | Revue par le modèle de la session, selon l'implémentation initiale | Vérification des preuves du fil | Modèle rapide distinct |
| Contrôle du budget | Pas de plafond de tokens propre à /goal documenté dans la première annonce | Comptabilisation et arrêt sur budget | Suivi des tokens et conditions d'arrêt définissables |
| Exécution non interactive du Goal | Non via opencode run dans la première version | Selon les interfaces et workflows compatibles | Oui, avec claude -p |
Les trois systèmes poursuivent donc un objectif comparable, mais avec des philosophies différentes.
OpenCode privilégie une intégration légère dans sa session de travail. Codex insiste sur le contrat de réalisation et la gestion des limites. Claude Code introduit un évaluateur séparé.
Aucune de ces approches ne garantit, à elle seule, la qualité du code produit.
Le problème fondamental : qui décide que le travail est terminé ?
Imaginons un objectif simple :
/goal Corriger tous les tests qui échouent.
Un agent pourrait modifier l'implémentation jusqu'à réussir les tests. Mais il pourrait aussi, volontairement ou non, supprimer un test problématique, modifier une assertion ou contourner une validation.
Dans les deux cas, le résultat apparent pourrait être identique : une suite de tests verte.
C'est pourquoi un objectif solide doit définir non seulement ce qu'il faut obtenir, mais aussi les conditions qui rendent le résultat acceptable.
Voici une formulation plus rigoureuse :
/goal
Migrer le module d'authentification vers
la nouvelle API cliente.
Critères de réussite :
- Tous les tests d'authentification passent.
- Le lint et le build passent.
- Aucun appel à l'ancienne API ne subsiste.
- Aucun test n'est supprimé ou affaibli.
- Les interfaces publiques restent compatibles.
Vérifier le diff final.
Si un critère ne peut pas être satisfait,
expliquer le blocage et arrêter.
Cette formulation transforme une instruction vague en objectif techniquement vérifiable.
Elle ne supprime pas tous les risques, mais elle fournit une base beaucoup plus solide pour juger le travail de l'agent.
L'autonomie multiplie aussi les appels aux modèles
Il existe une conséquence économique souvent sous-estimée.
Un agent qui poursuit automatiquement un objectif peut effectuer plusieurs cycles d'analyse, de modification et de vérification sans nouvelle intervention humaine.
Chaque cycle peut mobiliser le contexte de conversation, les résultats des commandes et des tokens supplémentaires.
Le coût total ne dépend donc plus uniquement du prix du modèle choisi. Il dépend aussi du nombre d'itérations, de la taille du contexte et des mécanismes d'évaluation.
Dans le cas d'OpenCode, une revue utilisant le même modèle que la session peut représenter une consommation supplémentaire non négligeable lorsque le modèle principal est coûteux.
Claude Code privilégie un évaluateur plus léger. Codex intègre une logique de budget dans le cycle de vie de ses Goals.
Mais dans les trois cas, un objectif mal défini peut entraîner une succession de tentatives peu productives.
Un agent capable de travailler plus longtemps n'est pas nécessairement un agent plus efficace.
Pour comparer sérieusement ces systèmes, il faudrait mesurer le taux de réussite des objectifs, les régressions introduites, le nombre d'itérations et les tokens consommés sur les mêmes tâches.
La seule présence de /goal ne permet pas de conclure qu'un outil est meilleur qu'un autre.
Et avec RouterLab ?
Cette évolution concerne directement les développeurs qui utilisent plusieurs modèles IA dans leurs outils de programmation.
RouterLab propose une API compatible OpenAI et permet de suivre l'utilisation des modèles et les crédits depuis un compte centralisé.
Son projet open source wrapper-scionos documente notamment la connexion de Claude Code, Codex CLI et OpenCode aux modèles RouterLab compatibles.
Le principe est de conserver l'environnement de développement habituel tout en choisissant les modèles et les routes disponibles.
Pour OpenCode, cette possibilité est particulièrement intéressante : l'outil accepte également des fournisseurs personnalisés utilisant des API compatibles OpenAI.
Il faut néanmoins distinguer la connexion du modèle de la prise en charge d'une fonctionnalité récente du client. Le nouveau mode /goal d'OpenCode 2 doit être vérifié avec la version exacte de l'outil, le modèle sélectionné et la configuration de transport utilisée.
Le suivi des crédits permet de rendre la consommation visible, mais ne remplace pas une véritable limite d'exécution ou de dépenses configurée pour une tâche autonome.
Une nouvelle étape, pas encore le pilote automatique
L'arrivée de /goal dans OpenCode confirme une évolution importante des agents de programmation.
L'utilisateur ne définit plus seulement une liste d'actions. Il fixe un résultat, des contraintes et des critères de validation.
L'agent prend davantage de décisions sur les étapes intermédiaires, tandis que le développeur conserve la responsabilité de définir le périmètre et d'examiner les preuves.
Le véritable progrès ne consiste donc pas simplement à éviter de répéter « continue ».
Il consiste à construire des workflows dans lesquels une tâche possède un objectif précis, une méthode de vérification, un budget et une condition d'arrêt.
OpenCode, Codex et Claude Code proposent trois implémentations de cette idée.
La prochaine étape sera de déterminer laquelle permet d'obtenir le meilleur résultat vérifiable avec le moins d'interventions, de régressions et de ressources consommées.
Sources et références
Tester l’API RouterLab
Passez d’un article à une requête réelle : créez un essai, récupérez une clé et appelez les modèles depuis une API compatible OpenAI.