Ollama says the model supports tools. Your curl works. Your agent hangs forever. Here is what is actually happening, verified against the open Ollama issues on August 20, 2026.
You pulled qwen3.8:27b, checked that Ollama lists tool support, ran a curl against it, and got a clean response with a proper tool_calls block. Then you pointed Claude Code at it and watched the cursor blink for twelve minutes.
The model supports tool calling. That is verified, and it is also why this is so maddening. Ollama's library page for qwen3.8 lists tools, vision, and thinking as capabilities, with a 256K context window. Nothing is missing. Nothing is misconfigured on your end.
The problem is the request path, not the model, and the two open Ollama issues tracking it make that unusually clear.
What the reports actually show
Two issues on the Ollama repository describe this, from completely different machines, and the pattern in both is the same shape.
The first, opened August 18, 2026, is from someone on macOS 15.7.7 with an M3 Max and 64 GB of RAM running Ollama 0.32.13. They tested qwen3.8:27b-mlx and qwen3.8:27b-mxfp8. The native /api/chat endpoint works. The OpenAI-compatible /v1/chat/completions endpoint works. Streaming works. Tool calling works, returning finish_reason: "tool_calls" with a properly formed function call, and a second turn with the tool result generates a correct final answer.
Then they pointed four separate agent integrations at the same model. Pi, OpenCode, Claude Code, and Hermes. All four hang indefinitely.
The second issue is from an entirely different stack: Ollama 0.32.13 in Docker on ROCm, two AMD RX 6800-class GPUs, 32 GB combined VRAM, running the official qwen3.8:27b tag with num_ctx at 32768. Same story from the other direction. ollama run works, /api/chat works and had been running in production for hours, and /v1/chat/completions for qwen3.6:27b on the very same instance responds normally in about twenty seconds.
/v1/chat/completions for qwen3.8:27b never returns. Not an error, not a timeout message. The connection stays open and no data ever arrives.
Apple Silicon with MLX and AMD with ROCm are about as far apart as two setups get. When both produce the same failure on the same model version, your hardware is not the variable.
That reporter ruled out an unusual amount before filing. Tools present or absent made no difference. Streaming on or off made no difference. Thinking disabled through think: false, through chat_template_kwargs.enable_thinking, and through reasoning_effort: none changed nothing. They forced use_mmap on to rule out a known memory heuristic, confirmed full GPU tensor offload in the logs, and the hang persisted past twelve minutes. They even captured a real client's request through a logging proxy and replayed it byte for byte. Same hang.
Why everyone misdiagnoses this as a tool calling problem
Here's the trap, and it is a good one.
When you run ollama show qwen3.8:27b --modelfile looking for the template, you will find it thin. That is because qwen3.8 ships its chat template inside the GGUF file rather than as a separate template layer in the manifest. I checked the registry manifests for 27b, latest, and 27b-mlx, and none of them carry a template layer.
So the natural conclusion, when your agent hangs and the modelfile looks empty, is that the model has no tool template. That conclusion is wrong. Capability detection reads the GGUF too, which is why the library page correctly lists tools as a capability.
If you are chasing a template that looks missing, you are debugging the wrong thing entirely. The template is there, Ollama can see it, and the failure happens somewhere after that.
This is a different failure from the ordinary "does not support tools" rejection, which is loud, immediate, and tells you exactly what is wrong. Our Ollama tool calling compatibility table covers that one and lists which models genuinely lack the capability. Qwen3.8 is not on that list, and that is the point.
How to tell if this is your bug in about two minutes
Run these in order. The pattern of what passes and what fails identifies it precisely.
First, the native endpoint:
curl -s http://127.0.0.1:11434/api/chat -d '{
"model": "qwen3.8:27b",
"messages": [{"role":"user","content":"Say hello"}],
"stream": false
}'
Then the OpenAI-compatible endpoint with the same content:
curl -s http://127.0.0.1:11434/v1/chat/completions -d '{
"model": "qwen3.8:27b",
"messages": [{"role":"user","content":"Say hello"}],
"stream": false
}'
Then the identical /v1 request against a different model you have pulled, such as qwen3.6:27b.
If the native call returns, the other model returns on /v1, and qwen3.8 on /v1 hangs with no error, you have matched the reported pattern. Note that the macOS report had /v1 working from curl while agents still hung, so a passing /v1 curl does not clear you. If your agent hangs regardless, you are still in the same territory.
If instead you get an immediate error rather than a hang, you have a different problem. A hang and a rejection are not the same failure, and treating them the same is how people lose afternoons. Our agent error decoder sorts the noisier error strings.
What to do right now
Neither issue has a merged fix as of August 20, 2026, so this section is about getting unblocked rather than getting closure.
Switch models for the agent loop. qwen3.6:27b was explicitly confirmed working on /v1 on the same instance where qwen3.8 hangs, which makes it the lowest-friction move available. Keep qwen3.8 for direct API work if you want it.
Point your agent at /api/chat instead of /v1 where the framework allows it. Both reports show the native path behaving correctly, so if your agent supports the Ollama-native format, that route avoids the failing path entirely.
Watch the issues rather than reinstalling. Both reports are on Ollama 0.32.13, which was current when they were filed, so upgrading when a fix lands is the actual resolution. Reinstalling the same version accomplishes nothing.
And do not spend the evening on num_ctx. One reporter had it at 32768 and ruled out context, thinking flags, mmap, and streaming individually. That work is done and published. You do not need to repeat it.
This is the tax nobody quotes on running local models for agents. Not the setup, the setup is fine. It is the week where a model you already validated stops working through one code path on one runtime version, and you are the integration test. If you want agents that keep running while a model provider sorts out a regression, BetterClaw supports 28+ model providers with one-click switching, so a broken model is a dropdown change rather than an evening. Free plan, no credit card, your own keys with no markup on inference.
The pattern worth learning from this one
Qwen3.8 landed with real capability. 256K context, tools, vision, and thinking, and over half a million pulls in its first days on Ollama. It is not a bad model, and the agent frameworks hitting the wall are not badly built either.
What broke is the seam between them. Model, runtime, and framework each shipped on their own schedule, and the failure appeared in the gap where nobody's tests run.
That gap is where most local agent debugging time actually goes, and it does not show up in any benchmark or comparison table. When you evaluate a stack, the question is not which model scores highest. It is how many independently-versioned pieces sit between your agent and a working response, because every seam is a place where next Tuesday's update can quietly stop returning data.
Four seams is a hobby. One is a product.
If you would rather your agents survive a model provider's bad week, start free on BetterClaw. One agent, every feature, no credit card, and 28+ providers behind one interface so switching models takes seconds. Pro is $49 per agent per month and full pricing fits on one page. If you are still weighing local against managed, our local LLM agent hardware guide is the honest version of that trade.
Frequently Asked Questions
Why do qwen3.8 27B tool calls hang in my agent?
Because of a reported request-path failure rather than a model limitation. Qwen3.8 genuinely supports tool calling, and Ollama's library page lists tools, vision, and thinking as capabilities. Two open Ollama issues describe /v1/chat/completions never returning for qwen3.8:27b while ollama run and /api/chat work normally on the same instance.
How does this differ from the "does not support tools" error?
That error is a capability rejection: Ollama checks the model's chat template, finds no tool handling, and refuses immediately with a clear message. This is a hang, meaning the connection opens and no data arrives, in one report for more than twelve minutes. Immediate rejection means switch models. A silent hang means the capability is present and something downstream is not returning.
How do I confirm this is the same bug I am hitting?
Send the same simple message three ways: to /api/chat, to /v1/chat/completions on qwen3.8:27b, and to /v1/chat/completions on a different model you have pulled. If the native call returns and another model returns on /v1 while qwen3.8 hangs without an error, you have matched the reported pattern. One reporter also saw curl succeed on /v1 while agents still hung, so a passing curl does not rule it out.
Is it worth switching models while this is unresolved?
Yes, and it costs almost nothing. qwen3.6:27b was confirmed responding normally on the same endpoint and the same instance where qwen3.8 hangs, so it is a one-line change rather than a migration. Keep qwen3.8 pulled for direct API use if you want it, since the native path works.
Is running local models reliable enough for production agents?
It depends on how many independently-versioned components sit between your agent and a response. Local stacks put a model, a runtime, and a framework in that chain, and this bug appeared in the seam between them rather than in any one piece. If a model regression cannot be allowed to take your agents offline, either keep a tested fallback model configured or run on a platform where switching providers is a settings change.
