OpenClaw: 302.000 Sterne, 110.000 Commits und ein Daemon auf deinem Gerät

Am 15. Oktober 2026 gegen 07:00 Uhr habe ich mir das OpenClaw-Repository direkt bei GitHub angeschaut, und zwei Zahlen des Abrufs drängen die übliche Schlagzeile in den Hintergrund. Die erste lautet laut Messbericht der SOO Group: mehr als 302.000 GitHub-Sterne, der schnellste Anstieg in der Geschichte der Plattform, schneller als React, Vue.js und TensorFlow ihn je geschafft haben. Die zweite steht nicht in einem Bericht, sondern auf der Repo-Seite selbst: 110.941 Commits auf dem Hauptzweig, mehr als 3.340 Mitwirkende, der letzte Commit nur Minuten vor meinem Abruf. Ich fass es vorweg zusammen: Der Rekord misst, wie schnell wir installieren. Wie gut wir betreiben, misst er nicht. Diese Lücke entscheidet, ob ein autonomer Agent auf dem eigenen Gerät ein Werkzeug ist oder ein Risiko.

Der Live-Abgleich trennt Bericht von Messung, und das lohnt sich bei jedem Rekord. Was ich am 15. Oktober 2026 selbst gelesen habe: openclaw/openclaw führt 505 Tags, 7.224 Branches, 110.941 Commits auf main, der Code dominiert mit 90,3 Prozent TypeScript, dazu Swift und Kotlin für die Geräteschicht, und über 3.340 Beiträger stehen im Protokoll. Die Selbstbeschreibung bleibt knapp: das KI-Gerät, das wirklich etwas tut, auf jedem Betriebssystem, auf jeder Plattform. Der Quick-Start-Eintrag aus der Projektanleitung macht daraus einen einzigen Satz, den man wörtlich nehmen sollte: openclaw onboard mit dem Installationsflag für einen Daemon, das Projekt richtet sich also bewusst als dauerhafter Bewohner auf deinem Rechner ein, nicht als Werkzeug, das man nach Feierabend wieder abreißt. Was die Sterne angeht, arbeite ich mit der berichteten Zahl: über 302.000, laut SOO-Group-Bericht vom April 2026 mit der Vergleichstabelle, dass React für seine 200.000 mehr als drei Jahre brauchte, Vue.js mehr als fünf und TensorFlow mehr als vier, während OpenClaw die 300.000 in Monaten erreichte. Eine zweite Titelthese, die ich ausdrücklich nur als These zitiere, kam über ein längeres Porträt des Projekts: der schnellst wachsende Open-Source-Kurs der Geschichte sei zugleich das Gefährlichste, was man auf dem eigenen Computer installieren kann. Berichtete Zahl, eigene Zahl, fremde These: genau drei Belegklassen, die dieser Beitrag sauber auseinanderhält.

Damit zum eigentlichen Thema, das weder Sterne noch Releases betreffen: der Daemon. Ein Daemon ist ein Prozess, der läuft, ohne dass du ihn bedienst. Die installierte Form von OpenClaw lauscht laut Projektdokumentation auf Nachrichtenkanälen wie Telegram, Slack oder Discord, führt Shell-Befehle aus, verwaltet Dateien und automatisiert Web-Aufgaben, alles auf deinem Gerät. Daraus folgt eine Risikostruktur mit genau zwei Klassen, und jede Installation sollte sie durchschauen. Klasse eins: der Agent tut, was du nicht erwartest, weil seine Berechtigungen größer sind als dein Gedanke an den Punkt. Klasse zwei: der Agent tut genau das Richtige, aber du erfährst es nie, weil niemand protokolliert. Die Messenger-Anbindung verschärft beides auf eine angenehme Art, für die Nutzungsgeschwindigkeit und eine unangenehme Art, für das Risiko: Sie senkt die Installationsschwelle radikal, ein Onboarding-Kommando, ein Daemon, und ein Chatfenster wird zur Ferntastatur deines Systems. Was bei einem Cloud-Dienst der Anbieter signiert und haften würde, verschiebt sich hier an dich: Berechtigungsumfang, Aktualisierung, Betriebsbeobachtung. Der Bericht der SOO Group listet als Sicherheitsbaukasten Sandbox-Umgebungen, feingranulare Rechte, Erlaubnis- und Sperrlisten, Ressourcengrenzen und Protokollierung. Das ist die richtige Liste, aber eine Liste von Möglichkeiten ist noch kein Betrieb.

Ein Blick auf die Installationsseite lohnt sich, weil sie die Erwartung prägt, mit der der erste Befehl läuft. Die Anleitung führt den Daemon-Eintrag als empfohlenen Weg, die Befehlszeile aus der Projektanleitung verbindet das Onboarding mit dem Daemon-Flag in einem Schritt, und danach hängt der Agent am Messenger. Die Voraussetzungen auf dieser Seite lesen sich harmlos: ein Gerät als Wirt, die Modell-Anbindung über einen Schlüssel, Zugang zu einer Anwendung für Kontakte und Nachrichten. Harmlos ist hier eine Frage des Lesens, denn alle drei Bedingungen sind Bausteine der Fernsteuerung: der Wirt hält die Läufe, der Schlüssel bezahlt sie, die Anwendung öffnet den Kanal, aus dem später Befehle kommen. Die Anleitung nennt für die Einrichtung einige Minuten und verweist die Kontrolle über die Sicherheit an eine eigene Seite, auf der Berechtigungen und Limits gepflegt werden. Genau diese Verweisstruktur ist die eigentliche Hausaufgabe: Die Installation dauert Minuten, die Betriebsaufsicht kostet Stunden, und wer nur die erste Hälfte liest, hinterlässt die zweite als leerer Platz. Auf meinem Deck hat der gleiche Ablauf ein halbes Jahr gedauert, geformt durch einen Fehler und eine Korrektur, einen OOM-Sturm mit fünf Gateway-Toten am 28. August und die anschließende Härtung. Der Daemon ist niemals das Problem gewesen, die fehlende Überwachung dahinter war es.

Die Gegenprobe läuft auf meinem Deck, und sie fällt nüchtern aus. Auf einem gebrauchten Google Pixel 6a für 45 Euro betreibe ich seit Jahren einen autonom arbeitenden Agenten mit derselben Grundformel, die OpenClaw populär macht: lokal, ansteuerbar aus dem Chat, in der Lage, Dateien, Skripte und Dienste auf dem Gerät wirklich zu benutzen. Die Betriebszahlen stehen im eigenen Messregister der stability-snapshots: 88 Stunden ununterbrochener Lauf vom 28. August 19:40 Uhr bis zum 1. September 12:18 Uhr, null Out-of-Memory-Kills seit der Härtung durch externen Cron-Tick und semantischen Watchdog, 36 von 36 bestandenen Tests der zwei verifizierten Projekte, die im lokalen Workflow entstanden: Hermes plant, pi Agent führt aus, Hermes verifiziert. Der Punkt dieser Zahlen ist nicht, dass mein Aufbau klüger wäre als OpenClaw. Der Punkt ist, dass dieselbe Fähigkeit auf demselben 45-Euro-Gerät dieselbe Disziplin braucht. Ein bündelnder Update-Rhythmus, den ich pi und Hermes mit dem gebündelten Stand der 1.2-Serie bzw. der 0.22-Serie halte, gehört für einen Android-Betrieb zur selben Disziplin: Der Dauerfluss von Commits bleibt ein Angebot, die Entscheidung über die Installation fälle der Betreiber, nicht der Feed.

Was der Star-Rekord nicht misst, zeigt mein eigener Stichtag vom 14. Oktober, derselbe Lauf, der die Release-Kultur von sieben Coding-Agenten vermisste: OpenClaw committete mit 4.254 Commits in sieben Tagen am lautesten der gesamten Tabelle und sammelte im selben Zeitraum nur etwa 673 Sterne. Tempo und Aufmerksamkeit sind zwei getrennte Kurven, und beide sagen nichts davon, wie sicher jemand läuft. Bleibt die von mir unbeantwortete Frage, die den Rekord kommentiert: ein Wachstum dieser Drehzahl strapaziert die Wartung schneller als die Dokumentation mitwachsen kann. Drei Jahre, fünf Jahre, vier Jahre für React, Vue und TensorFlow bedeuteten Zeit, in der sich Werkzeuge, Praktiken und Verantwortungen einspielen konnten. Der 60-Tage-Kurs, von dem das Porträt im Titel schreibt, lässt für genau diesen Einweisungsprozess zwei Monate. Wer den Daemon am eigenen Rechner betreibt, hat den Nachhilfekurs zu überspringen und trägt das Risiko, das sonst der Anbieter signiert.

Am Ende bleibt eine Richtung statt eines Urteils. Agenten mit Daemon-Schnittstelle normalisieren sich in den Heimrechnungen so, wie sich Server normalisiert haben: plötzlich, hauptsächlich durch Einfachheit, mit einem Risiko, das von der Plattform auf den Tisch des Betreibers wandert. Der Star-Rekord von OpenClaw ist das erste sichtbare Ausrufungszeichen dieser Verschiebung, ein Geschwindigkeitsdokument, kein Sicherheitszertifikat. Greifbare Grenzen meiner Betrachtung: die Sternenzahl ist die berichtete Zahl vom April 2026, nicht eine eigene API-Abfrage an diesem Stichtag, die Installationsrechtslage liest sich aus Anleitungen und Berichten, und ein 45-Euro-Deck ist kein Server, keine Aussage über Sicherheit unter Last. Was ich dafür belegen kann: drei Kontrollen, die aus einem Daemon Betrieb machen, laufen auf meinem Gerät seit der Härtung ohne einen Notfallstopp, und die Zahlen dazu stehen in meinem Messregister. Wer sich gerade einen Daemon installiert, sollte drei Fragen mit Ja beantworten können: Weiß ich, welche Berechtigungen er hat? Sehe ich, was er tut? Stoppt er, wenn ich es brauche? Erst danach zählen die Sterne.

Über den Autor: Ich bin Marcel, Grafikdesigner und Betreiber des HUNTER-Cyberdecks auf einem gebrauchten Google Pixel 6a. Die Repo-Zahlen dieses Beitrags habe ich am 15.10.2026 gegen 07:00 Uhr selbst von openclaw/openclau bei GitHub abgelesen, die Betriebszahlen meines Decks stehen im eigenen Messregister der stability-snapshots und Tagesnotizen, der Stichtag-Wert vom 14.10. aus der eigenen Release-Messung. Berichtete Zahlen wie die 302.000 Sterne sind im Text ausdrücklich als Bericht gekennzeichnet. Zuletzt fachlich geprüft am 15.10.2026.

Quellen: Eigene Repo-Lektüre am 15.10.2026, 07:00 bis 07:05 Uhr MESZ, openclaw/openclaw bei GitHub (Commits, Tags, Branches, Sprachverteilung, Mitwirkende). Berichtete Kernzahlen: SOO-Group-Blogbeitrag zu 302.000+ Sternen (Abruf 15.10.2026). Titelthese zur Sicherheitsdebatte: Porträt von A. Aftab auf Medium (Abruf 15.10.2026). Kontext der Agentenwoche: JetBrains-Blog zu Mellum 2.1 vom 08.10.2026 (Abruf 15.10.2026). Eigene Messwerte: Vault stability-snapshots und Tagesnotizen (88-Stunden-Rekord, OOM-Kills, Tests), eigene Stichtagsmessung vom 14.10.2026, 05:07 Uhr UTC (Commits und Sternen-Drift).