CashClaw : un agent autonome qui vend son travail sur le marché Moltlaunch

Le problème : un agent qui doit gagner sa vie, pas seulement répondre

La plupart des démos d'agents s'arrêtent au moment où le modèle produit du texte. CashClaw part de l'autre bout : une tâche arrive avec un client, un prix et une note à la clé. Le README résume la boucle en une phrase, prendre le travail, le faire, être payé, s'améliorer. Le projet vise donc un public précis : quelqu'un qui dispose d'un portefeuille sur Base, d'une clé LLM et qui veut laisser tourner un processus sur sa machine pour répondre à des demandes entrantes. Ce n'est pas un cadre général d'orchestration. C'est un agent unique, avec un métier défini, branché sur un marché précis. Le README précise d'ailleurs que Moltlaunch n'est pas obligatoire : le code est ouvert et peut être détourné vers d'autres clients. Cette phrase est honnête, mais elle déplace le travail sur l'utilisateur, car toute la couche marketplace passe par la CLI mltl.

Un processus, trois boucles : écoute, exécution, étude

L'architecture tient dans un seul processus Node.js. La première boucle écoute le marché : une connexion WebSocket vers l'API Moltlaunch pour les événements de tâches en temps réel, avec un repli en interrogation REST. La deuxième exécute le travail. La troisième, appelée self-study, tourne quand l'agent est inactif, par défaut toutes les 30 minutes, et alimente une base de connaissances. Le schéma du README montre aussi un serveur HTTP sur le port 3777 qui sert à la fois des points JSON sous /api/* et un tableau de bord React statique. Ce découpage a une conséquence pratique : le tableau de bord n'est pas un service séparé, il vit dans le même processus que l'agent. Si le processus tombe, l'interface tombe avec lui, et inversement.

La boucle d'agent : le LLM ne touche jamais une API directement

Le cœur du système est décrit dans loop/index.ts. C'est une conversation à plusieurs tours avec usage d'outils. Le déroulé donné par le README : construire un prompt système (identité de l'agent, règles de tarification, personnalité, connaissances apprises, et éventuellement le catalogue AgentCash), injecter le contexte de la tâche comme premier message utilisateur, laisser le modèle répondre avec un raisonnement et des appels d'outils, exécuter ces outils, renvoyer les résultats, répéter jusqu'à ce que le modèle arrête d'appeler des outils ou atteigne la limite de tours, fixée à 10 par défaut. Le point de conception intéressant est la phrase du README : le LLM n'appelle jamais les API directement. Tous les effets de bord passent par des outils qui lancent la CLI mltl ou npx agentcash. Cela donne une surface d'audit claire, mais cela veut aussi dire que chaque action dépend d'un sous-processus, avec la latence et les codes de sortie que cela implique.

Treize outils, répartis en trois familles

Le cycle de vie d'une tâche est explicite dans le README : requested, puis le LLM évalue et choisit entre quote_task, decline_task ou send_message ; accepted, le LLM produit le travail et appelle submit_work ; revision, il relit les retours du client et resoumet ; completed, la note et les commentaires sont stockés et la base de connaissances est mise à jour. Les outils se répartissent en trois catégories. Côté marketplace : read_task, quote_task, decline_task, submit_work, send_message, list_bounties, claim_bounty. Côté utilitaire : check_wallet_balance, read_feedback_history, memory_search, log_activity. Côté AgentCash : agentcash_fetch pour les appels d'API payantes et agentcash_balance pour le solde en USDC. Les devis sont exprimés en ETH. Cette séparation est lisible, mais elle montre aussi que la capacité de l'agent à facturer dépend d'un solde externe et d'un fournisseur tiers, deux points que le dépôt ne peut pas contrôler.

La mémoire : BM25, décroissance temporelle et rappel actif

Chaque session d'étude produit une entrée de connaissance structurée, stockée dans ~/.cashclaw/knowledge.json. Trois sujets tournent : l'analyse des retours clients, qui ne s'exécute que s'il existe des notes ; la recherche de spécialité, sur les domaines configurés ; et la simulation de tâche, qui génère un exercice et en esquisse l'approche. Au moment où une tâche arrive, le texte est découpé en jetons, puis une recherche BM25+ parcourt les connaissances et les retours. Le score subit ensuite une décroissance temporelle, score * e^(-lambda * ageDays), avec une demi-vie de 30 jours. Les cinq meilleurs résultats sont injectés dans le prompt système sous un titre Relevant Context. Deux points d'intégration existent : l'injection automatique à chaque tâche, et le rappel actif, où le modèle peut appeler memory_search en cours de route. Le choix de BM25 plutôt qu'une recherche vectorielle est un compromis assumé : pas d'embeddings à calculer ni à stocker, mais une correspondance lexicale qui rate les reformulations.

Mise en route : trois commandes et un assistant

L'installation tient en trois lignes, telles que le README les donne : npm install -g cashclaw-agent, puis npm install -g moltlaunch, puis cashclaw. Le processus ouvre http://localhost:3777 avec un assistant en quatre étapes. D'abord le portefeuille, qui détecte le portefeuille mltl, créé automatiquement au premier lancement. Ensuite l'agent, enregistré onchain avec un nom, une description, des compétences et un prix. Puis le LLM, avec le choix entre Anthropic, OpenAI et OpenRouter, et un appel de test en direct. Enfin la configuration : stratégie de tarification, bascules d'automatisation, limites de tâches. Les fournisseurs utilisent fetch() brut, sans SDK. Anthropic vise api.anthropic.com/v1/messages avec claude-sonnet-4-20250514 par défaut, OpenAI vise api.openai.com/v1/chat/completions avec gpt-4o, et OpenRouter vise openrouter.ai/api/v1/chat/completions avec openai/gpt-5.4. Un adaptateur partagé traduit le format d'outils natif d'Anthropic vers tool_calls d'OpenAI.

Ce que le dépôt ne dit pas, et pourquoi cela compte

Le README ne documente ni la structure des fichiers de configuration, ni la façon dont les clés LLM sont stockées sur disque. Il mentionne ~/.cashclaw/knowledge.json pour la mémoire, mais rien sur les identifiants. Pour un processus qui manipule un portefeuille et paie des API via npx agentcash, c'est une lacune à combler avant tout déploiement réel. Autre limite : la boucle d'agent plafonne à 10 tours par défaut. Une tâche complexe qui demande plusieurs allers-retours de révision peut donc s'arrêter avant d'avoir soumis un livrable, et le README ne décrit pas de mécanisme de reprise après cette coupure. Enfin, le repli REST n'est mentionné qu'en une ligne : on ne sait pas à quelle fréquence il interroge l'API ni comment il évite de traiter deux fois la même tâche si le WebSocket revient. Aucune de ces questions n'est tranchée par le matériel fourni. Sur la maintenance, le dépôt a reçu une poussée le 14 mars 2026 et n'a pas de version publiée dans les données disponibles, ce qui laisse la question du versionnage ouverte. La licence MIT autorise la modification et la redistribution, y compris commerciale, mais elle ne couvre pas les conditions d'usage de la plateforme Moltlaunch ni celles des API payantes appelées par les outils.

Face à un cadre d'orchestration généraliste

Le point de comparaison le plus direct n'est pas un autre agent marchand, mais un cadre comme LangGraph. La différence de conception est nette. LangGraph modélise le flux de travail comme un graphe d'états explicite : vous déclarez les nœuds, les transitions et les conditions d'arrêt, et vous pouvez reprendre une exécution interrompue depuis un point de contrôle. CashClaw ne déclare pas de graphe. Il laisse le LLM décider, tour après tour, quel outil appeler, avec un plafond de 10 tours comme seule borne. Le premier impose une structure au prix d'un travail de modélisation ; le second va plus vite à mettre en place mais rend le comportement moins prévisible. Le choix de CashClaw se défend pour un agent à métier unique, où les états se résument à requested, accepted, revision et completed. Il se défend moins dès qu'il faut plusieurs agents, des reprises sur incident ou une traçabilité fine de chaque décision.

Conclusion éditoriale

CashClaw convient à ceux qui veulent un agent unique, lisible, où chaque effet de bord passe par un outil explicite shell vers mltl, et qui acceptent de dépendre de la CLI Moltlaunch pour le marketplace. Ceux qui cherchent un framework multi-agents avec orchestration distribuée ou une isolation forte des secrets passeront leur chemin. Avant d'adopter, vérifiez deux points dans le dépôt : la façon dont ~/.cashclaw/knowledge.json est protégé sur disque, et le comportement du repli REST quand la connexion WebSocket tombe.

Sources officielles

1. Issues
2. License: MIT
3. moltlaunch/cashclaw on GitHub
4. Project website
5. README