jcode : 20 agents de code en parallèle dans 91 Mo grâce à un démon partagé

Vue d'ensemble : un harnais d'agent de code qui fait de l'empreinte mémoire une métrique centrale

jcode (1jehuang/jcode) est un harnais d'agent de code pour le terminal, écrit en Rust, sous licence MIT, pour Linux, macOS et Windows. Le projet se résume en deux phrases : le harnais le plus économe en RAM et le plus intelligent. Il évolue face à Claude Code, Codex CLI, OpenCode, GitHub Copilot CLI, Cursor Agent, pi et Antigravity CLI, mais avec un pari différent. La plupart des outils investissent dans les prompts et les chaînes d'outils. jcode commence par alléger à l'extrême l'exécution elle-même, puis ajoute un graphe de mémoire, la collaboration multi-agents (swarm) et un rendu de terminal très rapide.

L'installation tient en une ligne : `curl -fsSL https://jcode.sh/install | bash` sur macOS et Linux, `irm https://jcode.sh/install.ps1 | iex` sous PowerShell sur Windows 11. La commande `/update` dans l'interface, ou `jcode update` dans un shell, télécharge la dernière version stable en arrière-plan et recharge en conservant la session. Le README décrit aussi une politique anti-régression : les versions plus anciennes ou identiques sont ignorées, un build de développement compare son commit Git au tag de version, et si la filiation ne peut pas être vérifiée, la mise à jour s'arrête. Le canal par défaut est `features.update_channel = "stable"` ; seul `"main"` suit la branche source.

Architecture centrale : un démon partagé, des clients légers

Le choix le plus important est que les sessions partagent un seul démon. Le README le dit clairement pour les sessions sans interface (headless) : les sessions jcode partagent un démon, alors que Claude Code lance un processus `claude -p --input-format stream-json` par session. Le modèle de processus fixe la pente de la courbe mémoire.

Le test de l'auteur : chaque session réalise cinq tours réels avec le modèle (liste de fichiers, lecture, recherche dans le dépôt, résumé, réponse), puis on mesure le PSS total de tous les processus. Les deux outils utilisent claude-sonnet-4-6. Résultats : avec 1 session, 32,6 Mo pour jcode contre 261,0 Mo pour Claude Code (8,0 fois) ; avec 5 sessions, 51,0 contre 908,6 Mo (17,8 fois) ; avec 10 sessions, 66,7 contre 1749,7 Mo (26,2 fois) ; avec 20 sessions, 90,6 contre 3376,8 Mo (37,3 fois). Chaque session supplémentaire coûte environ 3,1 Mo à jcode et 164 Mo à Claude Code, soit un facteur d'environ 54. La mesure date du 29 septembre 2026, avec jcode v0.89.19-dev (build par défaut, sans embeddings locaux) et Claude Code 2.1.267. Elle se reproduit avec `python3 scripts/bench_headless_memory.py`.

C'est la pente qui compte. Si vous traitez les agents comme des ouvriers lancés en masse, par exemple 20 tâches parallèles, le modèle de Claude Code demande environ 3,4 Go, celui de jcode environ 91 Mo. La mémoire cesse de limiter le parallélisme ; le quota du modèle et le coût d'API prennent le relais.

Performance interactive : 14 ms jusqu'à la première image

Le README mesure aussi la latence de démarrage sur 10 lancements PTY interactifs. Délai avant la première image : jcode 14,0 ms (de 10,1 à 19,3 ms), Antigravity CLI 383,5 ms, pi 590,7 ms, Codex CLI 882,8 ms, OpenCode 1035,9 ms, GitHub Copilot CLI 1518,6 ms, Cursor Agent 1949,7 ms et Claude Code 3436,9 ms, soit environ 245,5 fois plus lent. Délai avant la première saisie : 48,7 ms pour jcode contre 3512,8 ms pour Claude Code, environ 72,2 fois.

Le tableau de mémoire interactive est plus nuancé. Avec une session, jcode sans embedding local occupe 27,8 Mo ; avec l'embedding local, 167,1 Mo, contre 144,4 Mo pour pi, 140,0 Mo pour Codex CLI et 386,6 Mo pour Claude Code. Avec l'embedding local activé, jcode n'est donc pas plus petit que pi ou Codex pour une seule session. L'avantage apparaît à l'échelle : avec 10 sessions, jcode occupe 260,8 Mo (117,0 Mo sans embedding), Codex CLI 334,8 Mo, pi 833,0 Mo, Claude Code 2300,6 Mo et OpenCode 3237,2 Mo. Le coût par session ajoutée est d'environ 10,4 Mo pour jcode, 21,6 Mo pour Codex CLI, 76,5 Mo pour pi, 212,7 Mo pour Claude Code et 318,4 Mo pour OpenCode.

Système de mémoire : embeddings et graphe de souvenirs

L'intelligence revendiquée par jcode vient surtout de sa mémoire d'agent. Selon le README, chaque tour et chaque réponse sont encodés en vecteur sémantique, et chaque tour interroge un graphe de souvenirs par similarité cosinus. Les résultats sont injectés dans la conversation, ou d'abord vérifiés par un agent annexe de mémoire.

L'écriture est asynchrone : dérive sémantique, K tours depuis la dernière extraction, fin de session. Un agent annexe extrait alors les souvenirs et les range dans le graphe. Des outils de mémoire explicites permettent aussi à l'agent de chercher ou d'enregistrer activement, et une recherche de session offre un RAG classique sur les sessions passées. Enfin, le mode ambiant consolide régulièrement la mémoire : réorganisation, détection de péremption et de conflits.

Swarm : collaboration multi-agents pilotée par le serveur

Lancez deux agents ou plus dans le même dépôt et le serveur les gère pour une collaboration native. Le mécanisme clé est la détection de conflit : quand l'agent A modifie un fichier que l'agent B a lu, le serveur prévient B, qui peut ignorer l'alerte ou relire le fichier. Les agents peuvent aussi appeler l'outil swarm pour créer leurs propres équipiers ; l'agent principal devient coordinateur et les agents créés deviennent ouvriers.

La configuration sépare le raisonnement de la racine et l'effort des ouvriers : `swarm_root_effort` et `swarm_deep_root_effort` dans la section `[agents]` de `~/.jcode/config.toml`, tous deux à `max` par défaut, avec les niveaux none, minimal, low, medium, high, xhigh et max. Les variables d'environnement sont `JCODE_SWARM_ROOT_EFFORT` et `JCODE_SWARM_DEEP_ROOT_EFFORT`. L'effort des ouvriers (`swarm_effort`) reste inchangé.

Fournisseurs et écosystème

jcode prend en charge des connexions OAuth adossées à des abonnements : Claude, OpenAI/ChatGPT/Codex, Google Gemini, GitHub Copilot, Azure OpenAI, Alibaba Cloud Coding Plan, Fireworks, Novita AI, MiniMax, Meta Model API, LM Studio, Ollama et tout point d'accès compatible OpenAI. La commande `jcode provider add` écrit un profil en une étape, avec `--api-key-stdin` pour garder la clé hors de l'historique du shell.

Le champ `extra_body` et la variable `JCODE_OPENAI_EXTRA_BODY` injectent des champs non standard, par exemple `chat_template_kwargs` pour activer la réflexion de DeepSeek-V4 sur NVIDIA NIM. Les passerelles compatibles Anthropic Messages sont gérées par des profils `anthropic-compatible`. Côté MCP, jcode lit `~/.jcode/mcp.json`, `.jcode/mcp.json` ainsi que les fichiers de Claude Code, mais ne gère pour l'instant que les serveurs stdio : HTTP et SSE sont reconnus puis ignorés.

Limites et observations

Pour les développeurs, jcode rapproche de zéro le coût marginal d'un agent parallèle. Pour les entreprises, la réutilisation des abonnements OAuth, les passerelles compatibles et le vLLM auto-hébergé facilitent l'intégration.

Quelques réserves. Tous les benchmarks viennent de l'auteur, sur sa propre machine Linux, sans reproduction indépendante citée, et les versions diffèrent selon les tableaux (v0.89.19-dev et Claude Code 2.1.267 pour le test headless ; v0.9.1888-dev et Claude Code 2.1.86 pour la mesure interactive). Le PSS mesure la mémoire, pas la qualité des résultats : « le plus intelligent » est une auto-description que ces chiffres ne démontrent pas. L'avantage dépend du démon partagé et de la configuration sans embedding. Un démon partagé concentre aussi le domaine de panne, point que le README n'aborde pas. Si vous exploitez de nombreux agents en parallèle, lancez `scripts/bench_headless_memory.py` sur votre propre matériel avant de vous fier aux chiffres.