RepoWatch / GitHub signal
Ollama aligns Gemma 4 chat templates for tool loops
If you run Gemma 4 through Ollama with tools or thinking, pull this before debugging another broken multi-turn tool loop.
Directly affects local agent reliability on Gemma 4: tool calls, tool responses, and thinking-channel handling after tool turns — same surface Hermes and OpenClaw hit via Ollama.
What changed
ollama/ollama landed #17182 on the default branch: model: align gemma4 chat template handling.
This is not a versioned release. It tightens the Gemma 4 parser/renderer path so multi-turn agent traffic matches the Hugging Face chat template more closely.
Concrete fixes in the diff:
- Tool-response continuation: after a
role: toolmessage, the parser starts in the thinking-collection state instead of mis-handling the next model turn. - Thinking after tools: when thinking is enabled and the previous message was a tool response, generation can open a
<|channel>thoughtblock correctly. - Turn folding: forward/back scans for the next non-tool role so consecutive model/assistant turns (with tools in between) do not emit the wrong
<|turn>/<turn|>boundaries. - Null tool args: tests for
nulloptional arguments inside Gemma 4 tool-call syntax (call:set_optional{value:null,...}). - Template parity: Jinja2 reference templates for Gemma 4 (31B / E2B style) updated alongside the Go renderer.
Commit: https://github.com/ollama/ollama/commit/8a0016f826305b0672daaf02c6c55a34f844bba3
Why it matters
Gemma 4 is usable as a local agent model only if tool loops stay coherent. Most “Gemma tool calling is flaky” reports are template bugs, not model IQ:
- wrong turn markers after tool results;
- thinking channel stripped or started in the wrong state;
- null/optional tool args rejected by the parser.
Those fail mid-loop — after the first successful tool call — which is exactly when agent stacks look broken and the model looks dumb.
Yesterday’s RepoWatch covered Ollama v0.32.0 packaging the agent shell as a product. This commit is the quieter companion: substrate correctness for one high-profile local model family. Hermes, OpenClaw, and any custom agent that routes tool turns through Ollama’s API all sit on that substrate.
If you are not on Gemma 4, this is noise. If you are, it is the difference between “tools sometimes work” and “multi-turn tool + thinking actually matches the model’s training template.”
My read
Worth a spike if:
- you run Gemma 4 (any size) via Ollama with tools; or
- you use thinking + tools on Gemma 4 and have seen truncated thought channels or garbled post-tool turns.
Watch only if you do not use Gemma 4, or you only do single-turn chat.
Ignore if your local stack is Llama / Qwen / GLM-only and Gemma is not on the roadmap.
Suggested check (non-production):
- pull latest Ollama main or next nightly that includes
8a0016f; - same Gemma 4 tag you already use;
- two-hop tool loop: user → tool call → tool result → model answer (with thinking on and off);
- optional arg tool with an explicit
null; - compare transcript structure (turn markers / thought channels) against the HF Jinja template for that model.
Do not treat this as a reason to re-evaluate Ollama vs Hermes/OpenClaw. It is a model-family template fix inside the runner, not a harness change.
Bottom line
Small commit, agent-shaped impact. Gemma 4 + tools on Ollama needed template alignment for multi-turn and thinking-after-tool paths; this is that alignment. Spike it if Gemma 4 is in your local agent mix; otherwise leave it on the watchlist and wait for the next tagged Ollama release if you only pin stables.