Tarifs de Nanocoder : la CLI gratuite, la facture du modèle et le pied de page des coûts

Nanocoder est gratuit : la CLI est sous licence MIT, ne nécessite ni compte, ni niveau d’abonnement, ni clé de licence ; en pratique, « tarification de Nanocoder » désigne donc la facture du modèle sous-jacent — les tokens au tarif du fournisseur que vous configurez, ou le matériel et l’électricité pour un modèle local. Le nombre affiché dans votre terminal n’est pas cette facture. Nanocoder tarife chaque réponse à partir d’une base de données tierce qui ne contient aucune entrée pour votre passerelle, et cette page reproduit exactement l’effet de cette base sur le chiffre.

Commençons par une clarification, car les résultats de recherche mélangent plusieurs choses. Cette page concerne Nano-Collective/nanocoder, publié sous le nom @nanocollective/nanocoder et documenté à l’adresse docs.nanocollective.org/nanocoder. Notez le r final. Un projet distinct appelé nanocode — un agent de programmation pour NanoGPT — ainsi que NanoGPT lui-même, qui vend des tokens et publie une véritable liste de prix sur nano-gpt.com et nanogpt.net, et une société polonaise de logiciels utilisant le nom Nanocoder apparaissent tous dans ces recherches. Aucun de leurs prix ne doit figurer sur cette page.

Ce que Nanocoder facture, et ce qui vous est réellement facturé

L’installation est gratuite par tous les parcours documentés et ne nécessite aucun compte : npm install -g @nanocollective/nanocoder, ou Homebrew, ou Nix. Le registre npm indique 1.30.0 comme latest, publié le 26 août 2026, avec engines.node >= 22 et "license": "MIT" (registre consulté le 21 septembre 2026 — aucune version plus récente n’avait été publiée à cette date).

Le projet est financé par des dons et du sponsoring plutôt que par les utilisateurs, et une information doit être précisée ici car elle influence les conseils que vous lirez ailleurs : Atlas Cloud est un sponsor listé dans le README de Nanocoder, qui contient également un lien vers sa « promotion de formule de programmation » pour un « accès API plus économique ». Cette recommandation figure dans un document que le sponsor contribue à financer ; elle ne prouve pas que la formule est la moins chère. Ces formules de programmation sont des abonnements mensuels assortis d’une allocation hebdomadaire de points ; les points sont consommés comme le nombre de tokens d’entrée multiplié par un multiplicateur d’entrée, plus le nombre de tokens de sortie multiplié par un multiplicateur de sortie, les multiplicateurs étant définis pour chaque modèle. Le coût par million de tokens dépend donc du modèle exécuté et ne constitue pas un nombre unique à placer à côté d’une grille tarifaire.

Le chiffre de coût affiché dans votre terminal n’est pas votre facture

La version 1.30.0 a ajouté sous chaque message de l’assistant un pied de page affichant, par exemple, Tokens: 4.2k | ~$0.01. C’est le nombre qui semble le plus utile à l’écran et le plus facile à mal interpréter, car Nanocoder ne demande jamais à votre fournisseur ce qu’il facture.

Voici le mécanisme, tel qu’il apparaît dans le code source publié au tag v1.30.0. Les tarifs proviennent de models.dev/api.json. La recherche prend votre identifiant de modèle et, dans son propre commentaire, parcourt « tous les fournisseurs en sélectionnant la correspondance ayant la limite de contexte la plus élevée » — le fournisseur que vous avez configuré n’est donc jamais consulté ; seul l’identifiant est utilisé. Lorsque ce fichier a été récupéré le 21 septembre 2026, il répertoriait 223 fournisseurs et aucune entrée pour Kunavo. Un identifiant servi par Kunavo correspond donc à l’entrée sans rapport qui porte par hasard la même chaîne et déclare la fenêtre de contexte la plus grande.

En rejouant exactement cet algorithme sur ce fichier, pour une session supposée de 200 000 tokens d’entrée et 15 000 tokens de sortie, on obtient l’écart ci-dessous. L’estimation du catalogue correspond au calcul du catalogue Kunavo ; la dernière colonne indique le total que le pied de page de Nanocoder afficherait pour les mêmes tokens.

Deux échecs différents, issus d’une seule recherche. Lorsque l’entrée gagnante publie un tarif plus élevé, le pied de page surestime. Lorsqu’elle publie des zéros, ou aucun bloc cost du tout, le pied de page n’affiche rien — et l’absence de coût se lit comme la gratuité. Cette dernière étape est intentionnelle dans le code livré : un bloc de coût manquant est converti en tarif nul plutôt qu’en « inconnu », et le formateur du paquet publié ne renvoie rien pour un coût inférieur ou égal à zéro afin que « les modèles gratuits/locaux n’affichent aucun segment de coût plutôt que “$0.00” ». Cette logique est correcte pour un modèle local et erronée pour un modèle payant dont l’identifiant entre en collision avec une entrée d’annuaire à prix nul.

Deux autres distorsions s’ajoutent. models.dev publie des paliers tarifaires pour les longs contextes de certaines entrées ; le client livré ne copie que les tarifs forfaitaires input et output de chaque entrée et ne lit jamais les paliers, si bien qu’un tour dépassant le seuil d’un palier est sous-estimé. De plus, le changelog de la version 1.30.0 indique lui-même que l’estimation « tarife tous les tokens d’entrée au tarif standard — les remises de lecture/écriture du cache ne sont pas prises en compte, de sorte que les coûts peuvent être surestimés pour les fournisseurs offrant la mise en cache des prompts ». Consultez mise en cache des prompts pour voir à quoi ressemblent ces remises lorsqu’un parcours les prend en charge.

Les tarifs de ce tableau sont un instantané : models.dev est modifié en continu, et l’entrée gagnante du départage par le contexte le plus élevé peut changer sans qu’aucun élément de votre machine ne change. La reproduction est courte : récupérez api.json, trouvez chaque fournisseur portant votre identifiant de modèle exact, conservez celui dont le limit.context est le plus grand, puis lisez son bloc cost. Le relevé de votre fournisseur est le chiffre faisant autorité ; consultez les détails de facturation.

Ce qui est livré et ce qui se trouve uniquement sur la branche de développement

Cette distinction détermine si plusieurs correctifs cités existent réellement sur votre machine. /latest/ et /v1.30.0/ sur le site de documentation diffusaient tous deux du contenu v1.30.0 lors de la vérification du 21 septembre 2026 ; le répertoire docs/ du dépôt sur main est en avance sur les deux.

Chaque « Non » ci-dessus a été vérifié en recherchant dans la page publiée plutôt que déduit, et la page du fournisseur Anthropic constitue le contrôle de cohérence : aucune occurrence de « Prompt caching » ni de « cache-aware », tandis que le même HTML contient sdkProvider à six reprises. Il s’agit d’absences réelles, et non d’un artefact de rendu. Le travail intégré sur main après la publication du 26 août ajoute tous ces éléments — une citation vers un fichier sur main décrit donc un logiciel que vous ne pouvez pas encore installer, et une version plus récente modifierait plusieurs de ces lignes.

Meilleur modèle pour Nanocoder : une question de capacités, pas un classement

Nanocoder ne publie aucun modèle recommandé, aucun classement et aucune spécification matérielle. Une lecture complète de sa documentation le 21 septembre 2026 n’a révélé aucune RAM minimale, aucune valeur de VRAM ni aucun GPU recommandé, et le répertoire benchmarks/ du dépôt est un rapport de qualité sur la CLI compilée — codes de sortie, nombre de modules, temps approximatifs de démarrage et de premier rendu, taille du bundle — plutôt qu’un élément qui évalue un modèle. Aucun benchmark de tâche n’a été exécuté ici non plus ; cette page ne publie donc aucun classement — un classement fabriqué à partir de rien vaut moins que l’absence de classement.

Ce que le fournisseur publie est de toute façon mieux adapté à une page consacrée au budget, car cela modifie ce que le modèle peut faire plutôt que son score. Le profil d’outils auto par défaut, selon la documentation tune v1.30.0, « conserve toute la surface d’outils pour les modèles cloud et les identifiants de modèle sans indication de taille, résout les modèles jusqu’à 15B paramètres vers minimal et les modèles jusqu’à 4B paramètres vers nano ».

Deux lectures pratiques. Premièrement, la documentation précise que « les outils MCP ne sont exposés que dans le profil full résolu » : connecter un serveur MCP à un petit modèle local ne sert donc à rien tant que vous ne changez pas manuellement de profil ou ne passez pas à un modèle plus grand. Deuxièmement, le préréglage intégré « Nano (matériel bas de gamme) » limite max tokens à 2048, ce qui constitue une véritable limite de longueur de réponse et non une indication. La propre battlemap de Nanocoder soutient que les modèles petits et anciens restent utilisables parce qu’il fournit trois parcours d’appel d’outils — appel de fonctions natif, solution de repli XML et solution de repli JSON, avec réparation pour les deux solutions de repli — mais il s’agit de l’affirmation du mainteneur et aucun taux de réussite n’est publié. Pour une vue plus large des compromis entre modèles, consultez la comparaison des modèles de programmation.

Local ou distant : deux budgets différents

Un utilisateur privilégiant le local n’est pas un acheteur d’API payante avec une facture plus modeste, et les traiter comme une seule catégorie produit de mauvais conseils dans les deux sens. La propre battlemap de Nanocoder indique que « si vous exécutez Nanocoder avec un modèle local, toute la boucle peut fonctionner avec zéro trafic réseau sortant », et que sept serveurs locaux — Ollama, llama.cpp, llama-swap, LM Studio, LocalAI, MLX Server et vLLM — sont documentés comme fournisseurs de premier ordre. Il s’agit de la position revendiquée par le projet, et non d’une mesure effectuée ici.

La déclaration honnête concernant le coût local est que personne n’en a publié. Nanocoder ne quantifie aucune exigence matérielle ; c’est donc à vous d’évaluer le capital et l’électricité. Deux comportements rendent l’écart visible plutôt que caché : le segment de coût est omis pour les modèles locaux et gratuits, et lors des exécutions sans interface, le bloc usage est « entièrement omis lorsque le fournisseur ne communique aucune télémétrie de tokens (cas fréquent avec les modèles locaux), de sorte qu’un bloc absent signifie “inconnu”, jamais “zéro” ».

Un piège à l’entrée. La page tarifaire d’Ollama indique que « l’exécution de modèles sur votre propre matériel est toujours illimitée », et la documentation du fournisseur Ollama de Nanocoder ne couvre que l’endpoint local, sans clé requise. Mais cette même page vend également des formules hébergées : Pro à $20 par mois avec $60 de crédits d’utilisation mensuels, Max à $100 avec $300, Team à $500 avec $1,000 partagés, ainsi qu’un niveau Enterprise personnalisé (vérifié le 21 septembre 2026). « Ollama est gratuit » est donc vrai pour le parcours local et faux pour le parcours hébergé. La documentation de l’endpoint compatible Ollama de Kunavo décrit la forme de cette API si vous passez de l’un à l’autre.

Une réserve concernant les frais de financement des passerelles, car c’est le point que l’on oublie. La FAQ d’OpenRouter indique qu’« il n’y a aucune majoration sur les tarifs d’inférence » et que des frais sont facturés « lorsque vous achetez des crédits », avec des frais supplémentaires pour l’utilisation de votre propre clé au-delà d’une allocation dépendant de la formule. Ces pourcentages varient selon le mode de paiement et la formule et sont renseignés sur cette page lors de son affichage ; aucun n’est donc cité ici — consultez le chiffre actuel lors de votre propre paiement. Les alternatives à OpenRouter et l’API compatible OpenAI présentent la comparaison plus généralement.

Budgétiser la partie consacrée aux tokens

La colonne « catalogue » du tableau ci-dessus fournit l’estimation à utiliser pour établir votre budget, et il s’agit d’un calcul illustratif fondé sur les tokens, et non d’un coût mesuré pour une tâche ni d’un plafond de facturation. Ce calcul repose sur une session comprenant 200,000 tokens d’entrée non mis en cache et 15,000 tokens de sortie aux tarifs en vigueur du catalogue, sans lecture du cache ni frais liés aux outils. Les sessions réelles varient selon la taille du dépôt, la fréquence à laquelle l’agent relit les fichiers et le volume de résultats d’outils réinjectés dans le contexte — et le profil d’outils présenté ci-dessus modifie les coûts supplémentaires par tour avant même que ces facteurs n’entrent en jeu.

Multipliez ce montant par le nombre de sessions que vous effectuez chaque jour avant de le considérer comme un budget. Selon ces hypothèses, les modèles Claude Haiku 4.5 permettent environ 51 sessions pour 10 $ de crédit, tandis que Claude Opus 5 en permettent environ 10, ce qui aide à dimensionner un portefeuille sans vous indiquer lequel achèvera votre travail. Le tarif affiché le plus bas et le coût total le plus faible pour terminer une tâche sont deux affirmations différentes : un modèle moins cher qui nécessite trois tentatives peut coûter plus cher qu’un modèle qui réussit en un seul passage. Optimisation des coûts de l’IA présente correctement cette méthode.

Le montant du catalogue Kunavo constitue un plancher de facturation plutôt qu’un plafond : lorsque le fournisseur en amont communique son coût, la facture correspond au plus élevé entre le coût du catalogue et le coût du fournisseur en 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é — il s’agit d’un minimum de financement, pas de frais de tâche ni d’un abonnement.

Configurer Nanocoder avec un point de terminaison personnalisé

Tout service compatible avec OpenAI est ajouté comme fournisseur personnalisé, soit de manière interactive via /settings providers, soit dans agents.config.json — d’abord le fichier du projet, puis un répertoire de configuration utilisateur propre à chaque système d’exploitation ; NANOCODER_CONFIG_DIR ignore les deux recherches et la variable d’environnement NANOCODER_PROVIDERS a la priorité absolue.

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

Trois remarques sur ce bloc, toutes issues de la documentation des fournisseurs v1.30.0. sdkProvider est omis, car sa valeur par défaut est openai-compatible ; les autres valeurs du tableau des options sdkProvider de cette version sont google, anthropic et github-copilot, tandis que chatgpt-codex est documenté sur sa propre page de fournisseur plutôt que dans ce tableau. Les clés et autres valeurs de configuration prennent en charge la substitution $VAR, ${VAR} et ${VAR:-default}. Enfin, requestTimeout vaut par défaut 120 000 ms, et -1 le désactive — ce qui compte bien davantage pour un modèle local lent que pour un modèle hébergé.

La fenêtre de contexte est l’élément le plus susceptible de vous coûter de l’argent si vous l’omettez. Nanocoder détermine la limite de contexte d’un modèle selon un ordre documenté en six étapes : une surcharge de session /context-max ou --context-max, puis contextWindows[model], puis contextWindow, puis NANOCODER_CONTEXT_LIMIT, puis les métadonnées de models.dev, et enfin une table de secours intégrée pour Ollama. Kunavo étant absent de models.dev, les deux dernières étapes ne peuvent pas aider ; l’une des quatre premières doit donc être définie manuellement — la valeur ci-dessus provient de l’entrée de catalogue Kunavo propre à ce modèle. Cela va au-delà d’un simple indicateur d’affichage : la compression automatique se déclenche à un pourcentage de la limite de contexte résolue, fixé par défaut à 60, de sorte qu’une limite incorrecte modifie la fréquence à laquelle l’agent compresse et renvoie le contexte, ce qui représente une dépense de tokens.

Encore un piège avant le premier lancement. Si vous définissez sdkProvider: "anthropic" pour un point de terminaison qui sert un identifiant de modèle que le SDK sous-jacent ne reconnaît pas comme un modèle Claude, celui-ci revient à une limite de sortie de 4096 tokens, tronquant les longues réponses au milieu d’une phrase sans générer d’erreur. Ce comportement est décrit sous « Limite de tokens de sortie » dans la documentation des fournisseurs sur main, et la limite elle-même provient de @ai-sdk/anthropic, dont v1.30.0 dépend déjà — le comportement est donc présent dans la version publiée, même si la documentation ne l’est pas. La correction indiquée sur cette page, maxOutputTokens, n’est pas encore publiée ; avec v1.30.0, la solution consiste à rester sur le chemin openai-compatible par défaut.

Kunavo publie un guide de configuration de Nanocoder, qui constitue une référence de configuration plutôt qu’un test de compatibilité : Nanocoder n’a pas été testé en conditions réelles avec le point de terminaison de Kunavo ; la diffusion en continu, les appels d’outils, l’authentification et le routage des modèles ne sont donc pas confirmés de bout en bout ici. Conservez une route fonctionnelle pendant vos essais, exécutez une tâche limitée, puis consultez le montant enregistré par votre compte plutôt que le pied de page. Créez un compte Kunavo lorsque vous serez prêt à créditer une clé.

Vous comparez les clients plutôt que les routes ? Nanocoder ou OpenCode oppose cet agent au client grand public, Tarifs d’OpenCode couvre un client dont le mainteneur vend effectivement des tokens, et le répertoire des API d’agents indique comment chaque client de cet espace gère une URL de base personnalisée.

Questions fréquentes

Vérifié le 21 septembre 2026 : le registre npm pour la version publiée, les moteurs et la licence ; les pages de documentation v1.30.0 consacrées aux fournisseurs, commandes, réglages et battlemap, y compris les comptages grep pour les fonctionnalités absentes ; le journal des modifications v1.30.0 et le code source publié pour la formule de coût et la recherche dans models.dev ; le propre formateur de coûts du paquet distribué ; models.dev/api.json pour la liste des fournisseurs et les tarifs repris ci-dessus ; la version de @ai-sdk/anthropic dont dépend v1.30.0, pour la limite de 4096 tokens ; la page tarifaire d’Ollama ; la page consacrée aux forfaits de programmation d’Atlas Cloud ; et la FAQ d’OpenRouter. Le volume de recherche pour les requêtes cibles de cette page n’a pas été mesuré dans l’étude qui la sous-tend, et les instantanés des résultats de recherche sous-jacents datent du 17 septembre 2026. Nanocoder n’a pas été testé en conditions réelles avec Kunavo, aucun benchmark de modèle n’a été réalisé, et chaque montant en dollars de Kunavo indiqué ici correspond à un calcul illustratif de tokens fondé sur le catalogue actuel, et non au coût mesuré d’une tâche.