Zerostack – Ein von Unix inspirierter Coding-Agent, vollständig in Rust geschrieben

 (crates.io)
1 Punkte von GN⁺ 4 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • zerostack ist ein minimalistischer Coding-Agent, der in Rust geschrieben wurde und mehrere LLM-Anbieter sowie benutzerdefinierte Anbieter unterstützt
  • Er bietet Datei-Lesen, -Schreiben und -Bearbeiten, grep, Dateisuche, Verzeichnislisten, Bash-Ausführung mit Berechtigungs-Gate, MCP und Exa-Web-Tools
  • Er umfasst etwa 7.000 LoC, ein 8,9-MB-Binary, und der RAM-Verbrauch wurde mit etwa 8 MB im leeren Zustand und etwa 12 MB während der Arbeit gemessen; die CPU-Auslastung liegt im Leerlauf bei 0,0 %
  • Standardanbieter ist OpenRouter; die Installation erfolgt mit cargo install zerostack, und für die Bash-Isolierung mit --sandbox wird bubblewrap benötigt
  • Enthält integrierte Prompts wie code, plan und review, vier Berechtigungsmodi, Sitzungsfortsetzung, Iterationsschleifen und Git-worktree-Integration

Überblick über zerostack

  • zerostack ist ein minimalistischer Coding-Agent, der in Rust geschrieben wurde und von pi und opencode inspiriert ist
  • Er besitzt eine Multi-Provider-Architektur mit Unterstützung für OpenRouter, OpenAI, Anthropic, Gemini, Ollama und benutzerdefinierte Anbieter
  • Er bietet Datei-Tools wie Datei-Lesen, -Schreiben und -Bearbeiten, grep, Dateisuche und Verzeichnislisten sowie Bash-Ausführung mit Berechtigungs-Gate
  • Enthalten sind Sitzungs-Speichern, -Laden und -Fortsetzen, automatische Komprimierung zum Erhalt des Kontextfensters, eine Terminal-UI auf Basis von crossterm, MCP-Server-Anbindung und Exa-basierte WebFetch- und WebSearch-Tools
  • Mit /worktree kann zwischen Git-worktrees gewechselt werden; außerdem sind Iterationsschleifen für lang laufende Aufgaben integriert

Leistung und Installation

  • zerostack umfasst etwa 7.000 LoC, und die Binary-Größe beträgt 8,9 MB
  • Der RAM-Verbrauch liegt bei etwa 8 MB in einer leeren Sitzung und etwa 12 MB während der Arbeit; verglichen wird das mit rund 300 MB bei opencode oder anderen JS-basierten Coding-Agenten
  • Die CPU-Auslastung wurde im Leerlauf mit 0,0 % und während der Tool-Nutzung mit etwa 1,5 % gemessen; auf einem Intel i5 der 7. Generation wurde opencode zum Vergleich mit etwa 2 % im Leerlauf und etwa 20 % während der Arbeit angegeben
  • Für die Installation werden Cargo und git benötigt; verwendet wird der folgende Befehl 
    cargo install zerostack
  • Bei Verwendung von --sandbox muss bubblewrap installiert werden, damit alle Bash-Befehle in einer isolierten Umgebung ausgeführt werden 
    # Debian/Ubuntu  
apt install bubblewrap  

# Fedora  
dnf install bubblewrap  

# Arch  
pacman -S bubblewrap

Schnellstart

  • Standardanbieter ist OpenRouter; der API-Schlüssel wird als Umgebungsvariable gesetzt 
    export OPENROUTER_API_KEY="[api_key]"
  • Eine interaktive Sitzung wird mit dem Standardprompt code gestartet 
    zerostack
  • Im Einmal-Ausführungsmodus wird mit -p ein Prompt übergeben 
    zerostack -p "Explain this project"
  • Die letzte Sitzung wird mit -c fortgesetzt 
    zerostack -c
  • Anbieter und Modell können explizit angegeben werden 
    zerostack --provider openrouter --model deepseek/deepseek-v4-flash

Prompt-System

  • zerostack enthält einen Satz integrierter System-Prompts, die Verhalten und Tonfall des Agenten verändern
  • Ziel ist es, eine Prompt-Sammlung zu schaffen, die superpower oder offizielle Claude Skills ersetzen kann
  • Mit /prompt lassen sich registrierte Prompts auflisten oder zu einem anderen Prompt wechseln

  • Integrierte Prompts

    • code ist der Standardwert und ein Coding-Modus mit Zugriff auf vollständige Datei- und Bash-Tools sowie einem TDD-Workflow
    • plan ist ein reiner Planungsmodus, der den Code zunächst erkundet und dann einen Plan erstellt, ohne Code zu schreiben
    • review ist ein Code-Review-Modus, der Korrektheit, Design, Tests und Auswirkungen prüft
    • debug ist ein Debug-Modus, der vor Änderungsvorschlägen die Grundursache findet
    • ask ist ein Nur-Lese-Modus und erlaubt nur read, grep und glob; Schreiben oder Bash sind nicht erlaubt
    • brainstorm ist ein reiner Designmodus, der Ideen erkundet und Entwürfe vorschlägt, ohne Code zu schreiben
    • frontend-design ist ein Frontend-Designmodus für einzigartige, produktionsreife UI
    • review-security ist ein Sicherheits-Review-Modus, der nach ausnutzbaren Schwachstellen sucht
    • simplify ist ein Modus zur Code-Vereinfachung, der die Klarheit erhöht, ohne das Verhalten zu ändern
    • write-prompt ist ein Modus zum Erstellen und Optimieren von Agenten-Prompts
    • Benutzerdefinierte Prompts können erstellt werden, indem Markdown-Dateien unter $XDG_CONFIG_HOME/zerostack/prompts/ abgelegt und per Namen referenziert werden
    • AGENTS.md oder CLAUDE.md im Projektstamm oder in übergeordneten Verzeichnissen werden automatisch gelesen und in den System-Prompt eingefügt; dies kann mit -n oder --no-context-files deaktiviert werden

Berechtigungssystem

  • zerostack bietet vier Berechtigungsmodi – von der sichersten bis zur freizügigsten Variante

  • Berechtigungsmodi

    • restrictive oder -R verlangt eine Bestätigung für jede Tool-Aktion, die in der Konfiguration nicht ausdrücklich erlaubt ist
    • standard ist der Standardwert; sichere Befehle wie ls, cd, git log oder cargo check werden automatisch genehmigt, während Schreib- und destruktive Aktionen eine Bestätigung erfordern
    • accept-all oder --accept-all genehmigt automatisch alle Aktionen innerhalb des Arbeitsverzeichnisses und verlangt für externe Pfade eine Bestätigung
    • yolo oder --yolo genehmigt alle Aktionen ohne Rückfrage automatisch
    • In der Konfigurationsdatei können glob-Muster pro Tool angegeben werden, um Berechtigungen fein granular zu steuern
    • So kann zum Beispiel write **.rs automatisch erlaubt werden, während Schreibzugriffe auf andere Dateien immer bestätigt werden müssen
    • Eine Sitzungs-Allowlist behält genehmigte Entscheidungen während der Sitzung bei, damit dieselbe Aktion nicht wiederholt bestätigt werden muss
    • Wenn derselbe Tool-Aufruf dreimal oder öfter wiederholt wird, löst die Doom-Loop-Erkennung einen Warn-Prompt aus oder lehnt den Aufruf je nach Einstellung ab, damit der Agent keine destruktiven Aktionen wiederholt ausführen kann

Slash-Befehle und Sitzungsverwaltung

  • Die wichtigsten Slash-Befehle steuern Modell, Denkstufe, Konversation, Sitzungen, Schleifen, Prompts und Berechtigungsmodus
  • /model wechselt das Modell, /thinking setzt die Denkstufe
  • /clear löscht die Konversation, /session listet Sitzungen auf, speichert oder lädt sie
  • /loop plant einen Iterations-Prompt, /prompt listet Agenten-Prompts auf oder ändert sie
  • /mode setzt den Modus des Berechtigungssystems; alle Befehle lassen sich mit /help anzeigen
  • Sitzungen werden unter $XDG_DATA_HOME/zerostack/sessions/ gespeichert
  • -c setzt die zuletzt verwendete Sitzung fort, -r durchsucht Sitzungen zur Auswahl, und --session <id> lädt eine bestimmte Sitzung

Iterationsschleifen

  • zerostack enthält iterative Coding-Schleifen für lang laufende Aufgaben
  • Der Agent liest die Aufgabe wiederholt, wählt Punkte aus dem Plan aus, führt Arbeiten aus, startet Tests, aktualisiert den Plan und setzt die Schleife fort, bis die Aufgabe abgeschlossen ist oder das Iterationslimit erreicht wird
  • Das Schleifensystem ist eine experimentelle Funktion

  • Verwendung der Schleifen

    • /loop Implement the user authentication system startet eine Schleife mit dem angegebenen Prompt
    • /loop stop beendet die aktive Schleife
    • /loop status zeigt den aktuellen Status der Schleife an
    • Jede Iteration enthält die ursprüngliche Aufgabe, die sich verändernde LOOP_PLAN.md, eine Zusammenfassung der vorherigen Iteration und Verifizierungs-Ausgabe
    • Während eine Schleife aktiv ist, werden Eingaben blockiert, die keine Slash-Befehle sind

  • CLI-basierte Headless-Schleife

    • Mit dem folgenden Befehl kann eine Headless-Schleife ausgeführt werden 
      zerostack --loop --loop-prompt "Refactor the API" --loop-max 10 --loop-run "cargo test"
    • --loop aktiviert den Headless-Schleifenmodus
    • --loop-prompt <text> legt den Prompt fest, der in jeder Iteration verwendet wird
    • --loop-plan <path> gibt den Pfad zu einer benutzerdefinierten Plandatei an; Standardwert ist LOOP_PLAN.md
    • --loop-max <N> gibt die maximale Anzahl von Iterationen an; standardmäßig gibt es kein Limit
    • --loop-run <cmd> legt den Verifizierungsbefehl fest, der nach jeder Iteration ausgeführt wird

Git-worktree-Integration

  • zerostack bietet einen Workflow für branch-spezifische Arbeit mit git worktrees
  • Innerhalb der Chat-UI können worktrees erstellt, darin gearbeitet, sie zusammengeführt und wieder verlassen werden
  • Die Git-worktree-Integration ist eine experimentelle Funktion

  • worktree-Befehle

    • /worktree <name> erstellt einen git worktree für den Branch <name> und wechselt dorthin; falls er bereits existiert, wird das Erstellen übersprungen
    • /wt-merge [branch] merged den worktree-Branch nach [branch], pusht ihn, räumt auf und kehrt dann zum Haupt-Repository zurück
    • /wt-exit kehrt ohne Merge zum Haupt-Repository zurück

  • Beispiel-Workflow

    • /worktree feature-x erstellt einen neuen Branch und ein worktree-Verzeichnis und wechselt dorthin
    • Danach kann zerostack wie gewohnt verwendet werden; Änderungen bleiben im Feature-Branch
    • /wt-merge lässt den Agenten den Branch mergen, pushen, aufräumen und dann zum Haupt-Repository zurückkehren
    • /wt-exit kehrt sofort ohne Merge zum Haupt-Repository zurück

Unterstützte Anbieter und Lizenz

  • Standardanbieter ist OpenRouter
  • Als OpenAI-kompatible Anbieter werden vLLM, LiteLLM und weitere unterstützt
  • Anthropic, Gemini und Ollama werden unterstützt
  • Benutzerdefinierte Anbieter können in $XDG_CONFIG_HOME/zerostack/config.json mit beliebiger Base-URL und einer API-Key-Umgebungsvariable konfiguriert werden
  • Die Lizenz ist GPL-3.0-only

Verwandte Beiträge

1 Kommentare

 
GN⁺ 4 시간 전
Hacker-News-Kommentare

  • Ich kenne mich mit solchen Tools nicht gut aus, aber mich würde interessieren, welche Vorteile es im Vergleich zu Modellen/Tools wie Claude Code hat.

  • Ich habe in meiner Freizeit selbst an etwas Ähnlichem gebaut, mit dem Ziel, Agenten besser zu verstehen und nebenbei Rust zu lernen.
    Ich wollte dabei aber die Konfigurierbarkeit von pi beibehalten. Die Fähigkeit, sich selbst zu verändern und neue Tools zu erzeugen, ist sehr nützlich, und ich finde nicht, dass solche Tools die Berechtigung zur Ausführung beliebigen Codes über bash haben sollten.
    Natürlich ist mit Zugriff auf edit und cargo run weiterhin beliebige Codeausführung möglich, aber wenn etwas anfällt, das ein Agent ohne bash erledigen sollte, erzeuge ich lieber jeweils ein passendes Tool.

    • Ich habe über dieses Problem nachgedacht, aber Pi basiert auf TypeScript und kann daher eine skriptartige Umgebung haben, während Rust als kompilierte Sprache hier Einschränkungen mitbringt.
      Deshalb habe ich mich entschieden, Anpassbarkeit auf andere Weise zu erlauben. Die Prompt-Bibliothek in ~/.config/hypernova/prompts/ ist eine einfache Alternative zu Skills, und die eingebauten Prompts sollen superpowers und Claudes frontend-design ersetzen.
      Funktionen, die den Agenten schwergewichtig machen könnten, lassen sich beim Kompilieren über Feature-Flags deaktivieren, und der Code ist kurz und gut lesbar, sodass man bei Bedarf zerostack auf dem eigenen zerostack-Quellcode laufen lassen und einen Custom Fork erstellen kann.
      Das Rechtemodell wurde, wie im README zu sehen ist, nach viel Überlegung in vier Stufen umgesetzt: von „Restrictive“ ohne Befehle bis zu „YOLO“, wo der Agent tun kann, was er will. Außerdem lassen sich für bash-Aufrufe Regex-Regeln für erlauben/fragen/ablehnen festlegen. In diesem Fall reicht zerostack -R, um zu erzwingen, dass alle Tools nach Berechtigungen fragen.
      An programmierbaren Agentenfunktionen arbeite ich ebenfalls, aber sie sind noch nicht vorzeigbar.
    • Ich baue gerade auch dasselbe in Zig.

  • Kürzlich habe ich halb zum Spaß, halb im Ernst sogar eines mit unter 200 Zeilen gebaut: https://github.com/pnegahdar/nano
    Es hat REPL, Sessions, nicht-interaktive Ausführung und Freigaben. Je schlauer die Modelle werden, desto weniger wichtig wird meiner Meinung nach der Harness, abgesehen von der Developer Experience.
    Vielleicht lasse ich es irgendwann auf SWE-bench laufen.

    • Wirklich cool, dass du das in 200 Zeilen, eigentlich nur 190 Zeilen, gebaut hast.
      Ich habe letzte Woche auch aus Spaß und zum Lernen selbst eines gebaut, und es funktioniert sogar mit der Integration in konfigurierte mcpServers, wie bei den meisten Coding-Agenten.
      Ich habe Schritt für Schritt festgehalten, was man wofür braucht: https://nb1t.sh/building-a-real-agent-step-by-step/

  • „RAM footprint: ~8MB on an empty session, ~12MB when working“
    Das gefällt mir. Claude Code braucht mehrere GB und ist auf leistungsschwachen Laptops ziemlich nervig.

    • Ich baue ein Agent-Framework in Go, und es ist sehr leichtgewichtig.
      Die Startzeit liegt unter 0,5 Sekunden und der RAM-Verbrauch ist ebenfalls sehr niedrig. Es läuft sogar auf einem 12 Jahre alten Laptop flüssig, ohne das System auszubremsen.
      Im Kern ist das fast nur eine Engine zum Aneinanderhängen von Strings, und es gibt keinen Grund, warum so etwas auf irgendeiner Hardware, auch älterer, langsam sein sollte.
    • Ich versuche gerade, zu Zed zu wechseln, und das Agent Client Protocol sieht ziemlich gut aus. Ich frage mich, wie stark sich der Speicherdruck verringern würde, wenn Claude Code über diesen Weg läuft.
      1: https://zed.dev/acp
    • Ja. Allein dieser Punkt dürfte viele Leute dazu bringen, es wenigstens einmal auszuprobieren.
    • Die Speichernutzung ist hervorragend, sodass man jetzt sogar auf sehr kleinen Instanzen wie x1 von shellbox.dev einen Coding-Agenten laufen lassen kann.
    • Man sollte prüfen, ob da nicht noch etwas wie ein LSP-Plugin mitläuft.

  • Ich werde es ausprobieren, wenn ich zu Hause bin. Leichte und schnelle Tools machen einen großen Unterschied beim Programmiererlebnis.
    Mich interessiert, wie sich der Prompt-Ansatz in der Praxis im Vergleich zur üblichen Kombination aus Skills und Sub-Agenten schlägt. Ich mische häufig Dinge wie einen /fix-ci-Skill bei Build-Fehlern ein, während ein Sub-Agent Fehlermeldungen, Stack-Traces und relevante Logs herauszieht und das Problem löst.
    Wenn in Integrationstests ein Problem mit einer DB-Abfrage auftaucht, ruft der Agent selbst oder mit einem kleinen Schubs von mir einen Skill für schreibgeschützten DB-Zugriff auf und untersucht es. Wenn ich lange und tief graben muss, sage ich Dinge wie: „Benutze einen Sonnet-Sub-Agenten und den DB-Query-Skill, um dieses Verhalten zu debuggen.“
    Skills geben spontan zusätzliche Fähigkeiten, und Sub-Agenten sorgen für Isolation, damit der Kontext nicht aufbläht. Vermutlich lässt sich etwas Ähnliches erreichen, wenn der Agent sich selbst mit einem anderen Prompt über bash ausführt, aber das wirkt etwas weniger elegant; ich muss es selbst ausprobieren.

    • Meistens werden sie wie Skills verwendet, aber man sollte sie eher als Umgebung denn als „Befehl“ verstehen.
      Einer der integrierten Prompts, /prompt debug, öffnet zum Beispiel einen auf Debugging ausgerichteten Agenten, und von dort kann man wie mit einem normalen Agenten weiterreden und später mit /prompt code wieder zum Standard-Coding-Agenten zurückkehren.
      Sub-Agenten werden derzeit noch nicht unterstützt, weil der gesamte Agent momentan in einem einzigen Kontextpuffer läuft und ich ihn leichtgewichtig halten möchte. Bei Aufgaben mit viel Exploration bläht sich das Kontextfenster allerdings schnell auf, daher ist es gut möglich, dass Sub-Agenten noch dazukommen.

  • Ich habe Claude Code auch so etwas bauen lassen und fürs Editieren außerdem Line Hashing von Dirac eingebaut.
    Geschrieben ist es in Rust, und ich hatte auch die Idee, Hooks als Plugins umzusetzen, um Selbstmodifikation zu ermöglichen. Letztlich habe ich es aber so gelöst, dass Verbesserungen in einer separaten Datei detailliert beschrieben werden, dann der Quellcode aktualisiert und anschließend neu kompiliert wird.
    Der Speicherort des Quellcodes ist fest, also kann der Agent sich selbst umschreiben und neu bauen. Ich benutze es mit DeepSeek 4 Flash auf 2x RTX 6000 Pro und komme auf ungefähr 138 tok/s.
    Ehrlich gesagt ist es im Wesentlichen von Pi, Dirac und OpenCode abgeschaut. Gibt es hier neue Techniken, die es wert wären, übernommen zu werden?

    • Abgesehen von der Leichtgewichtigkeit habe ich als interessante Funktionen noch die Prompt-Bibliothek, Git-worktree-Integration und Ralph-Wiggum-Loop-Integration eingebaut.
    • Ist das auf GitHub öffentlich verfügbar?

  • Ich habe es kurz ausprobiert, und es war tatsächlich ziemlich schnell.
    Mich würde interessieren, ob du Mitwirkende suchst oder es eher als persönliches Tool entwickelst.
    Allerdings bin ich auf ein paar Probleme gestoßen, als ich andere Modelle nutzen wollte. Bei Azure wird bei gpt-5.5 selbst mit einem OpenAI-kompatiblen Endpoint max_tokens zu max_completion_tokens, wodurch es nicht funktioniert.
    Außerdem scheint es keine Möglichkeit zu geben, Custom Header zu übergeben, sodass ich für DeepSeek-Modelle reasoning_effort nicht setzen konnte.

    • PRs nehme ich gern an.
      Das, was du beschrieben hast, sind klare Bugs in der Codebasis, daher wäre es super, wenn du nach Möglichkeit für jeden Bug ein eigenes GitHub-Issue anlegen könntest.

  • Claude Code und Opencode funktionieren bei mir gut.
    Es ist etwas lustig, dass Coding-Agenten in Rechenzentren mit mehr als 1000 W Leistung und über 2 TB Speicher laufen, während sich die Leute auf die letzten paar Watt und ein paar hundert MB RAM auf ihrem Laptop konzentrieren.
    Gegenüber den Energiekosten des eigentlichen Kompilierens fällt das zwar kaum ins Gewicht, aber schneller und leichter zu werden schadet natürlich trotzdem nicht.

    • Rechenzentren laufen über dedizierte Stromleitungen, mein Laptop dagegen über Akku.
      Wenn ich aktuell Coding-Agenten benutze, ist der Akku ziemlich schnell leer, was erstaunlich ist, wenn man bedenkt, dass die meisten Arbeitslasten gar nicht auf meinem Laptop laufen.
      Den clientseitigen Coding-Agenten effizienter zu machen dient nicht der Rettung des Klimas, sondern dazu, die Arbeitszeit zu verlängern. Tatsächlich könnte es fürs Klima sogar schlechter sein.
    • Natürlich konzentrieren sich Menschen auf Software, die auf ihrem eigenen Rechner läuft.
      Software, die auf fremden Rechnern läuft, ist nicht mein Problem. Ich kann nicht kontrollieren, was auf fremden Servern läuft, und selbst wenn doch, würde ich die RAM-Kosten dort nicht bezahlen, also wäre es mir egal.
      Den RAM in meiner eigenen Hardware bezahle ich hingegen selbst. Wenn ein TUI zur Anzeige von weniger als 1 KB Text mehrere GB Speicher belegt und dadurch unter Windows andere Apps per OOM beendet oder unter Linux auf die HDD auslagert und die ganze Maschine zum Stillstand bringt, muss mich das interessieren.
      Da sich der RAM-Preis real verfünffacht hat und auch andere Komponenten 2- bis 3-mal teurer geworden sind, ist es besonders wichtig, Speicherverschwendung zu vermeiden.
    • Das ist zu stark vereinfacht.
      Dass Modelle riesig sind und viele Ressourcen verbrauchen, stimmt, aber der Harness kann großen Einfluss darauf haben, wie intensiv das Modell tatsächlich genutzt wird.
      Wenn der Harness zum Beispiel ein starkes Toolset hat, kann das Modell viel effizienter arbeiten.

  • Die Codebasis ist klein genug, dass ich sie an DeepSeek v4 Flash in Pi übergeben und nach riskanten Stellen durchsuchen lassen konnte, ohne etwas Besorgniserregendes zu finden. Gut gemacht.

    • Weil der OP meinte, dass ein erheblicher Teil des Codes von DeepSeek V4 Flash erzeugt wurde, habe ich nachgesehen, ob veraltete Abhängigkeiten enthalten sind.
      Bei Rust-Projekten habe ich die Erfahrung gemacht, dass selbst Claude 4.7 Opus fast immer veraltete Abhängigkeiten hinzufügt, wenn man dem Modell nicht ausdrücklich sagt, Cargo.toml nicht direkt zu bearbeiten, sondern cargo add zu verwenden.
      Ich habe die Abhängigkeiten dieses Projekts manuell geprüft, und sie sind alle aktuell, was erfreulich ist. Das heißt natürlich nicht, dass sich in transitiven Abhängigkeiten nichts Problematisches versteckt.
      Bei Code-Reviews durch LLMs wird es schnell zur Geschmacksfrage. Als ich den Code so durchgesehen habe, dachte ich bei einigen Methoden, die zwischen Strings und Enums hin- und herwandeln: „Hätte man das nicht mit strum und einem einfachen #[derive] lösen können?“ Das hätte provider.rs deutlich kompakter gemacht, statt dafür lieber kein zusätzliches, abhängigkeitfreies Crate einzubauen.
      Zum Spaß habe ich die Codebasis auch von DeepSeek V4 Pro mit Max thinking „auditieren“ lassen; es meinte, es gebe keine offensichtlichen Hinweise auf versteckte Telemetrie. Allerdings hat es angemerkt, dass das Projekt den Panic-Handler auf abort setzt, und dazu habe ich eine starke Meinung.
      Vermutlich soll damit das Linken von libunwind vermieden werden, um ein paar KB Binärgröße einzusparen, aber dadurch erhält man ein Binary, das bei einem Crash sofort abbricht und dem Nutzer keinen Stack-Trace liefert. Wenn man im Panic-Fall nützliche Debug-Informationen bekommen kann, sind mir etwa 50 KiB zusätzliche Binärgröße lieber.
      Außerdem kann man bei Panics in asynchronen Tasks nicht mehr abfangen und eine normale Fehlermeldung anzeigen; stattdessen beendet sich sofort der gesamte Prozess.
    • Ein ziemlich großer Teil des Codes wurde von DeepSeek v4 Flash geschrieben, einige Teile der TUI-Logik habe ich aber selbst implementiert.
      Der Grund war, dass DeepSeek bei bestimmter Cursor-Bewegungslogik immer wieder gescheitert ist. Die Speicheroptimierung habe ich komplett selbst gesteuert und dabei, wie ich in einem anderen Kommentar erwähnt habe, Compiler-Optimierungen mit der Nutzung von Rust-Crates für effizientere Datenstrukturen kombiniert.
    • Ist so ein Vorgehen wie „an DeepSeek v4 Flash in Pi übergeben und nach riskanten Stellen suchen lassen“ wegen Prompt Injection nicht eine ziemlich schwache Untersuchung?

  • Lustig, dass es ausgerechnet heute erschienen ist. Ich wollte selbst gerade anfangen, eines in Rust zu schreiben.
    Es ist erstaunlich, wie opencode in großen Projekten langsam Speicher verliert, bis es bei 6 GB landet und immer träger wird.
    Ich werde es mir ansehen. Sieht cool aus.

    • Ja. Dieses Projekt entstand genau daraus, dass auf einem alten Laptop mit Firefox und mehr als zwei opencode-Instanzen gleichzeitig der OOM killer angesprungen ist.