jcode: Rust-Harness für Coding-Agenten mit 27,8 MB PSS und Schwarmmodus
jcode ist ein Rust-Coding-Agent-Harness mit Repository-Suche, Tool-Ausführung, Sitzungsstatus und Modellanbieter-Unterstützung.
Auf einen Blick
- Was ist das?
- 1jehuang/jcode ist ein in Rust geschriebener Coding-Agent-Harness mit semantischem Speicher, Koordination mehrerer Agenten im selben Repository und breiter Anbieterunterstützung. Der Beitrag prüft die selbst berichteten Messwerte, die Speicherarchitektur und die Konfigurationswege.
- Für wen ist es gedacht?
- Passend ist jcode für Entwickler, die mehrere Agentensitzungen parallel fahren und dabei Speicher und Startzeit im Blick haben, sowie für Umgebungen mit eigenen OpenAI-kompatiblen Endpunkten. Weniger passend ist es für Vorhaben, die eine stabile Schnittstelle über längere Zeit brauchen, denn die Releases stehen bei v0.81.2, und für Teams, die dem Selbstentwicklungsmodus ohne Frontiermodell vertrauen wollen.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Rust, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Was jcode als Rust-Harness für Coding-Agenten mitbringt
Die Beschreibung in den Metadaten ist sachlich und nennt die vier Säulen: Repositorysuche, Werkzeugausführung, Sitzungszustand und Unterstützung für Modellanbieter. jcode ist in Rust geschrieben, steht unter MIT und nutzt master als Standardbranch. Der letzte Push datiert vom 29. August 2026.
Das README formuliert zwei Behauptungen, die ausdrücklich als Eigenangaben zu lesen sind: der speichereffizienteste Harness und der intelligenteste Harness. Beide Aussagen werden nicht belegt, sie stehen als Anspruch über den Messreihen.
Zum Funktionsumfang zählen nach README ein semantisches Vektor-Speichersystem, ein Schwarmmodus für mehrere Agenten im selben Repository, eine integrierte Browser-Automatisierung auf Basis von Firefox Agent Bridge sowie eine Oberfläche mit Seitenleisten, eingebettetem Mermaid-Rendering und Info-Widgets, die ungenutzten Bildschirmplatz füllen.
27,8 MB gegen 386,6 MB: die PSS-Tabelle bei einer Sitzung
Die erste Messreihe vergleicht den Speicherbedarf bei einer aktiven Sitzung. Als Vergleichsgröße dient PSS. jcode mit abgeschaltetem lokalem Embedding liegt bei 27,8 MB und bildet die Bezugsgröße. Mit eingeschaltetem lokalem Embedding nennt das README 167,1 MB, also das Sechsfache.
Die übrigen Werte derselben Tabelle: pi bei 144,4 MB, Codex CLI bei 140,0 MB, OpenCode bei 371,5 MB, GitHub Copilot CLI bei 333,3 MB, Cursor Agent bei 214,9 MB, Claude Code bei 386,6 MB, Antigravity CLI bei 243,7 MB. Damit liegt jcode mit aktivem Embedding im Mittelfeld, nicht an der Spitze.
Genau dieser Unterschied ist für die Einordnung wichtiger als der Spitzenwert. Die Zahl, mit der das Projekt wirbt, setzt eine Konfigurationsentscheidung voraus, die den Speicherbedarf laut eigener Tabelle versechsfacht. Wer die 27,8 MB nachvollziehen will, muss das lokale Embedding abschalten und damit auf die semantische Suche im Speicher verzichten.
Von 27,8 MB zu 117 MB: was zehn Sitzungen kosten
Die zweite Tabelle skaliert auf zehn gleichzeitig aktive Sitzungen. jcode ohne lokales Embedding steigt von 27,8 auf 117,0 MB. Rechnerisch kommen damit rund 9,9 MB je zusätzlicher Sitzung hinzu, was für ein Rust-Programm mit getrennten Prozessen plausibel ist.
Bei jcode mit lokalem Embedding sind es 260,8 MB. Codex CLI liegt bei 334,8 MB, pi bei 833,0 MB, Antigravity CLI bei 1021,2 MB, Cursor Agent bei 1632,4 MB, GitHub Copilot CLI bei 1756,5 MB, Claude Code bei 2300,6 MB und OpenCode bei 3237,2 MB.
Das README begründet die ganze Übung mit dem Betrieb vieler Sitzungen gleichzeitig. Die Tabelle stützt das: Der Abstand zu den großen Werkzeugen wächst mit der Sitzungszahl, nicht mit der Einzelsitzung. Bei einer Sitzung liegen fünf der acht Vergleichswerte unter 250 MB, bei zehn übersteigen fünf davon 800 MB.
14,0 ms bis zum ersten Bild und die PTY-Messgrundlage
Die dritte Reihe misst die Zeit bis zum ersten Bild. jcode steht bei 14,0 Millisekunden mit einer Streubreite von 10,1 bis 19,3 Millisekunden. Antigravity CLI folgt mit 383,5 ms, pi mit 590,7 ms, Codex CLI mit 882,8 ms, OpenCode mit 1035,9 ms, GitHub Copilot CLI mit 1518,6 ms, Cursor Agent mit 1949,7 ms und Claude Code mit 3436,9 ms, dessen Spanne von 2032,7 bis 8927,2 ms reicht.
Zur Methode steht ein einziger Satz im README: gemessen auf diesem Linux-Rechner über zehn interaktive PTY-Starts. Welche Hardware, welche Prozessorlast, welcher Dateisystemcache und welche Versionen der Vergleichswerkzeuge beteiligt waren, ist in der Dokumentation nicht angegeben.
Auch die Definition des ersten Bildes bleibt unerklärt. Für den Alltag heißt das: Die Reihenfolge der Werkzeuge ist plausibel, die absoluten Werte sind ohne Nachmessung nicht übertragbar. Eine eigene Messung über jcode bench oder die Seite unter jcode.sh/bench fehlt in diesem Ausschnitt.
Kosinus-Ähnlichkeit im Speichergraphen und der Nebenagent
Der Speicher arbeitet laut README über Vektoren. Jede Runde oder Antwort wird als semantischer Vektor eingebettet. Jede Runde fragt einen Graphen von Erinnerungen per Kosinus-Ähnlichkeit ab und sucht verwandte Einträge.
Die gefundenen Erinnerungen wandern in die Konversation. Optional prüft ein Speicher-Nebenagent die Relevanz und kann vor dem Einfügen weitere Recherchen anstellen. Wann Extraktion und Speicherung stattfinden, ist an Ereignisse geknüpft: semantische Drift, eine Zahl von Runden seit der letzten Extraktion oder das Ende einer Sitzung.
Zusätzlich gibt es ausdrückliche Speicherwerkzeuge für aktives Suchen und Ablegen sowie eine Sitzungssuche für klassisches RAG über frühere Sitzungen. Im Umgebungsmodus erfolgt eine automatische Konsolidierung, die auf Veraltung und Widersprüche prüft. Diese letzte Eigenschaft ist die aufschlussreichste, weil ein Vektorspeicher ohne Widerspruchsprüfung mit der Zeit veraltete Fakten einspeist.
Schwarmmodus: zwei Agenten im selben Repository und der Server als Schiedsstelle
Im Schwarmmodus lassen sich laut README zwei oder mehr Agenten im selben Repository starten. Der Server hält sie zusammen und übernimmt eine Aufgabe, die bei parallelen Agenten sonst Konflikte erzeugt: Bearbeitet Agent A eine Datei, die Agent B gelesen hat, benachrichtigt der Server B. Der prüft den Diff und entscheidet, ob ein Konflikt vorliegt.
Kommunikation läuft auf drei Wegen. Agenten schreiben sich direkt, senden an alle vom Server gehosteten Agenten oder beschränken sich auf das eigene Repository. Außerdem können Agenten selbstständig Unteragenten starten, womit der Hauptagent zum Koordinator wird.
Das README nennt beide Betriebsarten, headless und mit Oberfläche. Welche Konflikte der Server erkennt und welche er durchlässt, wird nicht ausgeführt; die beschriebene Mechanik betrifft gelesene Dateien, nicht gleichzeitige Schreibzugriffe auf dieselbe Datei.
config.toml, ~/.jcode/mcp.json und die Login-Schalter ohne Browser
Bei den Anbietern ist die Liste lang. Das README nennt Abo-OAuth-Verfahren sowie Claude, OpenAI, Google Gemini, GitHub Copilot, Azure OpenAI und Alibaba Cloud Coding Plan, dazu den Aggregator OpenRouter und lokale Laufzeiten wie Ollama und LM Studio.
Für eigene OpenAI-kompatible Endpunkte gibt es drei Wege: benannte Profile, Überschreibungen über Umgebungsvariablen und ein extra_body-Mechanismus für Felder außerhalb des Standards. Die MCP-Konfiguration liegt getrennt von config.toml, global unter ~/.jcode/mcp.json und je Projekt unter .jcode/mcp.json.
Für Sitzungen ohne Browser oder über SSH sind drei Schalter dokumentiert: --no-browser, --print-auth-url und --callback-url. Installiert wird über curl -fsSL https://jcode.sh/install | bash auf macOS und Linux, über irm https://jcode.sh/install.ps1 | iex unter Windows 11, ergänzt um Homebrew und Quellbau.
Selbstentwicklungsmodus und was v0.81.2 offenlässt
Die ungewöhnlichste Funktion erlaubt dem Agenten, am eigenen Quelltext zu arbeiten. Das README beschreibt eine Infrastruktur, mit der jcode seinen eigenen Binärcode bearbeiten, bauen, testen und neu laden kann, um danach die Arbeit fortzusetzen. Die Warnung steht im selben Absatz: Die Codebasis ist komplex, und schwächere Modelle können subtile Brüche einbauen. Empfohlen wird ein Frontiermodell.
Die Releases stehen bei v0.81.2 vom 29. August 2026, v0.81.1 und v0.81.0 beide vom 26. August 2026. Eine Versionsnummer unter 1.0 ist keine Aussage über Qualität, aber ein Hinweis darauf, dass sich Schnittstellen noch ändern können.
Als Vergleichsgröße dient Claude Code, das in allen drei Tabellen des README auftaucht. Der Unterschied liegt im Ansatz: Dort steht ein einzelner Agent mit eigenem Kontext im Vordergrund, während jcode den Speicher als Graphen führt und mehrere Agenten über einen Server koordiniert. Dazu kommen getrennte MCP-Dateien statt einer einzigen Konfiguration. Die MIT-Lizenz erlaubt den Einsatz in kommerziellen Umgebungen, sofern der Lizenztext mitgeführt wird; zu Sicherheit und Support sagt sie nichts.
Redaktionelles Fazit
Passend ist jcode für Entwickler, die mehrere Agentensitzungen parallel fahren und dabei Speicher und Startzeit im Blick haben, sowie für Umgebungen mit eigenen OpenAI-kompatiblen Endpunkten. Weniger passend ist es für Vorhaben, die eine stabile Schnittstelle über längere Zeit brauchen, denn die Releases stehen bei v0.81.2, und für Teams, die dem Selbstentwicklungsmodus ohne Frontiermodell vertrauen wollen. Vor dem Umstieg gehört ein eigener Messlauf: jcode run mit deaktiviertem lokalem Embedding gegen das bisherige Werkzeug stellen und die PSS-Werte auf der eigenen Maschine erheben, statt die Tabelle aus dem README zu übernehmen.
Community-Notizen