OpenClaw Ollama: Gateway lokal anbinden

TL;DR

OpenClaw Ollama ist der lokale Weg, den OpenClaw-Gateway an die Ollama-API zu hängen. Der kürzeste Pfad in der Ollama-Integrationsdoku ist ollama launch openclaw: fehlendes OpenClaw kommt per npm, ein Sicherheitshinweis erscheint, Sie wählen ein Modell, der Daemon startet, die gebündelte Web-Suche wird gesetzt, die TUI öffnet sich. OpenClaw spricht die native Route /api/chat. Die Adresse http://host:11434/v1 ist falsch: Tool-Aufrufe zerfallen dann zu Text-JSON. Gelesen in Ollama-Integration, Provider-Index, Setup und Troubleshooting am 2026-10-11. Kein Ranking, kein Kaufguide.

Agent-Gateway, nicht Chat-UI

IT-Leiter suchen „openclaw ollama“, wenn der persönliche Assistent WhatsApp, Telegram, Slack, Discord oder iMessage an lokale Modelle binden soll — nicht, wenn nur die Chat-Oberfläche fehlt. Die UI-Schicht bleibt OpenWebUI hinter Nginx. Dieser Text behandelt nur Provider, Gateway und Modellwahl.

OpenClaw hieß zuvor Clawdbot und Moltbot. Der Ollama-Blog vom

1. Februar 2026 nennt clawdbot als Alias. Die Integrationsseite nennt zusätzlich ollama launch clawdbot.

Ollama selbst installieren Sie über Ollama Download oder den Linux-Dienst. Port und Bind-Adresse bleiben 11434. Die Sandbox-Variante mit NVIDIA OpenShell steht in NemoClaw auf dem DGX Spark; dort ist die Runtime weiter OpenClaw, die Inferenz dort vLLM.

Drei Setups laut Provider-Doku

Die OpenClaw-Ollama-Seite trennt drei Wege. Keiner ist ein Sieger, sie unterscheiden sich nur im Host.

Cloud + Local und Local only fragen nach einer Base-URL. Eine ollama.com-URL gehört dort nicht hin; gehosteter Zugriff läuft über --auth-choice ollama-cloud.

Die kanonische Config-Taste heißt baseUrl. baseURL akzeptiert die Doku nur als Altform. Neu: baseUrl: "http://host:11434" ohne /v1.

Schnellstart: ollama launch openclaw

Die Integrationsseite, Abschnitt Quick start:

ollama launch openclaw

Ollama prüft der Reihe nach: Installation per npm, Sicherheitshinweis zu Tool-Zugriff, Modellwahl (lokal oder Cloud), Provider-Config, Gateway-Daemon, primäres Modell, gebündelte Ollama-Web-Suche, Start der TUI.

Ohne TUI, nur Config:

ollama launch openclaw --config

Mit festem Modell; läuft der Gateway schon, startet er neu:

ollama launch openclaw --model kimi-k2.5:cloud

Headless für Docker, CI oder Skripte. --yes zieht das Modell, überspringt Auswahldialoge und verlangt --model:

ollama launch openclaw --model kimi-k2.5:cloud --yes

Gateway stoppen:

openclaw gateway stop

Onboarding ohne Launch-Wrapper

Die Setup-Seite empfiehlt openclaw onboard. Dort Ollama wählen, dann Cloud + Local oder Local only.

openclaw onboard

Automatische Entdeckung sieht nur Modelle, die /api/ps als geladen meldet, plus Tool-Support und mindestens 16K Kontext laut /api/show. Ein installiertes, aber nicht geladenes Modell ist kein automatischer Kandidat. Die gewählte Route braucht eine echte Completion, bevor OpenClaw sie speichert. Discovery lädt kein ruhendes Modell.

Ohne geladenes Tool-Modell darf Setup ein empfohlenes Modell ziehen. Ein Tag :latest wie gemma4:latest erscheint einmal, nicht doppelt.

Nicht-interaktiv, Beispiel der Setup-Seite:

openclaw onboard --non-interactive --accept-risk --skip-health \
  --auth-choice ollama \
  --custom-base-url "http://ollama-host:11434" \
  --custom-model-id "qwen3.5:27b"

Ohne Base-URL gilt der lokale Default-Host. Ohne Modell-ID bevorzugt Setup ein installiertes Tool-Modell mit mindestens 16K Kontext, zuerst ohne Reasoning, dann kleinere Varianten. Fehlt ein Treffer, versucht Setup das vorgeschlagene Modell gemma4.

Ein rein embedding-fähiges Modell darf nicht Chat-Default werden. Setup lässt die alte Config stehen.

Manuell nach der Setup-Seite: Ollama starten, Modell ziehen, Credential setzen, Modell wählen.

ollama pull gemma4
export OLLAMA_API_KEY="ollama-local"
openclaw models list --provider ollama
openclaw models set ollama/gemma4

Lokal und LAN (Loopback, privates Netz, .local, nackter Hostname) brauchen keinen echten Bearer. OpenClaw setzt den Marker ollama-local. Öffentliche Hosts und https://ollama.com brauchen einen echten Schlüssel, ein Auth-Profil oder apiKey. Reine OLLAMA_API_KEY gilt laut Setup als Cloud-Konvention und geht standardmäßig nicht an lokale Hosts.

Cloud-only ohne lokalen Daemon:

openclaw onboard --auth-choice ollama-cloud
openclaw models set ollama-cloud/minimax-m2.7:cloud

Kontext, Modelle, Web-Suche

Ollama-Integration und Ollama-Blog: OpenClaw braucht ein größeres Kontextfenster. Für lokale Modelle empfehlen beide Seiten mindestens 64k Tokens. Das ist eine Herstellerangabe, keine eigene Messung.

Dieselbe Integrationsseite nennt als lokale Beispiele gemma4 (Reasoning und Code, dort mit etwa 16 GB VRAM) und qwen3.5 (Reasoning, Code, Bildverstehen, dort mit etwa 11 GB VRAM). Cloud- Beispiele auf derselben Seite: kimi-k2.5:cloud, qwen3.5:cloud, glm-5.1:cloud, minimax-m2.7:cloud. Kein Ranking.

Web-Suche kommt gebündelt, wenn Sie über ollama launch openclaw starten. Manuell:

openclaw configure --section web

Lokale Modelle brauchen für Ollama-Web-Suche ollama signin.

Kanäle (WhatsApp, Telegram, Slack, Discord, iMessage):

openclaw configure --section channels

Windows ohne WSL: der Ollama-Blog nennt iwr -useb https://openclaw.ai/install.ps1 | iex. Linux/macOS: curl -fsSL https://openclaw.ai/install.sh | bash. GPU unter Windows: Ollama Windows GPU / WSL2.

Native API, nicht /v1

Der Provider-Index: OpenClaw nutzt /api/chat, nicht den OpenAI-kompatiblen Endpunkt. /v1 zerlegt Tool-Calling; Modelle schreiben dann rohes Tool-JSON als Text.

{
  models: {
    providers: {
      ollama: {
        baseUrl: "http://ollama-host:11434",
        api: "ollama",
      },
    },
  },
}

Wenn ein kleines lokales Modell Schemas weiter nicht trägt, setzt die Troubleshooting-Seite compat.supportsTools: false auf diesem Eintrag.

OpenClaw bricht nach drei gleichen Fehlern derselben Tool-Argumente ab. Das ist immer aktiv; tools.loopDetection ist dafür nicht nötig. Auf Ollama 0.40.1 können Templates den Marker <tool_call> mit Tool Search verwechseln. OpenClaw übersetzt intern, Session und Ausführung behalten die Originalnamen.

Wenn der Host nicht antwortet

Ollama nicht erkannt. Dienst läuft, OLLAMA_API_KEY oder Profil gesetzt, dann ollama serve und curl http://localhost:11434/api/tags.

Connection refused. Prozess prüfen oder ollama serve neu.

curl geht, OpenClaw nicht. Vom selben Host wie der Gateway:

openclaw gateway status --deep
curl http://ollama-host:11434/api/tags

Häufig laut Troubleshooting: baseUrl zeigt auf localhost, der Gateway läuft aber in Docker; die URL endet auf /v1; Firewall oder LAN-Bind fehlt; das Modell liegt auf dem Laptop, nicht auf dem entfernten Host.

Kalter Start timeout. Die Troubleshooting-Seite scoped timeoutSeconds: 300 auf den Ollama-Provider und setzt optional keep_alive: "15m" am Modell. Das ist ein Config-Beispiel der Doku, kein SLA.

WSL2-Reboot-Schleife. Der Linux-Installer legt ollama.service mit Restart=always an. Lädt der Dienst beim WSL2-Boot ein GPU-Modell, kann Windows die VM beenden, systemd startet neu. Die Doku: sudo systemctl disable ollama, in %USERPROFILE%\.wslconfig autoMemoryReclaim=disabled, danach wsl --shutdown. Alternative: OLLAMA_KEEP_ALIVE=5m und ollama serve nur bei Bedarf.

FAQ

Muss ich OpenClaw extra installieren?

ollama launch openclaw installiert fehlendes OpenClaw per npm. Der Blog-Pfad über install.sh bzw. install.ps1 bleibt gültig.

Darf die Base-URL auf /v1 enden?

Nein. Native URL ohne Suffix. Sonst Tool-JSON als Klartext.

Reicht ein kleines Chat-Modell?

Die Integrationsseite verlangt für lokale Modelle mindestens 64k Kontext. Auto-Discovery verlangt Tool-Support und 16K laut /api/show. Embedding-only ist als Chat-Default gesperrt.

Ist NemoClaw dasselbe?

Nein. NemoClaw sandboxt OpenClaw und hängt dort an vLLM. Die Ollama-Anbindung bleibt dieser Text.

Fazit

„OpenClaw Ollama“ ist die Provider-Schicht: native /api/chat, ollama launch openclaw oder openclaw onboard, Local only bzw. Cloud + Local, Gateway prüfen und stoppen. Port, Dienst und Download bleiben die bestehenden Ollama-Seiten. Hardware-Kauf gehört nicht in diesen Schritt.