Problem

With vLLM 0.19, when serving the model:

• Qwen/Qwen3.5-35B-A3B-FP8

using:

• --reasoning-parser qwen3
• --tool-call-parser qwen3_coder

non-streaming tool-call parsing can fail if the model emits XML tool-call markup inside the reasoning region, for example:

<think>
...
<tool_call>
<function=Finish>
<parameter=answer>
204
</parameter>
</function>
</tool_call>
</think>

In this case, the model may have produced a valid tool call, but the OpenAI-compatible response ends up with populated reasoning and empty tool_calls.

Observed model

The issue was observed and reproduced with:

• Qwen/Qwen3.5-35B-A3B-FP8

It may also affect other Qwen3 / Qwen3.5 models that use the same parser combination, but the confirmed reproduction here is specifically on Qwen/Qwen3.5-35B-A3B-FP8.

Why this happens

The issue appears to come from the interaction between the reasoning parser and the tool parser:

1. qwen3_reasoning_parser extracts everything before </think> into reasoning.
2. downstream tool parsing only inspects content.
3. if <tool_call>...</tool_call> remains inside reasoning, it never reaches qwen3_coder.

So the bug is not that vLLM makes Qwen3.5 generate tool calls inside <think>. The bug is that vLLM currently does not recover those tool calls when that output pattern occurs.

Scope

This report is specifically about the non-streaming path, which can break benchmark / agent flows that rely on structured tool_calls being returned.

Proposed fix

I have opened a PR with a minimal parser-side fix here:

• PR: https://github.com/vllm-project/vllm/pull/39055

That patch promotes embedded XML tool-call blocks out of reasoning into content in qwen3_reasoning_parser, so the existing qwen3_coder tool parser can still parse them.

Request

Please consider reviewing and merging the PR if the approach looks acceptable.