OpenCode CLI contre Desktop : comparaison des flux de travail en 2026

OpenCode CLI et Desktop sont des clients du même produit d’agent de codage. L’interface terminal convient au travail au clavier et aux scripts. L’application de bureau fournit un espace de travail graphique. La comparaison importante couvre le serveur, le projet, le fournisseur et la configuration derrière chaque client.

Choisissez l’interface après avoir identifié le backend. Deux fenêtres OpenCode n’utilisent pas forcément le même serveur ou la même session. Une application de bureau connectée à un autre serveur est un autre environnement d’exécution, même si le nom du modèle semble familier.

Points essentiels #

• Utilisez CLI pour le travail dans le terminal et les commandes non interactives.
• Utilisez Desktop pour un espace graphique, après avoir vérifié son serveur.
• La configuration du fournisseur détermine l’inférence, indépendamment de l’interface.
• La même identité de produit ne garantit pas le même état de session entre des serveurs ou versions distincts.

Portée et date : Documentation officielle vérifiée le 6 octobre 2026. Ce guide compare les interfaces, pas la qualité des modèles. Il vous faut un dépôt, une connexion fournisseur fonctionnelle et une pratique de base du terminal. Prévoyez 45 à 60 minutes pour l’essai.

Le client et le serveur #

OpenCode sépare l’interface du serveur. La documentation du serveur décrit l’UI terminal comme un client et opencode serve comme un serveur autonome. Cette architecture prend en charge plusieurs manières d’interagir avec l’agent.

Desktop démarre un serveur local par défaut. Le guide de dépannage identifie son sidecar opencode-cli et l’option de connexion à une URL de serveur configurée. Si les clients se comportent différemment, inspectez cette connexion avant de modifier le prompt.

L’emplacement du serveur n’est pas celui de l’inférence. Un serveur d’agent sur votre ordinateur envoie encore ses requêtes à un modèle hébergé configuré. À l’inverse, un service d’inférence local compatible est un processus distinct avec son propre modèle et ses propres besoins en ressources.

La référence officielle du serveur indique 127.0.0.1 comme nom d’hôte par défaut pour opencode serve. Gardez le service sur loopback pendant un essai local :

opencode serve --hostname 127.0.0.1

N’utilisez une adresse de liaison plus large qu’après avoir défini l’authentification, les règles du pare-feu et les chemins du dépôt exposés au serveur.

Interaction terminal et automatisation #

opencode

La commande par défaut ouvre l’UI terminal. La référence CLI documente aussi les commandes programmatiques. Commencez dans le dépôt prévu et confirmez l’agent et le modèle sélectionnés avant de demander des modifications.

opencode run "Identify this project's test command. Do not modify files."

Utilisez opencode run pour une requête non interactive limitée. Définissez séparément la politique de permissions appropriée. Une demande de ne rien modifier donne une direction, mais n’impose pas l’isolation du système de fichiers.

Choisissez ce flux si la composition shell compte. Un wrapper reproductible doit capturer la requête, le code de sortie, la sortie utile et les fichiers modifiés. Rendez la gestion des échecs explicite. Un diff vide et un message de réussite demandent une interprétation différente d’une correction vérifiée.

Configuration et compatibilité de Desktop #

Utilisez la page de téléchargement officielle pour la version prévue. La page de téléchargement OpenCode liste les paquets terminal et bureau. Lors de cette vérification, elle annonce des paquets terminal v2, tandis que la documentation générale contient aussi d’anciens exemples d’installation. Notez les versions exactes du client et du backend sans mélanger les instructions de canaux de publication différents.

Évaluez l’interaction de bureau avec une petite tâche réelle. Ouvrez un projet, confirmez le serveur, envoyez une requête limitée, inspectez les fichiers modifiés et demandez une correction. Évaluez l’effort nécessaire pour comprendre les actions de l’agent. Ne supposez pas qu’un client graphique remplace complètement votre éditeur et votre débogueur.

Configuration et accès au modèle #

OpenCode fusionne la configuration de plusieurs emplacements. La référence de configuration explique la priorité et la conservation des réglages sans conflit. Comparez le modèle, l’agent et les permissions effectifs, pas seulement un fichier de projet.

L’accès au fournisseur fait partie de la configuration d’exécution. Le guide des fournisseurs décrit les services pris en charge et les endpoints compatibles. Les identifiants, l’accessibilité de l’endpoint et le support des outils du modèle comptent. Un serveur distant doit avoir son propre accès valide au fournisseur et au dépôt.

Le client ne fixe pas votre coût total d’inférence. Comparez l’utilisation facturée avec des modèles et tâches identiques. Incluez les exécutions répétées causées par les erreurs de configuration. Pour l’inférence locale, notez la mémoire système, le format du modèle, la taille du contexte et les réglages du runtime. Ne présentez pas un téléchargement de bureau comme un remplacement gratuit du calcul hébergé.

Sessions et changement sûr #

Vérifiez la continuité au lieu de la supposer. Notez le projet et la session actifs avant de changer de client. Vérifiez que la destination se connecte au serveur prévu et affiche l’historique prévu. Si vous démarrez une nouvelle session, transmettez brièvement l’objectif, le travail achevé et les contrôles restants.

Évitez les modifications simultanées dans un checkout. Deux conversations aux plans différents partagent les fichiers si elles visent le même répertoire. Utilisez des worktrees ou checkouts séparés pour les essais indépendants. Examinez les changements avant intégration.

Handover record
Goal:
Current branch and working directory:
Files changed:
Checks already completed:
Known failures:
Next approved action:

Cette fiche rend le transfert vérifiable. Elle aide aussi à distinguer un problème d’interface d’une instruction manquante ou d’un écart d’environnement. Gardez les identifiants hors de la fiche.

Accès au serveur et permissions #

Traitez le serveur de l’agent comme un service d’exécution. La documentation du serveur décrit l’authentification facultative via OPENCODE_SERVER_PASSWORD. Configurez l’accès volontairement avant de connecter des machines. Un serveur d’agent accessible n’est pas un site statique inoffensif.

Examinez les permissions des outils séparément. Le guide des permissions définit les comportements allow, ask et deny. Appliquez la même politique pendant l’essai de l’interface. Ne considérez pas un client qui pose moins de questions comme plus sûr ou plus capable sans vérifier les règles effectives.

Commencez par un test de politique sans danger. Demandez une inspection autorisée et une modification interdite dans un projet jetable. Vérifiez le comportement observé, puis passez à une implémentation limitée. L’hypothèse de permissions devient ainsi testable.

Dépannage et choix #

Choisissez le terminal si les requêtes scriptées et le contexte shell facilitent le travail. Choisissez Desktop si la navigation graphique du projet améliore votre supervision. Séparez les décisions de fournisseur et de politique de cette préférence.

Étapes suivantes : Comparez les alternatives terminal dans le résumé CLI . Pour les besoins d’inférence locale, lisez le guide OpenCode et Strata . Pour les alternatives graphiques, utilisez le résumé GUI .