I'm not used to it so I'm sorry if it's hard to read.
Thank you for your support.
Environment
・OS: macOS (MacBook Pro 2019, 16GB RAM)
・OpenClaw Version: 2026.2.1 (ed4529e)
・Provider: Ollama (Local)
・Model: huihui_ai/dolphin3-abliterated:8b (Tools capable)
・Setup Method: Used ollama launch openclaw --config to generate config, then started via openclaw gateway start.
Description
I successfully configured a local Ollama model with OpenClaw. The model is recognized in the TUI (/models ollama) and I can switch to it.
The Issue: I sent only a very short message (e.g., "Hey") via the TUI. However, the logs reveal that the Gateway internally injected a massive amount of context/prompt data, totaling 12,209 tokens.
Since my local Ollama (8B model) truncates this to 4096 tokens and takes minutes to process (eventually timing out with a 500 error), the Gateway enters a "zombie" state. Even after Ollama aborts the request, the OpenClaw Gateway session remains active: true. As a result, all subsequent messages are never processed. They simply pile up in the queue (queueSize increments) because the Gateway believes the previous run is still active.
Configuration
~/.openclaw/openclaw.json (Snippet):
JSON
"ollama": {
"baseUrl": "http://127.0.0.1:11434/v1",
"apiKey": "ollama-local",
"api": "openai-completions",
"models": [
{
"id": "huihui_ai/dolphin3-abliterated:8b",
"name": "huihui_ai/dolphin3-abliterated:8b",
"reasoning": false,
"input": [ "text" ],
"cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 },
"contextWindow": 131072,
"maxTokens": 16384
}
]
}
Logs
- Ollama Server Log (~/.ollama/logs/server.log)
Despite the short user input, Ollama received a 12k+ token prompt. It truncated the prompt and eventually timed out.
level=WARN msg="truncating input prompt" limit=4096 prompt=12209
[GIN] ... | 500 | 5m1s | 127.0.0.1 | POST "/v1/chat/completions"
level=INFO msg="aborting completion request due to client closing the connection"
- OpenClaw Gateway Log (openclaw logs --follow)
Even after Ollama threw the 500 error, the Gateway continues to report the run as active. New messages are queued but never dequeued.
debug agent/embedded provider=ollama model=huihui_ai/dolphin3-abliterated:8b
debug diagnostic session state: sessionId=d9e5f4dd... new=processing reason="run_started"
...
(Time passes, Ollama times out)
...
debug diagnostic run active check: sessionId=d9e5f4dd... active=true
debug diagnostic run active check: sessionId=d9e5f4dd... active=true
info gateway/ws webchat disconnected code=1001
debug diagnostic lane enqueue: lane=session:agent:main:main queueSize=2
debug diagnostic lane enqueue: lane=session:agent:main:main queueSize=3
Troubleshooting Steps Taken
Isolation Test (Direct Ollama Run):
Running ollama run huihui_ai/dolphin3-abliterated:8b "hello" in the terminal works perfectly and responds immediately. The issue is not with the model performance itself.
Issue #2279 Workaround:
I have already applied the workaround for the "no output" bug by removing "ollama" from isReasoningTagProvider in provider-utils.js.
Service Reset:
Running openclaw gateway stop followed by killall -9 openclaw-gateway clears the stuck process, but I still cannot get any reply. Sending a request again immediately triggers the massive context injection and hangs the system.
Expected Behavior
The Gateway should not inject excessive context (12k+ tokens) for a simple short message, or it should respect the model's limitations better.
If the provider (Ollama) returns an error (500) or times out, the Gateway should detect this, mark the session as failed/idle, and process the next message in the queue instead of blocking indefinitely.
I'm not used to it so I'm sorry if it's hard to read.
Thank you for your support.
Environment
・OS: macOS (MacBook Pro 2019, 16GB RAM)
・OpenClaw Version: 2026.2.1 (ed4529e)
・Provider: Ollama (Local)
・Model: huihui_ai/dolphin3-abliterated:8b (Tools capable)
・Setup Method: Used ollama launch openclaw --config to generate config, then started via openclaw gateway start.
Description
I successfully configured a local Ollama model with OpenClaw. The model is recognized in the TUI (/models ollama) and I can switch to it.
The Issue: I sent only a very short message (e.g., "Hey") via the TUI. However, the logs reveal that the Gateway internally injected a massive amount of context/prompt data, totaling 12,209 tokens.
Since my local Ollama (8B model) truncates this to 4096 tokens and takes minutes to process (eventually timing out with a 500 error), the Gateway enters a "zombie" state. Even after Ollama aborts the request, the OpenClaw Gateway session remains active: true. As a result, all subsequent messages are never processed. They simply pile up in the queue (queueSize increments) because the Gateway believes the previous run is still active.
Configuration
~/.openclaw/openclaw.json (Snippet):
JSON
Logs
Despite the short user input, Ollama received a 12k+ token prompt. It truncated the prompt and eventually timed out.
Even after Ollama threw the 500 error, the Gateway continues to report the run as active. New messages are queued but never dequeued.
Troubleshooting Steps Taken
Isolation Test (Direct Ollama Run):
Running ollama run huihui_ai/dolphin3-abliterated:8b "hello" in the terminal works perfectly and responds immediately. The issue is not with the model performance itself.
Issue #2279 Workaround:
I have already applied the workaround for the "no output" bug by removing "ollama" from isReasoningTagProvider in provider-utils.js.
Service Reset:
Running openclaw gateway stop followed by killall -9 openclaw-gateway clears the stuck process, but I still cannot get any reply. Sending a request again immediately triggers the massive context injection and hangs the system.
Expected Behavior
The Gateway should not inject excessive context (12k+ tokens) for a simple short message, or it should respect the model's limitations better.
If the provider (Ollama) returns an error (500) or times out, the Gateway should detect this, mark the session as failed/idle, and process the next message in the queue instead of blocking indefinitely.