Skip to content

[Bug]: Ollama remote provider streaming not consumed — model_call:started never progresses in chat sessions #94251

Description

@tborer

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Environment:

OpenClaw version: 2026.6.8 (844f405)
OS: Linux (Debian/Ubuntu, kernel 6.12.90+deb13.1-amd64)
Ollama version: latest, running on a separate machine (Node 4, local IP)
Model: strategist-node:latest (custom Modelfile based on qwen2.5:32b, Q4_K_M, 32.8B parameters)
Node 4 hardware: 32GB RAM, no GPU, CPU-only inference
Node 1 (OpenClaw host): 3.7GB RAM, 4 cores, Ollama NOT installed locally

Summary
When OpenClaw is configured to use a remote Ollama instance as its primary model provider, chat sessions (both web console and Discord channel) never receive a response. The agent logs show model_call:started but progress never advances. Ollama on the remote machine shows the model loading and running at 100% CPU, then stopping — indicating OpenClaw's HTTP client is not consuming the stream, causing Ollama to treat the client as disconnected.
Direct curl requests from Node 1 to Node 4's Ollama work instantly and stream tokens correctly. The issue is specific to OpenClaw's internal Ollama plugin when Ollama is on a remote host.

Configuration
OpenClaw models.providers.ollama config:
json{
"baseUrl": local IP,
"apiKey": "ollama-local",
"timeoutSeconds": 18000,
"models": [
{
"id": "strategist-node:latest",
"name": "strategist-node:latest"
}
]
}
Primary model set to ollama/strategist-node via:
json"agents": {
"defaults": {
"model": {
"primary": "ollama/strategist-node"
}
}
}

What works
Direct curl from Node 1 to Node 4 streams tokens correctly and quickly:
bashcurl local IP/api/generate
-d '{"model":"strategist-node:latest","prompt":"what is 2+2?","stream":true}'

Returns tokens one by one, completes in ~56 seconds

curl -N local IP/v1/chat/completions
-H "Content-Type: application/json"
-d '{"model":"strategist-node:latest","messages":[{"role":"user","content":"what is 2+2?"}],"stream":true}'

Also streams correctly

Both the native /api/generate and OpenAI-compatible /v1/chat/completions endpoints stream tokens successfully from Node 1 to Node 4.

What fails
Any chat session through OpenClaw — web console or Discord — results in:
warn diagnostic stalled session: sessionId=... sessionKey=agent:main:main
state=processing age=146s queueDepth=1
reason=active_work_without_progress
classification=stalled_agent_run
activeWorkKind=model_call
lastProgress=model_call:started
lastProgressAge=146s
recovery=none
The session continues reporting active_work_without_progress indefinitely. No response is ever returned to the chat. The session never aborts (after raising stuckSessionAbortMs) but also never completes.

Node 4 Ollama behavior during chat session
When a chat message is sent, ollama ps on Node 4 shows:
NAME ID SIZE PROCESSOR CONTEXT UNTIL
strategist-node:latest 2b4cc6a489b3 24 GB 100% CPU 16384 Stopping...
The model loads briefly, runs at 100% CPU, then immediately goes to Stopping... — indicating OpenClaw's HTTP client disconnected before consuming the stream. During a direct curl test at the same time, the model runs successfully and returns to 4 minutes from now keep-alive.

Hypothesis
OpenClaw's internal Ollama plugin HTTP client appears to either:

Not be reading the SSE/streaming response from a remote Ollama host, causing Ollama to close the connection
Have an internal buffer or read timeout that fires before the first token arrives from a remote host, disconnecting before consumption begins

This does not appear to be a network, firewall, or Ollama configuration issue since direct curl streaming works perfectly. The issue seems specific to how the Ollama plugin manages the HTTP stream when Ollama is on a different machine than OpenClaw.

Steps to reproduce

Troubleshooting steps already attempted

Verified network connectivity — Node 1 can reach Node 4 on both port 11434 (Ollama) and port 8001 (MCP server). Both curl tests pass.
Verified Ollama is binding on network interface — curl local IP/api/tags from Node 4 itself returns model list correctly.
Raised provider timeout — Set models.providers.ollama.timeoutSeconds: 18000 (5 hours). Did not resolve the issue. Note: requestTimeoutMs was rejected as invalid by config schema.
Raised diagnostic stall abort threshold — Set diagnostics.stuckSessionAbortMs: 180000) (30 minutes). Sessions no longer abort but still never complete.
Raised agent timeouts — Set agents.defaults.timeoutSeconds: 1800 and agents.defaults.subagents.runTimeoutSeconds: 1800 and agents.defaults.subagents.announceTimeoutMs: 1800000. Did not resolve.
Explicitly registered model in provider config — Added {"id": "strategist-node:latest", "name": "strategist-node:latest"} to models.providers.ollama.models. Did not resolve.
Confirmed streaming works on both Ollama endpoints — Both /api/generate and /v1/chat/completions with stream:true return tokens correctly via curl from Node 1.
Restarted Ollama on Node 4 to clear any stuck requests before retesting. Did not resolve.
Updated OpenClaw from 2026.5.28 to 2026.6.8. Did not resolve.
Checked for noOutputTimeoutMs at various config paths — Not valid at agents.defaults, models.providers.ollama, or diagnostics levels per schema validation.

Expected behavior

The local connection should be able to send and receive info via the console, the same as what appears to work via the terminal

Actual behavior

The console times out, despite very small requests and increased timeouts. Where the terminal returns output quickly for the same request.

OpenClaw version

2026.6.8

Operating system

Linux (Debian/Ubuntu, kernel 6.12.90+deb13.1-amd64)

Install method

NPM

Model

qwen2.5:32b

Provider / routing chain

local IPs

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    P1High-priority user-facing bug, regression, or broken workflow.bugSomething isn't workingbug:behaviorIncorrect behavior without a crashclawsweeper:linked-pr-openClawSweeper found an open linked pull request for this issue.clawsweeper:needs-live-reproClawSweeper needs live local, crabbox, or manual validation to confirm this issue.clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.impact:auth-providerAuth, provider routing, model choice, or SecretRef resolution may break.impact:message-lossChannel message delivery can be lost, duplicated, or misrouted.impact:session-stateSession, memory, transcript, context, or agent state can drift or corrupt.issue-rating: 🐚 platinum hermitGood issue quality with a plausible reproduction path needing some confirmation.staleMarked as stale due to inactivity

    Type

    No type

    Fields

    Priority

    None yet

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions