nullClaw en Zig a dépassé OpenClaw sur la consommation mémoire et le démarrage lors de tests locaux d’agents AI

NullClaw — un runtime d'agent sur Zig sous forme d'un seul binaire — montre qu'un agent AI local n'a pas besoin de traîner une pile lourde avec lui. Dans les tests comparatifs avec OpenClaw, le projet démarrait plus vite et consommait un ordre de magnitude moins de mémoire, en particulier dans les tâches parallèles.

Pourquoi Zig ici

L'idée principale de l'article n'est pas de déclarer NullClaw le vainqueur absolu parmi toutes les plates-formes d'agents. L'auteur le compare avec OpenClaw uniquement dans de brefs scénarios locaux : commandes de service, une unique agent-run, une petite tâche de codage et un lot d'exécutions parallèles. Sur ce fond, il devient clair à quel point un agent AI typique coûte cher en tant que processus aujourd'hui.

La plupart de ces systèmes ont Node.js, Python, des dépendances, des services d'arrière-plan et une couche passerelle sous le capot. NullClaw propose une approche différente : un runtime maximalement compact sans surcharge inutile.

D'où le choix de Zig. Le langage est nécessaire ici non pour la mode, mais pour la franchise technique : un seul binaire, contrôle explicite de la mémoire, absence de runtime géré lourd et compilations plus compréhensibles. Dans build.

zig l'auteur note séparément les commutateurs de compile-time pour les canaux et les moteurs de mémoire, ce qui signifie que la compilation peut être adaptée à un scénario spécifique. Ceci est important non seulement pour la vitesse de démarrage, mais aussi pour les déploiements self-hosted et edge, où chaque mégaoctet supplémentaire et chaque dépendance deviennent rapidement un problème pratique.

Chiffres Sans Bruit

Les mesures ont été prises sur un Mac mini M4 avec 16 GB de RAM et 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 », séparément pour les scénarios warm, séparément pour les coding-runs et les tâches parallèles. L'auteur sépare délibérément la surcharge de runtime pure de la latence réseau vers le modèle, car dans ce dernier cas même un runtime très léger se heurte au round-trip externe.

• commande --help : NullClaw — 0,002 s et environ 1,9 MB RSS, OpenClaw — 0,621 s et environ 308 MB
• short agent-run : 2,55 s et environ 7,7 MB contre 3,37 s et environ 567 MB
• small coding-run : 4,86 s et environ 7,7 MB contre 6,64 s et environ 572 MB
• 10 tâches de codage parallèles : 9,3 s et environ 54 MB RSS total contre 13,14 s et environ 523 MB

La différence la plus forte est visible précisément dans la mémoire. En termes de vitesse, NullClaw est souvent plus rapide, mais pas toujours dramatiquement, car certains scénarios sont limités par la réponse du modèle sur le réseau. En même temps, dans les exécutions courtes et parallèles, OpenClaw reste constamment au niveau de centaines de mégaoctets, tandis que NullClaw — au niveau d'une ou de dizaines de mégaoctets. Pour un usage local, cela signifie des exécutions multi-agents moins chères, une charge plus prévisible et moins de friction lors du déplacement entre machines.

Sens Pratique de la Comparaison

L'article fournit également un exemple plus révélateur que des tableaux secs : le projet ClawWatch pour montres intelligentes. Il utilise NullClaw comme binaire ARM statique avec la reconnaissance vocale hors ligne Vosk et TTS intégré, et peut traiter certaines demandes sans appeler le modèle. Ici, la compacité cesse d'être simplement une optimisation agréable. Pour un appareil ayant une limite de mémoire difficile, la différence entre quelques mégaoctets et des centaines de mégaoctets détermine s'il est possible d'intégrer l'agent dans le produit, plutôt que de le faire fonctionner sur un ordinateur portable de développeur.

"Sur une montre intelligente, la différence entre 'quelques

mégaoctets' et 'des centaines de mégaoctets' est la question de 'est-ce que cela rentre du tout?'."

L'auteur note séparément qu'il n'y a pas non plus de magie avec la taille binaire ici. Dans le README pour ReleaseSmall, 678 KB est revendiqué, mais les artefacts de lancement publiés sont nettement plus volumineux : environ 3,9 MB pour macOS arm64 et 3,1 MB pour Linux arm64, avec une compilation locale donnant approximativement 2,6 MB. Mais la conclusion principale ne change pas : la valeur de NullClaw ne réside pas dans le chiffre vedette du README, mais dans la combinaison d'un démarrage rapide, d'un RSS faible et d'une surface fonctionnelle étroite qui est plus facile à contrôler à la fois du point de vue opérationnel et de sécurité.

Ce Que Cela Signifie

NullClaw ramène la conversation sur les agents AI à une question ancrée dans la réalité : combien devrait coûter une exécution de processus ? Si l'infrastructure d'agent se dirige vers edge, self-hosted et tâches parallèles en masse, les runtimes qui économisent la mémoire, démarrent sans pause et ne traînent pas la moitié des dépendances d'un serveur gagneront.