Qwen 3.5 27B's Ollama support just got patched again. Trust it yet?

I spent part of this week reading a GitHub issue that is, on its face, boring: someone’s tool calls stopped working. But the details are the whole story. Qwen 3.5 shipped February 16 as a genuinely strong open-weight release, Apache 2.0, a 397-billion-parameter flagship that only activates 17 billion per token. Eleven days later, an Ollama user filed issue #14493: “Qwen 3.5 27B: Tool calling completely non-functional and repetition penalties silently ignored.” Ollama was sending tool calls in the Qwen 3 Hermes-style JSON format. The model was trained on Qwen3-Coder’s XML format. Six concrete mismatches, by the reporter’s count, between what Ollama sent and what the model expected.

That was February. On July 11, Ollama shipped v0.32.0, and one line in the changelog reads: “select the qwen3.5 parser and renderer for Qwen3.5/Next.” Five months after the model landed, the team is still deciding which template pipeline actually serves it.

What “Ollama supports this model” actually promises

Here’s the gap that matters for anyone choosing a model this week. A serving engine’s library page that lists a model as supported means the weights load and the model produces tokens. It does not mean the tool-calling format is wired correctly, that sampling parameters like repeat_penalty or presence_penalty are implemented for that architecture, or that a multi-turn agent loop with thinking and tool calls survives more than one round trip without corruption. The February issue found all three problems at once: a silently discarded penalty parameter, a wrong tool-call template, and an unclosed thinking tag that broke every subsequent turn in the conversation.

None of that shows up in a quick chat test. It shows up when an agent is three steps into a task, calls a tool, and the tool call never fires because the model wrapped it in a format the parser was not built to catch. An evaluation that stops at “I asked it a few questions and it answered them” has tested exactly the part of the stack that was never broken.

That GPU-pricing number is not about Qwen 3.5 directly, but it is the backdrop worth keeping in view: H100 rental averaged $3.37 an hour across 47 providers this week, still climbing. A model that looks cheap to self-host because it fits the card on hand is not actually cheap if half the agent’s tool calls fail silently and a week goes into debugging a parser instead of shipping.

Why the library listing feels like the finish line

I get why teams stop at “it’s in Ollama’s model library, ship it.” Checking that a model loads and answers is fast, and it feels like due diligence. Checking that its tool-calling format matches what the model was actually trained on requires reading a model card closely enough to know Qwen 3.5 wants XML-style function calls, not the JSON style its own predecessor used. Almost nobody does that comparison by hand. They find out when an agent stalls in production and someone spends an afternoon in a GitHub issue thread instead of the model card.

A second issue, #14745 filed in March, showed the 9B variant of Qwen 3.5 intermittently printing tool-call syntax as plain text instead of executing it, described by the reporter as happening “fairly often” and halting whatever the agent was doing. That one got a fix. The July 11 patch suggests the underlying routing question, which template pipeline actually serves this model family correctly, was still being resolved five months later.

What a mature integration looks like by comparison

GPT-OSS is the useful contrast here, not because it is a better model in every sense, but because its Ollama, vLLM, and llama.cpp support has had time to settle. Its VRAM math is now boring in the good way: the 20B variant needs about 12GB of weights at Q4_K_M, roughly 15.5GB total with KV cache at a 32K context, and around 21.7GB at the full 131K context on a 16GB-class card. The 120B variant needs about 60GB at MXFP4 and fits one 80GB H100. Nobody is filing GitHub issues in July about GPT-OSS’s tool-call format being wrong, because that fight already happened and got resolved.

A serving engine listing a model as supported is a different claim than that model's tool calling being verified correct, and the gap can run for months before anyone outside a GitHub thread notices.

The five-minute check before deploying either one

None of this means avoid Qwen 3.5. Its benchmarks are genuinely strong for an open-weight model this size, and Apache 2.0 makes it usable without a licensing conversation. It means treating “listed as supported” as the start of an evaluation, not the end of one. Before putting any open-weight model behind an agent that calls tools, search the serving engine’s issue tracker for the model’s name plus “tool” or “function calling.” Five minutes of reading is usually enough to tell whether a team is the first to hit a bug or the hundredth to find the workaround already posted. Then run a real agentic test, 20 to 30 examples that actually call tools across multiple turns, rather than trusting a chat-only smoke test. A model that answers questions correctly and a model whose tool calls survive a real agent loop are not the same claim, and this week’s patch is a reminder that even five months after release, the second one is still being worked out in public.