Peter Steinberger, Entwickler des Open-Source-Agenten OpenClaw, wechselt zu OpenAI. Sam Altman feiert dies als Coup im Talentrennen, Steinberger spricht vom „schnellsten Weg, die Welt zu verändern“. Die offizielle Erzählung: Ein erfolgreicher Gründer geht zum größten Player im Feld. Doch ein Blick auf OpenClaws Architektur und die zeitgleich entstandene Alternative NanoClaw legt eine andere Deutung nahe: Was, wenn der Wechsel weniger über Chancen bei OpenAI aussagt als über versteckte Probleme seines eigenen Projekts? 

Die offizielle Erzählung

Es klingt nach einer klassischen Startup-Erfolgsgeschichte: OpenClaw, im November gestartet, erreichte binnen weniger Wochen 142.000 GitHub-Stars und geschätzt 150.000 laufende Instanzen weltweit. Ein Framework für autonome KI-Agenten, das via WhatsApp oder Slack gesteuert werden konnte und durch einfache Markdown-Skills erweiterbar war. Das Handelsblatt sprach von einem möglichen „iPhone-Moment“ für KI-Agenten.

Peter Steinberger, der österreichische Entwickler hinter dem Projekt, hatte 13 Jahre in seine eigene Firma investiert. Nun wechselt er zu OpenAI^[1]Open-Claw-Entwickler Steinberger wechselt zu OpenAI – nicht etwa zu Meta oder Anthropic, die ebenfalls intensiv um ihn geworben hatten. Sam Altman feiert dies öffentlich als wichtigen Erfolg. Steinbergers Begründung: OpenAI sei der „schnellste Weg, die Welt zu verändern“. OpenClaw soll open source bleiben, als unabhängige Stiftung weitergeführt werden. Eine Win-Win-Situation für alle Beteiligten.

Diese Erzählung hat nur einen Fehler: Sie ignoriert vollständig, was parallel zu diesem vermeintlichen Triumph mit OpenClaw technisch geschieht.

Die versteckten Signale

Während die Tech-Presse Steinbergers Wechsel als Erfolgsgeschichte rahmt, mehren sich parallel kritische Stimmen zu OpenClaw selbst^[2]OpenClaw und NanoClaw: Die Sicherheitsdebatte um autonome KI-Agenten. Sicherheitsforscher dokumentieren, dass rund 25 Prozent der Community-entwickelten Skills Schwachstellen enthalten. Einzelne populäre Erweiterungen exfiltrieren aktiv Daten. CSO Online publizierte einen Artikel mit unmissverständlichem Titel: „What CISOs need to know about the OpenClaw security nightmare.“

Das ist kein gewöhnlicher Sicherheitsvorfall, den man mit einem Patch beheben könnte. Die Probleme liegen in der fundamentalen Architektur: OpenClaw läuft in einem einzigen Node-Prozess mit shared memory. Alle Agenten teilen sich denselben Adressraum. Sicherheit wird über Allowlists und Pairing Codes auf Anwendungsebene implementiert – nicht über Betriebssystem-Isolation. Ein kompromittierter Agent oder manipulierter Skill kann potenziell auf alle Ressourcen des Host-Systems zugreifen.

Die Codebasis umfasst über 400.000 Zeilen mit 52 Modulen und 45 Dependencies. Diese Komplexität macht vollständige Security-Audits praktisch unmöglich. Ein Reddit-Post bringt die praktische Konsequenz auf den Punkt: „Thousands of OpenClaw installs are running with no auth on the gateway. If you can find it, you can reach it.“

OpenAI reagierte mit VirusTotal-Scanning für alle ClawHub-Skills – ein reaktiver Schritt, der bekannte Malware erkennen kann, aber logische Exploits in natürlichsprachigen Anweisungen nicht adressiert. Das ist, als würde man ein Leck in der Titanic mit einem Eimer bekämpfen.

NanoClaw: Die existenzielle Kritik

Dann kam NanoClaw. Entwickelt von Gavriel Cohen mit der expliziten Motivation: „I cannot sleep peacefully when running software I don’t understand and that has access to my life.“
NanoClaw ist keine bloße Alternative zu OpenClaw – es ist eine vernichtende Kritik an dessen Architektur. Der Core-Code umfasst etwa 500 Zeilen statt 400.000. Das gesamte System ist in acht Minuten auditierbar. Jeder Agent läuft in einem eigenen Linux Container mit separatem Filesystem. Ein kompromittierter Agent kann nur auf zugewiesene Container-Ressourcen zugreifen, nicht auf das gesamte System.

Die radikalste Innovation ist das Entwicklungsmodell: Statt alle Features direkt ins Programm zu integrieren, bleibt der Core minimal. „Skills“ sind Anleitungen, die einem KI-Assistenten beibringen, wie er den Code für spezifische Bedürfnisse umschreiben soll. Wer Telegram statt WhatsApp will, gibt einen Befehl, und der KI-Assistent baut den Code entsprechend um. Jeder Nutzer hat am Ende nur genau das, was er wirklich braucht.

NanoClaw beweist etwas Fundamentales: Alles, was OpenClaw kann, lässt sich auch in 0,1 Prozent der Codegröße realisieren – nur sicherer, auditierbar und kontrollierbar. Die Message ist eindeutig: OpenClaws Architektur ist nicht optimierungsbedürftig, sie ist fundamental falsch.

Die Komplexitätsfalle

Wie konnte es dazu kommen? OpenClaws ursprüngliche Designentscheidungen folgten einer bestechenden Logik: Maximale Features out-of-the-box, niedrigste Einstiegshürde, generische Lösung für viele Use-Cases. Jeder sollte sofort loslegen können. Skills in Markdown zu schreiben war so einfach, dass binnen Wochen ein reiches Ökosystem entstand.

Aber genau diese Entscheidungen schufen eine technische Schuld, die sich als unbezahlbar erweisen könnte. Die Shared-Memory-Architektur ermöglichte schnelle Kommunikation zwischen Komponenten, machte aber Isolation unmöglich. Die niedrige Skill-Einstiegshürde produzierte schnelles Wachstum, aber auch ein Qualitätsproblem: Wenn jeder Markdown-Files schreiben kann, die dann auf Systemen mit vollem Zugriff laufen, ist das kein Bug – es ist ein Governance-Problem ohne technische Lösung.

Mit jedem neuen Modul, jeder neuen Integration, jeder neuen Abhängigkeit wuchs nicht nur die Funktionalität, sondern auch die Angriffsfläche und die praktische Unüberprüfbarkeit. Bei 400.000 Zeilen Code gibt es keine vollständigen Security-Audits mehr, nur noch Stichproben und Hoffnung.

NanoClaw zeigt: Diese Komplexität war nicht unvermeidlich. Sie war das direkte Resultat von Architektur-Entscheidungen, die Convenience über Security stellten. Und diese Entscheidungen lassen sich nicht mehr rückgängig machen. OpenClaw vollständig neu zu schreiben würde bedeuten: Es ist nicht mehr OpenClaw. Das Projekt kann nur noch verwaltet werden, nicht mehr transformiert.

Eine alternative Deutung

In diesem Kontext lässt sich Steinbergers Wechsel anders lesen. Die entscheidende Frage ist nicht: „Warum wechselt er bei diesem Erfolg?“ Sondern: „Warum bleibt er nicht und rettet sein Projekt?“

Eine mögliche Antwort liegt im Timing. Steinberger wechselt möglicherweise nicht auf dem Höhepunkt des Erfolgs, sondern am Wendepunkt von Hype zu Krise. OpenClaw hat 150.000 Installationen – aber die CSO-Warnungen werden zum Reputationsrisiko. NanoClaw existiert und demonstriert, dass es einen besseren Weg gibt. Die Sicherheitsprobleme sind nicht behebbar, weil sie in der Architektur liegen. Die Community-Governance über Skills zeigt strukturelle Schwächen – 25 Prozent Fehlerquote ist kein Bug, es könnte ein systemisches Problem sein.

Wer jetzt geht, verlässt ein „erfolgreiches Open-Source-Projekt“ und übergibt es der Community. Wer in sechs Monaten geht, verlässt möglicherweise „das unsichere Framework, vor dem CSOs warnen“. Das wäre ein fundamentaler Unterschied in der persönlichen Marke eines Entwicklers.

Die Stiftungs-Konstruktion passt in diese Lesart: OpenClaw bleibt bestehen, die Community übernimmt, Steinberger ist nicht mehr persönlich verantwortlich. Er hätte den Erfolg (142.000 Stars), aber nicht mehr die Haftung. Bei OpenAI könnte er an fundamentaleren Problemen arbeiten – an den Modellen selbst, nicht an Frameworks, die diese Modelle orchestrieren. Ohne die Last der 400.000-Zeilen-Codebasis. Ohne Community-Governance-Kopfschmerzen. Ohne CSO-Warnungen.

Seine Formulierung – „schnellster Weg, die Welt zu verändern“ – bekäme eine neue Bedeutung: Nicht „OpenAI hat mehr Ressourcen“, sondern möglicherweise „OpenClaw ist nicht der Weg, die Welt zu verändern“. Zu komplex, zu unsicher, zu unkontrollierbar.

Das Muster hinter dem Exit

Diese Deutung würde einem Muster folgen, das sich in der Open-Source-Geschichte wiederholt: Gründer verlassen Projekte nicht, wenn sie scheitern, sondern wenn sie erfolgreich sind – aber unkontrollierbar werden.

Ryan Dahl, Gründer von Node.js, verließ das Projekt 2012 auf dem Höhepunkt der Verbreitung und entwickelte später Deno – eine Neuentwicklung, die Node.js‘ Architektur-Fehler korrigierte. Solomon Hykes trat 2018 als CTO von Docker zurück, während das Unternehmen wuchs, aber mit Orchestrierungs-Komplexität und Security-Fragen kämpfte. In beiden Fällen: Explosive frühe Adoption, wachsende technische Schulden, Gründer-Exit bevor die Krise eskaliert.

Der Unterschied: Dahl und Hykes gründeten neue Projekte oder Unternehmen. Steinberger geht zu OpenAI – dem Unternehmen, dessen Modelle OpenClaw antreiben. Das wäre klüger: Statt ein weiteres Framework zu bauen, das auf OpenAI-APIs angewiesen ist, entwickelt er jetzt die APIs selbst. Das wäre fundamentaler und würde die Wiederholung derselben Abhängigkeits-Struktur vermeiden.

Fazit: Die doppelte Wahrheit

Es gibt zwei mögliche Geschichten über Peter Steinbergers Wechsel zu OpenAI:

Die erste: Ein erfolgreicher Open-Source-Entwickler wird von Sam Altman persönlich rekrutiert, um an der nächsten Generation von Codex zu arbeiten. Eine Erfolgsgeschichte über Talent-Akquisition im KI-Wettbewerb.

Die zweite: Ein Gründer verlässt ein Projekt, das technisch in einer Sackgasse stecken könnte, bevor die öffentliche Wahrnehmung von „erfolgreiches Framework“ zu „Sicherheits-Alptraum“ kippt. Eine Geschichte über rechtzeitiges Risikomanagement.

Wir wissen nicht, welche Geschichte die wahre ist. Möglicherweise sind beide wahr.

NanoClaw existiert als technischer Beweis, dass OpenClaws Architektur nicht optimierbar, sondern fundamental anders gedacht werden muss. Die CSO-Warnungen sind der Vorbote eines möglichen Reputationsschadens. Die 400.000 Zeilen Code sind technische Schulden, die sich möglicherweise nicht mehr abbezahlen lassen. Die 25 Prozent fehlerhaften Skills zeigen: Community-Governance über natürlichsprachige Instruktionen mit Systemzugriff ist zumindest problematisch.

Steinberger könnte nicht trotz des Erfolgs gehen. Er könnte wegen einer versteckten Krise gehen.

Das wäre keine Kritik an seiner Entscheidung – es wäre möglicherweise die klügste Entscheidung, die er treffen konnte. Aber es lohnt sich, die Geschichte auch anders zu erzählen. Nicht nur als Triumphzug eines erfolgreichen Gründers, sondern als möglichen strategischen Exit aus einem Projekt, das seine eigene Architektur überlebt haben könnte.

Die eigentliche Lehre liegt woanders: Schneller Erfolg durch niedrige Einstiegshürden kann eine Falle sein, wenn die fundamentale Architektur nicht trägt. OpenClaw bewies, wie schnell man ein Ökosystem aufbauen kann. NanoClaw beweist, dass dieses Ökosystem möglicherweise auf Sand gebaut war. Und Steinbergers Wechsel könnte zeigen, dass selbst Gründer erkennen, wann es Zeit sein könnte zu gehen.

Die Frage bleibt: Welche Geschichte werden wir in sechs Monaten erzählen?

Ralf Keuper 

Quellen:

„Anleitung zur Integration von GPT-4 mit OpenClaw für multimodale Aufgaben und Function Calling.“​
Link: https://www.open-clawai.com/en/models/openai

Hacker News: OpenClaw bei OpenAI
Snippet: „Diskussion über ClawdBot’s Einstieg bei OpenAI und Synergien mit Codex.“​
Link: https://news.ycombinator.com/item?id=47027907

OpenClaw Docs: OpenAI HTTP API
Snippet: „Gateway für OpenAI Chat Completions in OpenClaw-Umgebung.“​
Link: https://docs.openclaw.ai/gateway/openai-http-api

YouTube: Azure OpenAI Fix
Snippet: „Schritt-für-Schritt-Lösung für Azure OpenAI-Support in OpenClaw.“​
Link: https://www.youtube.com/watch?v=5veaRxs2B3M

Milvus: OpenClaw Guide
Snippet: „Vollständiger Leitfaden zum Open-Source-KI-Agenten OpenClaw (ehemals ClawdBot).“​
Link: https://milvus.io/de/blog/openclaw-formerly-clawdbot-moltbot-explained-a-complete-guide-to-the-autonomous-ai-agent.md

OpenClaw API Docs
Snippet: „Dokumentation der OpenClaw API für Open-Source-KI-Assistenten.“​
Link: https://openclawapi.org/de

Ad-hoc News: Projekt bleibt unabhängig
Snippet: „OpenClaw als Stiftung: Gründer Steinberger zu OpenAI, Projekt offen.“​
Link: https://www.ad-hoc-news.de/boerse/news/ueberblick/openclaw-ki-projekt-bleibt-unabhaengig-gruender-geht-zu-openai/68584035

Reddit: Codex in OpenClaw
Snippet: „Diskussion: OpenClaw nutzt Codex-Modelle direkt für Code-Generierung.“​
Link: https://www.reddit.com/r/openclaw/comments/1r3hsdz/i_switch_openclaw_to_use_the_codex_model_does/

Handelsblatt: Steinberger-Wechsel
Snippet: „Peter Steinberger wechselt von OpenClaw zu OpenAI, Projekt bleibt open source.“​
Link: https://www.handelsblatt.com/technik/ki/ki-unternehmen-open-claw-entwickler-steinberger-wechselt-zu-openai/100200622.html