NullClaw, l’agent IA qui tient en 678 Ko : anatomie d’un binaire Zig minimaliste

678 Ko. Pas 678 Mo, pas une image Docker obèse. Un binaire. NullClaw débarque avec une promesse qui pique la curiosité de n’importe quel dev: faire tourner un framework d’agent IA complet sur environ 1 Mo de RAM, et démarrer en moins de 2 millisecondes.

Le truc, c’est que NullClaw ne joue pas le même jeu que les frameworks d’agents à la mode. Là où beaucoup empilent runtime, VM, garbage collector et dépendances, lui part en full Zig « raw », compilé en code machine, avec zéro couche d’exécution au-dessus. Du coup, ça vise clairement l’edge, les petites cartes à 5 dollars, et les scénarios où chaque milliseconde compte.

Pourquoi NullClaw coupe le runtime, et ça change tout

Dans l’écosystème agentique, la norme c’est souvent Python, TypeScript, Go. C’est confortable, tu as des bibliothèques partout, tu prototypes vite. Mais tu payes l’addition: runtime, interpréteur, VM, gestion mémoire automatique. NullClaw prend l’option inverse: tout est écrit en Zig, compilé, et il ne garde comme exigence externe que libc. Résultat: les cycles CPU partent dans la logique, pas dans la plomberie.

Les chiffres mis en avant sont brutaux: binaire statique de 678 Ko, environ 1 Mo de RAM en pic RSS, et un boot annoncé sous les 2 ms. Sur un coeur edge à 0,8 GHz, la famille de projets comparés donne une idée du fossé: certains démarrent en dizaines de secondes, d’autres en moins d’une seconde, NullClaw annonce moins de 8 ms sur ce type de CPU. Là, tu peux envisager des agents « événementiels » qui se réveillent, font le job, et se rendorment.

J’ai demandé à Marc, dev embarqué qui bosse sur des passerelles industrielles, ce qu’il en pense. Sa réaction est simple: « Si tu peux lancer un agent en quelques millisecondes, tu peux le traiter comme une fonction. Pas comme un service qui doit rester vivant. » Et ça, sur des équipements où tu n’as pas envie d’entretenir un gros daemon, ça compte. Tu limites les surfaces d’attaque, tu réduis la conso, tu simplifies le déploiement.

Mais il y a un prix: tu n’as pas la même « souplesse » qu’un runtime managé. Zig te laisse gérer la mémoire de façon manuelle. C’est puissant, mais ça demande de la rigueur. NullClaw mise sur ce contrôle bas niveau pour tenir dans 1 Mo, mais ça veut aussi dire que la qualité d’implémentation, les tests, et la discipline de code sont non négociables. Sur ce point, le projet met en avant plus de 3 230 tests, ce qui rassure un peu.

678 Ko et 1 Mo de RAM: ce que ça permet sur l’edge

Un binaire de 678 Ko, ça ouvre des portes très concrètes. D’abord, le stockage: tu peux déployer sur des systèmes où la place est comptée, sans trimballer 200 Mo de dépendances. Ensuite, la RAM: « 1 Mo », c’est le genre de chiffre qui te fait regarder autrement des cartes ARM bon marché, voire des environnements où tu n’as pas envie de réserver 100 Mo juste pour que le framework respire.

NullClaw se vend comme « runs on anything with a CPU », et insiste sur la portabilité: un binaire autonome, sans runtime, qui vise ARM, x86 et RISC-V. Dans la vraie vie, ça veut dire que tu peux standardiser ton outil d’agent sur plusieurs familles de machines. Tu n’es pas obligé de maintenir trois stacks différentes selon la passerelle IoT, le mini PC d’atelier ou le serveur de bord de réseau.

Sur les usages, l’edge computing est le terrain naturel. Exemple simple: une borne qui doit analyser des événements, déclencher des actions, envoyer une alerte, puis se taire. Si ton agent met 30 secondes à démarrer, tu oublies. Si ton agent démarre en moins de 2 ms, tu peux envisager un modèle « à la demande ». Même logique pour des architectures serverless côté edge: tu veux de la latence faible, et tu veux éviter la facture mémoire permanente.

Le revers de la médaille, c’est que « ça tourne avec 1 Mo » ne veut pas dire « ça fait tout, partout, sans compromis ». Tu ne vas pas embarquer un gros modèle local sur 1 Mo de RAM, on parle d’orchestration, d’agent, de providers, de canaux, d’outils, et de mémoire optimisée. En clair: NullClaw vise l’infrastructure d’assistant autonome ultra légère, pas un LLM géant embarqué comme sur un GPU. Si tu confonds les deux, tu vas être déçu.

Boot en moins de 2 ms: le rêve des systèmes événementiels

Le démarrage éclair, c’est le détail qui change la façon de concevoir un produit. NullClaw attribue ce boot à l’absence de VM et d’interpréteur: compilation directe en code machine, dépendances réduites, binaire statique. Sur Apple Silicon, la promesse est « <2 ms », et sur un coeur edge à 0,8 GHz, « <8 ms » est avancé. Même si tu prends ces chiffres avec prudence, l’ordre de grandeur est déjà inhabituel.

Dans un système événementiel, tu as souvent des contraintes bêtes mais dures: un capteur déclenche, tu dois décider vite, tu dois logguer, tu dois envoyer sur un canal, parfois tu dois exécuter un outil. Si ton agent est un gros service, tu le laisses tourner, tu gères les mises à jour, la supervision, la mémoire, les fuites. Si ton agent est quasi instantané, tu peux le lancer à la volée, traiter, et tuer le process. C’est une autre hygiène.

Marc me donnait un exemple parlant côté terrain: une passerelle d’usine qui reçoit des événements de vibration. « Tu veux un truc qui démarre, interroge une mémoire locale, applique une règle, et envoie une notif. » Le gain, ce n’est pas juste la vitesse. C’est aussi la capacité à faire des redémarrages fréquents sans douleur, à limiter l’état résiduel, et à rendre l’ensemble plus prévisible.

Mais soyons honnêtes: démarrer vite, c’est une partie de l’histoire. Le vrai sujet, c’est le temps de bout en bout: IO, réseau, providers, outils, sandbox, tunnels, et tout ce que tu actives. NullClaw peut booter en 2 ms, mais si tu enchaînes ensuite sur une requête réseau lente, tu retombes sur les réalités du monde. Le bénéfice reste énorme pour l’architecture, mais il ne transforme pas Internet en fibre magique.

La mémoire « hybride vector + mots-clés » au lieu d’une base externe

NullClaw met en avant un choix technique clé pour rester léger: une mémoire hybride « vector + keyword », pensée pour faire du RAG sans traîner une base vectorielle lourde à côté. L’idée est simple sur le papier: tu veux retrouver des infos pertinentes sans déployer un service séparé qui mange de la RAM, du disque, et de l’admin. Du coup, le framework intègre son approche de recherche dans son design bas niveau.

Dans les sources du projet, on parle de « hybrid vector + FTS5 memory » et d’une recherche mêlant vecteurs et mots-clés. Pour un agent, ça veut dire que tu peux indexer des éléments, retrouver par similarité, tout en gardant une couche « texte » plus classique. Le mix est souvent plus robuste que le tout-vectoriel, surtout quand tu veux des correspondances exactes sur des identifiants, des noms de pièces, des codes d’erreur.

Concrètement, tu peux imaginer une doc technique locale, des procédures, des messages d’erreur, des fiches de maintenance. Ton agent récupère un événement, fouille dans sa mémoire, ressort un contexte, puis déclenche un outil ou envoie un message sur un canal. Et comme tout est embarqué, tu n’ajoutes pas une dépendance réseau de plus. Pour l’edge, c’est souvent la différence entre « ça marche partout » et « ça marche sauf quand le lien est capricieux ».

La nuance, c’est que « pas de base externe » ne veut pas dire « illimité ». Une mémoire embarquée, même bien fichue, se heurte aux contraintes physiques: RAM, stockage, et coût CPU. Le choix de NullClaw est cohérent avec sa philosophie, mais il impose de penser petit, propre, ciblé. Si ton cas d’usage demande des millions de documents et des embeddings massifs, tu vas finir par externaliser. NullClaw, lui, vise les agents qui doivent rester autonomes et sobres.

22+ providers, 18 canaux, sandbox: le côté « framework complet »

Le piège des projets ultra légers, c’est d’être des démos. NullClaw essaie d’éviter ça en listant une pile de fonctionnalités: 22+ providers, 18 channels, 18+ tools, subagents, streaming, voice, MCP, tunnels, support de périphériques matériels, et une sandbox multi-couche. Sur le papier, ça ressemble à un framework d’agent « sérieux », juste compressé et compilé au maximum.

Le tableau de comparaison publié autour du projet est aussi un message politique: tu peux avoir un framework agentique en TypeScript avec « >1 GB » de RAM et un démarrage « >500 s » sur un CPU 0,8 GHz, ou viser une approche Zig à 1 Mo et quelques millisecondes. Les chiffres sont ce qu’ils sont, mais l’idée est claire: arrêter de considérer normal d’embarquer une usine à gaz pour orchestrer trois appels et deux outils.

Sur la sécurité, NullClaw insiste sur le fait qu’elle est intégrée au design bas niveau, pas rajoutée comme une surcouche. Et la sandbox multi-layer va dans ce sens: tu veux exécuter des outils, parler à des providers, ouvrir des tunnels, parfois toucher au matériel. Si tu fais ça sur l’edge, tu n’as pas le droit à l’à-peu-près. Un agent qui a trop de permissions sur une passerelle, c’est une porte ouverte.

Ma réserve, c’est l’adoption. Zig progresse, mais la majorité des équipes agentiques vivent dans Python. Passer à une stack Zig, c’est un choix culturel, pas juste technique. Tu gagnes en déterminisme, en empreinte, en vitesse de démarrage. Mais tu perds des habitudes, des libs, une partie du recrutement facile. NullClaw a un angle clair: pour l’edge et les environnements contraints, ça peut valoir le coût. Pour le reste, on verra bien qui est prêt à changer de réflexes.