zerostack: ein Rust-Coding-Agent mit Fokus auf Speicherverbrauch
Lightweight coding agent written in Rust, optimized for memory footprint and performance
Auf einen Blick
- Was ist das?
- zerostack ist ein in Rust geschriebener Coding-Agent, der sich über Speicherbedarf und Binärgröße definiert. Die README nennt konkrete Zahlen, lässt aber viele Fragen zu Build, Providern und Reifegrad offen.
- Für wen ist es gedacht?
- Wer auf einer Maschine mit wenig RAM arbeitet oder einen Agenten mit kleiner Binärgröße und ohne Node-Laufzeit sucht, findet in zerostack einen Kandidaten, der sich per cargo install zerostack oder über den Install-Skript installieren lässt. Wer Windows produktiv einsetzt, sollte zuerst einen anderen Agenten wählen, denn die README schreibt, Windows sei in keiner Weise getestet.
- Darf ich es kommerziell nutzen?
- Ja, unter Bedingungen. GPL-3.0 ist eine Copyleft-Lizenz: Wenn Sie Software weitergeben, die sie enthält, müssen Sie deren Quellcode unter derselben Lizenz veröffentlichen. Wer sie nur intern betreibt, ohne sie weiterzugeben, löst diese Pflicht nicht aus.
- 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
Wen das Speicherargument tatsächlich adressiert
Die README positioniert zerostack über eine Zahl: rund 16 MB RAM im Durchschnitt, Spitzen bei etwa 24 MB. Dem stellt sie etwa 300 MB mit Spitzen um 700 MB für opencode und andere JS-basierte Agenten gegenüber. Gemessen wurde laut README auf einem Intel i5 der siebten Generation, mit 0,0 Prozent CPU im Leerlauf und rund 1,5 Prozent bei Tool-Nutzung. Das ist die Zielgruppe: Entwickler auf älterer Hardware, in Containern mit engen Limits oder auf Servern, auf denen ein Agent parallel zu Builds und Testläufen existieren muss. Wer ohnehin auf einer Workstation mit 64 GB arbeitet, gewinnt durch diese Zahlen wenig. Der eigentliche Nutzen liegt nicht in der Zahl selbst, sondern darin, dass der Agent als einzelnes Rust-Binary ohne Node-Laufzeit ausgeliefert wird. Das entfernt eine ganze Klasse von Deployment-Fragen, etwa die nach der Node-Version im CI-Image. Die Kehrseite: Die README nennt keine Messmethode und keine Reproduktionsschritte. Wer die Zahlen als Einkaufsargument braucht, muss sie selbst nachmessen.
Wie der Agent aufgebaut ist: Provider, Tools, Subagents
Die README beschreibt zerostack als minimalen Agenten, inspiriert von pi und opencode. Als Provider nennt sie OpenRouter, OpenAI, Anthropic, Gemini, Ollama sowie eigene Provider. Die Tool-Auswahl folgt laut README den Standard-Tools, wie sie die opencode-Dokumentation beschreibt. Das ist eine bewusste Designentscheidung: kein eigenes Tool-Vokabular, sondern Anlehnung an ein bestehendes. Für Subagents nennt die README Parallelität und Geschwindigkeit beim Erkunden einer Codebasis. Ein zweiter Mechanismus ist ARCHITECTURE.md, das die README als Begleitdatei zu AGENTS.md beschreibt und als gemeinsam genutztes Kernwissen für alle Agenten, die an derselben Codebasis arbeiten. Dazu kommen Prompt-Modi, die zur Laufzeit wechseln, sowie Prompt-Chaining von brainstorm über plan und code bis review, wobei jeder Übergang einzeln konfigurierbar ist. Die README liefert zu keinem dieser Mechanismen ein Datenflussdiagramm oder ein Sequenzbeispiel. Wer verstehen will, wie ein Subagent einen Prompt erhält und wie dessen Ergebnis zurück in die Hauptsitzung gelangt, findet in der README keine Antwort, sondern nur den Verweis auf einen Blogpost zur Subagent-Architektur.
Installation und der Unterschied zwischen Standard- und All-Features
Drei Wege sind dokumentiert. Der Installer lautet curl -fsSL https://raw.githubusercontent.com/gi-dellav/zerostack/main/install.sh | bash, alternativ ein Tarball aus den GitHub Releases. Über Cargo installiert man mit cargo install zerostack; die README nennt als Standard-Features loop, git-worktree, mcp, subagents, archmd, status-signals und multithread. Für alles zusammen steht cargo install zerostack --all-features, für eine gezielte Auswahl cargo install zerostack --features acp,memory,hooks,advisor. Das ist der wichtigste Punkt der Installationsanleitung: acp, memory, hooks und advisor sind nicht im Standard enthalten. Wer persistente Memory über MEMORY.md erwartet oder Hooks über settings.json nutzen will, muss sie beim Build anfordern. Homebrew ist über brew tap gi-dellav/tap, brew trust gi-dellav/tap und brew install zerostack dokumentiert, wobei brew trust ab Homebrew 6.0.0 erforderlich ist. Für Nix zeigt die README nix-run mit dem Tarball der main-Branch sowie ein Overlay unter nix/overlay. Nach der Installation empfiehlt die README, /prompt autoconfig auszuführen, um die Dokumentation zu erkunden und die Konfiguration interaktiv zu setzen.
Sandbox: Rückfall auf ungeschützte Ausführung
Der Sandbox-Modus ist der einzige Bereich, in dem die README ein Fehlerverhalten offenlegt. Mit --sandbox laufen Bash-Befehle in einer isolierten Umgebung, wahlweise über bubblewrap oder über zerobox. bubblewrap ist Linux-only; unter macOS setzt man zerobox und schreibt sandbox-backend = "zerobox" in die Konfiguration. Entscheidend ist der Satz, dass --sandbox als best effort gilt: Fehlt das Backend-Binary, werden Bash-Befehle weiterhin ausgeführt, nur ohne Sandbox und mit einer Warnung im Log. Wer sich auf die Isolation verlässt, ohne sie zu prüfen, arbeitet also im Zweifel ungeschützt. Dagegen hilft --sandbox-required oder sandbox-required = true in der Konfiguration, was laut README aus dem Rückfall einen Fehler macht. Die README beschreibt die Sandbox ausdrücklich als Schutz gegen versehentliche Befehle, nicht als Grenze gegen nicht vertrauenswürdigen Code. Wer ungeprüfte Skripte oder fremde Repositories durch den Agenten laufen lässt, sollte diesen Unterschied ernst nehmen: bubblewrap oder zerobox begrenzen den Schaden eines Tippfehlers, nicht die Absicht eines Angreifers.
Was die README nicht beantwortet
Die Liste der offenen Punkte ist lang genug, um sie als eigenes Risiko zu behandeln. Es gibt keine Angabe zu unterstützten Rust-Versionen, keine Aussage zu Testabdeckung, kein Sicherheitsmodell für die Provider-Anbindung und keine Beschreibung, wie API-Schlüssel abgelegt werden. Die README verweist für Memory, Subagents und den Zwei-Wochen-Bau auf vier Blogposts, was die Dokumentation in diesem Repository dünn macht. Der Hinweis zu Windows ist eindeutig: nicht getestet, Fehlerberichte willkommen. Für Teams mit gemischten Arbeitsplätzen ist das ein Ausschlusskriterium, nicht ein Detail. Auch die Feature-Gates sind ein Reibungspunkt: Wer eine Distribution oder ein Homebrew-Paket nutzt, bekommt die dort gewählte Feature-Kombination und kann sie nicht ohne eigenen Build ändern. Die Permission-Modi werden als fünf konfigurierbare Modi mit Per-Tool-Mustern, Session-Allowlists und konfigurierbaren Regeln beschrieben, aber die README nennt weder die Namen der Modi noch ein Beispiel für ein Muster. Für ein Werkzeug, das Bash-Befehle ausführt, ist das die wichtigste fehlende Angabe.
Alternative: Claude Code und der Unterschied im Ansatz
Die naheliegende Alternative ist Claude Code, und die README selbst macht die Verbindung explizit: Das settings.json-Schema der Lifecycle-Hooks wird als weitgehend kompatibel mit Claude Code hooks beschrieben. Der Unterschied liegt nicht im Funktionsumfang, sondern in der Verteilung. Claude Code kommt als Node-Anwendung und bindet an einen Anbieter. zerostack ist ein Rust-Binary mit mehreren Providern, darunter Ollama für lokale Modelle, und lässt sich über Cargo mit selbst gewählten Features bauen. Wer bereits in der Claude-Code-Welt lebt, gewinnt durch einen Wechsel wenig, außer der Hook-Kompatibilität und einer geringeren Speicherlast. Wer dagegen ein lokales Modell über Ollama betreiben will oder in einer Umgebung ohne Node arbeitet, für den ist der Ansatz grundlegend anders. Ein zweiter Vergleichspunkt ist opencode, das die README als Inspiration nennt und als JS-basierten Agenten mit den genannten Speicherwerten einordnet. Die Tool-Oberfläche orientiert sich laut README an der opencode-Dokumentation, sodass ein Umstieg auf Werkzeugebene vertraut wirken dürfte. Ob Prompts, Sessions und Konfiguration ebenso übertragbar sind, sagt die README nicht.
Pflegeaufwand, Lizenz und Release-Tempo
Die Release-Historie zeigt v1.8.2, v1.8.3 und v1.8.4 innerhalb von drei Tagen Anfang September 2026, der letzte Push liegt bei 2026-09-09. Ein solches Tempo bedeutet häufige Updates und damit einen realen Pflegeaufwand, wenn man zerostack in einer Teamumgebung verteilt. Bei Installation über Cargo oder Homebrew fällt dieser Aufwand beim Aktualisieren an, bei einem selbstgebauten Binary mit eigener Feature-Auswahl zusätzlich beim Nachziehen der Features. Die Lizenz ist GPL-3.0. Wer zerostack nur intern einsetzt, hat damit in der Regel keine Weitergabepflicht für eigene Skripte. Wer den Agenten jedoch in ein Produkt einbettet oder modifiziert weiterverbreitet, muss die Bedingungen der GPL-3.0 prüfen, insbesondere die Pflicht, den Quellcode abgeleiteter Werke unter derselben Lizenz verfügbar zu machen. Das ist keine Rechtsberatung, sondern der Hinweis, dass die Lizenzwahl bei einem Werkzeug, das fremde Modelle und Tools ansteuert, vor einer Produktintegration geklärt werden sollte. Der gated Charakter von acp, memory, hooks und advisor bedeutet zusätzlich, dass diese Teile in einem verteilten Binary möglicherweise gar nicht enthalten sind, je nachdem, wie es gebaut wurde.
Redaktionelles Fazit
Wer auf einer Maschine mit wenig RAM arbeitet oder einen Agenten mit kleiner Binärgröße und ohne Node-Laufzeit sucht, findet in zerostack einen Kandidaten, der sich per cargo install zerostack oder über den Install-Skript installieren lässt. Wer Windows produktiv einsetzt, sollte zuerst einen anderen Agenten wählen, denn die README schreibt, Windows sei in keiner Weise getestet. Vor dem Einsatz lohnt es sich, cargo install zerostack --all-features gegen die Standard-Featureliste zu prüfen, damit acp, memory, hooks und advisor überhaupt im Binary landen, und danach /prompt autoconfig auszuführen, um die Konfiguration zu sichten. Ein Punkt bleibt offen: Die README nennt RAM- und CPU-Werte, ohne Messmethode oder Reproduktionsschritte, also sollten eigene Messungen auf der Zielhardware vor jeder Entscheidung stehen.
Community-Notizen