Lokale Modelle mit Ollama in OpenClaw: ohne API-Key loslegen

OpenClaw lässt sich nicht nur mit gehosteten APIs betreiben. Wenn du Modelle lokal auf deinem eigenen Rechner laufen lassen willst, ist Ollama ein direkter Einstiegspunkt. Das ist attraktiv, weil du ohne laufende API-Kosten testen kannst und sensible Prompts nicht sofort an einen externen Provider schickst. Der Haken: Lokal heißt nicht automatisch gut genug für einen Agenten-Workflow. Genau darauf weist auch die OpenClaw-Dokumentation ausdrücklich hin.

Für einen einfachen Start ist der Weg trotzdem überschaubar. OpenClaw unterstützt Ollamas native API und unterscheidet laut Dokumentation drei Modi: Local only, Cloud only und Cloud + Local. Für dieses Tutorial geht es um den lokalen Pfad ohne externen API-Key für ein Modell-Backend. Dabei ist wichtig, dass OpenClaw bei entfernten Ollama-Hosts nicht die OpenAI-kompatible /v1-URL erwartet, sondern die native Basis-URL ohne /v1.

Direkter Einstieg

Die offizielle Doku empfiehlt für Ollama zuerst openclaw onboard (https://docs.openclaw.ai/cli/onboard). Dort kannst du Ollama als Provider wählen und den Modus Local only auswählen. OpenClaw fragt dann nach der Ollama-Basis-URL, entdeckt verfügbare Modelle automatisch und kann ein fehlendes lokales Modell bei Bedarf nachziehen.

Wenn du lieber manuell startest, sind die Kernschritte klar definiert (laut Doku zu lokalen Modellen: https://docs.openclaw.ai/gateway/local-models):

# Ollama installieren + OpenClaw CLI-Befehle laut Doku: https://docs.openclaw.ai/cli/onboard + https://docs.openclaw.ai/gateway/local-models
curl -fsSL https://ollama.com/install.sh | sh
# Ein lokales Modell laden
ollama pull gemma4
# OpenClaw für lokalen Ollama-Betrieb aktivieren
export OLLAMA_API_KEY="<YOUR_API_KEY>"
# Modellerkennung: openclaw scannt laufendes Ollama automatisch (siehe lokale-Modelle-Doku)

Auf macOS bietet Ollama zusätzlich ein DMG an. Laut Download-Seite setzt die macOS-App macOS 14 Sonoma oder neuer voraus. Für OpenClaw ist das Entscheidende aber nicht die Installationsform, sondern dass ein erreichbarer Ollama-Host läuft und Modelle über die native API bereitstellt.

Minimale Konfiguration

Für lokale Setups braucht OpenClaw nicht zwingend einen ausführlichen Provider-Block. Die Dokumentation beschreibt einen einfachen Pfad über implizite Erkennung: Wenn OLLAMA_API_KEY gesetzt ist und du models.providers.ollama nicht explizit definierst, versucht OpenClaw standardmäßig das lokale Ollama unter http://127.0.0.1:11434 zu entdecken. Dabei fragt es /api/tags ab und nutzt zusätzlich /api/show, um Merkmale wie Kontextfenster oder Vision-Fähigkeiten best effort zu erkennen.

Das ist praktisch, weil du keine Modellliste von Hand pflegen musst. Du ziehst ein Modell mit ollama pull, und OpenClaw kann es danach automatisch einbinden. Für ein Hobby-Setup ist das meist der bessere Start als eine sofort komplett manuelle JSON-Konfiguration.

Wenn du das Standardmodell dauerhaft setzen willst, reicht laut Doku schon ein kleiner Eintrag in den Defaults:

{
  agents: {
    defaults: {
      model: { primary: "ollama/gemma4" },
    },
  },
}

Diese Kombination aus automatischer Modellerkennung und einem klar gesetzten primary ist die sauberste Minimalvariante für einen lokalen Einstieg.

Modellauswahl für lokale Setups

Ollamas Library zeigt sehr klar, dass dort nicht nur klassische Textmodelle liegen. Es gibt Tool-Modelle, Vision-Modelle, Embedding-Modelle und auch Cloud-Varianten. Für OpenClaw ist das relevant, weil ein Agent nicht nur formulieren, sondern oft mit langem Kontext, Tool-Schemas und robustem Prompt-Verhalten klarkommen muss.

Die OpenClaw-Seite zu lokalen Modellen bremst hier bewusst den Optimismus. Dort steht sinngemäß: Lokaler Betrieb ist möglich, aber OpenClaw erwartet große Kontextfenster und starke Abwehr gegen Prompt Injection. Kleine Karten oder stark quantisierte Mini-Modelle sind dafür schnell überfordert. OpenClaw warnt laut Doku bei weniger als 32k Kontext und blockiert lokale Setups sogar unter 16k Kontext.

Für den Testlauf heißt das nicht, dass du sofort einen teuren Workstation-Rechner brauchst. Es heißt aber schon: Nimm nicht automatisch das kleinste Modell, nur weil es auf deinem Laptop startet. Wenn du mit Ollama lokal experimentierst, sind größere und aktuell gepflegte Modelle der sicherere Pfad. In der Ollama-Library sind dafür etwa gemma2, qwen2.5, llama3.1 oder neuere Varianten als Kandidaten sichtbar. Welche davon auf deiner Hardware sinnvoll läuft, hängt stark von RAM, GPU und gewünschter Latenz ab.

Bildverarbeitung und Spezialfälle

Die Ollama-Integration in OpenClaw kann mehr als nur Text. Die Provider-Dokumentation beschreibt, dass Vision-Modelle über Ollama auch für Bildverständnis genutzt werden können. Als Beispiel nennt die Doku qwen2.5vl:7b. Wenn so ein Modell in Ollama verfügbar ist und OpenClaw es als bildfähig erkennt, kannst du es auch als imageModel für eingehende Medien setzen.

Das ist interessant, wenn du OpenClaw lokal nicht nur chatten, sondern etwa Screenshots, Fotos oder Dokumentbilder beschreiben lassen willst. Für den Einstieg in diese Tutorial-Serie ist das ein zweiter Schritt. Erst Text stabil bekommen, dann Vision ergänzen.

Grenzen lokaler Setups

Die häufigste Fehlerquelle bei Ollama-Setups ist nicht die Installation, sondern falsche Erwartungen. Lokal ist gut für Datenschutz, Kostenkontrolle und schnelle Experimente. Lokal ist nicht automatisch die beste Wahl für jede produktive Agenten-Aufgabe. Die OpenClaw-Dokumentation empfiehlt sogar ausdrücklich, gehostete Modelle als Fallbacks aktiv zu lassen und models.mode: "merge" zu nutzen, wenn du hybrid arbeiten willst.

Das ergibt Sinn. Ein lokales Modell kann den Alltagsverkehr übernehmen, während ein gehostetes Modell einspringt, wenn der Kontext größer wird oder die Aufgabe heikler ist. Gerade bei langen Sessions, Tool-Aufrufen und komplexen Sicherheitsanforderungen ist diese Absicherung deutlich vernünftiger als ein dogmatisches “alles lokal oder gar nichts”.

Typische Fehlerquellen

Drei Stolpersteine tauchen in der Dokumentation immer wieder auf. Erstens: ein falscher Endpoint. Bei Ollama-Hosts gehört in OpenClaw die native Basis-URL hinein, nicht eine /v1-Route. Zweitens: ein Modell ist zwar installiert, aber nicht geladen oder nicht sauber erkannt. Dann hilft zuerst ollama list, danach openclaw models list (https://docs.openclaw.ai/gateway/local-models). Drittens: das Modell ist schlicht zu klein für den realen Agenten-Prompt. Dann wirkt das Setup nicht „etwas langsam”, sondern qualitativ brüchig.

Wenn du nur einen funktionierenden Startpunkt willst, ist der empfohlene Weg deshalb überraschend langweilig: Ollama installieren, ein größeres Modell ziehen, OLLAMA_API_KEY="<YOUR_API_KEY>" setzen, Modell in OpenClaw auswählen und erst danach testen, wie weit deine Hardware wirklich trägt. Nicht andersherum.

Zusammenfassung

Ollama ist für OpenClaw ein praktischer Weg in lokale Modelle, solange du die Grenzen ernst nimmst. Für ein Hobby-Setup ohne laufende API-Kosten ist das ein solider Einstieg. Die Minimal-Konfiguration ist klein, die Modellerkennung bequem und die Einrichtung deutlich angenehmer als bei vielen anderen lokalen Stacks.

Der entscheidende Punkt ist aber nicht, ob ein Modell lokal startet, sondern ob es für OpenClaw stabil genug läuft. Wenn du das nüchtern testest und nicht am falschen Ende sparst, bekommst du mit Ollama eine lokale OpenClaw-Installation, die sich wirklich sinnvoll nutzen lässt.