OpenCode 2.0 : le harness IA pour développeurs accélère avec un service en arrière-plan
Sommaire
En bref
- OpenCode 2.0 introduit un service permanent en arrière-plan qui centralise les interactions (TUI, web, desktop, CLI).
- La nouvelle API est entièrement reconstruite et supporte des cas d'usage complexes, notamment via un interpréteur JavaScript minimal pour l'exécution de code.
- Les sous-agents, les tâches de fond et un système de plugins repensé (80+ internes) complètent cette refonte.
- Le produit vise à laisser l'agent IA orchestrer davantage de travail sans blocages, tandis que l'équipe a implémenté la quasi-totalité des nouvelles fonctionnalités comme plugins pour valider l'API.
Ce que dit la source
OpenCode reconçoit son architecture autour d'un modèle client/serveur automatique et d'une API entièrement nouvelle. La source affirme que la première API s'était développée de façon désordonnée au fur et à mesure de l'apprentissage collectif sur ce que les agents doivent être, et qu'elle répartit maintenant le travail entre l'interface utilisateur (TUI, web, desktop) et un service central persistent. Le système introduit un interpréteur JavaScript minimal (package codemode) qui laisse les modèles composer des appels d'outils sans appels multiples aller-retour, et des sous-agents qui peuvent s'exécuter en arrière-plan pendant que l'agent principal continue l'interaction utilisateur.
- Le service s'exécute par défaut comme un processus unique en arrière-plan ; les clients (TUI, web, desktop, CLI, script programmatique via @opencode/client) le découvrent automatiquement et communiquent avec ce processus central.
- Un interpréteur JavaScript minimal dans @opencode/codemode permet aux agents d'exécuter des scripts qui composent plusieurs appels d'outils en une seule requête (ex: récupérer les issues GitHub, mapper les résultats, créer des tickets Linear en une seule étape).
- Les serveurs MCP sont intégrés nativement sans surcharge contextuelle ; l'agent peut en ajouter des centaines et les découvrir/composer automatiquement.
- Sous-agents et tâches shell en arrière-plan : l'agent principal peut déléguer du travail (ex: révision de code avec un modèle différent) ou des commandes shell longues sans bloquer l'interaction utilisateur.
- Le système de plugins a été repensé : l'équipe a implémenté 80+ fonctionnalités internes comme plugins pour valider la stabilité de l'API.
- Configuration chargée depuis le dossier où la session est créée (pas depuis le dossier de lancement du serveur).
Dans les commentaires
Débat partagé : utilisateurs existants reconnaissent une amélioration nette (plugins/skills qui se rechargent, session backgrounding, configuration intégrée), mais quelques frictions techniques remontent (isolation des sandbox obsolète après la centralisation, consommation RAM toujours élevée, performance de l'installateur). Pas de consensus sur l'importance stratégique du modèle daemon permanent.
- Un commentateur note qu'après la migration vers le service central, son sandbox de restriction des appels d'outils du processus TUI est devenu inutile, car tous les appels passent maintenant par le processus en arrière-plan, cela pose une question d'isolation non adressée par la source.
- Plusieurs utilisateurs signalent que la documentation du post (très dense, format diagramme) est peu accessible ; un commentateur dit explicitement ne pas l'avoir lue complètement faute de lisibilité.
- L'absence de mode "auto" comparable à Claude Code (approuver/refuser chaque commande vs. exécution manuelle) est mentionnée comme un frein au flux ; la source ne répond pas à cette demande.
- La performance de l'installateur (curl | sh) est critiquée : un utilisateur rapporte 6 minutes pour atteindre 10% en raison du rendu de la barre de progression.
- Un commentateur signale une consommation RAM significativement plus élevée qu'un concurrent nommé Pi, malgré la refonte.
- Confusion sur l'identité du projet : un commentateur demande si OpenCode 2.0 est un fork, après l'avoir cru renommé en Crush, la source ne clarifiait pas ce point.
Alternatives citées : Pi (concurrent mentionné pour consommation RAM inférieure et efficacité CPU) ; Claude Code (principal concurrent, mais sans modèle client/serveur centralisé par défaut).
Notre lecture
OpenCode 2.0 représente une refonte solide du modèle interne et de l'API, avec une architecture client/serveur mieux exploitée et des primitives pour l'orchestration multi-agent qui alignent le harness sur les capacités réelles des LLM modernes. Pour une équipe de dev déjà sous OpenCode, cette mise à jour élimine des frictions significatives (plugins qui ne rechargeaient pas, config distribuée). Cependant, le choix par défaut d'un daemon permanent soulève des questions légitimes de sécurité (isolation sandbox) et de coût système (RAM, CPU) que la source n'adresse pas. À tester pour les utilisateurs existants ; pour les nouveaux utilisateurs, la comparaison avec Claude Code et d'autres harness sur les critères d'isolation, de consommation système et de degré d'autonomie acceptable reste ouverte.