zerostack : un agent de codage Rust qui tient dans 16 Mo de RAM

Le problème visé : la mémoire des agents de codage

Les agents de codage pilotés par LLM sont souvent distribués comme applications Node.js. Le README de zerostack chiffre l'écart : environ 16 Mo de RAM en moyenne, avec des pics à 24 Mo, contre environ 300 Mo avec des pics à 700 Mo pour opencode ou d'autres agents JavaScript. Ces chiffres proviennent du projet lui-même et n'ont pas été reproduits ici. Ils sont annoncés comme mesurés sur un Intel i5 de 7e génération, avec une consommation CPU de 0,0 % au repos et environ 1,5 % pendant l'usage des outils, contre environ 2 % au repos et 20 % en travail pour opencode.

La cible est donc identifiable : une machine modeste, un conteneur de développement, un serveur distant, un poste où faire tourner un runtime JavaScript complet aux côtés de l'éditeur et du serveur de langage devient pénible. Le projet revendique environ 30 000 lignes de code pour le cœur, hors tests, et un binaire de 26 Mo. Ce dernier point mérite d'être noté : la frugalité concerne la RAM en cours d'exécution, pas la taille sur disque. Un binaire de 26 Mo n'est pas petit au sens strict, et le README ne détaille pas la répartition entre code, dépendances statiques et ressources embarquées.

Ce que le binaire contient réellement : les feature flags

La particularité de zerostack tient moins à son langage qu'à son découpage. Le README liste les fonctions en deux catégories. D'un côté celles présentes par défaut : multi-fournisseurs (OpenRouter, OpenAI, Anthropic, Gemini, Ollama, plus des fournisseurs personnalisés), outils standard, système de permissions, gestion de sessions, interface terminal basée sur crossterm, sous-agents, boucles Ralph Wiggum, intégration des Git worktrees, chaînage de prompts, et signaux d'état émis sur une socket Unix.

De l'autre, quatre fonctions explicitement marquées comme gated, c'est-à-dire conditionnées à la compilation : le support ACP, la mémoire persistante, les hooks de cycle de vie et l'advisor. La commande d'installation cargo par défaut active cette liste : loop, git-worktree, mcp, subagents, archmd, status-signals, multithread. Ni acp, ni memory, ni hooks, ni advisor n'y figurent. Il faut donc les demander explicitement avec --features acp,memory,hooks,advisor, ou tout activer avec --all-features.

C'est un choix de conception défendable pour la taille et la surface d'attaque, mais il a une conséquence pratique : deux utilisateurs du même numéro de version peuvent avoir des capacités différentes. Un binaire installé par le script d'installation et un binaire compilé à la main ne se comportent pas forcément de la même façon. Le README ne précise pas quelles fonctionnalités le script active, ce qui laisse la question ouverte.

Mémoire persistante et hooks : le mécanisme décrit

La mémoire persistante est décrite comme du Markdown brut réparti sur plusieurs fichiers : un MEMORY.md global, plus, par projet, des journaux quotidiens, un scratchpad et des notes. Le point d'architecture important est la dernière étape : ce contenu est injecté dans le prompt système à chaque session. Il ne s'agit donc pas d'un système de récupération à la demande, mais d'une inclusion systématique. Le coût en tokens est proportionnel à ce que vous accumulez, et rien dans le README n'indique de mécanisme d'élagage automatique de ces fichiers. Un journal quotidien qui grossit pendant des mois finit par consommer une part fixe de la fenêtre de contexte à chaque démarrage.

Les hooks de cycle de vie suivent une autre logique : des commandes externes peuvent observer ou bloquer les appels d'outils, les prompts et les événements de session. Le README indique que le schéma de settings.json est largement compatible avec les hooks de Claude Code. Cette compatibilité est un argument d'adoption réel pour qui a déjà des scripts de ce type, mais le mot largement signale aussi que la reprise telle quelle n'est pas garantie.

L'advisor est un second modèle consultable en cours de session pour un avis stratégique, avec un mode de passage à l'humain optionnel. Le README ne documente pas la façon dont ce second modèle est configuré ni facturé, ce qui est une lacune pour une fonction qui implique un deuxième fournisseur.

Installation : quatre chemins et un piège

Le script est présenté comme la méthode recommandée :

curl -fsSL https://raw.githubusercontent.com/gi-dellav/zerostack/main/install.sh | bash

Cargo reste la voie la plus contrôlable, puisque c'est la seule qui rend les feature flags visibles :

cargo install zerostack cargo install zerostack --all-features cargo install zerostack --features acp,memory,hooks,advisor

Homebrew demande une étape supplémentaire depuis Homebrew 6.0.0, la commande brew trust gi-dellav/tap, avant brew install zerostack. Le paquet multistack, gestionnaire d'agents parallèles, s'installe séparément. Nix est supporté via nix-run sur l'archive de la branche main, ou par overlay.

Le piège concerne le sandbox. --sandbox s'appuie sur bubblewrap, qui est Linux uniquement. Sur macOS, il faut installer zerobox avec cargo install zerobox puis définir sandbox-backend = "zerobox". Et le README est explicite : --sandbox est best effort. Si le binaire du backend est absent, les commandes bash s'exécutent quand même, sans isolation, avec un avertissement dans les journaux. Pour transformer cet avertissement en refus, il faut --sandbox-required ou sandbox-required = true dans la configuration. Le README qualifie lui-même le sandbox de ceinture de sécurité, pas de frontière contre du code non fiable. C'est une distinction à prendre au sérieux.

Deux limites que la documentation assume mal

La première est Windows. Le README écrit que le support Windows n'est testé d'aucune manière, en invitant à ouvrir une issue en cas de bug. Ce n'est pas une réserve de politesse : c'est l'absence de toute validation annoncée. Pour une équipe sous Windows, zerostack est un pari, pas un outil.

La seconde est le rythme de publication. Trois versions en trois jours, v1.8.2 le 6 septembre, v1.8.3 le même jour en soirée, v1.8.4 le 7 septembre, pour un dernier push le 9 septembre. Un tel rythme signale un projet actif, mais aussi une surface qui bouge vite. Le README ne mentionne ni politique de compatibilité, ni période de support pour les versions antérieures. Un utilisateur qui compile avec des feature flags spécifiques devra refaire cette compilation à chaque mise à jour, et rien ne garantit que le schéma de settings.json ou le format des fichiers de mémoire reste stable entre deux versions mineures.

Il faut ajouter une troisième réserve, plus discrète : la compatibilité annoncée des hooks avec Claude Code est décrite comme largement compatible. Ce mot laisse entendre des écarts possibles, sans les lister.

Face à opencode et pi : la différence n'est pas le langage

Le README cite deux sources d'inspiration, pi et opencode, et se compare directement à opencode sur les chiffres de mémoire. La différence d'approche ne se réduit pas à Rust contre JavaScript. Elle porte sur la stratégie de distribution : opencode et les agents de la même famille visent une installation unique et complète, où toutes les fonctions sont disponibles dès l'installation. zerostack fait l'inverse, en découpant le binaire et en repoussant ACP, mémoire, hooks et advisor derrière des flags.

Le compromis est lisible. Vous gagnez un contrôle fin sur ce qui est compilé et une empreinte mémoire annoncée bien plus basse. Vous perdez la simplicité : un nouvel arrivant qui installe via le script recommandé obtient un binaire dont il ne connaît pas la liste exacte de fonctionnalités, et qui ne correspond peut-être pas à ce que décrit la documentation. Pour un utilisateur qui veut la mémoire persistante, la voie cargo avec --features memory est le seul chemin documenté, et il suppose une chaîne de compilation Rust fonctionnelle.

Sur les fonctions elles-mêmes, zerostack ne se distingue pas par l'invention : outils standard, sessions, sous-agents, MCP, worktrees et permissions existent ailleurs. Le projet se positionne sur le coût d'exécution et sur la compatibilité avec les conventions de Claude Code plutôt que sur des capacités inédites.

Licence, maintenance et coût de mise à jour

zerostack est publié sous GPL-3.0. Concrètement, si vous redistribuez le binaire ou une version modifiée, la licence impose de fournir le code source correspondant sous les mêmes termes. Pour un usage interne en entreprise, cela ne change rien. Pour intégrer zerostack dans un produit distribué, ou pour le lier à du code propriétaire, la question se pose et mérite un examen par une personne compétente : je ne donne pas d'avis juridique ici, et le README n'aborde pas ce point.

Le coût de maintenance a deux composantes. La première est la compilation : chaque mise à jour implique de rejouer cargo install avec la même liste de features, sous peine de perdre silencieusement la mémoire, les hooks ou l'ACP. La seconde est la configuration : settings.json porte les politiques de permissions, les hooks et le backend de sandbox. Un projet qui bouge au rythme observé en septembre 2026 impose de relire les notes de version avant de mettre à jour, en particulier si vous dépendez du format des hooks ou des fichiers MEMORY.md.

Un point de vérification utile avant tout déploiement : lancer /prompt autoconfig dans l'agent, que le README présente comme le moyen d'explorer la documentation et de configurer l'outil de façon interactive. C'est aussi le moyen le plus direct de constater quelles fonctionnalités votre binaire contient réellement.

Conclusion éditoriale

zerostack vise les développeurs qui travaillent sur des machines contraintes en RAM et qui acceptent de compiler eux-mêmes les fonctions avancées : les feature flags acp, memory, hooks et advisor ne sont pas dans l'installation cargo par défaut. Ceux qui veulent une configuration fonctionnelle sans toucher à cargo, ou qui dépendent de Windows, devraient passer leur chemin, la prise en charge de Windows n'étant pas testée selon le README. Avant d'adopter, vérifiez deux choses concrètes : que votre backend de sandbox est bien présent sur le PATH, sans quoi les commandes bash s'exécutent sans isolation, et que les quatre fonctions citées ci-dessus sont bien compilées dans votre binaire.

Sources officielles

1. gi-dellav/zerostack on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases