OpenCode 2.0 : ce que la plus grande refonte de l'agent de code ouvert change pour l'IA locale

Anomaly a publié OpenCode 2.0. L'entreprise parle d'une refonte majeure, bâtie sur l'expérience de millions d'utilisateurs quotidiens : un système capable de s'adapter à tout ce qu'un agent de code doit être. Il y a de nouvelles fonctionnalités, du travail de performance et beaucoup de corrections de bugs, mais les changements visibles sont plus structurels qu'esthétiques. OpenCode n'est plus seulement un programme terminal qui parle à un modèle. C'est à la fois un service, une API, un SDK et une plateforme de plugins.

Pour ceux qui font tourner des modèles en local, ce basculement compte plus que les notes de version ne le suggèrent. L'essentiel de ce qu'apporte la 2.0 répond aux mêmes goulots d'étranglement que les utilisateurs d'IA locale rencontrent chaque jour : un contexte rare, un seul GPU qui ne peut pas faire deux choses à la fois et un harnais qui doit s'adapter à des modèles qu'il ne contrôle pas.

Un service d'arrière-plan, plusieurs clients

OpenCode utilise un modèle client/serveur depuis le début, mais la 1.x en profitait rarement. Dans la 2.0 le serveur tourne désormais automatiquement comme un seul processus d'arrière-plan sur votre machine. Que vous ouvriez le TUI, l'interface web ou l'application de bureau, tous parlent au même processus central. Les sessions vivent au même endroit au lieu d'être dupliquées par client.

Cela a une conséquence pratique immédiate pour les scripts. Si vous utilisez le client programmatique @opencode/client, il détecte automatiquement le service local et fonctionne directement. Les tâches planifiées, les tâches cron, les déclencheurs de CI et les petits scripts d'automatisation peuvent piloter le même agent que celui que vous utilisez de façon interactive, sans gérer un serveur vous-même. Vous pouvez aussi l'appeler depuis la CLI avec les commandes opencode api.

Le service peut être exposé à d'autres hôtes et appairé via /pair ou opencode pair. Anomaly indique que des applications natives tirant parti de ce flux sont en préparation. Pour une installation locale l'intérêt est évident : la machine avec le GPU fait tourner le modèle et le service, tandis qu'un portable plus léger le pilote par le réseau.

Une API qu'OpenCode peut appeler lui-même

Anomaly est direct au sujet de l'ancienne API : elle a grandi au hasard et elle était mauvaise. La version 2.0 repart de zéro. La nouvelle API est conçue autour des cas étranges rencontrés chez des millions d'utilisateurs et couvre presque tout ce qu'un agent a besoin de faire.

Le plus intéressant, c'est qu'OpenCode est désormais conscient de sa propre API et l'appelle pour faire des choses utiles. L'annonce le montre déplaçant une session dans un git worktree au démarrage d'un nouveau travail, listant et inspectant des sessions, interrompant une exécution bloquée, renommant une session ou fermant un onglet. La gestion des agents devient une capacité de l'agent plutôt qu'une logique d'interface codée en dur. C'est une architecture plus propre et un bon signe pour ceux qui construisent par-dessus.

Le mode code : moins d'allers-retours, moins de contexte

Le mode code est la fonctionnalité la plus susceptible de compter pour les modèles locaux. OpenCode 2.0 inclut @opencode/codemode, un interpréteur JavaScript minimal. Il ingère des serveurs MCP ou des points de terminaison OpenAPI, les convertit en fonctions que l'agent peut appeler dans un script et exécute ces scripts nativement, sans VM Node.js ni moteur embarqué lourd comme QuickJS.

Au lieu d'appeler un outil à la fois, l'agent peut écrire un petit programme : appeler un outil, parcourir les résultats et appeler un autre outil en un seul aller-retour. C'est plus rapide, mais c'est aussi bien moins coûteux en contexte, car l'agent n'a plus à recoller chaque résultat intermédiaire dans la conversation.

Tous les serveurs MCP adoptent le mode code par défaut dans la 2.0. Anomaly affirme qu'on peut en ajouter un millier avec un gonflement de contexte minimal et que l'agent les découvrira et les composera selon les besoins. Sur un modèle local avec une fenêtre de 32K ce n'est pas un luxe. Les définitions d'outils seules peuvent consommer 30 à 50 % du contexte sur une installation bien équipée, comme nous l'expliquons dans notre guide MCP. Retarder la découverte jusqu'à ce que le script ait besoin d'un outil change entièrement le budget.

Une réserve mérite d'être posée. Le mode code échange des tours d'appels d'outils contre du JavaScript généré. Un modèle qui produit de manière fiable des appels d'outils JSON valides n'est pas automatiquement bon pour écrire des scripts multi-étapes corrects. Avec un petit modèle local, testez ce chemin avant de supposer qu'il est gagnant.

Sous-agents et commandes shell en arrière-plan

Les modèles récents sont bons en orchestration et les harnais doivent leur permettre d'exprimer cette capacité. OpenCode 2.0 ajoute deux façons de travailler en asynchrone.

D'abord, les sous-agents en arrière-plan. L'agent principal peut confier du travail à un autre agent pendant qu'il continue, automatiquement ou à la demande, même avec un modèle différent. L'exemple de l'annonce est de lancer un sous-agent en arrière-plan pour relire du code pendant que vous continuez à envoyer des requêtes.

Ensuite, les commandes shell en arrière-plan. L'outil shell peut être invoqué de façon asynchrone pour qu'un travail long ne bloque pas l'agent principal, qui est notifié à la fin. Si une commande au premier plan ou un sous-agent prend plus de temps que prévu, un raccourci clavier le déplace en arrière-plan.

Sur un seul GPU local c'est utile mais pas magique : l'inférence reste sérialisée et deux agents simultanés se disputeront la même VRAM. Le vrai gain est organisationnel. Vous pouvez laisser tourner une compilation ou une série de tests pendant que vous envoyez des requêtes et confier une relecture d'arrière-plan à un modèle local bon marché pendant qu'un plus grand reste sur la tâche principale, à condition que les deux tiennent en mémoire. Sur une seule carte, un modèle plus petit pour le sous-agent est le choix raisonnable par défaut.

Les plugins deviennent l'architecture

OpenCode 1.0 avait un système de plugins, mais il n'a jamais reçu l'attention nécessaire. Pour corriger cela, Anomaly s'est forcé à implémenter presque chaque fonctionnalité de la 2.0 comme un plugin interne. Il y en a désormais plus de 80. Cela garantit que l'API de plugins reste bien maintenue, puisque le produit lui-même en dépend.

Les plugins TUI passent du statut expérimental au statut stable, propulsés par OpenTUI. Anomaly a aussi beaucoup travaillé le rechargement à chaud, pour qu'OpenCode puisse écrire un plugin pour lui-même en pleine session et l'utiliser aussitôt. La conception est détaillée dans un précédent article sur le rechargement.

Pour l'IA locale c'est plus pertinent qu'il n'y paraît. Le harnais est là où se fait l'essentiel de l'adaptation quand on change de modèle : formats de prompt, parseurs d'appels d'outils, gestion du contexte, particularités des fournisseurs. Une API de plugins maintenue avec rechargement à chaud permet de corriger ces comportements sans forker l'agent. Si la documentation ne suffit pas, vous pouvez simplement demander à OpenCode de construire le plugin.

Le SDK : votre propre variante d'OpenCode

OpenCode peut désormais s'utiliser comme bibliothèque via @opencode/sdk. C'est exactement le même code que celui qui alimente la CLI. En principe vous pouvez l'épurer et faire votre propre variante d'OpenCode qui tourne sur un serveur ou dans des environnements spécialisés, puis vous y connecter depuis n'importe quel client OpenCode puisqu'elle parle le protocole serveur standard. Une API optionnelle basée sur Effect fait partie du paquet et reste en développement.

C'est la pièce qui transforme OpenCode d'application en infrastructure. Un assistant local adossé à votre propre modèle, un service de code interne sur un poste de travail ou un agent de maintenance planifié qui parle le même protocole sont désormais des projets raisonnables.

Ce que cela change pour l'IA locale

OpenCode 2.0 n'a pas été conçu spécifiquement pour les modèles locaux, mais plusieurs choix de conception s'alignent avec les contraintes de leur exécution :

• Un service au lieu de nombreux processus. Un agent unique et durable sur la machine, qui possède le modèle et les sessions, est plus simple à planifier, à surveiller et à appairer avec d'autres appareils.
• Le contexte est traité comme un budget. Le mode code retarde la découverte des outils et regroupe les appels multi-étapes dans un script, exactement ce dont une fenêtre locale de 32K ou 64K a besoin. Les règles de dimensionnement du contexte s'appliquent toujours, comme le décrivent notre guide Ollama et notre guide des modèles de code.
• L'asynchronie colle au matériel hétérogène. Un sous-agent d'arrière-plan peut faire tourner un petit modèle local pendant que l'agent principal utilise un plus grand et les longues tâches shell ne gèlent plus la session.
• Le harnais s'étend proprement. Une architecture centrée sur les plugins est la bonne façon d'adapter un agent ouvert qui évolue vite aux particularités des modèles à poids ouverts.

La limite honnête ne change pas : le modèle doit toujours appeler correctement les outils. Un modèle de frontière rend le mode code sans effort ; un modèle 7B, beaucoup moins. OpenCode 2.0 offre un meilleur harnais à un bon modèle local, pas un meilleur cerveau.

Mise à jour et changements cassants

Pour mettre à jour la CLI, assurez-vous d'être sur la dernière version 1.x, puis lancez :

opencode upgrade --major

L'application de bureau se télécharge séparément sur opencode.ai/download. Il y a de vrais changements cassants :

• Les plugins 1.0 ne fonctionneront pas dans la 2.0.
• L'API serveur est complètement différente.
• Le fichier de configuration tui.json passe à un format JSON.

La plupart des autres changements restent compatibles avec l'existant, mais sauvegarder votre configuration et vos plugins avant de basculer est prudent. Anomaly recommande de pointer OpenCode vers le guide de migration pour qu'il migre les choses pour vous. Comme l'agent peut désormais modifier sa propre installation, garder une copie de configuration qui fonctionne est une assurance bon marché.

Sources

• Site d'Anomaly — l'entreprise derrière OpenCode
• Annonce d'OpenCode 2.0 — Anomaly, octobre 2026
• Documentation des plugins — documentation OpenCode 2.0
• Documentation du SDK — documentation OpenCode 2.0
• Migration depuis la 1.x — guide de migration OpenCode 2.0
• Téléchargement d'OpenCode — application de bureau