Ce coding agent tourne avec 20 fois moins de mémoire que Claude Code. Gratuit, 18 000 étoiles sur GitHub, et quasiment personne n'en parle.
Chaque coding agent a deux moitiés : le modèle et le harnais. Le harnais, c'est l'atelier dans lequel le modèle travaille. Il contient vos fichiers, vos outils, vos notes, et il les tend à l'IA dès qu'elle en a besoin. La plupart des outils que vous payez font tourner cet atelier sur du JavaScript. Celui-ci est construit en Rust. Résultat : une session tourne avec seulement 28 Mo de RAM. Claude Code, pour le même boulot, est à 387. Et il se souvient tout seul. Pas de config, pas de fichiers de setup. Il sauvegarde discrètement ce qui compte et ressort le bon morceau quand vous en avez besoin.
Mais c'est là que ça change vraiment votre façon de travailler. Normalement, vous lancez un agent sur une tâche et vous attendez. Celui-ci permet aux agents d'embaucher leurs propres coéquipiers. Un agent prend le job, le découpe, fait apparaître les autres, et ils bossent tous sur la même codebase en même temps sans se marcher dessus. Dix sessions qui tournent simultanément, et tout ça tient dans des mégaoctets. C'est ça, le vrai game changer.
Pourquoi la mémoire change tout
Un coding agent qui pompe 387 Mo de RAM par session, ça paraît anodin sur une machine récente. Mais quand vous en lancez trois ou quatre, que vous avez Docker, un IDE, trente onglets de navigateur et un serveur de dev qui tourne en fond, la facture mémoire explose. Votre machine se met à swapper, le ventilateur décolle, et l'agent qui devait vous faire gagner du temps devient la raison pour laquelle tout rame.
28 Mo par session, c'est une autre échelle. C'est plus léger qu'un onglet Chrome vide. Vous pouvez lancer dix agents en parallèle sans que votre ordinateur s'en rende compte. Et ça, ce n'est pas juste un détail technique : ça change ce que vous pouvez faire avec.
La comparaison qui fait mal
Mettons les chiffres côte à côte. Claude Code, une session : 387 Mo. Ce nouvel agent, une session : 28 Mo. Le ratio n'est pas "un peu mieux", il est absurde. Vingt fois moins. Pour le prix mémoire d'une seule session Claude Code, vous en faites tourner treize de cet agent-là. Et il vous reste de la RAM pour le reste.
Ce n'est pas un argument marketing. C'est Rust contre JavaScript. Le runtime JavaScript traîne un poids mort structurel : le moteur V8, le garbage collector, l'écosystème de dépendances qui se chargent en mémoire dès l'instantiation. Rust compile en binaire natif, sans runtime, sans garbage collector. La différence est mécanique, pas cosmétique.
Le harnais : l'atelier que le modèle habite
Tout coding agent a besoin d'un espace de travail. Il doit voir vos fichiers, exécuter des commandes, lire les résultats, se souvenir de ce qui a été fait. Cet espace, c'est le harnais. C'est la couche qui fait le lien entre le modèle de langage et votre machine.
La plupart des outils du marché construisent ce harnais en JavaScript ou TypeScript. C'était le choix évident : l'écosystème est immense, les développeurs sont partout, et Node.js tourne sur tout. Mais ce choix a un coût. Chaque session charge un interpréteur, un tas de modules, et tout ça vit en RAM tant que l'agent travaille.
Rust entre dans l'atelier
Quand vous construisez le harnais en Rust, vous éliminez toute cette couche. Pas de runtime à embarquer. Pas de garbage collector qui décide quand nettoyer. Le binaire est compilé, optimisé, et il fait exactement ce qu'on lui demande sans bagages.
Le résultat, c'est qu'une session complète (fichiers, contexte, historique, outils disponibles) tient dans 28 Mo. Et ce n'est pas une session dégradée ou limitée. C'est le même périmètre fonctionnel, juste sans le gras.
La mémoire qui se souvient toute seule
L'autre morceau qui change tout, c'est la gestion du contexte. Normalement, vous devez configurer ce que l'agent retient. Fichiers de config, prompts système, instructions répétées à chaque session. Cet agent-là ne vous le demande pas. Il sauvegarde ce qui est pertinent et le ramène automatiquement quand le contexte l'exige.
Vous n'avez pas à lui redire quels fichiers sont importants. Vous n'avez pas à lui rappeler les décisions prises il y a trois sessions. Il garde une trace de ce qui compte et la ressort au bon moment. C'est le genre de détail qui paraît mineur sur le papier et qui change tout à l'usage. Le flux de travail n'est plus interrompu par des rappels constants.
Des agents qui embauchent leurs propres coéquipiers
C'est ici que l'architecture devient vraiment intéressante. Le fonctionnement classique d'un coding agent est linéaire : une tâche, un agent, une file d'attente. Vous lui donnez un job, il l'exécute, vous attendez. Si vous avez trois tâches, vous les lancez en séquence ou vous ouvrez trois terminaux et vous priez pour que la RAM tienne.
Ce nouvel outil casse ce modèle. Un agent peut recevoir une tâche complexe, la décomposer en sous-tâches, et faire apparaître d'autres agents pour les traiter. Il devient chef de projet. Il découpe le boulot, le distribue, et tout le monde travaille sur la même codebase en même temps.
Travailler à plusieurs sur le même code sans conflits
Le cauchemar de tout développeur qui a essayé de paralléliser des agents, c'est les conflits. Deux agents qui modifient le même fichier au même moment. Des overwrites silencieux. Des merges qui cassent tout. Un chaos que vous passez plus de temps à débugger qu'à coder.
Ici, le harnais gère la coordination. Les agents ne se marchent pas dessus parce que l'atelier sait qui touche quoi. Le codebase est partagé, mais les accès sont orchestrés. Dix sessions simultanées, toutes actives, et pas un conflit.
Dix sessions, des mégaoctets
C'est le chiffre qui rend tout ça possible. Dix agents qui bossent en parallèle, et l'ensemble tient dans une poignée de mégaoctets. Pas des gigaoctets. Des mégaoctets. Sur une machine normale, sans serveur, sans cloud.
Ça veut dire que vous pouvez lancer un refactoring multi-fichiers avec un agent par module. Ou faire auditer votre code par un agent pendant qu'un autre écrit des tests et qu'un troisième corrige des bugs. Tout ça en même temps, sans que votre machine ne bronche. Le parallélisme n'est plus un luxe de datacenter, c'est un mode de travail par défaut.
Ce que ça change dans le travail quotidien
Les benchmarks et les chiffres de mémoire, c'est bien. Mais la vraie question, c'est ce que ça transforme quand vous codez tous les jours.
D'abord, le feedback loop se raccourcit. Vous n'attendez plus qu'un agent termine pour en lancer un autre. Vous lancez plusieurs choses en parallèle et vous récupérez les résultats d'un coup. Le temps où vous restiez planté à regarder un terminal défiler, c'est fini.
Ensuite, la barrière à l'entrée disparaît. L'outil est gratuit, il tourne sur n'importe quelle machine, et il n'y a pas de setup. Pas de clé API à configurer, pas de fichier YAML à templater, pas de docker-compose à lancer. Vous l'installez, vous lui donnez une tâche, il bosse. C'est le genre de simplicité qui fait qu'un outil passe de "je devrais essayer" à "je l'utilise tous les jours".
Le vrai coût des outils payants
Quand vous payez pour un coding agent hébergé, vous ne payez pas que le modèle. Vous payez l'infrastructure qui fait tourner le harnais en JavaScript, les serveurs qui encaissent les sessions parallèles, la bande passante qui fait l'aller-retour entre votre machine et le cloud. Tout ça se retrouve dans le prix de l'abonnement.
Un outil qui tourne en local sur 28 Mo, il n'a pas besoin de cette infrastructure. Il n'a pas de coût marginal par session. Vous pouvez le lancer autant de fois que vous voulez, la seule limite c'est votre RAM, et avec 28 Mo par session, cette limite est théorique. C'est pour ça qu'il peut être gratuit sans être un produit d'appel dégradé.
L'écosystème open source derrière l'outil
18 000 étoiles sur GitHub, ce n'est pas anodin. C'est un signal fort que la communauté a validé l'approche. Les développeurs qui mettent une étoile sur un repo de coding agent savent exactement ce qu'ils regardent : ils ont testé les alternatives, ils connaissent les limites des outils existants, et ils ont jugé que celui-ci méritait leur attention.
Le fait que l'outil soit open source change aussi la dynamique de confiance. Vous pouvez lire le code du harnais. Vous pouvez vérifier comment la mémoire est gérée, comment les agents sont orchestrés, comment le contexte est sauvegardé. Vous n'avez pas à croire sur parole un papier blanc ou une page de pricing.
Pourquoi personne n'en parle encore
C'est la partie étrange. Un outil gratuit, open source, avec une architecture qui écrase les alternatives payantes sur la mémoire et le parallélisme, et il reste sous les radars. Peut-être parce que le marché est saturé de lancements de coding agents et que le bruit médiatique noie le signal. Peut-être parce que l'équipe derrière passe plus de temps à coder qu'à faire du marketing. Peut-être parce que "écrit en Rust" sonne comme un détail technique alors que c'est la raison structurelle pour laquelle tout le reste fonctionne.
Quelle que soit la raison, le déséquilibre entre la valeur de l'outil et sa notoriété est frappant. 18 000 étoiles, c'est énorme pour un outil de cette catégorie, mais c'est encore minuscule comparé à ce qu'il apporte. La vague n'a pas encore déferlé.
Points clés à retenir
- Une session tourne sur 28 Mo de RAM, contre 387 Mo pour Claude Code : un facteur 20 qui change ce que vous pouvez lancer en parallèle
- Le harnais est construit en Rust, pas en JavaScript, ce qui élimine le runtime et le garbage collector qui plombent la mémoire des alternatives
- Pas de configuration requise : l'agent sauvegarde automatiquement le contexte pertinent et le ramène quand vous en avez besoin
- Un agent peut décomposer une tâche complexe et faire apparaître d'autres agents qui travaillent la même codebase en même temps, sans conflits
- Dix sessions simultanées tiennent dans des mégaoctets, ce qui rend le parallélisme accessible sur une machine locale standard
- L'outil est gratuit, open source, et cumule 18 000 étoiles sur GitHub sans avoir encore percé dans la couverture médiatique
Le plus dingue dans tout ça, c'est peut-être que l'outil existe, qu'il est gratuit, et qu'il dort sur un repo GitHub avec 18 000 étoiles pendant que des gens paient des abonnements mensuels pour des alternatives moins efficaces. Le harnais en Rust n'est pas un argument de niche pour développeurs systèmes. C'est la raison pour laquelle tout le reste (la mémoire, le parallélisme, l'absence de setup) est possible. Et cette raison tient dans un seul chiffre : 28 mégaoctets.