Skip to content

Gemma4/Qwen3.6 via local Ollama: only first token/word? rendered, while Ollama streams clean content-only output #91428

Description

@anijatsu

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Chatting with gemma4:latest or qwen3.6 through OpenClaw's local Ollama provider returns only the first streamed token (e.g. "I", "this") in the UI, even though raw curl/ollama against the same model returns a full, clean content-only stream with no reasoning/thinking field present.

Steps to reproduce

  1. Install OpenClaw via the official install script (homepage); install Ollama via scoop on Windows (ollama-rocm bucket package, then the Openclaw install triggered through the OpenClaw/Ollama startup flow) or the official homepage script on Linux; ollama pull gemma4:latest or qwen3.6.
  2. Configure OpenClaw to use the local Ollama provider with that model - either running the default setup through ollama launch openclaw or openclaw configure
  3. See the first chat. The default message "Wake up, my friend!" already produced a response which is just "I"
  4. Each next message replies render as a single word only ("I", "this", etc.)
  5. Compare against direct curl against the same model and endpoint:

curl http://localhost:11434/api/chat -d '{"model":"gemma4:latest","messages":[{"role":"user","content":"hi"}],"stream":true}'

This returns a complete, coherent reply with content populated normally in every chunk and no reasoning/thinking field at all:

{"model":"gemma4:latest",...,"message":{"role":"assistant","content":"Hi"},"done":false}
{"model":"gemma4:latest",...,"message":{"role":"assistant","content":"!"},"done":false}
{"model":"gemma4:latest",...,"message":{"role":"assistant","content":" How"},"done":false}
... full reply: "Hi! How can I help you today? 😊"

This rules out the content vs reasoning field mismatch described in #27806. Ollama emits exactly the standard chunk shape OpenClaw expects, yet only the first token reaches the UI.

Reproduces identically across two machines, three OSs: Windows 11, CachyOS, and Debian stable.

Expected behavior

OpenClaw renders the full streamed reply, matching what raw Ollama / curl returns for the same model and prompt.

Actual behavior

Only the first streamed token is shown in the UI ("I", "this", etc.); the remainder of the reply never appears, even though the upstream delta.content stream from Ollama is clean, standard-shaped, and complete.
This might not be the #27806 content/reasoning field mismatch (no reasoning field present in the stream) and not the #67092 malformed leak (no think tags present either).
Both of those fixes are supposed to be already present in this build.

Image Image

OpenClaw version

2026.6.1 (2e08f0f)

Operating system

Windows 11, CachyOS, Debian stable (reproduces identically on all three)

Install method

Official install script from the OpenClaw homepage (all three machines). Ollama installed via the official script on Linux; via scoop (ollama-rocm bucket) on Windows, triggered through the Ollama/OpenClaw startup flow.

Model

ollama/gemma4:latest, ollama/qwen3.6 (plain local Ollama, no proxy/vllm/llama.cpp)

Provider / routing chain

openclaw -> ollama (local, plain Ollama provider)

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Photos of my screen (sorry, I literally distro hopped to make sure I'm not doing something dumb) of the affected chat session (gemma4 producing single-word "I" replies to "try again"/"once more?"/"now?", and the mistral:7b session quoting some sort of instructions/content) above

Raw curl output against Ollama directly (showing clean full-content streaming) is included in the Steps to reproduce section above.

Impact and severity

Affected: any user running gemma4 or qwen3.6 through OpenClaw's local Ollama provider.
Severity: blocks usage (models suggested by ollama launch openclaw are effectively unusable through OpenClaw: every reply truncates to one token).
Frequency: all the time, two independent machines, three OSes (existing Windows 11 install, fresh CachyOS, Debian stable installs).

Additional information

Switching to mistral:7b causes a full reply to render, but the reply itself is not a conversational response to the prompt.Instead it is a structured list of behavior/instructions (communication style, etc).
This may be a separate, unrelated issue from the gemma4/qwen3.6 truncation reported above; flagging only as additional context.

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:needs-infoClawSweeper needs more reporter information before it can verify this issue.clawsweeper:needs-maintainer-reviewClawSweeper marked this issue as needing maintainer review before automation.clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.impact:message-lossChannel message delivery can be lost, duplicated, or misrouted.issue-rating: 🦐 gold shrimpDecent issue quality, but reproduction details are still incomplete.

    Type

    No type

    Fields

    Priority

    None yet

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions