Nanobot contre OpenClaw : exécution, fournisseurs et coût d’exploitation

Choisissez nanobot si vous voulez un seul petit processus Python auto-hébergé avec un fichier de configuration JSON unique ; choisissez OpenClaw si vous avez besoin d'une passerelle soutenue par une fondation, avec davantage de canaux de chat, des environnements d'exécution d'agents sélectionnables et des rapports de dépenses fournis par le projet. Les deux sont sous licence MIT, auto-hébergés et gratuits au téléchargement ; la vraie décision porte donc sur l'environnement d'exécution que vous exploiterez, le bloc fournisseur que vous rédigerez manuellement et la cadence en arrière-plan pour laquelle vous paierez des tokens.

Versions vérifiées le 21 septembre 2026 : nanobot v0.3.5, publié le 15 septembre 2026, et OpenClaw v2026.9.5, publié le 19 septembre 2026. L'enregistrement npm d'OpenClaw comportait quatre publications dans les dix jours précédant cette vérification, sur ses lignes stable et extended-stable ; consultez donc le flux des versions et l'enregistrement npm plutôt qu'une version citée sur une page comparative, y compris celle-ci.

Commencez par vérifier quel nanobot vous installez

Cette page concerne HKUDS/nanobot, un framework d'assistant personnel Python du Data Intelligence Lab de l'Université de Hong Kong, dont la documentation se trouve sur nanobot.wiki. Deux homonymes proches orientent les acheteurs vers le mauvais logiciel :

• obot-platform/nanobot, sur nanobot.ai, est un projet Go distinct sous Apache-2.0 destiné à créer des agents MCP. Ses déclarations de fonctionnalités ne décrivent pas l'assistant de HKUDS.
• Le paquet PyPI nommé nanobot est une bibliothèque sans lien de navigation robotique. L'installation correcte est pip install nanobot-ai, version 0.3.5, sous MIT et Python 3.11 ou une version ultérieure selon la fiche PyPI. Le démarrage rapide propose également un script d'installation qui installe ou met à niveau le même paquet.

Il existe également des forks qui copient mot pour mot la description et la page d'accueil ; le guide de déploiement de nanobot avertit que les images Docker Hub publiées sous des espaces de noms tiers ne sont ni maintenues ni vérifiées par le projet. Ne leur transmettez donc pas de clés API ou de tokens de bot, sauf si vous faites confiance à l'éditeur. Pour OpenClaw, les surfaces officielles sont docs.openclaw.ai, openclaw.ai, openclaw.org et le dépôt GitHub ; si vous trouvez les clés de configuration ci-dessous ailleurs, comparez-les à ces sources, car une copie peut être obsolète précisément sur ces clés.

Qui devrait choisir lequel

Choisissez nanobot lorsque le flux de travail tient en une personne, une machine et un fichier de configuration. Toute sa configuration se trouve dans ~/.nanobot/config.json, avec des clés camelCase, et son état persistant réside dans un espace de travail d'agent — ~/.nanobot/workspace/ par défaut — sous la forme de SOUL.md, USER.md et memory/MEMORY.md, conformément à sa référence de la mémoire. Si vous voulez comprendre chaque élément avant de lui confier un compte de messagerie, une surface plus réduite constitue un véritable avantage. Son propre serveur compatible OpenAI en fait également un backend utile pour d'autres outils ; il est lié à 127.0.0.1 par défaut et refuse de démarrer sur 0.0.0.0 sans clé API.

Choisissez OpenClaw lorsque le flux de travail correspond à un déploiement exploité. Son catalogue des canaux répertorie 32 canaux, quelques-uns intégrés à l'installation principale et la plupart installés comme plugins officiels ou externes ; il sépare l'espace de travail de l'agent du répertoire d'état afin que vous puissiez déplacer l'un ou l'autre, et fournit un suivi de l'utilisation avec /status, /usage cost et openclaw status --usage. Il sépare également la référence du modèle de l'environnement d'exécution de l'agent, de sorte qu'un même déploiement puisse piloter côte à côte une route par clé API et une licence CLI fournisseur.

Concernant le modèle d'exécution et d'autorisations, prévoyez le même travail dans les deux cas. Chacun conserve une passerelle à longue durée d'exécution qui gère la remise en arrière-plan, et chacun transforme un endpoint personnalisé en décision de confiance explicite : OpenClaw traite un baseUrl personnalisé comme une autorisation de confiance réseau limitée à ce schéma, cet hôte et ce port ; les origines de métadonnées, link-local et NAT64 à usage local restent bloquées sans opt-in explicite, tandis que les autres plages privées ou CGNAT nécessitent request.allowPrivateNetwork: true, qui vaut par défaut false.

Sur le chemin des coûts, la différence tient à la visibilité, pas au prix. Les deux programmes sont gratuits. OpenClaw indique les tokens de session et un coût estimé pour les sessions par clé API, et masque les estimations en dollars par token pour les sessions facturées par forfait. La WebUI de nanobot affiche un graphique des tokens et du cache par tour et précise clairement que ces chiffres ne constituent pas un relevé de facturation ; sa référence CLI ne comporte aucune commande de dépenses agrégées. Les demandes ouvertes de suivi des coûts dans HKUDS/nanobot, issues n°1193 (dernière mise à jour le 25 février 2026) et n°2020 (dernière mise à jour le 16 mars 2026), sont toujours ouvertes — mais ne considérez pas leurs titres comme l'état actuel des fonctionnalités, car l'affichage par tour existe bien. Ce qui manque, c'est l'agrégation.

Pour le coût de migration, prévoyez une réécriture plutôt qu'un import. L'importateur de mémoire d'OpenClaw prend en charge Codex, Claude Code et Hermes, et aucun des deux projets ne documente d'importateur vers l'autre, dans quelque direction que ce soit. Les blocs fournisseurs, préréglages, identifiants de canaux, planifications et fichiers mémoire doivent tous être recréés manuellement.

Un point sur lequel aucun choix ne peut s'appuyer : il n'existe aucun benchmark commun et aucun des deux projets ne publie de chiffres sur la qualité des tâches. Le README de nanobot affirme disposer d'un « cœur petit et lisible », mais ne publie aucun nombre de lignes ; tout chiffre précis cité ailleurs ne constitue donc pas une affirmation du fournisseur. La taille du code ne permet de prédire la qualité des tâches dans aucun sens.

nanobot et OpenClaw en un coup d'œil

Le nombre d'étoiles mesure l'attention portée un jour donné, non la maturité ou le support, et les deux évoluent quotidiennement — consultez-les dans les deux dépôts plutôt que sur une page secondaire. Sur la ligne consacrée à la licence, un désaccord documenté existe : les métadonnées de l'API GitHub ne signalent aucune licence pour openclaw/openclaw, tandis que le fichier LICENSE contient le texte MIT sans clause de marque ou de dénomination, suivi uniquement d'un renvoi vers THIRD_PARTY_NOTICES.md. Lisez le fichier et confirmez-le vous-même avant de livrer quoi que ce soit construit dessus.

La configuration du fournisseur est la véritable différence

Les deux clients peuvent appeler un endpoint compatible OpenAI ou compatible Anthropic. Ils déterminent lequel de manière différente, et ce simple fait explique pourquoi une configuration fonctionnelle ne peut pas être transposée de l'un à l'autre.

nanobot décide selon la clé fournisseur que vous renseignez. Selon sa référence des fournisseurs, toute clé que vous inventez sous providers est traitée comme un fournisseur directement compatible OpenAI, apiBase est obligatoire puisque nanobot ne peut pas connaître l'URL de l'endpoint, et apiKey est facultatif. Pour une passerelle compatible Anthropic, vous devez conserver le fournisseur anthropic et remplacer son apiBase : la documentation précise que les noms de fournisseurs personnalisés arbitraires sont uniquement compatibles OpenAI et n'utilisent pas le format de requête Anthropic Messages. Il s'agit du principal piège de configuration de cette comparaison.

{
  "providers": {
    "kunavo": {
      "apiKey": "${KUNAVO_API_KEY}",
      "apiBase": "https://api.kunavo.com/v1"
    },
    "anthropic": {
      "apiKey": "${KUNAVO_API_KEY}",
      "apiBase": "https://api.kunavo.com"
    }
  },
  "modelPresets": {
    "openaiShaped": {
      "provider": "kunavo",
      "model": "claude-sonnet-5",
      "maxTokens": 1024
    },
    "anthropicShaped": {
      "provider": "anthropic",
      "model": "claude-sonnet-5",
      "maxTokens": 1024
    }
  },
  "agents": {
    "defaults": {
      "modelPreset": "openaiShaped"
    }
  }
}

Les noms comptent ici à deux niveaux. Évitez les collisions avec un nom intégré tel que openai, openai-codex, github-copilot ou lm-studio, et ne définissez pas apiType sur une clé personnalisée — ce champ est réservé à providers.openai. Avec un fournisseur personnalisé nommé explicitement, l'identifiant du modèle est envoyé tel quel ; model doit donc correspondre exactement à l'identifiant attendu par l'endpoint. Ce n'est que sous provider: "auto" qu'un préfixe correspondant est supprimé. Cette surcharge modifie directement le bloc fournisseur anthropic ; la passerelle remplace donc Anthropic direct dans chaque préréglage pointant vers ce fournisseur, au lieu de fonctionner à ses côtés. Notez également que les clés snake_case sont acceptées pour la compatibilité, mais que nanobot réécrit les clés en camelCase sur le disque.

OpenClaw décide à l'aide d'un champ. Sa référence des fournisseurs personnalisés regroupe tout dans un bloc uniforme sous models.providers, où api sélectionne l'adaptateur de requête. Cette référence répertorie onze valeurs, dont openai-completions, openai-responses, anthropic-messages, google-generative-ai, ollama et bedrock-converse-stream ; le schéma de configuration d'OpenClaw en v2026.9.7 en accepte une douzième, google-interactions, ajoutée le 25 septembre 2026 et documentée jusqu'à présent uniquement sur sa page du fournisseur Google. Un baseUrl sans api prend par défaut la valeur openai-completions.

{
  "models": {
    "mode": "merge",
    "providers": {
      "kunavo": {
        "baseUrl": "https://api.kunavo.com",
        "apiKey": "${KUNAVO_API_KEY}",
        "api": "anthropic-messages",
        "authHeader": true,
        "models": [
          {
            "id": "claude-sonnet-5",
            "name": "Claude Sonnet 5",
            "input": [
              "text"
            ],
            "contextWindow": 1000000,
            "maxTokens": 1024
          }
        ]
      }
    }
  },
  "agents": {
    "defaults": {
      "model": {
        "primary": "kunavo/claude-sonnet-5"
      }
    }
  }
}

L'ajout d'une référence de modèle sous agents.defaults ne suffit pas à l'enregistrer : une entrée correspondante portant le même id doit exister dans models.providers.<id>.models[]. Le 1024 ci-dessus est une limite de sortie volontairement réduite pour un premier essai, et non le maximum du modèle ; prenez contextWindow et maxTokens sur la page du modèle correspondant au modèle que vous acheminez. Kunavo n'a exécuté aucun des deux clients avec son endpoint — ces blocs sont tirés des propres références de configuration des deux projets au 21 septembre 2026 et nécessitent votre propre essai limité avant d'y déplacer un travail planifié.

Ce qu'un endpoint tiers ne peut pas atteindre

Les deux projets documentent des éléments précis qu’un point de terminaison personnalisé perd. Ce sont les aspects généralement omis par une comparaison des prix, et ils changent le coût réel d’une route bon marché. Les lignes nanobot proviennent de sa référence fournisseur liée ci-dessus ; les lignes OpenClaw proviennent de cette même référence de configuration ainsi que de sa page consacrée aux concepts des fournisseurs personnalisés, où le comportement de suppression des en-têtes est décrit.

Deux conséquences méritent d’être anticipées. Premièrement, sur une route OpenClaw compatible avec OpenAI vers un hôte non natif, les indices de mise en cache des invites côté client sont supprimés par conception, de même que service_tier, store et les en-têtes d’attribution ; la route anthropic-messages, elle, perd les en-têtes bêta implicites. Cela change ce que le client demande, et non, en soi, la mise en cache du point de terminaison — un point de terminaison qui met lui-même en cache peut toujours le faire, et la documentation d’OpenClaw ne dit pas le contraire. Ne supposez donc aucun des deux résultats : vérifiez l’utilisation renvoyée avant de budgétiser une tâche récurrente comme étant mise en cache. Notre guide de mise en cache des invites explique à quoi devraient ressembler les champs d’utilisation lorsque la mise en cache fonctionne.

Deuxièmement, dans OpenClaw, l’environnement d’exécution est aussi important que le fournisseur. La référence des environnements d’exécution résout l’environnement après la résolution du fournisseur et du modèle et permet d’en définir un par fournisseur avec models.providers.<provider>.agentRuntime : l’environnement intégré openclaw exécute lui-même le tour préparé, tandis que codex, claude-cli et copilot s’exécutent via des backends de fournisseurs qui utilisent leurs propres identifiants d’abonnement. La documentation ne précise pas non plus si ces backends respectent un baseUrl personnalisé ; considérez donc qu’une clé de type Kunavo doit être placée sur l’environnement openclaw plutôt que de supposer qu’un backend CLI peut être redirigé. Dans nanobot, la limite équivalente est que les comptes d’abonnement sont leurs propres fournisseurs OAuth, connectés avec nanobot provider login, et que sa référence fournisseur indique que les fournisseurs OAuth ne sont pas des replis automatiques valides ; une clé de passerelle n’hérite d’aucun de ces éléments. Le README d’OpenClaw indique qu’il n’a ni offre payante, ni service hébergé, ni jeton, et la documentation de nanobot ne décrit pas non plus d’offre payante ; aucun des deux ne documente donc de restriction liée à une formule logicielle.

Coût d’exploitation : le logiciel est à 0 $, la cadence ne l’est pas

nanobot est sous licence MIT selon sa licence de dépôt, et le README d’OpenClaw indique qu’il n’a ni offre payante, ni service hébergé, ni jeton. Aucun des deux ne publie de référence d’utilisation ; tout ce qui suit relève donc de calculs arithmétiques fondés sur les hypothèses indiquées, et non d’un résultat mesuré ou d’un plafond de facturation.

Prenons un seul assistant traitant 30 tours par jour pendant 30 jours, en supposant 6 000 jetons d’entrée non mis en cache et 400 jetons de sortie par tour — soit 5,4 M de jetons d’entrée et 360 000 jetons de sortie par mois. Aux tarifs actuels du catalogue Kunavo, Claude Sonnet 5 affiche $1.40 par million de jetons d’entrée et $7.00 par million de jetons de sortie, tandis que Claude Haiku 4.5 affiche $0.70 et $3.50.

Les lignes consacrées aux pulsations utilisent les propres chiffres d’OpenClaw : sa référence des pulsations indique que les pulsations exécutent des tours complets de l’agent, que la cadence par défaut est de 30 minutes pour l’authentification par clé API ou d’une heure pour OAuth, et que isolatedSession réduit le coût en jetons par pulsation d’environ 100 000 à environ 2 000 à 5 000 jetons. Il s’agit de la principale dépense contrôlable de toute la comparaison, et elle n’a rien à voir avec le client choisi. Il s’agit d’estimations arithmétiques fondées sur les hypothèses indiquées, hors frais de cache, sortie des tours de pulsation, outils externes et hébergement.

Deux lacunes à reconnaître. Il n’est pas vérifié qu’OpenClaw exécute une pulsation lorsqu’aucun bloc agents.defaults.heartbeat n’existe — la documentation indique la cadence par défaut sans préciser que la fonctionnalité est activée par défaut — ; considérez donc les lignes ci-dessus comme le coût d’une pulsation que vous configurez. Par ailleurs, la référence de configuration de nanobot active bien par défaut une pulsation de passerelle toutes les 1 800 secondes, avec les résultats courants « ignorés silencieusement », et cette même référence répertorie l’évaluation des pulsations parmi les tâches internes qui ouvrent un flux de modèle ; une pulsation ignorée n’est donc pas nécessairement gratuite. Aucun chiffre de jetons par pulsation n’est publié, si bien que le coût d’inactivité de nanobot ne peut pas être établi à partir de sa propre documentation. Mesurez les deux systèmes pendant une journée calme avant de vous engager sur une programmation.

Ce qu’OpenClaw active par défaut est la consolidation de la mémoire, via une tâche cron quotidienne à 03:00, utilisant le modèle par défaut de l’agent sauf si vous définissez dreaming.model — le faire pointer vers un modèle moins cher est une modification d’une ligne. nanobot présente un fonctionnement similaire : sa référence de la mémoire indique que Dream s’exécute par défaut selon une programmation cron et accepte un modelOverride désignant un préréglage moins cher ; il faut donc le budgétiser des deux côtés. Son idleCompactAfterMinutes distinct, dont la valeur par défaut est 15, est un minuteur de compactage plutôt qu’un appel de modèle programmé ; la documentation relie cette valeur par défaut à une fenêtre d’expiration typique du cache KV. Aucun des deux projets ne publie de chiffre de jetons par exécution pour son étape de consolidation, et les deux systèmes sont sans rapport — ne transposez pas les chiffres de l’un à l’autre.

Au-delà des jetons, budgétisez la machine qui maintient la passerelle en fonctionnement ainsi que tout compte payant de canal ou d’outil : le canal SMS d’OpenClaw repose sur une configuration Twilio et son canal Signal utilise signal-cli, sous forme de démon local ou de conteneur, avec son propre numéro, tandis que les options de transcription de nanobot et les outils d’image ou de recherche éventuels sont des comptes distincts.

Si vous souhaitez financer la partie modèle avec un crédit prépayé plutôt qu’un abonnement, le rechargement minimal de Kunavo est de $10 de crédit prépayé, et le solde n’expire pas. Lisez d’abord le guide de facturation : une estimation du catalogue ne constitue pas un plafond, car le montant facturé peut être supérieur lorsque la facturation fondée sur le coût amont le dépasse. Créez un compte Kunavo lorsque vous serez prêt à effectuer cet essai limité dans le client de votre choix.

Passer de l’un à l’autre, dans un sens comme dans l’autre

Ne supposez aucun transfert automatique. Le bloc du fournisseur est réécrit manuellement dans l’autre structure ; une entrée nanobot modelPresets n’a pas d’équivalent direct dans models.providers.<id>.models[] d’OpenClaw, et inversement. Les identifiants des canaux sont réémis pour chaque canal. Les programmations sont transférées en tant que définitions, et non en tant qu’état : nanobot conserve l’état cron dans <workspace>/cron/jobs.json, et les deux produits exigent que le processus de passerelle reste actif pour que toute tâche programmée puisse se déclencher.

La mémoire est l’élément qui mérite d’être exporté délibérément. Les connaissances persistantes de nanobot résident dans SOUL.md, USER.md et memory/MEMORY.md au sein d’un espace de travail dont la valeur par défaut est ~/.nanobot/workspace/. OpenClaw conserve par défaut son espace de travail dans ~/.openclaw/workspace, séparé de ~/.openclaw/, qui contient la configuration, les identifiants et les sessions, avec OPENCLAW_WORKSPACE_DIR permettant de remplacer le chemin d’espace de travail par défaut selon sa référence de l’espace de travail de l’agent. Copiez les fichiers, puis lisez-les dans la destination — transférer un fichier ne prouve pas que la session suivante récupérera le fait approprié.

Déplacez d’abord une tâche récurrente et conservez l’ancienne installation jusqu’à ce que le remplacement l’exécute correctement et survive à un redémarrage. Si la sélection oppose réellement OpenClaw à autre chose que nanobot, comparez les alternatives par flux de travail ; si vous avez déjà choisi OpenClaw et avez uniquement besoin de la route de modèle, la comparaison des fournisseurs et la ventilation des coûts d’exploitation vont plus loin que cette page.

Questions fréquentes

Documents sources vérifiés le 21 septembre 2026 : les deux dépôts, leur documentation publiée, la fiche PyPI de nanobot-ai et la fiche npm d’openclaw. Le 1er octobre 2026, les valeurs api et la valeur par défaut openai-completions d’OpenClaw ont été revérifiées par rapport à sa référence de configuration de passerelle, sa page du fournisseur Google et son schéma de configuration en v2026.9.7. Kunavo n’a testé aucun des deux clients en les exécutant ; les blocs de configuration sont lus dans la documentation des fournisseurs. Les tarifs Kunavo proviennent du catalogue en direct et les totaux sont des calculs de jetons fondés sur les hypothèses indiquées, et non le coût mesuré d’une tâche.