nullClaw, écrit en Zig, devance OpenClaw sur la mémoire et le démarrage dans des tests locaux d'agents IA

NullClaw, un runtime d'agents écrit en Zig et livré sous forme d'un seul binaire, montre qu'un agent IA local n'est pas obligé de traîner une pile logicielle lourde. Lors des tests comparatifs avec OpenClaw, le projet a démarré plus vite et consommé un ordre de grandeur de mémoire en moins, surtout sur les tâches parallèles.

Pourquoi Zig

L'idée centrale de l'article n'est pas de sacrer NullClaw vainqueur absolu parmi toutes les plateformes d'agents. L'auteur le compare à OpenClaw uniquement dans de courts scénarios locaux : commandes utilitaires, une exécution d'agent, une petite tâche de code et un lot d'exécutions parallèles.

Ce cadre met en évidence le coût actuel d'un agent IA ordinaire en tant que processus. La plupart de ces systèmes embarquent Node.js, Python, des dépendances, des services d'arrière-plan et une couche de gateway. NullClaw adopte une autre approche : un runtime aussi compact que possible, sans fioritures.

D'où le choix de Zig. Le langage n'est pas là par effet de mode, mais par franchise d'ingénierie : un binaire, un contrôle explicite de la mémoire, pas de lourd runtime managé et une compilation plus lisible. Dans `build.zig`, l'auteur relève séparément des interrupteurs à la compilation pour les canaux et les moteurs de mémoire, c'est-à-dire que le build peut être réduit à un scénario précis. Cela compte non seulement pour la vitesse de démarrage, mais aussi pour les déploiements auto-hébergés et en périphérie (edge), où chaque mégaoctet superflu et chaque dépendance deviennent vite un problème concret.

Les chiffres, sans bruit

Les mesures ont été effectuées sur un Mac mini M4 avec 16 Go de RAM sous macOS arm64. Les deux projets ont utilisé le même modèle via OpenRouter, et les métriques ont été calculées sur des séries d'exécutions : séparément pour les processus « frais », pour les scénarios warm, et pour les exécutions de code et les tâches parallèles. L'auteur distingue volontairement la surcharge pure du runtime de la latence réseau vers le modèle, car dans ce second cas, même un runtime très léger reste limité par l'aller-retour externe.

• commande `--help` : NullClaw — 0,002 s et environ 1,9 Mo de RSS, OpenClaw — 0,621 s et environ 308 Mo
• exécution courte d'agent : 2,55 s et environ 7,7 Mo contre 3,37 s et environ 567 Mo
• petite exécution de code : 4,86 s et environ 7,7 Mo contre 6,64 s et environ 572 Mo
• 10 tâches de code en parallèle : 9,3 s et environ 54 Mo de RSS cumulée contre 13,14 s et environ 523 Mo

L'écart le plus marqué concerne la mémoire. Côté durée, NullClaw est le plus souvent plus rapide, mais pas toujours de façon spectaculaire, car une partie des scénarios est bornée par la réponse réseau du modèle. Dans les exécutions courtes et parallèles, OpenClaw reste systématiquement à plusieurs centaines de mégaoctets, tandis que NullClaw se maintient à quelques unités ou dizaines. Pour un usage local, cela signifie un lancement multi-agents moins coûteux, une charge plus prévisible et moins de friction lors des transferts entre machines.

Le sens pratique de la comparaison

L'article donne aussi un exemple plus parlant que les tableaux secs : ClawWatch, un projet pour montres connectées. Il utilise NullClaw comme binaire ARM statique, avec la reconnaissance vocale hors ligne Vosk et un TTS intégré, et peut traiter une partie des requêtes sans appeler le modèle. Ici, la compacité cesse d'être une simple optimisation agréable. Pour un appareil soumis à une limite de mémoire stricte, l'écart entre quelques mégaoctets et plusieurs centaines de mégaoctets détermine s'il est possible d'intégrer l'agent dans un produit, et pas seulement de le lancer sur l'ordinateur portable d'un développeur.

«

Sur une montre, la différence entre “quelques mégaoctets” et “des centaines de mégaoctets” décide de la possibilité même de l'intégrer ».

L'auteur précise aussi qu'il n'y a pas de magie dans la taille du binaire. Le README annonce 678 Ko pour ReleaseSmall, mais les artefacts de release publiés sont nettement plus gros : environ 3,9 Mo pour macOS arm64 et 3,1 Mo pour Linux arm64, tandis qu'un build local a donné environ 2,6 Mo. Mais la conclusion principale ne change pas : la valeur de NullClaw ne tient pas au chiffre record du README, mais à l'association d'un démarrage rapide, d'une faible RSS et d'une surface fonctionnelle étroite, plus facile à maîtriser tant sur le plan de l'exploitation que de la sécurité.

Ce que cela signifie

NullClaw ramène le débat sur les agents IA à une question terre à terre : combien doit coûter le lancement d'un processus. Si l'infrastructure d'agents évolue vers l'edge, l'auto-hébergement et les tâches parallèles massives, les gagnants seront les runtimes qui économisent la mémoire, démarrent sans délai et ne traînent pas derrière eux la moitié d'un serveur de dépendances.