OpenClaw mit lokalem Modell - autonomer Agent ohne API-Kosten

Direkte Antwort

OpenClaw ist ein quelloffener Agent unter MIT-Lizenz, der auf deinem Rechner läuft und ein Sprachmodell mit deinen Dateien, deiner Shell, deinem Browser und deinen Messenger-Diensten verbindet. Die eigene Dokumentation bezeichnet ihn als modellagnostisch und nennt neben den Cloud-Anbietern ausdrücklich lokale Modelle über Ollama, LM Studio und vLLM.

Damit beantwortet OpenClaw die Frage, die nach den übrigen Guides auf dieser Seite logisch folgt: Das Modell läuft — und jetzt? Statt in einem Chatfenster zu tippen, bekommt das Modell Werkzeuge und darf handeln.

Zwei Dinge gehören in dieselbe Antwort. Erstens: Mit lokalem Modell liegen die laufenden Kosten bei null, die Doku führt genau das als Nullkosten-Pfad. Zweitens: OpenClaw läuft mit deinen Benutzerrechten und darf Befehle ausführen. Das ist kein Detail für später, sondern die Voraussetzung dafür, ob du es überhaupt einsetzen solltest. Der Abschnitt zur Sicherheit weiter unten ist der wichtigste dieser Seite.

Wie OpenClaw aufgebaut ist

Vier Bestandteile, die man kennen sollte, bevor man etwas einrichtet:

• Gateway — die zentrale Stelle, über die Verbindungen und Kommunikation laufen. Sie ist auch der Punkt, den man absichern muss.
• Brain und Hands — die Trennung zwischen der Ebene, die entscheidet (das Sprachmodell), und der, die ausführt (Dateizugriff, Shell, Browser).
• Memory — dauerhafter Speicher als Markdown-Dateien auf deiner Platte. Kein Cloud-Konto, keine fremde Datenbank. Du kannst hineinsehen und löschen, was nicht bleiben soll.
• Heartbeat — ein Taktgeber, der standardmäßig alle 30 Minuten prüft, ob etwas zu tun ist, und dann ohne Aufforderung handelt.

Der letzte Punkt ist der, den man beim ersten Lesen überliest und später bemerkt: OpenClaw wartet nicht nur auf Eingaben. Es wird von selbst aktiv. Das ist der eigentliche Unterschied zu einem Chatfenster — und zugleich der Grund, warum die Rechtefrage vorher geklärt sein muss.

Der Speicher als Markdown-Datei passt gut zur Logik lokaler Modelle: Die Daten bleiben da, wo du sie sehen kannst. Wer den Gedanken bis zum Ende führt, will auch das Modell selbst lokal haben — sonst wandert der Gesprächsinhalt trotz lokaler Notizen zu einem Anbieter.

Mit einem lokalen Modell verbinden

Der Aufbau ist unspektakulär, und das ist die gute Nachricht. Ollama stellt einen Server unter localhost:11434 bereit, LM Studio einen OpenAI-kompatiblen Endpunkt. OpenClaw spricht beide an.

# Ollama läuft und hält ein Modell bereit, das Funktionsaufrufe beherrscht
ollama pull hermes3:8b
ollama serve

# Prüfen, ob der Endpunkt erreichbar ist, bevor OpenClaw ins Spiel kommt
curl http://localhost:11434/api/tags

Wenn dieser Aufruf eine Modellliste zurückgibt, ist die lokale Seite fertig. In OpenClaw wird anschließend der lokale Endpunkt als Anbieter hinterlegt statt eines Cloud-Schlüssels.

Die Modellwahl ist hier kein Geschmacksthema. Ein Agent muss Funktionsaufrufe verlässlich im richtigen Format erzeugen — ein reines Chat-Modell scheitert daran und produziert Beschreibungen dessen, was es tun würde, statt es zu tun. Hermes 3 ist genau auf diese Fähigkeit abgestimmt und deshalb der naheliegende Startpunkt. Größere Modelle sind zuverlässiger, aber jeder Agentenschritt kostet Zeit, und bei zehn Schritten summiert sich das. Die Hardware-Grenzen dafür stehen im Hardware-Guide.

Sicherheit — der Abschnitt, den man nicht überspringen sollte

Hier wird es unbequem, und das gehört zur ehrlichen Einordnung dazu. Die folgenden Angaben stammen aus der offiziellen Dokumentation von OpenClaw selbst, nicht aus einer kritischen Fremdquelle:

• Vollzugriff mit deinen Benutzerrechten. Was du im Terminal darfst, darf der Agent auch.
• Zehn CVEs in sechs Monaten, darunter kritische Lücken mit Codeausführung aus der Ferne.
• Über 40.000 Instanzen waren öffentlich im Internet erreichbar.
• 341 mit Schadcode versehene Skills wurden im Erweiterungsverzeichnis gefunden.

Das ist kein Argument gegen OpenClaw — es ist ein Argument gegen sorglosen Betrieb. Ein junges Projekt mit rasanter Verbreitung und weitreichenden Systemrechten zieht Angriffe an. Die Doku nennt selbst die Gegenmaßnahmen:

1. Immer aktualisieren. Bei zehn CVEs in sechs Monaten ist eine veraltete Installation die eigentliche Lücke.
2. An localhost binden. Die 40.000 offenen Instanzen entstanden dadurch, dass das Gateway ans offene Netz gebunden wurde.
3. Authentifizierung aktivieren. Ein Gateway ohne Anmeldung ist eine Fernsteuerung für deinen Rechner.
4. Befehlsfreigabe eingeschaltet lassen, zumindest am Anfang. Der Agent fragt dann vor jeder Ausführung.
5. Niemals als root betreiben.

Und ein sechster Punkt, den ich ergänze, weil die 341 Skills genau darauf hinauslaufen: Erweiterungen aus einem offenen Verzeichnis sind fremder Code mit deinen Rechten. Vor der Installation hineinsehen, wie bei jedem npm-Paket auch — nur mit größerer Angriffsfläche.

Wer damit nicht umgehen will oder in einem regulierten Umfeld arbeitet: nicht auf dem Arbeitsrechner betreiben. Eine virtuelle Maschine oder ein separater Rechner kostet wenig und begrenzt den Schaden auf eine Umgebung, in der es keinen gibt.

Absicherung in der Reihenfolge, in der sie zählt

Die Empfehlungen aus der Doku sind richtig, aber unsortiert. In der Praxis gibt es eine Reihenfolge, weil die ersten beiden Punkte den Großteil des Risikos abdecken.

Zuerst: Isolieren. Bevor über Konfiguration geredet wird, gehört die Frage geklärt, wo der Agent läuft. Ein Agent mit Shell-Zugriff auf dem Rechner, auf dem auch Mandantendaten, Buchhaltung und SSH-Schlüssel liegen, ist eine Risikoentscheidung, keine Konfigurationsfrage. Eine virtuelle Maschine oder ein separater Mini-PC kostet wenig und begrenzt jeden Fehler auf eine Umgebung, in der es nichts zu verlieren gibt. Wer lokale Modelle ohnehin auf einer zweiten Maschine betreibt, hat das Problem schon gelöst.

Dann: Nicht ins Netz stellen. Die über 40.000 öffentlich erreichbaren Instanzen sind nicht durch einen Angriff entstanden, sondern dadurch, dass das Gateway an alle Netzwerkschnittstellen gebunden wurde statt nur an localhost. Wer von unterwegs zugreifen will, nimmt einen VPN- oder Tailscale-Tunnel — nicht eine offene Portfreigabe im Router.

Dann: Authentifizierung an. Ein Gateway ohne Anmeldung ist eine Fernsteuerung für den Rechner, auf dem es läuft.

Dann: Befehlsfreigabe anlassen. Der Reiz eines Agenten ist, dass er ohne Rückfrage handelt — und genau das ist am Anfang der Fehler. Lass die Freigabe eingeschaltet, bis du eine Woche lang gesehen hast, was er eigentlich ausführen will. Die Abschaltung ist eine Entscheidung, die man nach Beobachtung trifft, nicht bei der Installation.

Dann: Aktualisieren, und zwar wirklich. Zehn CVEs in sechs Monaten heißt: Eine Installation, die drei Monate liegt, ist mit hoher Wahrscheinlichkeit angreifbar. Wer keinen Weg hat, das regelmäßig zu tun, sollte OpenClaw nicht dauerhaft laufen lassen.

Und schließlich: Erweiterungen wie fremden Code behandeln. Die 341 gefundenen Schad-Skills sind der Beleg dafür, dass ein offenes Erweiterungsverzeichnis dieselbe Angriffsfläche hat wie jedes Paketregister — nur dass hier jede Erweiterung mit deinen vollen Rechten läuft. Hineinsehen, bevor sie installiert wird.

Niemals als root. Der Punkt braucht keine Erklärung, taucht aber in Anleitungen im Netz erstaunlich oft auf, weil es „einfacher” ist.

Was im Speicher landet — und warum das gut ist

Der Memory-Bereich ist eine Sammlung von Markdown-Dateien auf deiner Platte. Das klingt nach einem technischen Detail, ist aber der praktisch wichtigste Unterschied zu Agenten, die ihren Zustand in einer fremden Datenbank halten.

Du kannst hineinsehen. Du kannst löschen, was nicht bleiben soll. Du kannst in eine Versionsverwaltung legen, was bleiben soll. Und du kannst vor allem prüfen, was der Agent über dich und deine Arbeit festgehalten hat — eine Frage, die bei jedem System mit Langzeitgedächtnis irgendwann relevant wird.

Für datenschutzrechtliche Zwecke ist das ein handfester Vorteil: Auskunft und Löschung sind bei Textdateien im eigenen Dateisystem trivial. Wie sich das grundsätzlich einordnet, steht unter Sicherheit und DSGVO.

Gewöhn dir an, gelegentlich hineinzuschauen. Ein Agent, der seit Wochen läuft, sammelt mehr an, als man vermutet.

Womit man anfängt

Der häufigste Fehleinstieg ist eine große, vage Aufgabe. Lokale Modelle brechen bei mehrstufigen Ketten früher ab als Cloud-Modelle, und ein Agent, der bei Schritt sieben von zwölf etwas Falsches tut, ist schlimmer als gar keiner.

Aufgaben, die auch mit einem 8B-Modell verlässlich funktionieren, haben drei Eigenschaften: ein Werkzeug, ein klares Ergebnis, überprüfbar. Zum Beispiel:

• Eine PDF-Datei im Downloads-Ordner zusammenfassen und die Zusammenfassung als Textdatei danebenlegen
• Die Dateien eines Ordners nach Datum in Unterordner einsortieren
• Aus einer Nachricht einen Kalendereintrag vorbereiten — zum Bestätigen, nicht zum Eintragen
• Einen wiederkehrenden Statustext aus einer lokalen Datei erzeugen

Aufgaben, an denen es lokal scheitert: alles mit „und dann entscheide, ob…”, alles über mehr als drei Werkzeuge hinweg, alles mit unklarem Erfolgskriterium. „Organisiere mein Projekt” gehört in diese Kategorie.

Der Heartbeat verdient dabei einen eigenen Gedanken: Ein Taktgeber, der alle 30 Minuten aktiv wird, erzeugt bei einem Cloud-Modell rund um die Uhr Kosten. Lokal ist das eine Frage von Strom und Auslastung — was den Dauerbetrieb überhaupt erst vertretbar macht. Wer den Agenten auf einem Notebook laufen lässt, sollte trotzdem das Intervall verlängern, statt alle 30 Minuten den Lüfter anzuwerfen.

Was der lokale Betrieb wirklich bringt

Kosten. Ein Agent, der alle 30 Minuten von selbst aktiv wird, erzeugt dauerhaft Anfragen. Mit einer Cloud-API läuft dabei ein Zähler mit, den niemand im Blick hat. Mit lokalem Modell liegen die API-Kosten bei null; es bleiben Strom und Anschaffung.

Vertraulichkeit. Ein Agent mit Zugriff auf Dateien und Messenger sieht potenziell alles. Genau hier wird die Frage, wohin diese Inhalte gehen, unangenehm konkret. Läuft das Modell lokal, verlässt nichts davon deinen Rechner. Die datenschutzrechtliche Einordnung steht unter Sicherheit und DSGVO.

Unabhängigkeit. Kein Anbieter, der Preise ändert, Modelle abkündigt oder den Zugang sperrt.

Was der lokale Betrieb nicht bringt: dieselbe Zuverlässigkeit. Agenten verketten mehrere Schritte, und lokale Modelle brechen dabei häufiger ab oder rufen Werkzeuge falsch auf als die großen Cloud-Modelle. Wer OpenClaw lokal einsetzt, sollte mit engen, klar umrissenen Aufgaben anfangen — eine Datei zusammenfassen, einen Ordner aufräumen, eine Nachricht vorbereiten. Nicht: „organisiere mein Projekt”.

Wann OpenClaw lokal sinnvoll ist — und wann nicht

Sinnvoll, wenn du wiederkehrende Abläufe auf deinem eigenen Rechner automatisieren willst, die Daten berühren, welche das Haus nicht verlassen sollen, und wenn du bereit bist, die Absicherung ernst zu nehmen.

Nicht sinnvoll, wenn du komplexe mehrstufige Aufgaben erwartest, die zuverlässig durchlaufen — das leisten lokale Modelle Stand 2026 nicht stabil genug. Ebenso wenig, wenn du auf einem Rechner mit sensiblen Firmendaten arbeitest und die Absicherung nicht sauber aufsetzen kannst. Und nicht, wenn du nur ausprobieren willst, wie sich ein Agent anfühlt — dafür reicht ein Chatfenster mit Werkzeugen, ohne Vollzugriff auf dein System.

Nächster Schritt

Wenn OpenClaw mit einem lokalen Modell läuft, ist der nächste sinnvolle Baustein RAG lokal: Damit bekommt der Agent Zugriff auf deine eigenen Dokumente, ohne dass sie in den Kontext jedes einzelnen Aufrufs müssen. Wer mehrere Agenten koordinieren will, findet die Einordnung dazu unter Paperclip — inklusive der Stelle, an der der Lokal-Bezug dort endet.