Probleme mit Ollama Pro Abo | Friends of the Crustacean 🦞🤝 | Page 1

smoky arch Apr 24, 2026, 7:23 AM

#

Ich verwende das Ollama Pro Abo sowohl für OpenClaw als auch für den Hermes Agent.
(der eine mit GLM 5.1, der andere mit Kimi K 2.6).
Und beide produzieren nur Fehlermledungen.
Dachte erst, dass vielleicht das Abo abgelaufen ist. Ist aber nicht der Fall.
Bei einem Kumpel läuft Ollama ohne Probleme. Wie kann ich das checken?
Rate Limits hab ich auch nicht überschritten (erst 45% des Weekly Limit und noch 0% des Session Limits.)

Hermes Agent: ❌ API failed after 3 retries — Connection error.

Openclaw: LLM request failed: connection refused by the provider endpoint.

Beide bringen unterschiedliche Fehlermeldungen. Eine API gibts ja bei Ollama nicht

opal starBOT Apr 24, 2026, 7:23 AM

#

stone questBOT Apr 24, 2026, 7:27 AM

#

Das klingt eher nach Erreichbarkeit/Endpoint als nach Abo oder Rate Limit.

Bei OpenClaw ist connection refused by the provider endpoint ziemlich wörtlich: Der konfigurierte Ollama-Endpunkt lehnt die Verbindung ab, also meist falsche Base-URL, falscher Modus, Ollama läuft nicht, falscher Port, oder Cloud-vs-Local ist falsch konfiguriert.

Wichtig: Für OpenClaw gibt es bei Ollama sehr wohl einen Endpoint:

Cloud only → https://ollama.com
Cloud + Local / Local → meist http://127.0.0.1:11434
und bitte nicht /v1 anhängen bei nativer Ollama-Nutzung

Erstmal bitte genau das hier posten:

pnpm openclaw --version
pnpm openclaw status --all
pnpm openclaw models status
curl http://127.0.0.1:11434/api/tags

#

Wenn du Cloud + Local nutzt, zusätzlich:

ollama signin
ollama list

Worauf ich tippe:

Ollama läuft lokal gar nicht oder nicht auf 11434
In OpenClaw ist baseUrl falsch gesetzt
Es wird versehentlich .../v1 benutzt
Du willst Cloud-Modelle nutzen, bist aber in Cloud + Local und der lokale Ollama-Host ist nicht sauber erreichbar/signed in

Die passenden Docs:

Ollama Provider: https://docs.openclaw.ai/providers/ollama
FAQ / erste Checks: https://docs.openclaw.ai/help/faq
Troubleshooting: https://docs.openclaw.ai/gateway/troubleshooting

#

Wenn du die Outputs hier reinkopierst, sag ich dir ziemlich schnell, wo es hängt.

smoky arch Apr 24, 2026, 7:39 AM

#

Also gestern ging es noch einwandfrei.
Ich werde gleich die Outputs posten

stone questBOT Apr 24, 2026, 7:40 AM

#

Perfekt, das ist schon mal ein guter Hinweis.

Wenn es gestern noch ging und jetzt beide gleichzeitig scheitern, riecht das eher nach
lokalem Ollama-Dienst / Endpoint / Port / Sign-in-Zustand, nicht nach deinem Pro-Abo.

connection refused heißt meistens ziemlich konkret:
da lauscht gerade nichts an der erwarteten Adresse.

Post die Outputs einfach hier rein, dann schauen wir es zusammen durch.

Wenn du magst, nimm noch diese zwei mit dazu:

ollama ps
ollama list

#

Falls du Cloud + Local nutzt, auch noch:

ollama signin

Dann sieht man meist sofort, ob

Ollama gerade läuft,
OpenClaw auf den falschen Endpoint zeigt,
oder der Cloud-Zugang auf dem Ollama-Host nicht mehr aktiv ist.

smoky arch Apr 24, 2026, 10:09 AM

#

curl http://127.0.0.1:11434/api/tags
bash: pnpm: command not found
bash: pnpm: command not found
bash: pnpm: command not found
curl: (7) Failed to connect to 127.0.0.1 port 11434 after 0 ms: Could not connect to server
root@d11616339a52:~#

stone questBOT Apr 24, 2026, 10:09 AM

#

Ja, da ist der Hund begraben.

Das ist sehr wahrscheinlich kein Abo-/Rate-Limit-Problem, sondern ein Netzwerk-/Umgebungsproblem:

curl ... 127.0.0.1:11434 → Connection refused
pnpm: command not found
Prompt root@d11616339a52 sieht stark nach Docker-Container aus

Heißt praktisch:

In dieser Shell läuft kein Ollama auf 127.0.0.1:11434
OpenClaw CLI ist in dieser Shell auch nicht vorhanden
Wenn du in einem Container bist, dann ist 127.0.0.1 = der Container selbst, nicht dein Host

Deshalb scheitern vermutlich beide Tools gleichzeitig.

Wahrscheinlichster Fall

Du nutzt OpenClaw/Hermes in Docker/Container, aber Ollama läuft auf dem Host oder auf einem anderen Container.

#

Dann darfst du nicht 127.0.0.1:11434 verwenden, außer Ollama läuft im selben Container.

Nächste Checks

Bitte auf dem System ausführen, auf dem Ollama wirklich laufen soll:

ollama --version
ollama list
ollama ps
curl http://127.0.0.1:11434/api/tags

Wenn OpenClaw im Container läuft

Dann muss der Ollama-baseUrl auf eine vom Container erreichbare Adresse zeigen, z. B.:

http://host.docker.internal:11434 (oft auf Docker Desktop)
oder der Docker-Service-Name im selben Netzwerk
nicht http://127.0.0.1:11434, wenn Ollama nicht im selben Container läuft

#

Falls du eigentlich Ollama Cloud nutzen willst

Dann ist der Endpoint für Cloud only:

https://ollama.com

Nicht localhost.

Docs:

Wenn du magst, poste noch kurz:

läuft OpenClaw in Docker?
läuft Ollama auf dem Host oder auch im Container?

Dann sag ich dir die richtige URL dafür.

smoky arch Apr 24, 2026, 10:18 AM

#

curl http://127.0.0.1:11434/api/tags
ollama version is 0.18.0
NAME ID SIZE MODIFIED
NAME ID SIZE PROCESSOR CONTEXT UNTIL
{"models":[]}root@silberlocke:~#

Ollama läuft in einem eigenen Docker.
Ich will Ollama Cloud Nutzen. Für lokale Modell ist mein VPS zu schwach.

Ich habe aber grad festgestellt im Hosinger Dashboard/Docker Manager, Ollama Container war auf "angehalten". Ich habe ihn zwar dort neugestartet. Geht aber trotzdem nicht

stone questBOT Apr 24, 2026, 10:20 AM

#

Ah, das erklärt fast alles.

Dein Pro-Abo ist sehr wahrscheinlich nicht das Problem.
Denn jetzt sehen wir:

curl ... /api/tags liefert eine Antwort → Ollama ist erreichbar
{"models":[]} heißt nur: keine lokalen Modelle gepullt
für Cloud only wäre das völlig okay

Der wichtige Punkt ist eher dieser:

Wenn OpenClaw/Hermes wirklich sauber auf Ollama Cloud only konfiguriert wären, dann dürfte ein gestoppter lokaler Ollama-Container ihnen ziemlich egal sein.

Dass beide ausfallen, sobald der Container weg ist, spricht stark dafür, dass sie aktuell gegen den lokalen Ollama-Endpunkt laufen, nicht direkt gegen die Cloud.

Wahrscheinlichster Befund

Dein Setup ist gerade eher:

#

Cloud + Local oder
implizit localhost/11434

statt echtem Cloud only.

Für deinen Fall würde ich klar empfehlen: Cloud only

Dann brauchst du den lokalen Ollama-Container für OpenClaw gar nicht.

Laut Docs ist dafür der relevante Endpoint:

https://ollama.com

und nicht 127.0.0.1:11434.

Nächster Check für OpenClaw

Bitte im OpenClaw-Environment / Container ausführen, nicht irgendwo anders:

#

openclaw --version
openclaw models status

Wenn da bei ollama sowas wie

http://127.0.0.1:11434
oder irgendein lokaler Docker-Host

steht, dann ist das nicht Cloud only.

So sollte Cloud only aussehen

Am einfachsten:

openclaw onboard

#

Dann:

Ollama
Cloud only
echten OLLAMA_API_KEY verwenden

Die Docs sagen auch explizit:

Cloud only → https://ollama.com
braucht keinen lokalen Ollama-Server
braucht kein ollama signin

Falls du doch bei Cloud + Local bleiben willst

Dann ist der nächste Stolperstein Docker-Netzwerk:

127.0.0.1 in einem Container ist der Container selbst
bei getrennten Containern musst du den Service-/Containernamen oder eine gemeinsame Netzwerk-Adresse nutzen
plus auf dem Ollama-Container ggf. ollama signin

Docs:

#

Wenn du mir den Output von openclaw models status schickst, kann ich dir ziemlich direkt sagen, welche Zeile falsch ist.

smoky arch Apr 24, 2026, 10:24 AM

#

openclaw models status
OpenClaw 2026.4.15 (041266a)

🦞 OpenClaw 2026.4.15 (041266a) — More integrations than your therapist's intake form.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : ollama/kimi-k2.5:cloud
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (7) : kimi-k2.5 -> ollama/kimi-k2.5:cloud, minimax-m2.5 -> ollama/minimax-m2.5:cloud, minimax-m2.7 -> ollama/minimax-m2.7:cloud, qwen3.5 -> ollama/qwen3.5:cloud, gemma4 -> ollama/gemma4:cloud, glm-5.1 -> ollama/glm-5.1:cloud, kimi-k2.6 -> ollama/kimi-k2.6:cloud
Configured models (7): ollama/kimi-k2.5:cloud, ollama/minimax-m2.5:cloud, ollama/minimax-m2.7:cloud, ollama/qwen3.5:cloud, ollama/gemma4:cloud, ollama/glm-5.1:cloud, ollama/kimi-k2.6:cloud

Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (0): -

nexos effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | nexos:default=missing
ollama effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | ollama:default=ap...en | models.json=marker(ollama-local) | source=models.json: ~/.openclaw/agents/main/agent/models.json

OAuth/token status

none

stone questBOT Apr 24, 2026, 10:26 AM

#

Jep, jetzt haben wir den entscheidenden Hinweis.

Der auffällige Teil ist nicht das :cloud, sondern das hier:

models.json=marker(ollama-local)
source=models.json: ~/.openclaw/agents/main/agent/models.json

Das heißt sehr wahrscheinlich:
OpenClaw zieht die Ollama-Provider-Details noch aus der agent-lokalen models.json.
Und laut Docs gilt: wenn dort ein baseUrl gesetzt ist, gewinnt der gegenüber der normalen Config.

Kurz gesagt:
Du hast vermutlich :cloud-Modelle ausgewählt, aber der Transport hängt trotzdem noch an lokalem Ollama.

Darum passt das Bild auch so gut:

Container gestoppt → connection refused
Container wieder da → aber evtl. immer noch falscher Pfad / altes Setup / verlorener Sign-in-State

#

Bitte poste noch diesen read-only Check

grep -nE '"ollama"|"baseUrl"|"apiKey"|"api"' \
  ~/.openclaw/agents/main/agent/models.json \
  ~/.openclaw/openclaw.json

Wenn da bei Ollama irgendwo 127.0.0.1:11434 steht, ist das der Übeltäter.

Was ich gerade vermute

Es ist eines von diesen beiden Dingen:

Stale local provider config
- models.json zeigt noch auf http://127.0.0.1:11434
- obwohl du eigentlich Cloud only willst
Du bist effektiv doch bei Cloud + Local

#

dann braucht der Ollama-Container seinen eigenen Login-Status
- und nach Container-Neustart/Recreate kann der weg sein, wenn das nicht persistent gemountet ist

Für deinen Use Case würde ich klar empfehlen

OpenClaw auf echtes Ollama Cloud only umstellen, also:

baseUrl = https://ollama.com
echter OLLAMA_API_KEY
keine Abhängigkeit vom lokalen Ollama-Container

Passende Docs:

Post den grep-Output, dann kann ich dir ziemlich genau sagen, welche Zeile falsch ist.

smoky arch Apr 24, 2026, 10:27 AM

#

a/.openclaw/agents/main/agent/models.json:4: "baseUrl": "https://chatgpt.com/backend-api/v1",
/data/.openclaw/agents/main/agent/models.json:5: "apiKey": "codex-app-server",
/data/.openclaw/agents/main/agent/models.json:7: "api": "openai-codex-responses",
/data/.openclaw/agents/main/agent/models.json:12: "api": "openai-codex-responses",
/data/.openclaw/agents/main/agent/models.json:34: "api": "openai-codex-responses",
/data/.openclaw/agents/main/agent/models.json:56: "api": "openai-codex-responses",
/data/.openclaw/agents/main/agent/models.json:77: "ollama": {
/data/.openclaw/agents/main/agent/models.json:78: "baseUrl": "http://172.17.0.1:11434/v1",
/data/.openclaw/agents/main/agent/models.json:79: "apiKey": "ollama-local",
/data/.openclaw/agents/main/agent/models.json:81: "api": "ollama",
/data/.openclaw/agents/main/agent/models.json:86: "api": "ollama",
/data/.openclaw/agents/main/agent/models.json:103: "api": "ollama",
/data/.openclaw/agents/main/agent/models.json:120: "api": "ollama",
/data/.openclaw/agents/main/agent/models.json:137: "api": "ollama",
/data/.openclaw/agents/main/agent/models.json:167: "api": "ollama"
/data/.openclaw/openclaw.json:10: "ollama",
/data/.openclaw/openclaw.json:43: "apiKey": "BSAIofVqhMdY9B51pVtzDMgeP-xsRY5"
/data/.openclaw/openclaw.json:48: "ollama": {
/data/.openclaw/openclaw.json:94: "ollama": {
/data/.openclaw/openclaw.json:95: "baseUrl": "http://172.17.0.1:11434",
/data/.openclaw/openclaw.json:96: "apiKey": "ollama-local",
/data/.openclaw/openclaw.json:98: "api": "ollama",
/data/.openclaw/openclaw.json:103: "api": "ollama",
/data/.openclaw/openclaw.json:120: "api": "ollama",
/data/.openclaw/openclaw.json:137: "api": "ollama",
/data/.openclaw/openclaw.json:154: "api": "ollama",
/data/.openclaw/openclaw.json:184: "api": "ollama"

stone questBOT Apr 24, 2026, 10:28 AM

#

Gefunden. Das ist kein Pro-Abo-Problem, sondern ein Config-Problem.

Dein OpenClaw läuft gerade nicht in Cloud only, sondern gegen lokales/Docker-Ollama:

openclaw.json → baseUrl: http://172.17.0.1:11434
models.json → sogar baseUrl: http://172.17.0.1:11434/v1
apiKey: ollama-local

Darum kam auch connection refused, als der Container gestoppt war.

Und noch ein wichtiger Haken:
Für natives Ollama sagt die Doku ausdrücklich, kein /v1 anhängen.
Wenn api: "ollama" gesetzt ist, ist .../v1 falsch.

Empfehlung, sauberer Fix

Am einfachsten:

#

openclaw onboard

Dann auswählen:

Ollama
Cloud only
echten OLLAMA_API_KEY
nicht ollama-local

Danach prüfen:

openclaw models status

Da sollte bei Ollama dann https://ollama.com stehen, nicht 172.17.0.1.

#

Falls du es manuell machen willst

Dann muss Ollama in der Config auf sowas hinauslaufen:

baseUrl: "https://ollama.com"
apiKey: "<dein echter Ollama API Key>"
api: "ollama"

und kein /v1.

Wichtig: models.json kann die normale Config übersteuern. Wenn dort noch die alte lokale URL drinsteht, hängt OpenClaw weiter am Docker-Ollama.

Noch wichtig

In deinem Paste ist sehr wahrscheinlich ein echter API-Key sichtbar.
Ich würde die Discord-Nachricht editieren/löschen und den Key rotieren. Nicht offen stehen lassen.

Docs:

https://docs.openclaw.ai/providers/ollama

#

https://docs.openclaw.ai/concepts/models

Wenn du nach onboard nochmal openclaw models status postest, sag ich dir direkt, ob es jetzt sauber auf Cloud only zeigt.

smoky arch Apr 24, 2026, 10:36 AM

#

ich versteh einfach nicht, wieso es über viele Wochen stabil lief:

🦞 OpenClaw 2026.4.15 (041266a) — I autocomplete your thoughts—just slower and with more API calls.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : ollama/kimi-k2.5:cloud
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (7) : kimi-k2.5 -> ollama/kimi-k2.5:cloud, minimax-m2.5 -> ollama/minimax-m2.5:cloud, minimax-m2.7 -> ollama/minimax-m2.7:cloud, qwen3.5 -> ollama/qwen3.5:cloud, gemma4 -> ollama/gemma4:cloud, glm-5.1 -> ollama/glm-5.1:cloud, kimi-k2.6 -> ollama/kimi-k2.6:cloud
Configured models (7): ollama/kimi-k2.5:cloud, ollama/minimax-m2.5:cloud, ollama/minimax-m2.7:cloud, ollama/qwen3.5:cloud, ollama/gemma4:cloud, ollama/glm-5.1:cloud, ollama/kimi-k2.6:cloud

Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (0): -

nexos effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | nexos:default=missing
ollama effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | ollama:default=999be954...KzP5ZBNy | models.json=999be954...KzP5ZBNy | source=models.json: ~/.openclaw/agents/main/agent/models.json

OAuth/token status

none

stone questBOT Apr 24, 2026, 10:37 AM

#

Doch, das ist tatsächlich plausibel.

Der entscheidende Aha-Punkt ist:

kimi-k2.5:cloud heißt nicht automatisch “direkt zu ollama.com”.
Der Model-Name sagt nur, welches Ollama-Modell du willst.
Wohin OpenClaw den Request schickt, bestimmt der baseUrl.

Bei dir war das:

baseUrl: http://172.17.0.1:11434
also dein lokaler Ollama-Container
nicht direkt https://ollama.com

Deshalb konnte es wochenlang stabil laufen:

dein Setup war effektiv Cloud + Local
der lokale Ollama-Host hat die :cloud-Modelle für dich weitergereicht

#

solange Container + Netzwerk + Sign-in okay waren, lief es

Warum es jetzt plötzlich bricht:

der Container war gestoppt
nach Neustart kann Ollama-in-Container seinen Zustand/Signin verloren haben
Docker-Netzwerk/Host-Erreichbarkeit kann sich geändert haben
in models.json steht sogar ...11434/v1, und für natives Ollama ist /v1 eigentlich falsch

Kurzform

:cloud ≠ automatisch Cloud-only
Bei dir war es sehr wahrscheinlich hybrid über den lokalen Ollama-Container.

Ich würde jetzt 1 von 2 Wegen nehmen

A. Sauber auf Cloud only umstellen
Wenn du den Container gar nicht brauchst:

openclaw onboard

#

Ollama
Cloud only
echter OLLAMA_API_KEY

Danach sollte openclaw models status bei Ollama auf https://ollama.com zeigen.

B. Hybrid behalten
Dann musst du sicherstellen:

Ollama-Container läuft
Ollama ist im Container sauber signed in
baseUrl zeigt auf den richtigen Host
kein /v1, wenn api: "ollama" genutzt wird

Die Doku dazu:

#

Und bitte noch wichtig:
Falls der gepostete Key echt war, rotieren und die Nachricht am besten editieren/löschen.

smoky arch Apr 24, 2026, 10:42 AM

#

Der Key war nicht echt. Habe einige zahlen geändert.

Muss ich jetzt noch Openclaw Container restarten?

stone questBOT Apr 24, 2026, 10:43 AM

#

Ja, nach einer echten Config-Änderung würde ich den OpenClaw-Container einmal neu starten.

Wichtig ist aber der Haken:

Nur Neustarten reicht nicht, wenn in der Config weiter
http://172.17.0.1:11434 steht.
Erst Config auf Cloud only korrigieren, dann OpenClaw neu starten.

Praktische Reihenfolge

OpenClaw auf Ollama Cloud only umstellen
- baseUrl: https://ollama.com
- echter OLLAMA_API_KEY
- nicht ollama-local
Danach OpenClaw/Gateway/Container neu starten
Dann prüfen:

#

openclaw models status

Wenn da noch irgendwo 172.17.0.1 auftaucht, ist das alte lokale Setup noch aktiv.

Kurz gesagt

Config nicht geändert? Dann bringt Restart allein fast nichts.
Config geändert? Dann ja, OpenClaw-Container restarten.

Und weil bei dir models.json mitmischt, würde ich es am ehesten über openclaw onboard → Ollama → Cloud only sauber neu setzen und danach neu starten.

Docs:

Wenn du nach dem Restart nochmal openclaw models status postest, sag ich dir direkt, ob es jetzt sauber ist.

smoky arch Apr 24, 2026, 10:46 AM

#

Neustart des Dockers gemacht. Nicht echter Key. Das ist jetzt der status:

🦞 OpenClaw 2026.4.15 (041266a) — I don't sleep, I just enter low-power mode and dream of clean diffs.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : ollama/kimi-k2.5:cloud
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (7) : kimi-k2.5 -> ollama/kimi-k2.5:cloud, minimax-m2.5 -> ollama/minimax-m2.5:cloud, minimax-m2.7 -> ollama/minimax-m2.7:cloud, qwen3.5 -> ollama/qwen3.5:cloud, gemma4 -> ollama/gemma4:cloud, glm-5.1 -> ollama/glm-5.1:cloud, kimi-k2.6 -> ollama/kimi-k2.6:cloud
Configured models (7): ollama/kimi-k2.5:cloud, ollama/minimax-m2.5:cloud, ollama/minimax-m2.7:cloud, ollama/qwen3.5:cloud, ollama/gemma4:cloud, ollama/glm-5.1:cloud, ollama/kimi-k2.6:cloud

Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (0): -

nexos effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | nexos:default=missing
ollama effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | ollama:default=999be123...KzP7CBNy | models.json=999be954...KzP5ZBNy | source=models.json: ~/.openclaw/agents/main/agent/models.json

OAuth/token status

none

stone questBOT Apr 24, 2026, 10:48 AM

#

Der Restart war nicht verkehrt, aber die Ausgabe zeigt auch, warum sich nichts geändert hat:

OpenClaw lädt weiter aus der persistenten models.json

source=models.json: ~/.openclaw/agents/main/agent/models.json

Bei Docker heißt das leider:
Container neu gestartet, aber derselbe alte Provider-State aus /data/.openclaw bleibt aktiv.

Darum ist der nächste Schritt nicht noch ein Restart, sondern die Ollama-Config wirklich auf Cloud only umstellen.

Was ich jetzt machen würde

openclaw config get models.mode
openclaw onboard

Dann in onboard:

#

Ollama
Cloud only
echter OLLAMA_API_KEY

Danach:

openclaw gateway restart

Danach prüfen

grep -nE '"baseUrl"|"apiKey"|"api"' \
  /data/.openclaw/openclaw.json \
  /data/.openclaw/agents/main/agent/models.json

Zielbild:

#

baseUrl: "https://ollama.com"
kein 172.17.0.1
kein /v1
kein ollama-local

Falls es danach immer noch lokal bleibt

Dann gewinnt die alte agent-lokale models.json weiter. Laut Docs ist dafür oft models.mode relevant, weil merge alte baseUrl-Werte behalten kann. Dann wäre der nächste Fix:

models.mode: "replace"

Docs:

Wenn du magst, poste noch openclaw config get models.mode, dann sag ich dir direkt, ob genau das gerade dein blocker ist.

smoky arch Apr 24, 2026, 10:54 AM

#

🦞 OpenClaw 2026.4.15 (041266a) — Runs on a Raspberry Pi. Dreams of a rack in Iceland.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : ollama/kimi-k2.5:cloud
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (7) : kimi-k2.5 -> ollama/kimi-k2.5:cloud, minimax-m2.5 -> ollama/minimax-m2.5:cloud, minimax-m2.7 -> ollama/minimax-m2.7:cloud, qwen3.5 -> ollama/qwen3.5:cloud, gemma4 -> ollama/gemma4:cloud, glm-5.1 -> ollama/glm-5.1:cloud, kimi-k2.6 -> ollama/kimi-k2.6:cloud
Configured models (7): ollama/kimi-k2.5:cloud, ollama/minimax-m2.5:cloud, ollama/minimax-m2.7:cloud, ollama/qwen3.5:cloud, ollama/gemma4:cloud, ollama/glm-5.1:cloud, ollama/kimi-k2.6:cloud

Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (0): -

nexos effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | nexos:default=missing
ollama effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | ollama:default=99.....Ny | models.json=999be954...KzP5ZBNy | source=models.json: ~/.openclaw/agents/main/agent/models.json

#

grep -nE '"baseUrl"|"apiKey"|"api"'
/data/.openclaw/openclaw.json
/data/.openclaw/agents/main/agent/models.json
/data/.openclaw/openclaw.json:43: "apiKey": "B........sRY5"
/data/.openclaw/openclaw.json:95: "baseUrl": "https://ollama.com/",
/data/.openclaw/openclaw.json:96: "apiKey": "99.....BNy",
/data/.openclaw/openclaw.json:98: "api": "ollama",
/data/.openclaw/agents/main/agent/models.json:4: "baseUrl": "https://chatgpt.com/backend-api/v1",
/data/.openclaw/agents/main/agent/models.json:5: "apiKey": "codex-app-server",
/data/.openclaw/agents/main/agent/models.json:7: "api": "openai-codex-responses",
/data/.openclaw/agents/main/agent/models.json:12: "api": "openai-codex-responses",
/data/.openclaw/agents/main/agent/models.json:34: "api": "openai-codex-responses",
/data/.openclaw/agents/main/agent/models.json:56: "api": "openai-codex-responses",
/data/.openclaw/agents/main/agent/models.json:78: "baseUrl": "https://ollama.com/v1",
/data/.openclaw/agents/main/agent/models.json:79: "apiKey": "99.....Ny",
/data/.openclaw/agents/main/agent/models.json:81: "api": "ollama",
root@d11616339a52:~#

stone questBOT Apr 24, 2026, 10:55 AM

#

Das sieht leider noch unverändert aus.
Der Restart allein hat also nicht auf Cloud only umgestellt.

Der wichtige Teil ist immer noch:

source=models.json: ~/.openclaw/agents/main/agent/models.json

Heißt: OpenClaw zieht weiter den persistierten Ollama-Provider aus der alten Agent-Config.

Nächster sinnvoller Schritt

Nicht nochmal blind restarten, sondern die Config hart auf replace + Cloud only setzen:

openclaw config get models.mode
openclaw config set models.mode '"replace"' --strict-json
openclaw onboard

#

Dann in onboard:

Ollama
Cloud only
echten OLLAMA_API_KEY

Danach:

openclaw gateway restart
openclaw config get models.providers.ollama --json

Das willst du danach sehen

baseUrl: "https://ollama.com"
kein 172.17.0.1
kein /v1
kein ollama-local

#

Gute Gegenprobe

Wenn Cloud only wirklich sauber aktiv ist, sollte OpenClaw auch ohne laufenden Ollama-Container funktionieren.
Wenn der Container weiter “nötig” ist, hängst du immer noch am alten Hybrid-Setup.

Docs:

Wenn du magst, poste als Nächstes einfach nur den Output von:

openclaw config get models.providers.ollama --json

Das ist jetzt die kürzeste Wahrheit.

#

Aha, jetzt ist es ziemlich klar.

openclaw.json ist jetzt korrekt, aber models.json ist noch falsch:

gut: https://ollama.com/
schlecht: https://ollama.com/v1

Und laut Doku gilt beides:

Bei gleichem Provider gewinnt die agent-lokale models.json mit ihrem baseUrl
Für api: "ollama" sollst du kein /v1 verwenden

Heißt: OpenClaw hängt gerade noch an einem stale falschen Endpoint in models.json.

Nächster Fix

openclaw config set models.mode '"replace"' --strict-json

#

openclaw gateway restart

Danach direkt prüfen:

grep -nE '"baseUrl"|"apiKey"|"api"' /data/.openclaw/agents/main/agent/models.json
openclaw models status

Ziel

In models.json sollte dann bei Ollama nur noch sowas stehen:

"baseUrl": "https://ollama.com"

oder mit trailing slash, aber nicht https://ollama.com/v1.

#

Wenn danach immer noch `/v1` drinsteht

Dann einmal zusätzlich:

openclaw onboard

Dann:

Ollama
Cloud only

und danach nochmal:

openclaw gateway restart

Wichtig: Wenn das sauber gefixt ist, brauchst du für Cloud only den lokalen Ollama-Container nicht mehr.

Docs:

#

Wenn du den nächsten grep-Output postest, können wir es in einem Schritt verifizieren.

smoky arch Apr 24, 2026, 11:00 AM

#

Jetzt hat ein Gateway Restart was gebracht, Mein Bot antwortet.

Ich weiss, du bist ein OpenClaw Help Bot. Aber wie kann ich mein Hermes Agent Bot reparieren? Da müsste das Problem ja das gleiche sein. Oder hast du für meinen OpenClaw Bot eine Anleitung wie ich meinen Hermes Agent repariere?

stone questBOT Apr 24, 2026, 11:00 AM

#

Nice, glad we caught it 🎉

For Hermes, my guess is yes, same class of problem: stale/wrong Ollama endpoint, or it was still pointed at the local/container host.

The important difference is:

OpenClaw wants native Ollama, so no /v1
Hermes might be different. Some apps use native Ollama, others use OpenAI-compatible mode, so I would not blindly copy the OpenClaw fix 1:1

What I’d check in Hermes

Find its Ollama config/env
- OLLAMA_BASE_URL
- OLLAMA_HOST
- OPENAI_BASE_URL
- provider/model settings in its config UI or .env
Check whether Hermes is pointing to:

#

old local Docker address like 172.17.0.1:11434
- 127.0.0.1:11434 inside a container
- or the intended cloud endpoint

After changing that config, restart Hermes

Rule of thumb

If Hermes says it supports native Ollama → use the Ollama base URL it expects
If Hermes says it supports OpenAI-compatible Ollama → it may intentionally want a /v1 style endpoint

So the safest Hermes fix is:

verify which API mode Hermes expects
then point it either to the correct cloud endpoint or the correct reachable local container
restart Hermes after the change

If you paste:

the Hermes Ollama config section, or

#Probleme mit Ollama Pro Abo

Wahrscheinlichster Fall

Nächste Checks

Wenn OpenClaw im Container läuft

Falls du eigentlich Ollama Cloud nutzen willst

Wahrscheinlichster Befund

Für deinen Fall würde ich klar empfehlen: Cloud only

Nächster Check für OpenClaw

So sollte Cloud only aussehen

Falls du doch bei Cloud + Local bleiben willst

Bitte poste noch diesen read-only Check

Was ich gerade vermute

Für deinen Use Case würde ich klar empfehlen

Empfehlung, sauberer Fix

Falls du es manuell machen willst

Noch wichtig

Kurzform

Ich würde jetzt 1 von 2 Wegen nehmen

Praktische Reihenfolge

Kurz gesagt

Was ich jetzt machen würde

Danach prüfen

Falls es danach immer noch lokal bleibt

Nächster sinnvoller Schritt

Das willst du danach sehen

Gute Gegenprobe

Nächster Fix

Ziel

Wenn danach immer noch /v1 drinsteht

What I’d check in Hermes

Rule of thumb

Wenn danach immer noch `/v1` drinsteht