VT Code vs OpenCode : flux de travail, modèles et coût total

VT Code et OpenCode sont tous deux des agents de codage gratuits dans le terminal : aucun ne facture le client et tous deux acceptent votre propre endpoint compatible avec OpenAI ; il ne s’agit donc pas d’une comparaison de prix. Les vraies différences résident dans l’endroit où chacun vous permet de déclarer cet endpoint, l’orientation des paramètres d’autorisation par défaut et la question de savoir si vous souhaitez un abonnement à 10 $ par mois dans la même interface. VT Code est un binaire Rust unique issu d’un projet indépendant dirigé par un seul mainteneur. OpenCode est un agent TypeScript de l’entreprise Anomaly, avec une application de bureau, des extensions d’éditeur et deux portefeuilles propriétaires.

Deux pièges liés aux noms doivent d’abord être écartés, car se tromper sur l’un ou l’autre invalide tout ce qui suit. « VT Code » n’est pas Visual Studio Code, et VT Code fournit, de manière déroutante, sa propre extension compagnon pour VS Code, avec une série de versions distincte. Et trois choses différentes s’appellent OpenCode — une seule figure dans cette comparaison.

Ce que vous comparez réellement

Métadonnées des dépôts, versions et dist-tags lus depuis l’API GitHub, npm et crates.io le 21 septembre 2026. Une quatrième collision : « OpenCode Go » est également le nom de l’abonnement à 10 $ par mois d’Anomaly, qui n’a rien à voir avec le langage Go ni avec le CLI Go archivé — et VT Code aggrave la confusion en donnant à l’une de ses clés de fournisseur intégrées le nom opencode-go. Notez également la vitesse à laquelle la version de VT Code évolue : 0.164.0, 0.164.2 et 0.165.0 sont toutes sorties en environ 27 heures, les 20 et 21 septembre ; consultez donc le tag plutôt que de faire confiance à une version imprimée sur une page, y compris celle-ci.

Qui devrait choisir lequel

Concernant le coût de migration. La moitié bon marché est AGENTS.md : les deux outils le lisent à la racine du projet, de sorte que le fichier décrivant vos conventions survit intact à un changement dans un sens comme dans l’autre. La moitié coûteuse est tout le reste. Les deux formats de configuration sont disjoints — TOML avec des tableaux de tables contre JSON nommant un paquet npm par fournisseur — et il n’existe aucun convertisseur ; une configuration locale au projet doit donc être réécrite à la main. Cette page n’a pas établi si les définitions MCP, les compétences, les plugins, les agents personnalisés ou l’historique des sessions sont transférés ; elle ne fournit donc aucune estimation du temps de migration au-delà de cette réécriture.

La seule asymétrie qui mérite de guider la décision : où l’endpoint peut résider

C’est la différence que les modèles génériques ne mentionnent jamais, et elle inverse l’instinct habituel concernant les monorepos. OpenCode traite un fournisseur personnalisé comme une donnée de projet ordinaire : un opencode.json versionné fonctionne, ce qui permet à une équipe d’imposer la même passerelle à tous dans un seul fichier révisé. VT Code refuse délibérément cette approche.

La référence des champs de configuration de VT Code l’énonce directement dans le champ : « Les valeurs non vides provenant de couches d’espace de travail/projet contrôlées par le dépôt sont rejetées ; définissez les endpoints des fournisseurs dans la configuration système/utilisateur approuvée ou explicitement sélectionnée. » Le même rejet est répété pour custom_providers[].base_url, custom_providers[].auth.command, ainsi que pour provider_overrides.*.base_url et .api_key_env. Son modèle de sécurité présente ce raisonnement comme une couche distincte — le chargeur enregistre l’origine gagnante de chaque champ fusionné, considère les fichiers à la racine de l’espace de travail, les fichiers .vtcode/ de l’espace de travail et les profils de projet comme contrôlés par le dépôt, puis échoue de manière fermée avant la validation du fournisseur ; il indique que cela empêche un dépôt d’introduire le auth.command exécutable d’un fournisseur personnalisé ou de rediriger les requêtes via une URL de base remplacée.

La conséquence pratique est donc la suivante : avec OpenCode, une seule pull request fusionnée dirige toute l’équipe vers une passerelle. Avec VT Code, la même modification est une installation par machine dans la configuration utilisateur ou système, ou un chemin --config transmis au lancement. Il s’agit d’un véritable compromis — l’un privilégie la facilité de déploiement, l’autre le contrôle de la chaîne d’approvisionnement — et votre préférence constitue ici une raison plus solide de choisir un client que n’importe quelle liste de fonctionnalités. Les deux faits proviennent de main au 21 septembre 2026.

Autorisations, autonomie et interfaces fournies par chacun

Sources : référence des champs de configuration, modèle de sécurité et guide des fournisseurs de VT Code ; documentation OpenCode sur les autorisations, les fournisseurs, le serveur et l’ACP. Toutes consultées le 21 septembre 2026, et toutes décrivent des valeurs par défaut — chaque client peut être reconfiguré dans l’autre sens. Tous deux parlent ACP et prennent en charge MCP ; l’accès depuis l’éditeur est donc proche de la parité plutôt qu’un facteur de différenciation.

C’est le portefeuille, et non le client, qui reçoit l’argent

OpenCode vend deux produits qui lui sont propres. VT Code ne vend rien, ce qui constitue en soi un élément de décision : chaque token qu’il envoie est facturé par le fournisseur que vous avez configuré, et il n’existe aucun forfait propriétaire de secours.

Prix et quotas relevés dans la documentation officielle d’OpenCode le 21 septembre 2026. Deux points à connaître avant de les comparer. Go publie des conditions de données par modèle qui ne sont pas uniformes — la plupart des lignes indiquent que les données ne sont pas utilisées pour l’entraînement et une conservation nulle, tandis que quelques-unes mentionnent une conservation de 30 jours et que deux modèles de contributeurs sont indiqués comme utilisés pour l’entraînement et sans conservation nulle — vérifiez donc la ligne correspondant au modèle que vous comptez utiliser. Zen publie également des dépréciations datées ; une comparaison ancrée sur un seul identifiant de modèle peut donc devenir obsolète plus vite que la page elle-même. OpenCode Enterprise est un formulaire de contact sans prix publié, et cette page n’en cite aucun.

Ce que coûte une session sur votre propre endpoint

Les chiffres ci-dessous sont des calculs illustratifs de tokens, et non des coûts de tâches mesurés ni un plafond de facturation. Supposons une session d’agent qui envoie 200,000 tokens d’entrée non mis en cache et reçoit 15,000 tokens de sortie — une hypothèse de comparaison, pas une mesure de votre dépôt. Les tarifs sont les prix actuels du catalogue Kunavo par million de tokens ; la dernière colonne effectue simplement une division et hérite donc de toutes les hypothèses précédentes.

Comparez cette dernière colonne aux 10 $ par mois d’OpenCode Go, puis résistez à l’envie d’y voir un verdict. Les deux ne représentent pas la même unité : les plafonds de Go sont exprimés en dollars d’utilisation sur sa liste de modèles, et non en dollars que vous dépensez ; les deux catalogues ne se recouvrent que partiellement — GPT 5.6 Luna figure dans la liste publiée de Go, tandis que les lignes Claude et Gemini du tableau ci-dessus n’y figurent pas. Un abonnement achète également de la prévisibilité plutôt qu’un tarif. Ce que le tableau établit, c’est la nature de la question : si votre travail consiste en quelques longues sessions par semaine sur un modèle bon marché, les tokens facturés à l’usage sont plus avantageux ; s’il s’agit d’une utilisation intensive toute la journée sur des modèles effectivement proposés par Go, un forfait fixe cesse d’être manifestement moins bon. Mesurez vos propres sessions avant de choisir, car un modèle qui nécessite une deuxième tentative efface immédiatement tout avantage tarifaire.

Le montant du catalogue Kunavo constitue un plancher de facturation, pas un plafond : lorsque le fournisseur amont signale son coût, la facture correspond au montant le plus élevé entre le coût catalogue et le coût amont multiplié par la majoration applicable. Les frais de cache et les outils externes ne sont pas inclus dans cet exemple. Le rechargement minimal est de $10 de crédit prépayé — un minimum de financement, pas des frais de tâche ni un abonnement. Voir détails de facturation.

Diriger l’un ou l’autre vers votre propre endpoint

Du côté de VT Code, il s’agit d’un bloc [[custom_providers]], et la règle de placement de la section précédente est le point que les utilisateurs comprennent souvent mal :

# This block is rejected if it arrives from a repository-controlled
# layer. Put it in your user config, in the Unix system layer
# (/etc/vtcode/vtcode.toml), or pass it with --config / VTCODE_CONFIG_PATH.
[[custom_providers]]
name = "kunavo"
display_name = "Kunavo"
base_url = "https://api.kunavo.com/v1"
api_key_env = "KUNAVO_API_KEY"
api_format = "openai-chat"
model = "claude-sonnet-5"
models = ["claude-sonnet-5", "claude-haiku-4-5"]
context_window = 1000000   # omit this and VT Code assumes 128000

Quatre remarques sur ce bloc, toutes issues du guide des fournisseurs et de la référence des champs. La clé est lue depuis la variable d’environnement nommée dans api_key_env, et la documentation de configuration comporte une mise en garde explicite : ne mettez jamais de clés API dans vtcode.toml. api_format accepte auto, openai-chat, openai-responses ou anthropic-messages — une valeur explicite est respectée plutôt que remplacée silencieusement — et la route Anthropic mérite un examen distinct, car les deux conventions d’URL de base diffèrent, comme l’explique la référence de l’URL de base. Définir context_window est important : si vous l’omettez, le fournisseur est supposé disposer de 128 000 tokens, ce qui limite discrètement la compaction et les vérifications préalables dans un contexte beaucoup plus large. VT Code applique également des restrictions d’échantillonnage OpenAI fondées sur le nom aux endpoints personnalisés — un identifiant de modèle correspondant à gpt-6-astra, par exemple, ne reçoit jamais temperature ni top_p — et le guide conseille lui-même de « préférer des identifiants de modèles neutres sur les passerelles si vous avez besoin de valeurs épinglées pour ces noms ».

L’équivalent d’OpenCode est un fichier de données, et le champ npm sélectionne le format filaire — @ai-sdk/openai-compatible pour un endpoint qui fournit /v1/chat/completions, @ai-sdk/openai pour /v1/responses :

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "kunavo": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Kunavo",
      "options": {
        "baseURL": "https://api.kunavo.com/v1",
        "apiKey": "{env:KUNAVO_API_KEY}"
      },
      "models": {
        "claude-sonnet-5": {
          "name": "Claude Sonnet 5",
          "limit": { "context": 1000000, "output": 128000 }
        }
      }
    }
  }
}

OpenCode peut également remplacer le baseURL d’un fournisseur intégré plutôt que d’en déclarer un personnalisé ; sa documentation indique que les métadonnées des modèles pour les fournisseurs connus proviennent de Models.dev — un fournisseur déclaré manuellement doit donc fournir son propre limit — et les clés ajoutées via la commande /connect sont enregistrées dans ~/.local/share/opencode/auth.json. Kunavo publie une page de configuration pour ce client : le guide d’intégration OpenCode. Il n’existe pas ici de page d’intégration VT Code, et le bloc TOML ci-dessus est une référence de configuration assemblée à partir des définitions de champs documentées par VT Code — aucun des deux clients n’a été testé en conditions réelles avec Kunavo, et aucune compatibilité n’est revendiquée pour l’un ou l’autre. Conservez une route fonctionnelle, exécutez une tâche limitée et consultez le montant enregistré par votre compte avant de remplacer votre outil quotidien. Créez un compte Kunavo lorsque vous serez prêt à approvisionner une clé.

Un avertissement d’installation qui peut coûter beaucoup de temps. Le paquet npm public nommé vtcode n’est pas le VT Code actuel : son dist-tag latest était 0.52.8, publié le 24 décembre 2025, tandis que crates.io était en version 0.165.0 le 21 septembre 2026. La documentation d’installation de VT Code indique un autre chemin npm — npm install -g @vinhnx/vtcode --registry=https://npm.pkg.github.com — ainsi que cargo install vtcode et un dépôt Homebrew qui nécessite brew trust vinhnx/tap avant brew install vinhnx/tap/vtcode. Le même document précise que les artefacts Windows sont fournis au mieux et peuvent ne pas apparaître dans chaque version, tandis que la page d’installation d’OpenCode recommande WSL sous Windows — aucun des deux n’est donc un outil Windows de première classe selon sa propre documentation.

Vous comparez plus largement ? Crush vs OpenCode compare le même OpenCode à l’agent de Charm, les tarifs d’OpenCode approfondissent Zen et Go, et la référence de l’API compatible avec OpenAI couvre la convention d’endpoint sur laquelle reposent les deux clients.

Questions fréquentes

Vérifié le 21 septembre 2026 : l’API GitHub pour les trois dépôts, ainsi que la liste des versions de VT Code ; les dist-tags npm pour opencode-ai, @opencode/cli et vtcode ; l’enregistrement crates.io pour vtcode ; le README, le modèle de sécurité, le guide des fournisseurs, la référence des champs de configuration, la documentation d’installation et le manifeste de l’extension VS Code de VT Code sur main ; ainsi que les pages d’OpenCode consacrées aux autorisations, aux fournisseurs, au serveur, à Zen, à Go et au téléchargement. Les tarifs des tokens Kunavo proviennent du catalogue actuel. Aucun des deux clients n’a été installé, exécuté ou dirigé vers un endpoint Kunavo pour cette page ; aucun benchmark ni aucune comparaison de performances n’ont été réalisés, et rien de tel n’est revendiqué ; chaque montant en dollars présenté ici correspond à un calcul illustratif de tokens, et non au coût mesuré d’une tâche.