jcode: 20 parallele Coding-Agenten in 91 MB dank gemeinsamem Daemon

Überblick: ein Coding-Agent-Harness, das den Speicherbedarf zur Kernmetrik macht

jcode (1jehuang/jcode) ist ein in Rust geschriebenes Terminal-Harness für Coding-Agenten unter MIT-Lizenz, verfügbar für Linux, macOS und Windows. Das Projekt beschreibt sich in zwei Zeilen: das RAM-effizienteste und das intelligenteste Harness. Es konkurriert mit Claude Code, Codex CLI, OpenCode, GitHub Copilot CLI, Cursor Agent, pi und Antigravity CLI, setzt aber anders an. Die meisten Werkzeuge investieren in Prompts und Tool-Ketten. jcode macht zuerst die Laufzeit selbst extrem leicht und baut darauf einen Gedächtnisgraphen, Multi-Agenten-Zusammenarbeit (Swarm) und schnelles Terminal-Rendering auf.

Die Installation ist eine Zeile: `curl -fsSL https://jcode.sh/install | bash` auf macOS und Linux, `irm https://jcode.sh/install.ps1 | iex` in der PowerShell unter Windows 11. `/update` in der Oberfläche oder `jcode update` in der Shell lädt die neueste stabile Version im Hintergrund und lädt mit erhaltener Sitzung neu. Das README beschreibt zudem eine Downgrade-Sperre: ältere oder gleiche Versionen werden übersprungen, ein Entwicklungs-Build vergleicht seinen Git-Commit mit dem Release-Tag, und wenn sich die Abstammung nicht prüfen lässt, bricht das Update ab. Der Standardkanal ist `features.update_channel = "stable"`; nur `"main"` folgt dem Quell-Branch.

Kernarchitektur: ein gemeinsamer Daemon, viele schlanke Clients

Die wichtigste Entscheidung: Sitzungen teilen sich einen einzigen Daemon. Das README sagt es bei den Headless-Messungen deutlich: jcode-Sitzungen teilen einen Daemon, Claude Code startet pro Sitzung einen Prozess `claude -p --input-format stream-json`. Das Prozessmodell bestimmt die Steigung der Speicherkurve.

Der Headless-Benchmark des Autors: Jede Sitzung führt fünf echte Modellrunden aus (Dateiliste, Datei lesen, Repository-Suche, Zusammenfassung, Antwort), danach wird die PSS-Summe aller Prozesse gemessen. Beide Werkzeuge nutzten claude-sonnet-4-6. Ergebnisse: Bei 1 Sitzung braucht jcode 32,6 MB, Claude Code 261,0 MB (8,0-fach). Bei 5 Sitzungen 51,0 gegen 908,6 MB (17,8-fach), bei 10 Sitzungen 66,7 gegen 1749,7 MB (26,2-fach), bei 20 Sitzungen 90,6 gegen 3376,8 MB (37,3-fach). Jede zusätzliche Sitzung kostet jcode etwa 3,1 MB und Claude Code etwa 164 MB, rund das 54-Fache. Gemessen wurde am 29.09.2026 mit jcode v0.89.19-dev (Standard-Build ohne lokale Embeddings) und Claude Code 2.1.267. Reproduzierbar mit `python3 scripts/bench_headless_memory.py`.

Entscheidend ist die Steigung. Wer Agenten als massenhaft gestartete Arbeiter nutzt, etwa 20 parallele Aufgaben, braucht mit Claude Code rund 3,4 GB, mit jcode rund 91 MB. Der Speicher begrenzt dann nicht mehr die Parallelität, sondern Modellkontingent und API-Kosten.

Interaktive Leistung: 14 ms bis zum ersten Frame

Das README misst auch die Startlatenz, über 10 interaktive PTY-Starts. Zeit bis zum ersten Frame: jcode 14,0 ms (10,1 bis 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 und Claude Code 3436,9 ms, etwa 245,5-mal langsamer. Zeit bis zur ersten Eingabe: jcode 48,7 ms, Claude Code 3512,8 ms, etwa 72,2-fach.

Die Tabelle zum interaktiven Speicher ist differenzierter. Mit einer Sitzung belegt jcode ohne lokales Embedding 27,8 MB. Mit lokalem Embedding sind es 167,1 MB, gegenüber 144,4 MB bei pi, 140,0 MB bei Codex CLI und 386,6 MB bei Claude Code. Mit aktiviertem lokalem Embedding ist jcode bei einer einzelnen Sitzung also nicht kleiner als pi oder Codex. Der Vorteil zeigt sich beim Skalieren: Bei 10 Sitzungen belegt jcode 260,8 MB (117,0 MB ohne Embedding), Codex CLI 334,8 MB, pi 833,0 MB, Claude Code 2300,6 MB und OpenCode 3237,2 MB. Der Zusatzbedarf je weiterer Sitzung beträgt etwa 10,4 MB bei jcode, 21,6 MB bei Codex CLI, 76,5 MB bei pi, 212,7 MB bei Claude Code und 318,4 MB bei OpenCode.

Gedächtnissystem: Embeddings und Gedächtnisgraph

Die behauptete Intelligenz von jcode stammt vor allem aus dem Agentengedächtnis. Laut README wird jede Runde samt Antwort als semantischer Vektor eingebettet, und in jeder Runde wird ein Graph von Erinnerungen per Kosinus-Ähnlichkeit abgefragt. Treffer fließen in die Unterhaltung ein, oder ein Gedächtnis-Nebenagent prüft sie zuvor auf Relevanz.

Das Schreiben läuft ebenfalls asynchron: bei semantischer Drift, nach K Runden seit der letzten Extraktion oder am Sitzungsende extrahiert ein Nebenagent Erinnerungen und legt sie im Graphen ab. Explizite Gedächtniswerkzeuge erlauben dem Agenten, aktiv zu suchen oder zu speichern, und eine Sitzungssuche bietet klassisches RAG über frühere Sitzungen. Zuletzt konsolidiert der Ambient-Modus die Erinnerungen regelmäßig: Er ordnet sie neu und prüft auf Veralterung und Widersprüche.

Swarm: serverseitig koordinierte Zusammenarbeit

Startet man zwei oder mehr Agenten im selben Repository, verwaltet der Server sie für native Zusammenarbeit. Der Schlüsselmechanismus ist die Konflikterkennung: Ändert Agent A eine Datei, die Agent B gelesen hat, benachrichtigt der Server B. B kann die Meldung ignorieren oder die Datei neu lesen. Agenten können über das Swarm-Werkzeug auch selbst Teammitglieder erzeugen; der Hauptagent wird dann Koordinator, die erzeugten Agenten werden Arbeiter.

Die Konfiguration trennt das Denken der Wurzel vom Aufwand der Arbeiter: `swarm_root_effort` und `swarm_deep_root_effort` im Abschnitt `[agents]` von `~/.jcode/config.toml`, beide standardmäßig `max`, mit den Stufen none, minimal, low, medium, high, xhigh und max. Umgebungsvariablen sind `JCODE_SWARM_ROOT_EFFORT` und `JCODE_SWARM_DEEP_ROOT_EFFORT`. Der Aufwand der Arbeiter (`swarm_effort`) bleibt unberührt.

Anbieter und Ökosystem

jcode unterstützt abonnementbasierte OAuth-Anmeldungen: Claude, OpenAI/ChatGPT/Codex, Google Gemini, GitHub Copilot, Azure OpenAI, Alibaba Cloud Coding Plan, Fireworks, Novita AI, MiniMax, Meta Model API, LM Studio, Ollama und beliebige OpenAI-kompatible Endpunkte. Der Befehl `jcode provider add` legt ein Profil in einem Schritt an; mit `--api-key-stdin` bleibt der Schlüssel aus der Shell-Historie.

Über `extra_body` und die Variable `JCODE_OPENAI_EXTRA_BODY` lassen sich nicht standardisierte Felder einfügen, etwa `chat_template_kwargs`, damit DeepSeek-V4 auf NVIDIA NIM nachdenkt. Anthropic-Messages-kompatible Gateways laufen über Profile vom Typ `anthropic-compatible`. Bei MCP liest jcode `~/.jcode/mcp.json`, `.jcode/mcp.json` sowie die Dateien von Claude Code, unterstützt aber bisher nur stdio-Server: HTTP und SSE werden erkannt und übersprungen.

Grenzen und Beobachtungen

Für Entwickler senkt jcode die Grenzkosten eines parallelen Agenten nahe null. Für Unternehmen erleichtern die Wiederverwendung von OAuth-Abonnements, kompatible Gateways und selbst betriebenes vLLM die Anbindung.

Einige Vorbehalte. Alle Benchmarks stammen vom Projektautor auf dessen eigener Linux-Maschine, eine unabhängige Reproduktion wird nicht genannt, und die Versionen unterscheiden sich je Tabelle (v0.89.19-dev und Claude Code 2.1.267 im Headless-Test; v0.9.1888-dev und Claude Code 2.1.86 in der interaktiven Messung). PSS misst Speicher, nicht Ergebnisqualität: Das „intelligenteste" Harness ist eine Selbstbeschreibung, die diese Zahlen nicht belegen. Der Vorteil hängt vom gemeinsamen Daemon und von der Konfiguration ohne Embedding ab. Ein gemeinsamer Daemon bündelt zudem den Ausfallbereich, was das README nicht behandelt. Wer viele Agenten parallel betreibt, sollte `scripts/bench_headless_memory.py` auf der eigenen Hardware ausführen, bevor er den Zahlen traut.