Atomic Agent: lokaler Agenten-Loop mit llama.cpp, GBNF und Tauri-Sidecar

Welche Lücke der lokale Kontrollloop schließt

Die meisten Agenten-Projekte behandeln das Modell als austauschbaren Backend-Aufruf und verlagern den Kontrollloop in einen Dienst. Atomic Agent dreht das um: Der Loop und der gesamte Zustand laufen laut README auf der eigenen Maschine, das Modell kommt über llama.cpp. Die Zielgruppe sind damit nicht Teams, die einen gehosteten Agenten an eine API hängen, sondern Einzelpersonen und kleine Gruppen, die mehrstufige Aufgaben auf Consumer-Hardware ausführen wollen, ohne pro Token zu zahlen. Die README nennt als Anwendungsfälle Browser-Steuerung, Lesen und Bearbeiten von Dateien, genehmigte Shell-Kommandos, Dokumentenprüfung, sitzungsübergreifenden Kontext, geplante Folgeaufgaben und externe Tools über MCP. Der Anspruch ist ausdrücklich bescheiden formuliert: kleine quantisierte Modelle sollen für lange, mehrstufige Arbeit brauchbar bleiben. Wer stattdessen ein großes Cloud-Modell für schwierige Einzelschritte nutzt, gewinnt durch den lokalen Loop nichts, verliert aber Durchsatz und Kontextfenster.

Loop, Grammatik und Sidecar: der sichtbare Aufbau

Aus dem Repository-Aufbau und den Topics lassen sich mehrere Schichten ablesen. Der Agent selbst ist TypeScript, die Laufzeit Node.js ab Version 25.7. Die Modellausführung liegt bei llama.cpp, das Projekt spricht von einem eigenen TurboQuant-Build von llama.cpp und nennt in der README eine Steigerung des Durchsatzes um 30 bis 50 Prozent bei kleinen lokalen Modellen. Diese Zahl stammt aus der README und ist nicht unabhängig nachvollziehbar. Für die Steuerung des Desktops ist Playwright als Topic gelistet, was zur Beschreibung der Browser-Automatisierung passt. GBNF und GGUF verweisen auf llama.cpp-Grammatiken und das Modellformat: Die Grammatiken liegen nach der Installation als Verzeichnis grammars/ neben dem Binary, was erklärt, warum der Installer sie als Support-Assets mitliefert. MCP dient als Protokoll für externe Tools. Für die Einbettung in eigene Anwendungen nennt die README zwei Wege, HTTP und einen Tauri-Sidecar. Der Sidecar-Ansatz bedeutet, dass der Agent als eigener Prozess neben einer Tauri-Anwendung läuft und nicht als Bibliothek im selben Prozess. Das ist eine bewusste Trennung, kostet aber einen zusätzlichen Prozess-Lebenszyklus, den die einbettende Anwendung verwalten muss.

Installation, Alias und Update-Pfad

Die Installation ist ein Einzeiler. Unter macOS und Linux lautet er `curl -fsSL https://atomicagent.io/install | sh`, unter Windows in PowerShell `irm https://atomicagent.io/install.ps1 | iex`. Der Installer lädt laut README das Release-Archiv, prüft die Checksumme und legt CLI plus Support-Assets ab, also grammars/, native Prebuilds und ein gebündeltes ripgrep. Gestartet wird mit `atomic-agent`, wobei beide Installer einen kurzen Alias danebenlegen, sodass `atag` dasselbe tut. Ein zweiter Agent entsteht im TUI über Ctrl+N oder den Befehl `/window`, der ein neues Terminalfenster mit einer frischen Instanz im selben Verzeichnis öffnet. Für Updates gibt es `atomic-agent update` beziehungsweise `atag update`, das nach einer neueren Version sucht und den Installer an Ort und Stelle erneut ausführt. Mit `atomic-agent update --check` wird nur geprüft, ohne zu installieren, und `--version <tag>` bindet eine bestimmte Release-Version. Wichtig ist die Einschränkung aus der README: Nur das installierte Binary kann sich selbst aktualisieren, eine Entwickler-Kopie wird über git aktualisiert. Wer den Agenten aus einem Checkout betreibt, hat also einen anderen Update-Weg als der Endnutzer.

Import aus anderen Agenten und was dabei übertragen wird

Der erste Start bietet an, Daten aus Hermes, OpenClaw, Claude Code oder Codex zu übernehmen. Übertragen werden laut README Skills, Memory, MCP-Server, Sitzungen, Cron-Jobs und optional Provider-Schlüssel. Der Import ist als Dry-Run-Vorschau beschrieben, bevor etwas geschrieben wird, und lässt sich später über `/import` im TUI oder über `atomic-agent import <hermes|openclaw|claude-code|codex>` erneut aufrufen. Die Opt-in-Formulierung bei den Provider-Schlüsseln ist der relevanteste Punkt: Wer fremde Schlüssel übernimmt, sollte vorher wissen, wo sie nach dem Import liegen und ob sie in den lokalen Zustand wandern. Die README beschreibt die Vorschau, geht aber nicht darauf ein, wie die Schlüssel danach abgelegt oder geschützt werden. Das ist eine Lücke in der Dokumentation, keine Widerlegung des Ansatzes. Für Umsteiger ist der Import trotzdem der günstigste Einstieg, weil er den manuellen Neuaufbau von MCP-Konfiguration und Memory erspart.

Der GAIA-L1-Vergleich und was er nicht zeigt

Die README dokumentiert einen Vergleich auf dem öffentlichen GAIA-Validierungs-Split Level 1 mit 53 Aufgaben. Beide Agenten, Atomic Agent und Hermes, liefen demnach mit demselben lokalen Modell, demselben Schritt-Budget und demselben Timeout; einzige Variable sei der Agenten-Loop. Atomic Agent erreicht in dieser Tabelle 37 von 53 Aufgaben, also 69,8 Prozent, bei durchschnittlich etwa 217 Sekunden pro Aufgabe. Hermes kommt auf 31 von 53, also 58,5 Prozent, bei etwa 351 Sekunden. Die Aufschlüsselung nennt 15 nur von Atomic Agent gelöste Aufgaben und 9 nur von Hermes gelöste. Eine zweite Tabelle zeigt dieselbe Aufteilung mit kleineren Modellen: 28 von 53 bei einem 9B-Modell und 24 von 53 bei einem 12B-Modell. Diese Zahlen sind Selbstdarstellung des Projekts, kein unabhängiger Test, und die Modellbezeichnungen in den Tabellen lassen sich nicht ohne Weiteres gegen öffentliche Modellkarten prüfen. Der Vergleich isoliert den Loop, was methodisch sinnvoll ist, aber nichts über absolute Kosten oder über Aufgaben außerhalb von GAIA L1 sagt.

Deinstallation, Zustandsverzeichnis und Lizenz

Der Uninstall-Befehl ist `atomic-agent uninstall`. Er entfernt laut README das Zustandsverzeichnis mit Konfiguration, Memory, Sitzungen, Aufgaben, Traces und heruntergeladenen Modellen, dazu das Binary mit seinem atag-Alias, die Asset-Verzeichnisse daneben und die PATH-Zeile, die der Installer in die Shell-Konfiguration geschrieben hat. Vor dem Löschen zeigt der Befehl an, was entfernt wird, inklusive Größen, und verlangt die Eingabe des Wortes `uninstall`. Mit `atomic-agent uninstall --dry-run` lässt sich das vorab ansehen, `--keep-data` behält die Daten, `--yes` überspringt die Rückfrage. Dieselbe Prozedur liegt im TUI unter Esc → Danger zone oder `/uninstall`. Bemerkenswert ist, dass heruntergeladene Modelle im Zustandsverzeichnis liegen und damit mitgelöscht werden. Wer mehrere GB GGUF-Dateien lokal hält, verliert sie bei einem normalen Uninstall und muss sie nach einer Neuinstallation erneut laden. Die Lizenz ist MIT, was Weitergabe und kommerzielle Nutzung erlaubt, solange Copyright-Hinweis und Lizenztext erhalten bleiben. Das ist keine Rechtsberatung, und die Lizenz gilt für den Agenten, nicht automatisch für die mitgelieferten Modellgewichte, die eigenen Bedingungen unterliegen können.

Grenzen: Developer Preview, Plattformliste, Modellabhängigkeit

Die README markiert den Stand selbst als Developer Preview und schreibt, dass sich APIs, Kommandos, Konfiguration und Verhalten noch bewegen. Wer eine stabile Integrationsschnittstelle braucht, soll eine Release-Version festnageln. Das ist die wichtigste Einschränkung des Projekts. Dazu kommt die Plattformliste: aktuelle Builds gibt es für macOS auf Apple Silicon, Linux x64 und arm64 sowie Windows x64. Wer auf macOS mit Intel-Prozessor oder auf einer anderen Architektur arbeitet, ist nicht abgedeckt. Die Laufzeitumgebung verlangt Node.js ab Version 25.7, was auf älteren Systemen oder in Umgebungen mit festen Node-Versionen ein Hindernis sein kann. Und die Qualität des Ergebnisses hängt am lokalen Modell: Die GAIA-Tabelle zeigt einen Rückgang von 69,8 auf 52,8 beziehungsweise 45,3 Prozent, sobald kleinere Modelle zum Einsatz kommen, während die Laufzeit pro Aufgabe beim 12B-Modell auf etwa 423 Sekunden steigt. Der lokale Ansatz ist also kein kostenloses Upgrade, sondern verschiebt die Grenze dorthin, was die eigene Hardware und das gewählte Quantisierungsformat leisten.

Wann ein gehosteter Agent die bessere Wahl bleibt

Der naheliegende Gegenentwurf ist ein Agent, dessen Loop und Modell in der Cloud laufen, etwa Claude Code oder Codex. Der Unterschied liegt nicht in der Funktionsliste, denn beide Ansätze lesen Dateien, führen Kommandos aus und greifen auf externe Tools zu. Der Unterschied liegt in der Verteilung: Bei einem gehosteten Agenten wandern Dateiinhalte, Kommandos und Sitzungskontext über die Leitung, und die Rechenleistung skaliert mit dem Abonnement statt mit der eigenen GPU. Dafür entfällt jede Modellverwaltung, und die Ergebnisse hängen nicht davon ab, ob eine 9B-Quantisierung die Aufgabe noch trägt. Atomic Agent positioniert sich genau gegen diese Abhängigkeit, mit dem Preis, dass der Nutzer Modelle besorgen, Quantisierungen wählen und Speicherplatz einplanen muss. Für Aufgaben, die selten laufen und hohe Genauigkeit brauchen, ist der gehostete Weg oft der günstigere. Für wiederkehrende, lange Ketten auf sensiblen Dateien kippt die Rechnung zugunsten des lokalen Loops. Der Import-Pfad aus Hermes, OpenClaw, Claude Code und Codex macht den Wechsel in beide Richtungen zumindest technisch vorgesehen.

Redaktionelles Fazit

Wer einen Agenten sucht, dessen Kontrollloop und Zustand vollständig lokal bleiben und der Browser-, Datei- und Shell-Aktionen über MCP und Playwright ausführt, findet hier ein MIT-lizenziertes Projekt mit dokumentiertem Self-Update und sauberem Uninstall-Pfad. Wer stabile APIs für eine Produktionsintegration braucht, sollte bis zu einem stabilen Release warten, denn die README bezeichnet den Stand selbst als Developer Preview. Vor dem ersten Einsatz zu prüfen: ob die genannten Modellbezeichnungen auf den eigenen Modell-Quellen existieren, ob die Zielplattform in der Liste macOS Apple Silicon, Linux x64/arm64 oder Windows x64 enthalten ist und ob node >= 25.7 auf der Maschine verfügbar ist.

Offizielle Quellen

1. AtomicBot-ai/atomic-agent on GitHub
2. License: MIT
3. Project website
4. README
5. Releases