how to use Ipex-llm ollama qwen2.5-coder:7b locally in openclaw | Friends of the Crustacean 🦞🤝 | Page 1

wanton stirrup Feb 15, 2026, 1:09 PM

#

Hello, my name is Aman.
Just as the title says, i want to use the ollama model locally on openclaw, I am a window user so i am using WSL and install the openclaw in it, and as for Ollama, since i am using the integrated intel iris Xe graphic, i am using Ipex llm Ollama to use 100% of GPU for ollama model. I am facing dificulty to connect the model to openclaw. I am not a tech guy so can anyone please help me.

Thankyou

shrewd otterBOT Feb 15, 2026, 1:09 PM

#

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

wanton stirrup Feb 15, 2026, 1:10 PM

#

how to use Ipex-llm ollama qwen2.5-coder:7b locally in openclaw

prisma otterBOT Feb 15, 2026, 1:13 PM

#

Aman — OpenClaw can talk to Ollama just fine, but the main gotcha in your setup is usually networking: OpenClaw is in WSL, and Ollama/ipex-llm might be running on Windows (or a different host), so 127.0.0.1 might not point to the same place.

1) First, verify WSL can “see” Ollama

In your WSL terminal, run:

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

If you get JSON back (a list of models), great → go to step 2.
If it fails, tell me: is Ollama (ipex-llm) running in Windows or inside WSL?
- If it’s on Windows, try:
```
curl http://localhost:11434/api/tags
```
- If that still fails, we’ll point OpenClaw at the Windows host IP.

#

2) Enable Ollama in OpenClaw (works even though Ollama doesn’t need a real key)

If you run the Gateway as a service/daemon, the easiest is to put the env var in OpenClaw’s global env file:

In WSL:

nano ~/.openclaw/.env

Add this line:

OLLAMA_API_KEY=ollama-local

Restart the gateway:

openclaw gateway restart

#

3) Select your model

Set OpenClaw’s default model to your Ollama model:

openclaw config set agents.defaults.model.primary "ollama/qwen2.5-coder:7b"
openclaw gateway restart

Then in chat you can also run:

/model list (should show Ollama models)
or from terminal: openclaw models list

If you’re stuck, paste these 3 outputs here

From WSL terminal:

#

openclaw --version
curl -sS http://127.0.0.1:11434/api/tags | head
openclaw models list | head -50

…and tell me whether Ollama/ipex-llm is running on Windows or WSL. That will determine if we need to set a custom baseUrl.

#

Ipex-llm “Ollama” still exposes the normal Ollama HTTP API, so OpenClaw connects to it the same way as regular Ollama: http://<host>:11434.

Step 1 — make sure WSL can reach Ollama

In WSL, run:

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

If you get JSON back → good, go to step 2.
If you get “connection refused / timeout” and Ollama is running on Windows, use the Windows host IP from WSL:

WIN_IP=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2}')
curl "http://$WIN_IP:11434/api/tags"

#

If that works, you’ll use http://$WIN_IP:11434 as the Ollama host (and you may need to allow port 11434 in Windows Firewall / make ipex-llm listen on the network, not just localhost).

Step 2 — enable Ollama provider in OpenClaw

Easiest (works even though Ollama doesn’t need a real key): put this in OpenClaw’s global env file (so the gateway service can see it):

nano ~/.openclaw/.env
# add:
# OLLAMA_API_KEY=ollama-local

Then restart the gateway:

openclaw gateway restart

#

Now check models:

openclaw models list

Step 3 — select the model

If it shows up, set it:

openclaw config set agents.defaults.model.primary "ollama/qwen2.5-coder:7b"
openclaw gateway restart

If qwen2.5-coder:7b doesn’t appear in `openclaw models list`

OpenClaw only auto-discovers Ollama models that report tool support. If your model isn’t listed, you’ll need to define it manually in config (docs explain this): https://docs.openclaw.ai/providers/ollama

#

If you paste these outputs, I can tell you exactly what to set for your case:

openclaw --version
curl -sS http://127.0.0.1:11434/api/tags | head
openclaw models list | head -50

Also: is ipex-llm Ollama running on Windows or inside WSL?

wanton stirrup Feb 15, 2026, 1:17 PM

#

here: aman@LAPTOP-TDGHKO2M:~$ openclaw --version
curl -sS http://127.0.0.1:11434/api/tags | head
openclaw models list | head -50
Invalid config at /home/aman/.openclaw/openclaw.json:\n- agents.defaults.models.providers: Unrecognized key: "ollama"
2026.2.14
curl: (7) Failed to connect to 127.0.0.1 port 11434 after 0 ms: Couldn't connect to server
Invalid config at /home/aman/.openclaw/openclaw.json:\n- agents.defaults.models.providers: Unrecognized key: "ollama"
Config invalid
File: ~/.openclaw/openclaw.json
Problem:

agents.defaults.models.providers: Unrecognized key: "ollama"

Run: openclaw doctor --fix

and ipex-llm Ollama is running on window cmd

prisma otterBOT Feb 15, 2026, 1:19 PM

#

You’ve got two separate issues:

Your OpenClaw config is invalid (wrong config path)
WSL can’t reach Ollama because Ollama is running on Windows, not inside WSL

1) Fix the config error first

This line tells you what’s wrong:

agents.defaults.models.providers: Unrecognized key: "ollama"

providers must NOT be under agents.defaults.models.
Providers live at the top level: models.providers.

Do this in WSL:

#

cp ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.bak
openclaw doctor --fix

If it still complains after doctor, open the file and delete the bad block that starts with something like:
agents: { defaults: { models: { providers: { ollama: ... }}}}

Edit:

nano ~/.openclaw/openclaw.json

2) Make sure WSL can reach Ollama on Windows

In WSL, your curl http://127.0.0.1:11434/... failed, so WSL can’t see it.

#

2a) Get the Windows host IP (from inside WSL)

Run:

WIN_IP=$(awk '/nameserver/ {print $2; exit}' /etc/resolv.conf)
echo $WIN_IP
curl "http://$WIN_IP:11434/api/tags"

If that still fails: on Windows, ipex-llm Ollama is probably listening only on 127.0.0.1. You need it to listen on the network (often 0.0.0.0:11434) and allow port 11434 through Windows Firewall.

On Windows, check what address it’s listening on:

netstat -ano | findstr :11434

If you only see 127.0.0.1:11434, WSL won’t be able to reach it via $WIN_IP.

#

3) Correct OpenClaw config for Ollama-on-Windows (minimal example)

Once WSL can curl http://$WIN_IP:11434/api/tags, put this in ~/.openclaw/openclaw.json (after removing the wrong agents.defaults.models.providers thing):

{
  models: {
    mode: "merge",
    providers: {
      ollama: {
        baseUrl: "http://WIN_IP_HERE:11434/v1",
        apiKey: "ollama-local",
        api: "openai-completions",
        models: [
          {
            id: "qwen2.5-coder:7b",
            name: "qwen2.5-coder:7b (local)",

#

            reasoning: false,
            input: ["text"],
            cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
            contextWindow: 8192,
            maxTokens: 8192
          }
        ]
      }
    }
  },

  agents: {
    defaults: {
      model: { primary: "ollama/qwen2.5-coder:7b" }
    }

#

}
}

(Replace WIN_IP_HERE with the value you printed from WSL.)

Then restart:

openclaw gateway restart
openclaw models list

Docs (matches what we’re doing): https://docs.openclaw.ai/providers/ollama

#

If you paste the output of these, I can tell you exactly what to change next:

WIN_IP=$(awk '/nameserver/ {print $2; exit}' /etc/resolv.conf); echo $WIN_IP
curl -v "http://$WIN_IP:11434/api/tags"
cat ~/.openclaw/openclaw.json

wanton stirrup Feb 15, 2026, 1:23 PM

#

WSL:
aman@LAPTOP-TDGHKO2M:~$ WIN_IP=$(awk '/nameserver/ {print $2; exit}' /etc/resolv.conf)
echo $WIN_IP
curl "http://$WIN_IP:11434/api/tags"
10.255.255.254
curl: (7) Failed to connect to 10.255.255.254 port 11434 after 0 ms: Couldn't connect to server
aman@LAPTOP-TDGHKO2M:~$ curl http://$WIN_IP:11434/api/tags
curl: (7) Failed to connect to 10.255.255.254 port 11434 after 0 ms: Couldn't connect to server
aman@LAPTOP-TDGHKO2M:~$ curl http://$WIN_IP:11434/api/tags

cmd:
PS C:\Users\prade> netstat -ano | findstr :11434
TCP 127.0.0.1:11434 0.0.0.0:0 LISTENING 21384
TCP 127.0.0.1:59724 127.0.0.1:11434 TIME_WAIT 0
PS C:\Users\prade>

prisma otterBOT Feb 15, 2026, 1:24 PM

#

That netstat output is the key:

TCP 127.0.0.1:11434 ... LISTENING

Your ipex-llm Ollama is only listening on Windows localhost, so WSL cannot reach it (that’s why curl from WSL fails).

You need to make Ollama listen on a real interface (0.0.0.0), or add a Windows port-forward.

A) Recommended: make Ollama listen on `0.0.0.0:11434` (Windows)

If ipex-llm Ollama respects the normal Ollama env var, set this in PowerShell and restart Ollama:

setx OLLAMA_HOST "0.0.0.0:11434"

#

Then close/reopen the terminal and restart the ipex-llm Ollama service/app.

Verify on Windows:

netstat -ano | findstr :11434

You want to see 0.0.0.0:11434 (or your LAN IP), not 127.0.0.1:11434.

Security note: listening on 0.0.0.0 exposes the port to your network unless the firewall blocks it. Keep it private unless you know what you’re doing.

B) If you can’t change ipex-llm binding: use Windows `portproxy` (Admin PowerShell)

Run PowerShell as Administrator:

#

netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=11434 connectaddress=127.0.0.1 connectport=11434
New-NetFirewallRule -DisplayName "Ollama 11434" -Direction Inbound -Protocol TCP -LocalPort 11434 -Action Allow

This makes Windows accept connections on 11434 and forward them to the localhost-only Ollama.

After A or B: test from WSL again

In WSL:

WIN_IP=$(awk '/nameserver/ {print $2; exit}' /etc/resolv.conf)
curl "http://$WIN_IP:11434/api/tags"

#

Once that works, OpenClaw can use it.

Fix your OpenClaw config error

Your config currently has ollama under the wrong place:

agents.defaults.models.providers ❌

Providers must be:

models.providers ✅

Fast fix:

#

openclaw doctor --fix

If it still errors, open ~/.openclaw/openclaw.json and remove the whole bad block under agents.defaults.models.providers.

Then configure OpenClaw to use your Windows Ollama

Because your Ollama is not at WSL’s 127.0.0.1, use an explicit provider (example):

{
  models: {
    mode: "merge",
    providers: {

#

      ollama: {
        baseUrl: "http://10.255.255.254:11434/v1",
        apiKey: "ollama-local",
        api: "openai-completions",
        models: [
          {
            id: "qwen2.5-coder:7b",
            name: "qwen2.5-coder:7b",
            reasoning: false,
            input: ["text"],
            cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
            contextWindow: 8192,
            maxTokens: 8192
          }
        ]

#

      }
    }
  },
  agents: { defaults: { model: { primary: "ollama/qwen2.5-coder:7b" } } }
}

(Use your real $WIN_IP instead of 10.255.255.254 if it changes.)

Restart gateway after config changes:

openclaw gateway restart
openclaw models list

#

If you tell me whether option A (OLLAMA_HOST) works or you had to use B (portproxy), I can give you the cleanest final config for your exact setup.

wanton stirrup Feb 15, 2026, 1:37 PM

#

cmd:
PS C:\Users\prade> netstat -ano | findstr :11434
TCP 127.0.0.1:11434 0.0.0.0:0 LISTENING 3792
PS C:\Users\prade>

wsl:

#

aman@LAPTOP-TDGHKO2M:~$ WIN_IP=$(awk '/nameserver/ {print $2; exit}' /etc/resolv.conf)
curl "http://$WIN_IP:11434/api/tags"
curl: (7) Failed to connect to 10.255.255.254 port 11434 after 0 ms: Couldn't connect to server

prisma otterBOT Feb 15, 2026, 1:39 PM

#

That still failing means Windows is still not accepting connections from WSL on port 11434.

Right now your netstat showed Ollama is bound to 127.0.0.1 only, so WSL can’t reach it until you do one of these Windows-side fixes.

Option B (most reliable): Windows portproxy (run as Administrator)

Open PowerShell as Administrator and run:

netsh interface portproxy delete v4tov4 listenaddress=0.0.0.0 listenport=11434
netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=11434 connectaddress=127.0.0.1 connectport=11434

netsh interface portproxy show v4tov4

Allow it through Firewall (Admin PowerShell):

#

New-NetFirewallRule -DisplayName "Ollama 11434" -Direction Inbound -Protocol TCP -LocalPort 11434 -Action Allow

Now test again from WSL:

WIN_IP=$(awk '/nameserver/ {print $2; exit}' /etc/resolv.conf)
curl -v "http://$WIN_IP:11434/api/tags"

If it still fails

Paste these outputs (they’ll tell us exactly what’s wrong):

Windows (Admin PowerShell):

#

netsh interface portproxy show v4tov4
netstat -ano | findstr :11434

WSL:

WIN_IP=$(awk '/nameserver/ {print $2; exit}' /etc/resolv.conf); echo $WIN_IP
curl -v "http://$WIN_IP:11434/api/tags"

Separate issue: your OpenClaw config is invalid

You should also run (in WSL):

wanton stirrup Feb 15, 2026, 1:41 PM

#

PS C:\Users\prade\ollama> netstat -ano | findstr :11434
TCP 0.0.0.0:11434 0.0.0.0:0 LISTENING 27220
TCP [::]:11434 [::]:0 LISTENING 27220
PS C:\Users\prade\ollama>

aman@LAPTOP-TDGHKO2M:~$ WIN_IP=$(awk '/nameserver/ {print $2; exit}' /etc/resolv.conf)
curl "http://$WIN_IP:11434/api/tags"
curl: (7) Failed to connect to 10.255.255.254 port 11434 after 0 ms: Couldn't connect to server

prisma otterBOT Feb 15, 2026, 1:42 PM

#

openclaw doctor --fix

…but let’s get the WSL→Windows Ollama connection working first, otherwise OpenClaw won’t be able to reach it anyway.

#

Yep — this is exactly what we’d expect with your current Windows netstat:

127.0.0.1:11434 LISTENING
Meaning: Ollama is only listening on Windows “localhost”, so WSL cannot connect to it via 10.255.255.254:11434.

You need to expose it to WSL.

Fix (do this on Windows): `portproxy` (Admin PowerShell)

Open PowerShell as Administrator and run:

netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=11434 connectaddress=127.0.0.1 connectport=11434
netsh interface portproxy show v4tov4

Allow the port in Windows Firewall (Admin PowerShell):

#

Nice — Windows side is correct now (0.0.0.0:11434 is listening). The reason WSL still can’t connect is: 10.255.255.254 is not the right Windows-reachable IP in your setup (it’s often just a DNS/NAT address, not where your service is reachable).

Let’s do this in the simplest, most reliable way.

1) Allow Windows Firewall (important)

In PowerShell (Run as Administrator):

New-NetFirewallRule -DisplayName "Ollama 11434" -Direction Inbound -Protocol TCP -LocalPort 11434 -Action Allow

2) Find the correct “Windows ↔ WSL” IP (on Windows)

In normal PowerShell (not necessarily admin), run:

Get-NetIPAddress -AddressFamily IPv4 | Where-Object { $_.InterfaceAlias -like "*WSL*" } | Select-Object InterfaceAlias,IPAddress

#

You should see an IP like 172.xx.xx.1 (often ends with .1). Copy that IP.

3) Test from WSL using that IP

In WSL replace PASTE_IP_HERE with the IP from step 2:

curl "http://PASTE_IP_HERE:11434/api/tags"

If that works, OpenClaw can use it.

After curl works: configure OpenClaw

You still have a config error (agents.defaults.models.providers.ollama is the wrong place). Fix it first:

#

openclaw doctor --fix

Then set Ollama baseUrl correctly (example uses the same PASTE_IP_HERE):

openclaw config set models.providers.ollama.baseUrl "http://PASTE_IP_HERE:11434/v1"
openclaw config set models.providers.ollama.apiKey "ollama-local"
openclaw config set models.providers.ollama.api "openai-completions"
openclaw config set agents.defaults.model.primary "ollama/qwen2.5-coder:7b"
openclaw gateway restart

If you paste the output of step 2 (the Get-NetIPAddress ... command), I’ll tell you exactly which IP to use.

#

New-NetFirewallRule -DisplayName "Ollama 11434" -Direction Inbound -Protocol TCP -LocalPort 11434 -Action Allow

Verify Windows is now listening on all interfaces:

netstat -ano | findstr :11434

You should now see something like 0.0.0.0:11434 listening (in addition to the 127.0.0.1 one).

Test again from WSL

WIN_IP=$(awk '/nameserver/ {print $2; exit}' /etc/resolv.conf)
curl -v "http://$WIN_IP:11434/api/tags"

#

If it still fails, paste these exact outputs

Windows (Admin PowerShell):

netsh interface portproxy show v4tov4
netstat -ano | findstr :11434

WSL:

WIN_IP=$(awk '/nameserver/ {print $2; exit}' /etc/resolv.conf); echo $WIN_IP
curl -v "http://$WIN_IP:11434/api/tags"

#

After networking works: fix OpenClaw config error

You also have an invalid config key (agents.defaults.models.providers.ollama is wrong). Once Ollama is reachable, run:

openclaw doctor --fix

and we’ll set models.providers.ollama.baseUrl to http://<WIN_IP>:11434/v1 and pick ollama/qwen2.5-coder:7b.

wanton stirrup Feb 15, 2026, 1:52 PM

#

aman@LAPTOP-TDGHKO2M:~$ curl "http://172.29.32.1:11434/api/tags"
{"models":[{"name":"qwen2.5-coder:7b","model":"qwen2.5-coder:7b","modified_at":"2026-02-14T13:29:01.7772783+05:30","size":4683087561,"digest":"dae161e27b0e90dd1856c8bb3209201fd6736d8eb66298e75ed87571486f4364","details":{"parent_model":"","format":"gguf","family":"qwen2","families":["qwen2"],"parameter_size":"7.6B","quantization_level":"Q4_K_M"}},{"name":"llama3.2:3b","model":"llama3.2:3b","modified_at":"2026-02-14T09:02:09.8923594+05:30","size":2019393189,"digest":"a80c4f17acd55265feec403c7aef86be0c25983ab279d83f3bcd3abbcb5b8b72","details":{"parent_model":"","format":"gguf","family":"llama","families":["llama"],"parameter_size":"3.2B","quantization_level":"Q4_K_M"}}]}
aman@LAPTOP-TDGHKO2M:~$ openclaw config set models.providers.ollama.baseUrl "http://172.29.32.1:11434/v1"
Error: Config validation failed: models.providers.ollama.baseUrl: Invalid input: expected string, received undefined

🦞 OpenClaw 2026.2.14 (c1feda1) — I'm the reason your shell history looks like a hacker-movie montage.

Failed to discover Ollama models: TypeError: fetch failed
Config overwrite: /home/aman/.openclaw/openclaw.json (sha256 c1f5ca25d52ebb5b83689639c7a32b3c221a2a9b43ad4a01252a7e3a586b191c -> 1c1d103fd046f6a78a05800b1aea3ed30a777a144f7789f7d1137e03e6d55993, backup=/home/aman/.openclaw/openclaw.json.bak)
Updated agents.defaults.model.primary. Restart the gateway to apply.

🦞 OpenClaw 2026.2.14 (c1feda1) — Your terminal just grew claws—type something and let the bot pinch the busywork.

Failed to discover Ollama models: TypeError: fetch failed
Restarted systemd service: openclaw-gateway.service
aman@LAPTOP-TDGHKO2M:~$

prisma otterBOT Feb 15, 2026, 1:54 PM

#

Good news: curl "http://172.29.32.1:11434/api/tags" works from WSL, so networking is finally OK.

The reason openclaw config set models.providers.ollama.baseUrl "http://..." failed is a JSON5 parsing gotcha: http:// contains // which JSON5 treats like a comment, so it ends up parsing your value wrong.

1) First confirm the OpenAI-compatible endpoint works (this is what OpenClaw uses)

In WSL:

curl "http://172.29.32.1:11434/v1/models"

If that returns JSON, continue.

2) Set the Ollama provider using `--json` (so the URL is parsed correctly)

In WSL, run this exactly:

#

openclaw config set models.providers.ollama --json '{
  baseUrl: "http://172.29.32.1:11434/v1",
  apiKey: "ollama-local",
  api: "openai-completions",
  models: [{
    id: "qwen2.5-coder:7b",
    name: "qwen2.5-coder:7b",
    reasoning: false,
    input: ["text"],
    cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
    contextWindow: 8192,
    maxTokens: 8192
  }]
}'

#

Then set it as your default model + restart:

openclaw config set agents.defaults.model.primary "ollama/qwen2.5-coder:7b"
openclaw gateway restart
openclaw models list | head -50

If `curl /v1/models` fails

Tell me what it prints — it would mean ipex-llm’s server is exposing /api/* but not the /v1/* OpenAI-compatible endpoints, and we’ll need a different approach.

If this ends up fixing it, please mark the solution message (right-click message → Apps → Mark Solution) so it’s searchable for the next person.

wanton stirrup Feb 15, 2026, 1:57 PM

#

aman@LAPTOP-TDGHKO2M:~$ curl "http://172.29.32.1:11434/v1/models"
{"object":"list","data":[{"id":"qwen2.5-coder:7b","object":"model","created":1771055941,"owned_by":"library"},{"id":"llama3.2:3b","object":"model","created":1771039929,"owned_by":"library"}]}
aman@LAPTOP-TDGHKO2M:~$ openclaw config set models.providers.ollama --json '{
baseUrl: "http://172.29.32.1:11434/v1",
apiKey: "ollama-local",
api: "openai-completions",
models: [{
id: "qwen2.5-coder:7b",
name: "qwen2.5-coder:7b",
reasoning: false,
input: ["text"],
cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
contextWindow: 8192,
maxTokens: 8192
}]
}'
Failed to discover Ollama models: TypeError: fetch failed
Config overwrite: /home/aman/.openclaw/openclaw.json (sha256 1c1d103fd046f6a78a05800b1aea3ed30a777a144f7789f7d1137e03e6d55993 -> 918602712d148227a55cade97f0ce02621c9feaaef188767d31d41cf5340151d, backup=/home/aman/.openclaw/openclaw.json.bak)
Updated models.providers.ollama. Restart the gateway to apply.
aman@LAPTOP-TDGHKO2M:~$ openclaw config set agents.defaults.model.primary "ollama/qwen2.5-coder:7b"
openclaw gateway restart
openclaw models list | head -50

🦞 OpenClaw 2026.2.14 (c1feda1) — I don't judge, but your missing API keys are absolutely judging you.

Config overwrite: /home/aman/.openclaw/openclaw.json (sha256 918602712d148227a55cade97f0ce02621c9feaaef188767d31d41cf5340151d -> 3a4ee32c87f40798b5c00a5bde093da93f1c831a796b9fac8b8f2095d445fa7f, backup=/home/aman/.openclaw/openclaw.json.bak)
Updated agents.defaults.model.primary. Restart the gateway to apply.

🦞 OpenClaw 2026.2.14 (c1feda1) — Ship fast, log faster.

Restarted systemd service: openclaw-gateway.service
Model Input Ctx Local Auth Tags
ollama/qwen2.5-coder:7b text 8k no yes default
anthropic/providers - - - - configured,missing
aman@LAPTOP-TDGHKO2M:~$

#how to use Ipex-llm ollama qwen2.5-coder:7b locally in openclaw