Adapted community discussion: Paraphrased and condensed from an anonymized public OpenClaw Discord support conversation from August 2026. Technical guidance was reviewed for OpenClaw 2026.9.3.
I am running a Gemma model locally through Ollama on Windows. Simple prompts work, but complex agent tasks appear to freeze or get interrupted. I cannot tell whether I am running out of resources, filling the context, or hitting a tool-calling problem.
It could be resource pressure, but long context and repeated tool calls can look similar. Let us separate the layers. Please collect:
openclaw --version
ollama --version
ollama ps
ollama list
openclaw models list --provider ollama
openclaw status --all
Run ollama ps and openclaw logs --follow while the task is actually frozen. Also verify the native Ollama base URL has no /v1 suffix. A loaded model with exhausted memory points one way; an idle Ollama server while OpenClaw stalls points another.
The versions are installed, but ollama ps was empty when I checked. I also copied the placeholder from the example literally, so ollama show <exact-model-tag> failed in Windows Command Prompt.
An empty ollama ps means no model was loaded at that moment. The angle brackets were a placeholder, not literal syntax. Use the real model name returned by ollama list, then inspect it directly.
ollama list
ollama show gemma4:latest
openclaw models list --provider ollama
openclaw gateway status
During the next freeze, leave ollama ps running in a second terminal. That will tell us whether OpenClaw reaches Ollama and whether the model is on CPU, GPU, or under memory pressure.
OpenClaw discovers the configured Gemma models and reports a 131k context size. The model-list command then ends with a Windows Node UV_HANDLE_CLOSING assertion.
The 131k model metadata makes a model-reported 32k ceiling less likely, but the configured Ollama model entry could still lower the effective limit. The Windows UV_HANDLE_CLOSING assertion is a separate Node/libuv crash. Do not edit configuration or memory files yet.
Start a fresh conversation with /new, run /status and /context list, then send Reply exactly: pong. If that crashes, collect the Node, Ollama, and OpenClaw versions, openclaw config get models.providers.ollama.models, and the full assertion. This isolates a general Gateway or model failure from one specific workflow.
The fresh session and the pong test both worked.
That rules out a general Gateway startup failure and makes a universal 32k context ceiling much less likely. In the fresh session, retry the smallest version of the original task, then add files, tools, and complexity one step at a time.
If the crash returns, capture the exact prompt and /context list output immediately before it. Keep configuration and memory unchanged while isolating the operation that triggers the Windows libuv crash.