Chat wont work, running local ollama qwen-2.5:0.5b on raspberry pi debian | Friends of the Crustacean 🦞🤝 | Page 1

willow patrol May 14, 2026, 1:26 AM

#

Im running a raspberry pi debian installation with node 24 installed systemwide and on user. I installed ollama, pulled the qwen-2.5 model, and am serving it locally. If i access it thru the ollama local api, i get a response within 5-10 seconds.
Ive installed openclaw, done the onboarding, made sure gateway is up and running, ran openclaw doctor. Nevertheless, no matter what i do, i keep getting "This response is taking longer than expected. Send another message to continue." for all responses. I wont get a response at hatch during onboarding, i wont get a response when invoking openclaw chat, i wont get a response even after resetting sessions in the cli chat. What else can i do?

pallid vectorBOT May 14, 2026, 1:26 AM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

rotund helmBOT May 14, 2026, 1:27 AM

#

A couple things jump out here.

First: please post openclaw --version — version mismatch is a super common cause of weird hangs.

Second: qwen2.5:0.5b on a Pi is very likely below the practical floor for OpenClaw agent turns. A direct Ollama /api/chat “say hi” test is much smaller than an OpenClaw run, which includes system context and tool schemas. The TUI watchdog message usually means the run didn’t produce a usable assistant turn before the watchdog fired, not necessarily that Ollama is totally unreachable.

I’d check these in order:

openclaw --version
openclaw status
openclaw models status
openclaw models list --provider ollama
openclaw infer model run --model ollama/qwen2.5:0.5b --prompt "Reply with exactly: smoke-ok" --json
openclaw logs --follow

#

Also verify the Ollama config is using the native Ollama endpoint, not /v1:

http://127.0.0.1:11434

not:

http://127.0.0.1:11434/v1

For local Ollama, OpenClaw expects OLLAMA_API_KEY to be set to any placeholder value, e.g. ollama-local, so the provider is enabled/discoverable.

If the infer model run command hangs/fails but direct Ollama works, try the experimental lean mode to reduce the tool prompt load:

#

openclaw config set agents.defaults.experimental.localModelLean true --strict-json
openclaw gateway restart

But honestly, if this is really the 0.5b Qwen model, I’d use it only for testing transport. For actual OpenClaw chat, try a much larger Ollama model or use a hosted/cloud model as primary/fallback.

Docs: https://docs.openclaw.ai/providers/ollama and https://docs.openclaw.ai/gateway/local-models

willow patrol May 14, 2026, 1:50 AM

#

i am going to use an anthropic opus 4.5 model as soon as i can make openclaw work with atleast the qwen 0.5b, cuz i cant even get a response for hello. ive been stuck with trying to bootstrap openclaw and make it work for the past 8 hours. even switched to debian from windows cuz i thought that wsl is the bottleneck.
openclaw version: OpenClaw 2026.5.7 (eeef486)
openclaw status gives no errors
openclaw infer worked, but hanged for about 2 minutes. i did set local mode lean to true.

rotund helmBOT May 14, 2026, 1:50 AM

#

Oof, yeah — 8 hours is brutal. The useful signal is: openclaw infer did work, but took ~2 minutes. That means OpenClaw can reach Ollama, but the Pi + qwen2.5:0.5b path is far too slow/weak for the full chat/bootstrap runtime.

A few concrete next steps:

Update first. 2026.5.7 is not where I’d debug this for hours.

openclaw update
openclaw gateway restart
openclaw --version

Don’t use Hatch/onboarding as the smoke test for this model. Use the smallest direct OpenClaw test:

openclaw infer model run --model ollama/qwen2.5:0.5b --prompt "Reply with exactly: smoke-ok" --json

#

If that takes 2 minutes, chat is expected to hit the “taking longer than expected” watchdog.

If you still want to force chat to try the tiny model, mark it as non-tool-capable so OpenClaw doesn’t send tool schemas to it:

openclaw config set models.providers.ollama.models '[{"id":"qwen2.5:0.5b","name":"qwen2.5:0.5b","input":["text"],"contextWindow":32768,"maxTokens":512,"compat":{"supportsTools":false}}]' --strict-json --merge
openclaw config set agents.defaults.model.primary '"ollama/qwen2.5:0.5b"' --strict-json
openclaw gateway restart

Keep agents.defaults.experimental.localModelLean=true too.

But: I wouldn’t block your Anthropic setup on making qwen2.5:0.5b behave like a real OpenClaw chat model. Passing infer already proves the provider path works. The 0.5b model is just not a good bootstrap/chat target on Pi hardware.

For getting unstuck tonight, I’d switch primary to Anthropic/Opus once you have the key, then keep Ollama as an experiment/fallback later. Docs: https://docs.openclaw.ai/providers/ollama https://docs.openclaw.ai/gateway/local-models

willow patrol May 14, 2026, 11:21 AM

#

i switched to chatgpt 5 4 mini thru a custom provider. so, it either works either doesnt - too unstable. i get 2 responses, then i get a loop of run error: LLM request timed out. then i create a new chat, get same error, create a new one, get 3 responses, and then get back in that loop. so, how do i troubleshoot whats happening and how do i find out if the fault is on my raspberry or the custom provider?

rotund helmBOT May 14, 2026, 11:22 AM

#

First thing: please paste openclaw --version. Version mismatches cause a surprising amount of weirdness.

For this specific pattern — “2–3 replies, then LLM request timed out, then new sessions sometimes work briefly” — I’d split the test into OpenClaw vs Raspberry/network vs provider:

Get the safe baseline report:

openclaw status --all
openclaw gateway status

Docs: https://docs.openclaw.ai/help/faq

Tail logs while reproducing once:

openclaw logs --follow

Look for the exact provider/model, HTTP status, retries, timeout duration, and whether it dies while streaming or before first byte.

#

From the Raspberry Pi, test the custom provider directly, outside OpenClaw:

time curl -sS "$BASE_URL/v1/models" \
  -H "Authorization: Bearer $API_KEY" | head

Then do a tiny chat-completions request to the same baseUrl + model OpenClaw uses. If direct curl also hangs/slows/fails, it’s not OpenClaw — it’s provider, network, DNS, rate limit, or Pi connectivity.

Watch the Pi while reproducing:

htop
free -h
df -h
ping -c 20 your-provider-hostname

If CPU/RAM is pinned, swap is active, disk is full, or ping has packet loss/spikes, the Pi is suspect. If the Pi is calm but requests stall, provider/proxy is more likely.

Check your custom provider config. For OpenAI-compatible proxies, it should usually be api: "openai-completions", and for slow providers/LAN proxies you can set:

#

models: {
  providers: {
    yourProviderId: {
      baseUrl: "https://.../v1",
      apiKey: "${YOUR_API_KEY}",
      api: "openai-completions",
      timeoutSeconds: 300,
      models: [{ id: "your-model-id", name: "Your Model" }]
    }
  }
}

Docs: https://docs.openclaw.ai/concepts/model-providers#providers-via-modelsproviders-custombase-url

Important: raising timeoutSeconds is a diagnostic, not a real fix. If it only works with huge timeouts, the provider is too slow/queued/unstable for interactive chat.

#

The cleanest “fault isolation” result is:

Direct curl from Pi times out too → provider/network/Pi path.
Direct curl is fast, OpenClaw times out → OpenClaw config/request-shaping/session/tool payload issue; paste the log chunk around the timeout.
Only after 2–3 messages → likely provider rate limiting/queueing, context growth, streaming hang, or Pi resource pressure.

Paste openclaw --version, your redacted provider config, and the log lines around one timeout and we can narrow it down without guessing. 🦞

willow patrol May 14, 2026, 12:02 PM

#

ok, can you write me a python script that will help me test if provider is failing somehow? like, a list of 5 prompts, that are sequentially selected and sent to the api with a delay of 5 seconds between each response?

rotund helmBOT May 14, 2026, 12:02 PM

#

Yep — here’s a simple OpenAI-compatible tester. It sends 5 prompts sequentially, waits 5 seconds after each response/error, and logs latency + failures.

Save as provider_probe.py:

#!/usr/bin/env python3
import os
import time
import json
import requests
from datetime import datetime

BASE_URL = os.getenv("BASE_URL", "http://127.0.0.1:11434/v1").rstrip("/")
API_KEY = os.getenv("API_KEY", "ollama")
MODEL = os.getenv("MODEL", "qwen2.5:0.5b")
TIMEOUT = int(os.getenv("TIMEOUT", "120"))

#

DELAY_SECONDS = int(os.getenv("DELAY_SECONDS", "5"))

PROMPTS = [
    "Reply with exactly: test one ok",
    "In one sentence, explain what an API timeout means.",
    "Count from 1 to 20, comma separated.",
    "Write a tiny Python function that adds two numbers.",
    "Summarize this in one short sentence: OpenClaw connects chat apps to local or cloud AI models.",
]


def call_model(prompt, index):
    url = f"{BASE_URL}/chat/completions"
    headers = {
        "Authorization": f"Bearer {API_KEY}",

#

        "Content-Type": "application/json",
    }
    payload = {
        "model": MODEL,
        "messages": [
            {"role": "system", "content": "You are a concise test assistant."},
            {"role": "user", "content": prompt},
        ],
        "temperature": 0,
        "stream": False,
    }

    started = time.time()
    print(f"
[{index}/5] {datetime.now().isoformat(timespec='seconds')}")

#

    print(f"Prompt: {prompt}")

    try:
        r = requests.post(url, headers=headers, json=payload, timeout=TIMEOUT)
        elapsed = time.time() - started
        print(f"HTTP: {r.status_code} | elapsed: {elapsed:.2f}s")

        if not r.ok:
            print("ERROR BODY:")
            print(r.text[:2000])
            return False

        data = r.json()
        content = data["choices"][0]["message"].get("content", "")
        print("Response:")

#

        print(content[:2000])
        return True

    except requests.exceptions.Timeout:
        elapsed = time.time() - started
        print(f"TIMEOUT after {elapsed:.2f}s")
        return False
    except Exception as e:
        elapsed = time.time() - started
        print(f"EXCEPTION after {elapsed:.2f}s: {type(e).__name__}: {e}")
        return False


def main():
    print("Provider probe")

#

    print(f"BASE_URL={BASE_URL}")
    print(f"MODEL={MODEL}")
    print(f"TIMEOUT={TIMEOUT}s")
    print(f"DELAY_SECONDS={DELAY_SECONDS}s")

    results = []
    for i, prompt in enumerate(PROMPTS, start=1):
        ok = call_model(prompt, i)
        results.append(ok)
        if i < len(PROMPTS):
            print(f"Waiting {DELAY_SECONDS}s...")
            time.sleep(DELAY_SECONDS)

    passed = sum(results)
    failed = len(results) - passed

#

    print("
Summary")
    print(f"Passed: {passed}")
    print(f"Failed: {failed}")

    if failed:
        raise SystemExit(1)


if __name__ == "__main__":
    main()

Run it like this for local Ollama’s OpenAI-compatible endpoint:

#

python3 -m pip install requests
BASE_URL="http://127.0.0.1:11434/v1" \
MODEL="qwen2.5:0.5b" \
API_KEY="ollama" \
TIMEOUT=120 \
DELAY_SECONDS=5 \
python3 provider_probe.py

If this times out too, OpenClaw is probably not the cause — it’s Ollama/model/Raspberry Pi resource pressure/network. If this is consistently fast but OpenClaw times out, then we look at OpenClaw logs/config/request shape next.

willow patrol May 14, 2026, 12:03 PM

#

you know what? lets try something else first. lets try using a proxy. how can i use a socks5 or https proxy for openclaw to use?

rotund helmBOT May 14, 2026, 12:04 PM

#

OpenClaw’s built-in proxy setting expects an HTTP forward proxy URL — not socks5://, and not an https:// proxy listener.

Important nuance: the proxy URL is http://..., but HTTPS API calls still go through it using CONNECT, so this is normal:

openclaw config set proxy.enabled true
openclaw config set proxy.proxyUrl http://127.0.0.1:3128
openclaw gateway restart

Docs: https://docs.openclaw.ai/security/network-proxy

Before enabling it, validate the proxy from the same machine running OpenClaw:

openclaw proxy validate --proxy-url http://127.0.0.1:3128

#

You can also test your provider manually:

curl -x http://127.0.0.1:3128 https://your-provider-host/v1/models \
  -H "Authorization: Bearer $API_KEY"

If you only have a SOCKS5 proxy, put a tiny HTTP-to-SOCKS bridge in front of it. On Debian/Raspberry Pi, privoxy is common:

sudo apt install privoxy
sudo nano /etc/privoxy/config

Add this line, replacing the SOCKS host/port:

#

forward-socks5t / 127.0.0.1:1080 .

Privoxy usually listens on 127.0.0.1:8118, so then configure OpenClaw with:

openclaw config set proxy.enabled true
openclaw config set proxy.proxyUrl http://127.0.0.1:8118
openclaw gateway restart

Then validate:

openclaw proxy validate --proxy-url http://127.0.0.1:8118

#

One catch: if your model/provider endpoint is actually local/LAN, your proxy may block private IPs by design. For a remote custom provider this is useful; for local Ollama/LAN routing it can make things worse unless the proxy policy allows that destination.

willow patrol May 14, 2026, 12:06 PM

#

no, i have an auth-proxy, http, https and socks5. so, ocne again, how do i use it? with auth. easiest way, would be better if it was non-global, only for openclaw gateway or whatever uses it at openclaw

rotund helmBOT May 14, 2026, 12:06 PM

#

Yep — use OpenClaw’s own proxy.* config. That is not global system proxy; it only affects OpenClaw runtime processes like the gateway/node/agent.

Use your proxy’s HTTP proxy endpoint, with auth in the URL:

openclaw config set proxy.enabled true
openclaw config set proxy.proxyUrl 'http://USERNAME:PASSWORD@PROXY_HOST:PROXY_PORT'
openclaw gateway restart

Example:

openclaw config set proxy.enabled true
openclaw config set proxy.proxyUrl 'http://myuser:mypass@proxy.example.com:8080'
openclaw gateway restart

#

If your username/password has special chars like @, :, /, #, ?, encode them first. Example: p@ss:word becomes p%40ss%3Aword.

Then test it:

openclaw proxy validate --proxy-url 'http://USERNAME:PASSWORD@PROXY_HOST:PROXY_PORT'

And test the provider specifically:

curl -x 'http://USERNAME:PASSWORD@PROXY_HOST:PROXY_PORT' \
  'https://YOUR_PROVIDER_HOST/v1/models' \
  -H "Authorization: Bearer $API_KEY"

For OpenClaw specifically: even if the upstream site is HTTPS, the proxy URL should still usually be http://... because HTTPS destinations go through HTTP CONNECT. So prefer your proxy’s HTTP endpoint.

#

If you only want to test temporarily without saving config, run the gateway in foreground like this:

OPENCLAW_PROXY_URL='http://USERNAME:PASSWORD@PROXY_HOST:PROXY_PORT' \
openclaw gateway run

But for an installed gateway service, config is easiest/most durable:

openclaw config set proxy.enabled true
openclaw config set proxy.proxyUrl 'http://USERNAME:PASSWORD@PROXY_HOST:PROXY_PORT'
openclaw gateway restart

Docs: https://docs.openclaw.ai/security/network-proxy

willow patrol May 14, 2026, 12:11 PM

#

yeah still doesnt work. i dont know where to dig. why does everyoens work and my doesnt. im pretty sure my provider is fine, i even tried a proxy, but it still wont work properly. how come??? what can i even do right now. do i just give up after 20 hours

rotund helmBOT May 14, 2026, 12:12 PM

#

No, don’t give up — but I would stop changing random variables now. After 20 hours your brain is fried and proxy/testing/provider changes start making the picture noisier, not clearer.

Given the thread title says local Ollama qwen-2.5:0.5b on Raspberry Pi, the proxy probably won’t help at all. If the model is local, the problem is much more likely one of these:

OpenClaw is pointed at Ollama’s OpenAI-compatible /v1 endpoint instead of native Ollama
the Pi/model is too slow and hits timeouts once context grows
qwen 0.5b can answer tiny prompts but is not reliable enough for full agent chat/tool prompts
Ollama is unloading/reloading or memory pressure is causing stalls

First: please paste this:

openclaw --version

Then do this reset/isolation path:

#

openclaw config set proxy.enabled false
openclaw gateway restart

Now verify Ollama directly:

curl http://127.0.0.1:11434/api/tags
ollama list

Then run the lean OpenClaw model probe — this avoids full chat-agent/tool context:

OLLAMA_API_KEY=ollama-local \

#

openclaw infer model run \
  --local \
  --model 'ollama/qwen2.5:0.5b' \
  --prompt 'Reply with exactly: pong' \
  --json

If that fails or takes forever: the issue is Ollama/Pi/model path, not Discord/chat/proxy.

If that works but normal chat fails: OpenClaw can reach the model, but the model is probably choking on the full assistant prompt/tool context. A 0.5B local model on a Raspberry Pi is very likely to be unstable for OpenClaw agent chat even if simple one-shot prompts work.

Also: if you manually configured Ollama as a custom OpenAI provider like this:

http://...:11434/v1

#

that’s a red flag. OpenClaw’s Ollama docs specifically say not to use /v1 for remote/local Ollama because it can break tool calling. Use native Ollama instead:

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

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

The most useful next thing you can paste is:

#

openclaw --version
openclaw status --all

plus the output of that openclaw infer model run command. That will tell us whether we’re debugging OpenClaw chat, Ollama, or the Pi. You’re not crazy — this exact class of issue is brutal because tiny local models can look “fine” for 2 messages and then collapse once the real agent context shows up. 🦞

willow patrol May 14, 2026, 12:12 PM

#

i just told you im using a custom provider with gpt 5 4 mini, not ollama

rotund helmBOT May 14, 2026, 12:13 PM

#

You’re right — I messed that up. I anchored on the thread title instead of what you just told me. Sorry. Let’s ignore Ollama completely.

For a custom OpenAI-compatible provider using GPT-5.4 mini, here’s the clean next step:

Confirm OpenClaw can hit the provider through its own model layer:

openclaw infer model run \
  --gateway \
  --model 'YOUR_PROVIDER_ID/YOUR_MODEL_ID' \
  --prompt 'Reply with exactly: pong' \
  --json

Use the exact model ref you selected in OpenClaw, like myproxy/gpt-5.4-mini.

If that fails, run the same prompt directly against the provider:

#

curl -sS 'https://YOUR_BASE_URL/v1/chat/completions' \
  -H 'content-type: application/json' \
  -H "Authorization: Bearer $API_KEY" \
  -d '{
    "model": "YOUR_MODEL_ID",
    "messages": [{"role":"user","content":"Reply with exactly: pong"}],
    "stream": false
  }'

If direct curl works but openclaw infer model run fails, then we inspect the custom provider config. The common gotchas are:

models: {
  providers: {

#

    yourProviderId: {
      baseUrl: "https://YOUR_BASE_URL/v1",
      apiKey: "${YOUR_API_KEY}",
      api: "openai-completions",
      timeoutSeconds: 300,
      models: [
        {
          id: "YOUR_MODEL_ID",
          name: "GPT 5.4 mini",
          input: ["text"],
          maxTokens: 8192,
          contextWindow: 128000,
          compat: {
            supportsTools: false,
            requiresStringContent: true

#

The two diagnostic flags I’d try are:

compat.supportsTools: false — if the custom provider/model chokes on OpenClaw’s tool schemas
compat.requiresStringContent: true — if the provider only accepts plain string message content

That can turn “works for 2 messages then melts” into a stable text-only baseline. Once baseline works, we can re-enable tools if the provider supports them properly.

Please paste these three things, redacting secrets:

#Chat wont work, running local ollama qwen-2.5:0.5b on raspberry pi debian