Nanocoder contre OpenCode : flux de travail, modèles et coût total

OpenCode est la réponse par défaut, et Nanocoder le choix délibéré d’une minorité : le 19 septembre 2026, OpenCode comptait 208 444 étoiles GitHub contre 2 487 pour Nanocoder, et son paquet npm avait été téléchargé 9 436 914 fois au cours des 30 jours précédant le 16 septembre, contre 6 614 pour Nanocoder. Les deux sont des agents de programmation en terminal gratuits, sous licence MIT, qui permettent de cibler un point de terminaison API personnalisé. Le choix entre eux n’est pas un classement de qualité : c’est le choix entre la surface la plus large, avec deux produits officiels en concurrence pour vos dépenses de jetons, et une surface plus restreinte gérée par un collectif qui ne vend rien.

Considérez ces chiffres de téléchargement comme des ordres de grandeur plutôt que comme un nombre d’utilisateurs. OpenCode s’installe également via un script curl et Homebrew, et les exécuteurs CI gonflent tout chiffre npm, tandis que Nanocoder est aussi distribué par Homebrew et Nix en dehors de npm. Le ratio est solide dans ses grandes lignes ; les chiffres absolus ne le sont pas.

Commencez par vous assurer que vous comparez bien les deux projets concernés

Trois collisions de noms apparaissent directement dans les résultats de recherche pour cette comparaison, et deux d’entre elles feront échouer une configuration au lieu de simplement vous induire en erreur.

Un autre changement mérite d’être connu avant de suivre un ancien tutoriel. Le dépôt que de nombreux guides appellent encore sst/opencode redirige désormais via une redirection 301 vers anomalyco/opencode, et l’organisation GitHub sst est vide, avec une description indiquant qu’elle a été transférée vers anomalyco (API GitHub, 19 septembre 2026). La propre documentation d’OpenCode le confirme dans les commandes d’installation — brew install anomalyco/tap/opencode, ghcr.io/anomalyco/opencode — et toutes les pages de documentation portent un pied de page indiquant le copyright d’Anomaly. Le nom du produit n’a pas changé, seule l’organisation a changé. Une date de renommage circule sur les réseaux sociaux ; elle n’a pas pu être vérifiée ici et n’est donc pas publiée sur cette page.

Qui devrait choisir lequel

Partez de votre modèle par défaut, pas de la liste des fonctionnalités. Si votre journée repose déjà sur un modèle avancé hébergé et que l’inférence locale reste une expérimentation occasionnelle, la position d’OpenCode correspond à la vôtre. Si votre journée repose sur Ollama, llama.cpp, LM Studio, vLLM ou MLX et qu’une API hébergée constitue l’exception, celle de Nanocoder vous correspond — même s’il s’agit d’une différence de valeur par défaut, et non de capacité, car OpenCode documente également les URL de base d’Ollama, LM Studio et llama.cpp.

Le coût de migration est symétrique et faible au niveau du fournisseur, mais asymétrique au-dessus. Un point de terminaison personnalisé tient dans un bloc JSON dans les deux clients, si bien que déplacer une passerelle prend quelques minutes. En revanche, ce que vous avez construit par-dessus ne se transpose pas : les bundles de skills Nanocoder sous .nanocoder/skills/ et ses hooks de cycle de vie — lorsqu’un hook pre-tool-use se termine avec un code différent de zéro, il refuse l’appel et en explique la raison au modèle — n’ont aucun équivalent OpenCode dans lequel les copier, tandis que les blocs d’autorisations par agent, les plugins et la configuration LSP d’OpenCode n’ont aucun équivalent Nanocoder. Évaluez ce travail avant de compter les lignes de configuration.

Les différences réelles entre les deux clients

Sources de ce tableau, toutes consultées le 19 septembre 2026 sauf indication contraire : l’API GitHub, le registre npm, les documentations de configuration et de fonctionnalités de Nanocoder, ainsi que les pages configuration, autorisations et CLI d’OpenCode.

Diriger l’un ou l’autre vers votre propre point de terminaison d’API

Les deux documentent un point de terminaison personnalisé ; une passerelle est donc une configuration prise en charge dans les deux cas. La différence réside dans le nombre de formats filaires accessibles.

OpenCode nomme un package npm dans le bloc du fournisseur, et ce choix sélectionne le protocole : @ai-sdk/openai-compatible utilise /v1/chat/completions, tandis que @ai-sdk/openai utilise /v1/responses. Kunavo fournit les deux, il s’agit donc d’un véritable choix et non d’une formalité.

{
  "$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-4-6": {
          "name": "Claude Sonnet 4.6",
          "limit": { "context": 200000, "output": 64000 }
        }
      }
    }
  }
}

Deux détails explicitement indiqués sur la page des fournisseurs et importants pour tout point de terminaison qu’il ne connaît pas déjà. Premièrement, enregistrez la clé avec /connect, faites défiler jusqu’à Other et utilisez le même identifiant de fournisseur que celui du fichier ; les identifiants sont enregistrés dans ~/.local/share/opencode/auth.json. Deuxièmement, le bloc limit mérite d’être défini ici — la documentation indique que les fournisseurs standard récupèrent automatiquement les limites de contexte et de sortie depuis models.dev, et que Kunavo n’en fait pas partie. Les valeurs du bloc ci-dessus sont les chiffres de l’exemple fourni par la documentation, et non les limites publiées de ce modèle ; définissez-les à partir de la propre page du modèle avant de vous fier à l’indicateur de contexte.

L’équivalent de Nanocoder se trouve sous nanocoder.providers. Notez le baseUrl en minuscules, qui diffère du baseURL d’OpenCode, ainsi que la substitution ${VAR} appliquée récursivement aux champs de type chaîne.

{
  "nanocoder": {
    "providers": [
      {
        "name": "Kunavo",
        "sdkProvider": "openai-compatible",
        "baseUrl": "https://api.kunavo.com/v1",
        "apiKey": "${KUNAVO_API_KEY}",
        "models": ["claude-sonnet-4-6"],
        "contextWindow": 200000
      }
    ]
  }
}

Trois pièges propres à Nanocoder méritent d’être lus avant de coller ce bloc. L’union sdkProvider est limitée à cinq valeurs dans source/types/config.ts — openai-compatible, google, anthropic, chatgpt-codex et github-copilot — et la quatrième est reliée à une connexion via navigateur au point de terminaison Codex propre à ChatGPT, plutôt qu’à une URL de base arbitraire ; il n’existe donc aucune option Responses générique à déclarer. Si vous dirigez plutôt sdkProvider: "anthropic" vers un point de terminaison compatible avec Anthropic, la propre documentation des fournisseurs de Nanocoder avertit que @ai-sdk/anthropic déduit la limite de sortie de l’identifiant du modèle et revient à 4096 tokens pour tout ce qu’il ne reconnaît pas comme un modèle Claude, tronquant les longues réponses en plein milieu d’une phrase sans erreur ; la solution consiste à définir explicitement maxOutputTokens dans l’entrée du fournisseur. Et comme les paramètres sont résolus bloc par bloc, un fichier au niveau du projet qui définit nanocoder.providers fournit l’intégralité de ce bloc — les entrées sœurs de votre configuration globale ne sont pas fusionnées. nanocoder config diff est la méthode documentée pour voir ce qui a effectivement été résolu.

Aucun des deux extraits n’a été testé à l’exécution avec le point de terminaison de Kunavo. Kunavo publie un guide de configuration pour OpenCode, qui constitue une référence de configuration plutôt qu’un test de compatibilité, et n’en publie aucun pour Nanocoder. Considérez les deux blocs comme des points de départ, exécutez une tâche limitée et consultez ce que votre compte a effectivement enregistré.

Une lacune commune : aucun des deux clients ne connaît les métadonnées des modèles de votre passerelle

Les deux clients s’appuient sur models.dev pour les limites de contexte, les plafonds de sortie et le coût par token. Ce fichier répertoriait 222 fournisseurs lors de sa vérification le 19 septembre 2026, et Kunavo n’en faisait pas partie — cette page ne peut pas établir la raison de cette absence. La conséquence diffère légèrement selon le client, mais s’applique également aux deux ; ce n’est donc pas une raison de préférer l’un à l’autre.

Dans OpenCode, déclarez limit.context et limit.output pour chaque modèle, sinon l’indicateur de contexte restant établit son budget à partir d’une valeur par défaut qui n’est pas celle de votre modèle. Dans Nanocoder, définissez contextWindow ou contextWindows par modèle ; son pied de réponse affiche un nombre de tokens et un coût estimé calculé à partir de models.dev, et sa documentation précise que le segment de coût est omis lorsqu’aucun tarif n’est disponible : un nombre manquant signifie donc inconnu, et non zéro. Dans tous les cas, le chiffre du client correspond à son propre calcul sur les tokens déclarés — rapprochez-le du relevé de votre fournisseur, et non du pied de page.

Ce que chacun vous coûte

Les deux clients sont gratuits. L’asymétrie réside dans ce qui se trouve derrière eux.

Nanocoder n’a ni compte, ni offre, ni service hébergé, ni formule supérieure — son README indique qu’aucune offre payante ne bloque les fonctionnalités utiles, et le projet se décrit comme financé par des sponsors plutôt que par les utilisateurs. Une précision s’impose ici : Atlas Cloud figure parmi les sponsors, apparaît également dans la propre liste de fournisseurs pris en charge par Nanocoder et vend une formule de codage. Il s’agit d’un intérêt non neutre dans un projet par ailleurs indépendant de tout fournisseur, et vous devez le savoir.

OpenCode est également gratuit, mais le même fournisseur vend deux produits qui se disputent exactement les dépenses qu’une passerelle cherche à capter. Aucun des deux n’est obligatoire : la documentation les décrit comme facultatifs, et la page des objectifs de Zen s’engage à vous laisser utiliser n’importe quel autre fournisseur avec OpenCode.

Consulté le 19 septembre 2026. Deux points auxquels ce tableau prête attention. La page des objectifs de Zen indique l’intention de répercuter les baisses de prix en vendant au prix coûtant, avec une majoration limitée aux frais de traitement. Les trois tarifs Claude qu’il publie correspondent bien aux tarifs publiés par Anthropic pour ces modèles — Opus 5 à 5 $ / 25 $, Sonnet 5 à 2 $ / 10 $, Haiku 4.5 à 1 $ / 5 $ — ; pour ces trois modèles, comparer Zen revient donc à comparer la grille tarifaire du fournisseur du modèle. Cette vérification n’a été effectuée que pour ces trois modèles, le 19 septembre 2026, et ne dit rien du reste de la gamme de Zen. Par ailleurs, les modèles gratuits de Zen comportent des mentions d’utilisation des données affichées sur la même page, allant de l’utilisation des données pour améliorer le modèle pendant une période gratuite à des points de terminaison réservés aux essais qui vous demandent de ne pas envoyer de données confidentielles. Une offre gratuite assortie de droits d’entraînement est un produit différent d’une offre gratuite qui n’en comporte pas.

Une estimation détaillée de la facture de tokens sous-jacente à l’un ou l’autre client

Il s’agit d’un calcul illustratif de tokens, et non du coût mesuré d’une tâche ni d’un plafond de facturation. Supposons une session qui envoie 200,000 tokens d’entrée non mis en cache et reçoit 15,000 tokens de sortie. Les tarifs proviennent du catalogue Kunavo actuel, par million de tokens ; vos sessions réelles varieront selon la taille du dépôt, la sortie des outils et la fréquence à laquelle l’agent relit les fichiers.

La comparaison que les utilisateurs veulent réellement ici est celle avec les 10 $ mensuels d’OpenCode Go, et elle n’est pas strictement équivalente. Go propose une gamme fixe assortie de plafonds mensuels de 15 $ à 60 $ par modèle : son propre tableau des limites d’utilisation ne répertorie aucun modèle Claude ni Gemini, son unique entrée GPT est GPT 5.6 Luna, et Grok 4.6 y figure également — l’expression « modèles de codage ouverts » de la documentation ne signifie donc pas uniquement des poids ouverts (vérifié le 19 septembre 2026). Les modèles ci-dessus appartiennent à une gamme entièrement différente. Selon ces hypothèses, 10 $ de crédit prépayé Kunavo correspondent approximativement à 51 sessions de ce type sur Claude Haiku 4.5 à $0.192 chacune, et à environ 10 sur Claude Opus 5. Cela dimensionne un budget ; cela ne vous indique pas lequel produit le meilleur travail sur votre dépôt, et le tarif affiché le plus bas ne répond pas à la même question que le coût minimal pour terminer la tâche — un modèle moins cher qui nécessite trois tentatives peut coûter plus cher qu’un modèle qui n’en nécessite qu’une.

La comparaison strictement équivalente est celle avec la gamme de paiement à l’usage de Zen, où le même modèle apparaît des deux côtés. Zen publie Claude Opus 5 à 5.00 $ par million de tokens d’entrée et 25.00 $ par million de tokens de sortie ; le catalogue de Kunavo affiche actuellement $3.50 et $17.50 pour ce même modèle. C’est la comparaison qui mérite d’être faite, et elle mérite d’être lue attentivement : les 5.00 $ / 25.00 $ de Zen correspondent au tarif publié par Anthropic pour ce modèle ; il s’agit donc de deux catalogues tarifant différemment le même modèle, et non d’un revendeur gonflant ses prix puis se faisant dépasser. Confirmez les deux tarifs au moment du paiement avant de déplacer un budget, car l’un ou l’autre catalogue peut modifier ses prix.

Le montant du catalogue Kunavo constitue un plancher de facturation plutôt qu’un plafond : lorsque le fournisseur amont signale son coût, la facture correspond au montant le plus élevé entre le coût du 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é, ce qui constitue un minimum de financement, et non des frais de tâche ou un abonnement.

Configurer celui que vous avez choisi

Si vous avez choisi OpenCode, le bloc de configuration ci-dessus constitue l’intégralité de l’intégration et le guide d’intégration OpenCode couvre les deux formats filaires en détail ; créez un compte Kunavo lorsque vous êtes prêt à approvisionner une clé. Si vous avez choisi Nanocoder, utilisez la même URL de base via son fournisseur openai-compatible et gardez une route fonctionnelle disponible pendant vos essais — aucun test d’exécution Nanocoder-Kunavo n’a été effectué ici.

Vous hésitez encore ? Les alternatives à OpenCode élargissent le champ au-delà de ces deux options, la meilleure API pour OpenCode compare les routes de fournisseurs spécifiquement pour ce client, les tarifs d’OpenCode approfondissent Zen et Go, et l’annuaire des API d’agents indique comment chaque client de cet espace gère une URL de base personnalisée. Si un bloc de fournisseur échoue déjà, Fournisseur OpenCode introuvable couvre la cause habituelle, et API compatible OpenAI explique ce que cette expression garantit ou non.

Questions fréquentes

Les chiffres relatifs au dépôt, aux versions et aux téléchargements ont été relevés dans l’API GitHub et le registre npm le 19 septembre 2026 ; les affirmations concernant le comportement et les tarifs proviennent de la documentation des deux projets consultée à la même date, tout comme la liste des fournisseurs de models.dev. Aucun des deux clients n’a été testé à l’exécution avec le point de terminaison de Kunavo, aucun test de performance ou de compatibilité n’a été effectué, et chaque montant en dollars indiqué pour Kunavo sur cette page correspond à un calcul illustratif de tokens fondé sur le catalogue actuel, et non au coût mesuré d’une tâche.