Coût et configuration de l’API ZeroClaw : runtime gratuit, fournisseurs personnalisés, coût réel des tokens

Le runtime ZeroClaw coûte 0 $ : il est open source et proposé sous double licence MIT OU Apache-2.0, et la propre FAQ de zeroclaw.com indique qu’il n’y a ni abonnement ni poste hébergé — vous payez uniquement les coûts de votre propre fournisseur LLM, ou rien du tout si vous exécutez un modèle local avec Ollama. La documentation présentant la philosophie du projet est encore plus directe : « Pas de SaaS. Il n’y a pas de version hébergée, de système de compte ni de facturation. » En pratique, la « tarification de ZeroClaw » désigne donc deux autres factures : les jetons du modèle sur le point de terminaison vers lequel vous dirigez un alias, et la machine sur laquelle s’exécute le daemon. Les deux ont été vérifiés le 21 septembre 2026.

Deux éléments vous coûteront de l’argent ou du temps si vous les ignorez. ZeroClaw Labs ne publie aucun prix mensuel ; tout abonnement mensuel « ZeroClaw » que vous avez déjà vu concerne donc le produit de quelqu’un d’autre. Et le registre des coûts de ZeroClaw indiquera zéro dépense sur une passerelle tierce tant que vous n’aurez pas saisi les tarifs manuellement, car l’emplacement fournisseur custom ne possède aucun catalogue de prix. Les deux points sont détaillés ci-dessous.

Tarification de ZeroClaw : coût du logiciel et éléments réellement facturés

La dernière ligne est le mauvais résultat vers lequel une recherche « zeroclaw pricing » peut mener. Le README de ZeroClaw désigne github.com/zeroclaw-labs/zeroclaw comme l’unique dépôt officiel et indique que tout autre dépôt, organisation, domaine ou paquet se présentant comme ZeroClaw est non autorisé et sans affiliation. Un deuxième montant mensuel par agent circule dans les extraits de recherche pour zeroclaw.live ; ce site a renvoyé une erreur plutôt qu’une page le 21 septembre 2026. Le nombre n’a donc pas pu être lu sur la page et n’est volontairement pas reproduit ici. Par ailleurs, examinez attentivement les chiffres marketing, même sur les domaines utilisés par le projet lui-même : les pages d’accueil de zeroclaw.dev, zeroclaw.org et zeroclaw.net annoncent toutes un binaire de 3,4 Mo, tandis que la page de philosophie du projet indique qu’une version type compilée atteint environ 26 MiB. Il s’agit d’un écart entre la documentation et la page d’accueil, et non d’une preuve d’usurpation — le README redirige lui-même les signalements de sécurité vers une adresse en zeroclaw.dev. ZeroClaw vs OpenClaw examine ce problème d’identification en détail.

Une précision de périmètre, car les deux faits semblent contradictoires. « Aucune facturation » est vrai pour l’exécution de ZeroClaw et faux pour ZeroClaw Labs en tant qu’organisation : la même organisation GitHub fournit ZeroRouter, une passerelle AGPL dont la description du dépôt mentionne une facturation Stripe prépayée, accessible depuis ZeroClaw via son propre zerorouter. Il s’agit d’un produit différent en bêta, et non d’un abonnement ZeroClaw ; ses tarifs hébergés reflètent l’état réel de la passerelle plutôt qu’une grille tarifaire publiée.

La structure de configuration à écrire aujourd’hui : schéma 3, et non l’extrait à plat

La documentation officielle est à jour ; une grande partie de la configuration ZeroClaw que vous trouverez dans les résultats de recherche ne l’est pas. La version actuelle du schéma de configuration est 3 — CURRENT_SCHEMA_VERSION: u32 = 3 dans crates/zeroclaw-config/src/migration.rs au tag de la version v0.8.5, avec une chaîne de migration de V1 vers V2 puis V3. La structure à plat qui circule dans les anciens tutoriels correspond au schéma 1. Un fichier de configuration ne contenant aucun schema_version est traité comme la version 1 et migré en mémoire lors du chargement ; le fichier sur disque n’est donc pas réécrit par le chargement lui-même.

Attention à la terminologie : « ZeroClaw V3 » n’est pas une version. La dernière version est v0.8.5, publiée le 5 septembre 2026 (API GitHub, vérifiée le 21 septembre 2026) ; le schéma 3 est le format de configuration qu’elle contient. Les deux nombres n’ont aucun lien.

Noms de champs du schéma 1 lus dans la représentation de migration V1 à la version v0.8.5 ; les lignes du schéma 2 proviennent des commentaires de documentation de la représentation V2 sur master, dans les deux cas au 21 septembre 2026. Lors de la migration, un ancien fichier est analysé en tant que l’une de ces représentations, ce qui en fait de bonnes preuves des anciens noms de champs. Sur la dernière ligne, deux sources divergent selon leur date : la représentation V2 indique que V3 a supprimé cost.prices et déplacé la tarification directement dans chaque fournisseur de modèles, tandis que la documentation actuelle du suivi des coûts qualifie le champ pricing défini directement pour chaque alias de champ obsolète et désigne [cost.rates.*] comme la structure d’avenir prioritaire en cas de conflit. Écrivez [cost.rates.*].

Dans le schéma 3, chaque fournisseur de modèles se trouve dans [providers.models.<type>.<alias>], où le type est un emplacement de famille canonique — « un emplacement par fournisseur, sans synonymes » — et où vous choisissez le nom de l’alias. La vue d’ensemble des fournisseurs précise qu’« il n’existe aucun paramètre global de “fournisseur par défaut” ou de “modèle par défaut” », et que Config::validate() échoue explicitement au démarrage si une référence ne peut pas être résolue. Un extrait du schéma 1 copié n’est pas rejeté parce qu’il est ancien : la chaîne de migration regroupe ses api_key, api_url et default_model de niveau supérieur dans une entrée de fournisseur nommée par default_provider, et la perspective V1 remplace cette clé absente par openrouter. Ainsi, un extrait à plat contenant uniquement une clé et une URL aboutit à une entrée openrouter plutôt qu’à la passerelle voulue. Le problème vient d’une référence impossible à résoudre, et non d’un ancien nom de champ.

Fournisseur personnalisé ZeroClaw : diriger un alias vers une API compatible OpenAI

Un point de terminaison compatible avec les chat-completions OpenAI utilise l’emplacement custom, et la page des fournisseurs personnalisés de la version v0.8.5 indique qu’il s’agit d’une modification limitée à la configuration : « l’emplacement custom nécessite uri (l’énumération des points de terminaison de la famille n’a aucune valeur par défaut) ». Un point de terminaison utilisant le protocole Anthropic Messages utilise l’emplacement anthropic, avec uri défini sur override — et non custom. Kunavo fournit les deux formats de protocole sous https://api.kunavo.com/v1 avec une seule clé ; sur le papier, les deux emplacements conviennent donc. L’extrait ci-dessous combine les champs documentés de l’emplacement personnalisé avec la structure à quatre en-têtes de l’exemple détaillé de la documentation ; il s’agit d’une adaptation, et non d’un bloc officiel copié.

# Four section headers is the smallest config that loads clean.
[providers.models.custom.kunavo]
uri     = "https://api.kunavo.com/v1"   # REQUIRED: the custom family has no default endpoint
model   = "claude-sonnet-4-6"
api_key = "sk-kn-..."                   # or the secrets store, op://, or a ZEROCLAW_ env override

[agents.assistant]
model_provider  = "custom.kunavo"       # there is no global default provider
risk_profile    = "supervised"
runtime_profile = "resident"

[risk_profiles.supervised]
level                            = "supervised"
workspace_only                   = true
require_approval_for_medium_risk = true
block_high_risk_commands         = true

[runtime_profiles.resident]
max_actions_per_hour   = 10             # example values from the docs, not defaults
max_cost_per_day_cents = 100
max_tool_iterations    = 4
agentic_timeout_secs   = 120

Quatre remarques pratiques. Les identifiants peuvent être fournis de quatre façons — directement avec api_key, via une référence 1Password op://vault/item/field, dans le stockage chiffré à l’emplacement ~/.zeroclaw/secrets, ou avec le remplacement générique par variable d’environnement ZEROCLAW_providers__models__custom__kunavo__api_key, où un double caractère de soulignement correspond à un point. Un nom de variable shell par défaut de l’écosystème tel que $ANTHROPIC_API_KEY n’est pas lu directement, sauf si la famille de fournisseurs documente son propre pont natif vers les variables d’environnement — la documentation vous demande de le développer vous-même vers le nom miroir du schéma — et une variable d’environnement miroir du schéma est une injection à l’exécution qui ne devient jamais une configuration persistante. L’emplacement custom utilise par défaut le protocole des chat-completions, et wire_api est respecté pour les familles permettant de fournir son propre point de terminaison (openai, llamacpp, custom), tandis que les emplacements de fournisseurs de marque utilisent un protocole fixe et l’ignorent, à l’exception de opencode. Si votre passerelle rejette un champ temperature, laissez-le absent : la documentation indique qu’un temperature absent est entièrement omis du corps de la requête. Enfin, un démarrage réussi est moins probant qu’il n’y paraît : la préchauffe de connexion est un GET qui consomme le corps et accepte les codes d’état non réussis, de sorte que le démon démarre dans les deux cas ; la page des fournisseurs personnalisés sur master le documente sous la forme GET {base_url}/models, tandis que le code v0.8.5 préchauffe plutôt l’URL des chat-completions.

Validez dans l’ordre documenté, les trois commandes étant celles de la version v0.8.5 : zeroclaw config list charge la configuration et affiche les échecs de validation sur stderr, zeroclaw models refresh --model-provider custom.kunavo répertorie ce que le point de terminaison annonce, et zeroclaw agent -a assistant -m "hello" effectue un test de bon fonctionnement de l’agent. Le /v1/models de Kunavo répond HTTP 401 sans clé (vérifié le 21 septembre 2026), ce qui ne bloque pas la procédure : la commande d’actualisation envoie la clé de l’alias. Kunavo n’a pas testé ZeroClaw à l’exécution — tout ce qui figure dans cette section est une revue des documents sources de ZeroClaw ; exécutez donc vous-même une tâche limitée avant de faire confiance à la route.

Kunavo ne fournit aucun modèle d’embeddings, de synthèse vocale ou de reconnaissance vocale ; un agent qui a besoin de ces étapes doit donc les diriger vers un autre point de terminaison, quel que soit l’emplacement ZeroClaw utilisé par le modèle de chat.

Le compteur de coûts reste à 0 $ jusqu’à ce que vous écriviez la grille tarifaire

ZeroClaw mesure ses propres dépenses, et sur une passerelle tierce ce compteur démarre avec une valeur erronée. Le suivi des coûts est activé par cost.enabled, et les enregistrements sont écrits dans un journal en ajout uniquement à l’emplacement <workspace>/state/costs.jsonl, avec un objet JSON par ligne. Le problème est l’origine des prix. Dans catalog.rs à la version v0.8.5, catalog_source_for ne renvoie ni clé models.dev ni préfixe de fournisseur OpenRouter pour la famille custom — la plupart des emplacements de marque possèdent au moins l’un des deux, bien que plusieurs (zerorouter, telnyx, nearai) n’en possèdent aucun. L’option live_pricing est désactivée par défaut et, lorsqu’elle est activée, lit d’abord la liste /models du point de terminaison, puis utilise en secours models.dev avec le nom models.dev de la famille ; la famille custom n’a pas de telle clé, donc, pour cet emplacement, la liste propre au point de terminaison est l’unique source. La liste de Kunavo ne contient aucun champ de prix par jeton, lu depuis la source de la route et non depuis une réponse de production authentifiée. Un alias utilisant un emplacement personnalisé enregistre donc cost_usd = 0 avec unpriced_tokens supérieur à zéro jusqu’à ce que vous saisissiez vous-même les tarifs.

[cost]
enabled = true

# Keyed by the UPSTREAM model id as it appears in usage telemetry,
# not by your alias. USD per 1M tokens.
[cost.rates.providers.models.custom.claude-sonnet-4-6]
input        = 2.1
output       = 10.5
cached_input = 0.21

Trois comportements en découlent, tous issus de la documentation du suivi des coûts, vérifiée le 21 septembre 2026. Les entrées tarifaires sont indexées par l’identifiant du modèle amont tel qu’il apparaît dans la télémétrie d’utilisation, et non par votre alias. Les comparaisons de budget utilisent cost_usd, de sorte qu’un total quotidien ou mensuel inférieur à son plafond ne constitue aucune garantie de sécurité si le mois contient des jetons non tarifés. Les lignes existantes du journal ne sont jamais recalculées : « il n’existe pas de recalcul rétroactif des tarifs », qui ne s’appliquent donc qu’aux requêtes effectuées après leur configuration. Le contrôle comporte trois modes — warn (par défaut), block et route_down, qui remplace par un route_down_model moins cher — ainsi que allow_override, désactivé par défaut, qui permet à une requête de contourner block avec un jeton de remplacement sur la CLI.

Estimation détaillée fondée sur le plafond quotidien de ZeroClaw

Il s’agit d’un calcul illustratif de jetons, et non du coût mesuré d’une tâche ni d’un plafond de facturation. L’exemple détaillé de la documentation avec [runtime_profiles] limite un agent à max_actions_per_hour = 10 et max_cost_per_day_cents = 100 — des valeurs d’exemple pour un petit modèle local, et non des valeurs par défaut. Prenez ce plafond au pied de la lettre pendant huit heures d’activité par jour : 80 tours par jour, chacun envoyant 6 000 jetons d’entrée non mis en cache et renvoyant 500 jetons de sortie. Les tarifs sont les prix actuels du catalogue Kunavo par million de jetons.

L’interprétation utile ne concerne pas le classement, mais son interaction avec le plafond. Un profil écrit pour un petit modèle local place un modèle de pointe sous les mêmes limites : max_actions_per_hour borne le volume de tours, et le plafond de coût quotidien ne refuse une requête que lorsque enforcement.mode est block. Avec warn, le mode par défaut, le plafond ne bloque jamais : il consigne l’événement et laisse passer la requête. (warn_at_percent, 80 % par défaut, est un paramètre distinct : il détermine quand la passerelle affiche une bannière d’avertissement avant la limite stricte.) Pire encore, si vous n’avez jamais écrit la grille tarifaire ci-dessus, rien de tout cela ne se déclenche, car le plafond ne peut pas voir les jetons non tarifés. Redimensionnez le tableau selon votre propre volume de tours et votre ratio entrée-sortie avant de le considérer comme un budget ; il exclut les frais de cache, les appels d’outils et les nouvelles tentatives, et suppose que le modèle moins cher termine le travail sans tentative supplémentaire.

Le montant du catalogue Kunavo constitue un plancher de facturation plutôt qu’un plafond : lorsque l’amont indique 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. Le rechargement minimal est de $10 de crédit prépayé, ce qui constitue un minimum de financement, et non des frais par tâche ou un abonnement — consultez les détails de facturation.

Meilleur modèle et meilleure API pour ZeroClaw : ce que le projet vous dira ou non

ZeroClaw ne publie aucun modèle recommandé et refuse de se prononcer officiellement. Sa page de configuration multi-modèles indique que « ce flux de travail n’établit pas de liste de modèles vérifiée par ZeroClaw » et que « les éléments probants concernant une compilation, un modèle, une quantification et un paramètre de contexte ne vérifient pas les autres combinaisons ». C’est la réponse honnête à « quel est le meilleur modèle pour ZeroClaw » : il n’existe aucun classement officiel à citer ; choisissez donc selon deux propriétés vérifiables.

La première est l’appel natif d’outils, et la même page fixe une exigence stricte : « Inspectez l’exécution pour vérifier un véritable appel d’outil, son résultat exécuté et une continuation de l’assistant qui utilise ce résultat. Une réponse plausible ou un balisage d’appel d’outil imprimé ne suffit pas pour réussir le test d’outil. » Le paramètre de profil d’exécution strict_tool_parsing traite le texte de secours ressemblant à du XML ou du JSON comme du texte ordinaire de l’assistant, sauf si le fournisseur renvoie de véritables appels d’outils ; un modèle qui se contente de décrire un appel d’outil semblera donc fonctionner, mais n’agira jamais. La seconde est la capacité du modèle à terminer votre tâche sans tentatives supplémentaires — c’est pourquoi le prix affiché le plus bas et le coût minimal pour terminer la tâche sont deux affirmations différentes.

Deux comportements à budgéter avant d’activer le basculement. Le streaming obéit au contrat le plus restrictif : la page du cycle de vie du routage des fournisseurs indique que l’enveloppe « choisit la première entrée ordonnée qui prend en charge les capacités de streaming demandées et qui n’est pas en période de refroidissement », puis « ouvre ce flux une seule fois » et « ne change pas d’entrée une fois le flux démarré » — toutefois, un flux qui échoue avant qu’une sortie soit validée est retenté via le chemin sans streaming, qui reprend le parcours complet de fiabilité sur fallback_models et fallback. Ces nouvelles tentatives sans streaming couvrent les délais d’expiration, les erreurs de connexion, 429 et 503, mais explicitement pas 400, les échecs d’authentification permanents ni les erreurs de sortie du modèle. Une entrée de secours peut aussi déplacer le travail vers un autre niveau de prix ; prévoyez donc un budget. Pour une comparaison plus large des routes de passerelle, consultez le guide de l’API compatible OpenAI et les alternatives à OpenRouter.

Travail récurrent : profils de risque, plafonds et service qui le redémarre

L’autonomie est définie par agent, et non globalement. La page sur l’autonomie de la version v0.8.5 accepte exactement trois niveaux — readonly, supervised et full — et rejette read_only avec un trait de soulignement lors du chargement de la configuration. Avec la valeur par défaut supervised, les outils à faible risque s’exécutent automatiquement, ceux à risque moyen déclenchent une demande d’approbation de l’opérateur et ceux à risque élevé sont bloqués. Les demandes d’approbation expirent après le approval_timeout_secs du canal, soit 120 secondes pour la plupart des canaux, et une expiration est considérée comme un refus ; un agent sans surveillance échoue donc par défaut plutôt que de mettre la demande en file d’attente.

Deux limites concernant le travail récurrent. Le comportement au redémarrage n’est pas uniforme selon les plateformes : l’unité utilisateur systemd installée définit Restart=always avec RestartSec=3 et sans liste blanche de codes de sortie, de sorte qu’un démon qui échoue rapidement à cause d’une mauvaise configuration peut redémarrer en boucle ; le LaunchAgent macOS définit RunAtLoad et KeepAlive ; et sous Windows, zeroclaw service install enregistre une tâche du Planificateur de tâches ONLOGON qui démarre le démon à l’ouverture de session sans ajouter de politique de redémarrage en cas d’échec. Le travail planifié est lui-même déclaratif et indexé par alias dans [cron.<alias>], séparément des propres paramètres de la section [scheduler]. Enfin, le moteur SOP déterministe est qualifié d’expérimental par la propre matrice de fonctionnalités du projet — les déclencheurs périphériques et calendaires sont définis et mis en correspondance, mais ne sont pas encore acheminés vers une source active ; ne concevez donc pas encore de flux de travail sans surveillance autour de lui.

Configurez-le et vérifiez le premier débit

Kunavo ne publie aucune page d’intégration spécifique à ZeroClaw et n’a pas testé le client à l’exécution ; considérez donc la configuration ci-dessus comme une route fondée sur les documents sources, et non comme un résultat de compatibilité. La séquence pratique est courte : créez une clé, financez le rechargement minimal, écrivez les quatre en-têtes, exécutez les trois commandes de validation dans l’ordre, puis écrivez le bloc [cost.rates.*] avant le premier long fonctionnement afin que le journal ait quelque chose à enregistrer. Commencez par le guide de démarrage rapide pour l’URL de base et le format de clé, par la référence des chat-completions pour le protocole utilisé par l’emplacement custom, puis créez un compte Kunavo lorsque vous êtes prêt à le financer. Si votre agent utilise plutôt le protocole Anthropic, la documentation de l’URL de base Anthropic décrit la route de l’emplacement anthropic.

Questions fréquentes

Vérifié le 21 septembre 2026. Relu directement pour cette page : la FAQ de zeroclaw.com, le README du dépôt, l’API GitHub pour l’état du dépôt et la version v0.8.5, migration.rs, schema/v1.rs, catalog.rs, compatible.rs, providers/custom.md, security/autonomy.md et ops/service.md au tag v0.8.5, ainsi que, sur master, la perspective de migration V2, providers/overview.md, providers/configuration.md, providers/catalog.md, providers/routing.md, providers/custom.md, architecture/provider-routing-lifecycle.md, ops/cost-tracking.md, getting-started/multi-model-setup.md, philosophy/minimal.md, philosophy/what-this-isnt.md et reference/feature-matrix.md, en plus du dépôt zerorouter, des sites tiers et pages d’accueil nommés ci-dessus, et d’un GET non authentifié vers le /v1/models de Kunavo. Tout élément cité depuis master provient de la documentation de la branche de développement et peut devancer la version stable. Kunavo n’a pas testé ZeroClaw à l’exécution : aucune installation, aucun config list et aucune exécution d’agent n’ont été effectués ; le streaming, l’appel natif d’outils et la vision via cette route ne sont donc pas vérifiés ici. Les tarifs de jetons Kunavo sont lus depuis le catalogue en direct et chaque montant en dollars de cette page correspond à un calcul illustratif de jetons.