#Ollama and Llama not working

1 messages · Page 1 of 1 (latest)

simple pilot
#

I am attempting to connect Openclaw to Llama using Ollama. I asked Openclaw to summarize what we were facing. Please let me know if there is something we need to do that we did not do. Openclaw claims this is a bug so posting here first before filing a bug report:

• OpenClaw 2026.4.15
• macOS, Apple M4 Mac Mini, 24GB RAM
• Ollama running locally, llama3.1:8b pulled and loaded (confirmed via /api/ps)
• Config: baseUrl: http://127.0.0.1:11434, api: ollama (native API, not openai-completions)
Steps to reproduce:

  1. Start gateway, switch model to ollama/llama3.1:8b
  2. Send "hello" via TUI or Signal
  3. Typing indicator appears briefly (Signal) or spinner starts (TUI)
  4. No response ever arrives — hangs indefinitely (tested up to 7+ minutes)
  5. Ollama shows model loaded in memory (/api/ps) but no active generation
  6. Gateway logs show no Llama request — the request never reaches Ollama
  7. Second message gets no typing indicator at all — gateway is unresponsive
  8. Only fix is openclaw gateway restart
    Also observed:

• Before switching to native API (api: ollama), config was incorrectly set to api: openai-completions with /v1 URL — this caused raw tool JSON to be output as plain text on first response, then same hang behavior on second message
Expected: Response to "hello" within reasonable timeActual: Gateway hangs, requires restart to recover

Please let me know your thoughts! Thanks!

dreamy spindleBOT
#

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

shrewd pierBOT
copper wrenBOT
#

I’m checking the Ollama provider docs and the recent code paths now. If there’s a known limitation or a fix already on main, I’ll pull that out so you don’t have to guess.

#

I don’t think you missed an obvious setup step.

What you already caught is real:

  • api: "openai-completions" + /v1 is wrong for Ollama here, and can cause raw tool JSON / bad behavior
  • native Ollama config is the right path: baseUrl: "http://127.0.0.1:11434" and api: "ollama"

The big thing is: there was also a fresh Ollama regression around this area right after 2026.4.15.

A fix landed on main for Ollama chat requests incorrectly sending ollama/<model> instead of the bare model id to Ollama:

So my read is:

  1. the /v1 config was one problem
  2. even after correcting it, you may still be hitting a real Ollama bug in 2026.4.15

A couple notes:

#
  • llama3.1:8b is also pretty small for full agent runtime, so even once transport works it may still be flaky with tools
  • if you get past the current hang but local runs are brittle, try lean mode: agents.defaults.experimental.localModelLean: true

My recommendation:

  • first retest on the latest build, not 2026.4.15
  • if it still reproduces there, then yes, file a GitHub bug

If you do file, include:

  • openclaw status --all
  • openclaw models status
  • openclaw logs --follow around one failed hello
  • the relevant models.providers.ollama block
  • confirmation that baseUrl has no /v1

Docs:

simple pilot
#

I just ran update and the version still is 2026.4.15. You said to run on the latest build- is there one after 2026.4.15?

copper wrenBOT
#

Yep, there is a newer release after 2026.4.15, the changelog shows 2026.4.18 at the top:

Also, the Ollama fix I was referring to is now in the changelog too:

  • Ollama/chat: strip the ollama/ provider prefix from Ollama chat request model ids ... (#67457)

So if openclaw update left you on 2026.4.15, I’d check the updater path next, not just Ollama.

Could you paste:

openclaw --version
openclaw update --dry-run

If you want to target the newest code path directly, you can also try:

# 
openclaw update --tag main

Then re-check:

openclaw --version

If you paste the --dry-run output, I can tell you pretty quickly what it’s doing.

simple pilot
#

openclaw --version
OpenClaw 2026.4.15 (041266a)

openclaw update --dry-run
Update dry-run
No changes were applied.

Root: /opt/homebrew/lib/node_modules/openclaw
Install kind: package
Mode: npm
Channel: stable
Tag/spec: openclaw@latest
Current version: 2026.4.15
Target version: 2026.4.15

Planned actions:

  • Run global package manager update with spec openclaw@latest
  • Run plugin update sync after core update
  • Refresh shell completion cache (if needed)
  • Restart gateway service and run doctor checks
copper wrenBOT
#

Nice, this is helpful, and it changes the picture a bit.

Your output confirms that npm stable latest is still 2026.4.15 on your install path, so you did not miss a normal stable update. In other words:

  • newer code exists in the repo/changelog
  • but it is not on the npm stable tag you’re pulling from yet

So I’d treat this as:

Option A, fastest verification

Try the newer code directly:

openclaw update --tag main --dry-run
openclaw update --tag main
openclaw --version
#

Then retest the Ollama flow.

Option B, conservative

Stay on stable and file the bug now against 2026.4.15, because your repro is already clean.

Honestly, I think filing is fair at this point. Your report is solid, and stable users can still hit this.

If you want my recommendation:
try --tag main once, because if that fixes it, you can include that in the bug report, which is super useful for maintainers.

If you do file, I’d mention exactly this line from your dry-run:

Tag/spec: openclaw@latest
Current version: 2026.4.15
Target version: 2026.4.15

That tells maintainers the fix is likely not yet in npm stable.

simple pilot
#

Working on filing a bug, what do i put in the Provider/routing chain field for this bug?

copper wrenBOT
#

I’d use the simplest repro path, so probably TUI, not Signal.

Put this in Provider / routing chain:

TUI → OpenClaw gateway :18789 → Ollama native API http://127.0.0.1:11434/api/chat

If you want, you can add one sentence in the body like:

Also reproduced through Signal, but TUI shows the same hang, so the cleanest repro does not require any external channel integration.

If you file a second chain for Signal, it would be: