zclaw - Un assistant IA personnel qui tourne sur ESP32 avec 888 KB

• Assistant IA ultra-léger fonctionnant sur une carte ESP32, avec une taille totale de firmware limitée à moins de 888 KiB
• Écrit en C, il permet de combiner en langage naturel le contrôle GPIO, la planification (cron), la mémoire persistante et des outils personnalisés
• L’image complète, incluant Wi-Fi, TLS/chiffrement et bundle de certificats, tient dans 888 KiB, tandis que le code de l’application lui-même représente environ 25 KB
• Prend en charge l’intégration avec Telegram et le chat via relais web, ainsi qu’avec les principaux fournisseurs de LLM comme Anthropic, OpenAI et OpenRouter
• Testé sur les cartes ESP32-C3/S3/C6, publié en open source (licence MIT), avec un bon potentiel pour les expérimentations IA embarquées et l’extensibilité

---

Aperçu du projet

• zclaw est un assistant IA personnel pour ESP32, conçu avec pour objectif de maintenir la taille totale du firmware sous 888 KiB
  • Le firmware inclut la logique zclaw, le runtime ESP-IDF/FreeRTOS, ainsi que le Wi-Fi, TLS et le bundle de certificats
  • Le code de l’application lui-même ne représente qu’environ 25 KB, soit à peu près 4 % de l’image complète
• Écrit en C, il prend en charge la composition d’outils via des commandes en langage naturel, ainsi que le contrôle GPIO et des fonctions de planification
• Avec la formule « Fun to use, fun to hack on », le projet met l’accent sur l’expérimentation côté développeur et l’extensibilité

Fonctionnalités principales

• Interface de chat disponible via Telegram ou un relais web
• Prise en charge d’une planification sensible au fuseau horaire : daily, periodic, once, etc., pour des tâches récurrentes ou ponctuelles
• Extension des capacités grâce à des outils intégrés et personnalisés
• Contrôle en lecture/écriture des GPIO et protections intégrées comme gpio_read_all
• Fonction de mémoire persistante après redémarrage
• Choix de persona possible : neutral, friendly, technical, witty
• Intégration avec des fournisseurs de LLM : Anthropic, OpenAI, OpenRouter

Prise en charge matérielle

• Plateformes testées : ESP32-C3, ESP32-S3, ESP32-C6
  • D’autres variantes ESP32 peuvent aussi fonctionner avec une configuration manuelle
• Carte recommandée : Seeed XIAO ESP32-C3
• Scripts fournis pour une boucle locale de développement et de bidouillage
  • build.sh, flash.sh, provision-dev.sh, monitor.sh, etc.

Installation et configuration

• Commande de bootstrap en une ligne pour macOS/Linux
  • bootstrap.sh clone le dépôt puis exécute install.sh
• Le flash en mode sécurisé (--flash-mode secure) permet de stocker des identifiants chiffrés
• Les identifiants Wi-Fi et LLM se configurent avec provision.sh
• Limites par défaut des appels LLM : 100 par heure, 1000 par jour (modifiables à la compilation)
• Un script de test (web-relay.sh) permet de vérifier la réponse de l’appareil

Licence et informations du dépôt

• Licence MIT
• Site de documentation officiel : zclaw.dev

[GN⁺]

Réactions sur Hacker News

• Je me trompe peut-être, mais je me demande s’il s’agit d’un petit LLM embarqué, ou simplement d’un wrapper qui nécessite une connexion Internet

  • C’est un wrapper. Il utilise essentiellement l’API OpenAI. Voir le lien vers le code
  • La plupart des projets claw ont ce genre d’architecture en wrapper

• Ce qui rend l’exécution de claw sur un ESP32 intéressante, ce n’est pas la puissance de calcul, mais le fait qu’il soit toujours allumé et ne demande presque aucune maintenance
  Je fais tourner des pipelines d’automatisation sur un serveur Linux, et le plus gros problème n’est pas la logique IA, mais la gestion de l’hôte. Mises à jour, OOM, redémarrages, etc.
  Si l’ESP32 sert de proxy vers l’API cloud et gère localement l’orchestration des outils, il devient en fait une cible de déploiement plus stable pour une simple boucle d’agent

  • Je me demande quel OS est installé, et comment les mises à jour sont gérées
  • Je suis totalement d’accord. Les microcontrôleurs sont en pratique des hôtes auto-réparateurs — pas de gestionnaire de paquets, pas de mise à niveau du noyau, pas de configuration de cgroup. Après un reset, ils reviennent toujours au même état. À l’inverse, sous Linux, les « problèmes apparus après une mise à jour apt de routine » font partie du quotidien du débogage
  • On ne peut pas aussi garder ça simple sous Linux ? J’exploite plusieurs serveurs Apache, et ils tournent très bien tant que je n’y touche qu’au moment de la fin de vie
  • Mais dans ce cas, il y a davantage de points de défaillance. Serveur cloud, Internet, liaison sans fil, etc. Si un seul maillon casse, ça pose problème. Ce n’est pas une mauvaise approche, mais ça ne réduit pas les problèmes

• Quelqu’un peut expliquer l’ADC (convertisseur analogique-numérique) des SoC ESP du point de vue d’un ingénieur ?
  Ceux qui ont de l’expérience disent que c’est capricieux, mais j’ai aussi entendu dire qu’on peut en tirer quelque chose d’équivalent aux puces STM si on sait s’y prendre
  L’ESP32 était l’une des seules grandes puces à utiliser sa propre ISA, avant de passer ensuite à RISC-V

  • Les spécifications de l’ADC de l’ESP32 sont définies de manière très lâche. Si le « savoir-faire » inclut un étalonnage précis ou une caractérisation difficile à faire en production, alors vous avez sans doute votre réponse
  • L’ancienne ISA de l’ESP32 était basée sur une IP acquise auprès de Tensilica
  • L’ADC de l’ESP32 n’est pas fait pour de l’audio haute précision, mais pour du contrôle d’entrée simple. Le genre de chose où l’on branche un potentiomètre pour récupérer une entrée physique. Pour obtenir des valeurs stables, il faut faire la moyenne de plusieurs échantillons. Pour surveiller des tensions qui varient lentement, c’est tout à fait exploitable

• Est-ce qu’il existe une version collaborative de ce type de claw ? Par exemple une version auto-hébergée qu’une famille pourrait utiliser ensemble
  J’ai entendu dire qu’OpenClaw avait une fonction de profils, mais je me demande si ça gère à la fois les conversations privées et les conversations partagées

  • J’ai moi-même bricolé quelque chose de similaire. Un bot auto-hébergé basé sur Signal, avec prise en charge des discussions de groupe
    Récemment, j’y ai ajouté une fonction d’automatisation des courses — elle crée une liste brouillon à partir de l’historique des commandes, puis, quand les membres de la famille la modifient, l’agent utilise des outils navigateur pour remplir le panier. Le paiement reste manuel pour l’instant, mais c’est presque terminé. Ce genre de projet finira probablement bientôt en open source

• J’ai quelques ESP32 et de petits écrans OLED, et je me disais que je pourrais en faire un Tamagotchi intelligent. D’autres idées ?

  • J’ai fait quelque chose d’un peu similaire, mais au final ça revient à écrire une machine à états. Le LLM ne sait pas très bien décider tout seul « quand il doit manger » ou ce genre de choses. À force d’ajouter des variables et des règles, on finit par perdre la direction
  • C’est cool. Ce serait par hasard la version avec le micro-écran 0,46 pouce ? On peut faire des choses amusantes avec pour plein d’usages

• Quand on y pense, OpenClaw ressemble au ROS (Robot Operating System) du monde des agents IA
  Ça définit la façon dont des nœuds distribués interagissent, et permet d’assembler plusieurs nœuds fonctionnels pour construire un système plus large

  • Mais est-ce qu’il existe vraiment une spécification ou un protocole de ce type ? De ce que j’en vois, ça ressemble plutôt à une plateforme avec plusieurs intégrations empilées. C’est l’impression que j’ai eue après l’avoir utilisé pendant environ une semaine

• Homme simple : dès que je vois ESP32, j’upvote

• Vous recommandez un agent style claw léger pour Linux ? Je n’ai pas besoin de conteneurs ni de sandbox

  • J’utilise picoclaw
  • Si tu veux simplement WhatsApp et un chat web, j’utilise mon propre frontend web par-dessus piclaw. C’est présenté comme une web app accessible via Tailscale
  • zeroclaw vaut aussi le détour

• Ça faisait longtemps que je n’avais pas vu ce genre de motif

  bash <(curl foo.sh)
  

  D’habitude, on utilise

  curl foo.sh | bash
  

  mais les deux sont dangereux du point de vue de la sécurité. Je recommande plutôt les méthodes suivantes

  curl foo.sh | tee /tmp/foo.sh | bash
  bash -c "$(curl foo.sh)"
  curl foo.sh -o /tmp/foo.sh && bash $_
  

  Je préfère la dernière

  • J’ai entendu dire qu’il vaut mieux enregistrer dans un fichier temporaire puis exécuter, plutôt que de piper directement curl dans bash. Mais au fond, le problème de confiance reste le même. À moins de lire le code soi-même, on n’est jamais totalement en sécurité
  • Pour faire un peu plus sûr

    t=$(mktemp) && [ -w $t ] && curl foo.sh -o $t && echo "$t ..." | sha256sum -c - && bash $t
    

    il vaut mieux ajouter une vérification du hash
  • Si on veut vraiment bien faire, on peut aussi viser quelque chose d’indépendant du shell

• En réalité, ces projets claw ont une structure assez triviale. Il suffit en gros de donner au LLM le droit d’appeler des API

  • Ce qui m’a surpris avec l’engouement autour d’OpenClaw, c’est le nombre de gens qui ne maîtrisent même pas les concepts informatiques de base. On dirait qu’ils n’ont jamais regardé au-delà du dossier node_modules
  • Je développe moi-même un claw en ce moment, et dire que « ce n’est pas grand-chose », c’est un peu comme regarder quatre roues vissées sur du contreplaqué et dire qu’une voiture n’a rien de compliqué. Faire un véritable assistant personnel est bien plus complexe
  • Si tout le monde finit par faire tourner des agents personnels 24/7, il faudra peut-être bien plus de ressources de calcul qu’on ne l’imagine. Cela dit, rien ne dit que ça arrivera vraiment
  • C’est pareil pour la programmation. C’est du niveau « bah, il suffit juste de taper sur un clavier »
  • Au final, on va bientôt découvrir ce qui se passe quand on donne un cookie à une souris