Response contains template placeholder (Ollama + gwen2.5:3b) | Friends of the Crustacean 🦞🤝 | Page 1

royal valley Apr 16, 2026, 3:21 PM

#

I'm using qwen2.5:3b with a 4G VRAM gpu on a i9 bare metal using local ollama (latest version) on a Debian 13 system with fast ssd and 64G ram.

Latest Openclaw 2026.4.14, Onboarded well, websearch configured and tested, works well but I constantly get placeholder answers of this:

Prompt:
Go to sbb.ch and find me the train from Zurich to Lenzerheide arriving 12pm coming Saturday.

Response:
Here are the latest available train connections:

Train Connection: [Insert information about the train schedule here]
Departure Time: [Insert departure time from Zurich SBB]
Arrival Time: [Insert arrival time at Lemzerheide]

Issue:
Irrelevant how long I try to request a better answer, it still remains placeholders.

Is the model too weak or how I could improve that Openclaws result?

gentle owlBOT Apr 16, 2026, 3:21 PM

#

real vaultBOT Apr 16, 2026, 3:23 PM

#

Yeah, most likely.

That placeholder-style answer is a classic sign the model is too weak to reliably use the web/tool results and it falls back to a generic template. qwen2.5:3b on a 4 GB card is fine for light chat, but pretty rough for agentic tasks like “go to a site, inspect it, extract exact travel info”.

A few concrete checks:

Make sure Ollama is using the native API, not /v1
OpenClaw explicitly warns that http://...:11434/v1 breaks reliable tool calling with Ollama. It should be just http://...:11434 with api: "ollama".
https://docs.openclaw.ai/providers/ollama
sbb.ch is probably browser territory
web_fetch does not execute JavaScript, so JS-heavy sites often need the browser tool instead.
https://docs.openclaw.ai/tools/browser
https://docs.openclaw.ai/tools/web-fetch
3B is too small for this workload
OpenClaw’s local-model guidance is pretty blunt here: small local models are not a good fit for tool-enabled/web agents.

#

https://docs.openclaw.ai/gateway/local-models
https://docs.openclaw.ai/concepts/models

My recommendation: use a stronger model for web/browser tasks, and keep your local Ollama model as a fallback or for simple chat. Hybrid usually works best.

If you want, paste these and I’ll sanity-check whether it’s just model weakness or also config:

openclaw status
openclaw models status
openclaw config get models.providers.ollama

For current community model picks, also check the community notes here:
https://docs.openclaw.ai/concepts/models#model-discussions-community-notes

next isle Apr 16, 2026, 3:52 PM

#

Hello. I am a Senior Software Engineer. I think I can help you resolve your issue. If you have any questions or need assistance with project development, please contact me via DM.

real vaultBOT Apr 16, 2026, 3:53 PM

#

If you’ve got a fix, please share it here in the thread instead of DM 🙂

That way everyone can benefit, and if it solves the issue it can get indexed on Answer Overflow for future users.

royal valley Apr 16, 2026, 5:17 PM

#

Response contains template placeholder (Ollama + gwen2.5:3b)

royal valley Apr 16, 2026, 5:49 PM

#

you want the output from:

openclaw status
openclaw models status
openclaw config get models.providers.ollama

however, it exceeds the upload limit of max number of characters, how can I send it to you?

real vaultBOT Apr 16, 2026, 5:50 PM

#

Yep, a few easy options:

Best option: attach them as .txt files instead of pasting inline.

If you want to paste, split them into 2 to 4 messages and label them, for example:

1/3 openclaw status
2/3 openclaw models status
3/3 openclaw config get models.providers.ollama

Also, please redact any secrets before posting, especially:

apiKey
tokens
passwords

#

If you want to keep it shorter, this is enough for me to start:

openclaw --version
openclaw models status
openclaw config get models.providers.ollama

You can skip full openclaw status for now if that one is the biggest.

royal valley Apr 16, 2026, 5:52 PM

#

$ openclaw --version
OpenClaw 2026.4.14 (323493f)

#

$ openclaw models status

🦞 OpenClaw 2026.4.14 (323493f) — The lobster in your shell. 🦞

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : openai/qwen2.5:3b
Fallbacks (2) : ollama/qwen2.5:3b, ollama/glm4:9b-chat-q4_0
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (3): ollama/qwen2.5:3b, ollama/llama3.2:latest, ollama/qwen2.5:7b

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

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

Missing auth

openai Run openclaw models auth login --provider openai, openclaw configure, or set an API key env var.

OAuth/token status

none

real vaultBOT Apr 16, 2026, 5:52 PM

#

Nice, thanks, version looks fine, so this probably isn’t just “old build weirdness”.

Next, the most useful bits are:

openclaw models status
openclaw config get models.providers.ollama

If models status is too long, paste it in chunks or attach it as a .txt.

What I’m mainly checking for:

whether Ollama is using the native API instead of /v1
the resolved model/provider
any odd compat/settings around the Ollama provider

royal valley Apr 16, 2026, 5:52 PM

#

$ openclaw config get models.providers.ollama

🦞 OpenClaw 2026.4.14 (323493f) — WhatsApp automation without the "please accept our new privacy policy".

{
"baseUrl": "http://127.0.0.1:11434",
"apiKey": "OPENCLAW_REDACTED",
"api": "ollama",
"models": [
{
"id": "gemma4",
"name": "gemma4",
"reasoning": false,
"input": [
"text"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 128000,
"maxTokens": 8192,
"api": "ollama"
},
{
"id": "qwen2.5:7b",
"name": "qwen2.5:7b",
"reasoning": false,
"input": [
"text"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 32768,
"maxTokens": 8192,
"api": "ollama"
},
{
"id": "qwen2.5:3b",
"name": "qwen2.5:3b",
"reasoning": false,
"input": [
"text"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 32768,
"maxTokens": 8192,
"api": "ollama"
},
{
"id": "llama3.2:latest",
"name": "llama3.2:latest",
"reasoning": false,
"input": [
"text"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 131072,
"maxTokens": 8192,
"api": "ollama"
}
]

real vaultBOT Apr 16, 2026, 5:53 PM

#

Aha, this shows a real config issue.

This line is the giveaway:

Default       : openai/qwen2.5:3b

But your actual local models are all ollama/..., and OpenClaw is also telling you:

Missing auth
- openai

So before we even get to “is 3B too weak?”, your primary model/provider mapping is off. For an Ollama setup, your default should be ollama/..., not openai/....

#

What I’d do next:

Test with an Ollama model selected explicitly
In the thread, use /model and switch to ollama/qwen2.5:7b if available.
If not, at least switch to ollama/qwen2.5:3b so we know the provider routing is correct.
Retry the same SBB prompt

Paste this too:

openclaw config get models.providers.ollama

What I’m checking there is whether your Ollama provider is using the native URL (http://...:11434) and not the broken /v1 OpenAI-compatible path.

So, short version:

#

Yes, 3B is probably too weak for this task
But also yes, your config currently looks miswired, because the default is openai/qwen2.5:3b instead of ollama/...

Docs for the Ollama bit here:
https://docs.openclaw.ai/providers/ollama

#

Nice, this helps a lot.

Your Ollama provider config looks correct:

baseUrl is native Ollama: http://127.0.0.1:11434
api is correctly set to "ollama"
no broken /v1 path

So the picture now is:

Your provider config is fine
Your default model selection is not fine
3b is still probably too weak for this exact task

The big problem is still this from models status:

#

Default : openai/qwen2.5:3b

That means OpenClaw is not actually pinned cleanly to Ollama as the primary. It’s trying an openai/... model ref first, even though your real local models are ollama/....

What I’d do now

Set the model explicitly with the provider prefix, not just the bare model name.

For a quick test, switch to:

ollama/qwen2.5:7b

You can do that via the /model picker in the thread, or via the CLI if you prefer.

#

Then retry the same SBB prompt.

My read

If switching to explicit ollama/qwen2.5:7b improves things, then the misresolved default provider was part of the problem.
If it still gives placeholder/template junk, then it’s mostly the model being too small for agentic web work.

For this kind of “go to site, inspect, extract exact answer” task, I’d strongly prefer:

a stronger model as primary
local Ollama as fallback

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

If you want, send the result after switching to explicit ollama/..., and I’ll help narrow it down from there.

unkempt bloom Apr 16, 2026, 6:45 PM

#

OpenClaw 2026.4.14 (323493f)

Gateway: unreachable (gateway closed (1008): pairing required)
Gateway service: running (pid 40852)
Node service: running (pid 40906)
Agents: 7 total, 1 active, 119 sessions
Channels:

Discord ON / OK
LINE ON / OK

Dashboard: http://127.0.0.1:18789/
Config: ~/.openclaw/openclaw.json
OS: macos 26.4.1 (arm64)
Node: 24.14.0

Runtime: running (pid 40852, state active)
Listening: 127.0.0.1:18789
RPC probe: failed
gateway closed (1008): pairing required
Service config issue:
Gateway service embeds OPENCLAW_GATEWAY_TOKEN and should be reinstalled.
Suggested fix: openclaw gateway install --force

Checking channel status (probe)…
gateway closed (1008): pairing required

Config-only status:

Discord default: enabled, configured, token:config
LINE default: enabled, configured, mode:webhook, token:env

lane wait exceeded:

waitedMs=14270 queueAhead=0
waitedMs=14688 queueAhead=0
waitedMs=5164 queueAhead=0

2026-04-17T01:43:51.494+08:00 [discord] connect error: pairing required
2026-04-17T01:44:34.105+08:00 [ws] unauthorized ... reason=rate_limited
2026-04-17T01:44:37.627+08:00 [ws] closed before connect ... reason=unauthorized: too many failed authentication attempts (retry later)
2026-04-17T01:45:02.422+08:00 [ws] closed before connect ... reason=pairing required
2026-04-17T02:42:42.880+08:00 [ws] closed before connect ... reason=pairing required

2026-04-17T02:42:22~02:42:26 [ws] res ✓ sessions.list / chat.history / models.list

real vaultBOT Apr 16, 2026, 6:46 PM

#

unkempt bloom OpenClaw 2026.4.14 (323493f) Gateway: unreachable (gateway closed (1008): pairi...

What you'll see: "disconnected (1008): pairing required"

This does not mean the Gateway crashed. It means the gateway is healthy but
the browser/device is not yet approved for WebSocket access.

Approve the device in one of these ways:

openclaw devices list
openclaw devices approve <requestId>

Or in the Control UI, use the Device Approvals panel if available.

Loopback exception: when you connect from 127.0.0.1 / localhost, the
dashboard should be auto-approved. If pairing still appears on localhost, the
most common causes are:

#

you actually opened a non-loopback URL (for example a LAN IP or Tailscale URL)
you have a stale device token or changed auth mode/scopes
the service was installed with stale env/config and needs reinstall

Try:

openclaw devices list
openclaw gateway install --force
openclaw gateway restart
openclaw doctor

If you see too many failed authentication attempts (retry later), wait a
minute before retrying to let the limiter cool down.

I’d fix this first

Wait a minute for the auth rate limit to cool down, then run:

#

openclaw devices list
openclaw gateway install --force
openclaw gateway restart
openclaw doctor

If openclaw devices list shows a pending request, approve it:

openclaw devices approve <requestId>

Also make sure you’re opening the dashboard on:

#

http://127.0.0.1:18789/

and not a LAN/Tailscale URL, because localhost should auto-approve.

After that

Re-run:

openclaw status
openclaw models status

What we want to see:

#

RPC probe: ok
no more pairing/auth spam
and ideally the default model no longer showing the wrong provider mapping

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

If this fixes the gateway side and the model still outputs placeholders, then I’d treat the remaining problem as mainly:

wrong default model/provider selection
qwen2.5:3b being too weak for this browser-ish task

#Response contains template placeholder (Ollama + gwen2.5:3b)

What I’d do now

My read

I’d fix this first

After that