Tool call parser scans inside <think> blocks, creating false-positive parse attempts from reasoning content

[shanevcantwell]

Environment

• Linux (Ubuntu)
• LM Studio 0.4.6
• Models: qwen/qwen3.5-35b-a3b, qwen3.5-27b (both reproduce)
• MCP tools connected (webfetch-mcp with web_search/web_fetch)

What is the bug?

LM Studio's tool call parser scans the content inside <think> blocks for tool call patterns (<function=...>, <tool_call>, <tool_call_start|>). When the model reasons about tool calling syntax as prose, the parser interprets those text patterns as actual tool call attempts, which then fail to parse.

This is distinct from #1589 and #827, where <think> tags break tool call output. Here, the parser actively enters the thinking block and finds false positives.

Reproduction

1. Load qwen3.5-35b-a3b with reasoning enabled
2. Connect any MCP tool (e.g., web_search)
3. Give the model a task that causes it to reason about tool calling — e.g., debugging a tool call format issue, or researching how different models handle tool calls
4. The model's thinking block will mention tool call syntax as prose (e.g., "some models use <function=...>, others use <tool_call>")
5. Parser picks up these prose mentions as tool call attempts → parse failure

Observed behavior

The parser treats reasoning-block prose like:

<think>
...LM Studio's parser is treating <tool_call_start|> as raw text instead of
recognizing it as a special token that should trigger tool call parsing...
</think>

as containing actual tool call markers. The </think> boundary is not respected as a parsing firewall.

Recursive trap

This creates a self-referential failure loop:

1. Model reasons about tool call syntax → emits tool-call-like tokens in <think> block
2. Parser finds them → parse fails (they're prose, not well-formed calls)
3. Error fed back to model → model reasons about the parse failure → mentions more tool call syntax
4. Goto 2

The model explicitly recognizes the trap ("I'm getting caught in a loop where my thoughts about tool calling syntax are being interpreted as actual tool call markers") but cannot escape it — reasoning about the problem reproduces it.

Multiple format matching widens false-positive surface

The parser appears to scan for multiple tool call formats simultaneously (<tool_call>, <function=...>, <tool_call_start|>). When the model discusses format differences between models (e.g., Qwen's <tool_call> vs LFM2.5's <tool_call_start|> vs <function=...>), multiple patterns trigger in a single thinking block.

Expected behavior

The </think> boundary should be a firewall — everything between <think> and </think> should be treated as reasoning text, not scanned for tool call patterns. Ollama handles this correctly by stripping reasoning tags before tool call parsing (as noted in #1589).

Workaround

Disabling reasoning via {%- set enable_thinking = false %} in the prompt template eliminates the issue. 20+ consecutive tool calls succeed with reasoning disabled.

Evidence

Parse failure output shows reasoning content flowing into the parsed "tool call":

Failed to parse tool call: Expected "<parameter=", but got "`, `<parame" at index 14.

<tool_call>, some use `<tool_call_start|>`, some use `<function=...>`)
4. LM Studio's parser may not recognize all token formats Let me search
for more specific information... </think> <tool_call>
<function=web_search> <parameter=limit> 10 </parameter>
<parameter=query> LM Studio "reasoning" "tool call" parsing bug scan
thought block </parameter> </function> </tool_call>

The reasoning prose and the actual tool call are concatenated in the parser's view — the </think> boundary was not used as a delimiter.

Related issues

• [qwen3.5-35b-a3b / qwen3.5-122b-a10b] Qwen3.5 reasoning tags <think> break tool JSON output for web search / plugins #1589 — <think> tags adjacent to JSON break parsing (different: that's about output format, this is about false positives inside thinking blocks)
• tool parser cannot identify the tool calls of qwen3's response with thinking tags #827 — Qwen3 thinking tags prevent tool call identification (same family, different manifestation)
• Parsing error for tool call with gpt-oss:20b in Harmony format #942 — gpt-oss Harmony format parsing (related: Harmony tokens may also trigger false positives when present in reasoning)

[shanevcantwell]

Extended analysis: mechanism, repro, and cross-ecosystem evidence

Minimal repro

curl http://localhost:1234/v1/chat/completions \
  -H "Content-Type: application/json" -d '{
  "model": "qwen3.5-35b-a3b",
  "messages": [
    {"role": "system", "content": "Answer in exactly 3 bullet points. No explanation needed."},
    {"role": "user", "content": "Name 3 XML tags that LLMs use for reasoning. Include the angle brackets in your answer."}
  ],
  "temperature": 0.6, "max_tokens": 4000
}'

The model reasons about <thought>, <reasoning>, <step> — writing angle brackets in its thinking block. The parser pattern-matches on these and repeatedly re-enters reasoning mode. Developer logs show 30+ "Start thinking..." entries in a single generation:

Non-deterministic across runs with identical inputs:

• Run A: Parser exits thinking prematurely mid-sentence — content contains reasoning spillover, reasoning_content truncated at 613 chars
• Run B: Parser never exits thinking — content = "\n\n* " (effectively empty), reasoning_content = 8,043 chars, finish_reason: "stop"

This is the mechanism behind #1602: when the parser stays in reasoning mode for the entire generation, all output lands in reasoning_content and content comes back empty.

Mechanism: no phase state tracking

The parser has no concept of "we already left thinking mode." Every angle-bracket pattern in the body can flip it back into reasoning. The </think> boundary is not a one-way gate.

The split is server-side — it affects all API consumers, not just the chat UI. Any framework checking finish_reason == "stop" as a success signal will silently accept an empty response.

Toggle complementarity with #1589

The "separate reasoning_content and content" toggle creates complementary failure modes — neither position is safe:

	Toggle OFF	Toggle ON
<think> blocks in conversation history	Yes (~5,600 chars over 20 blocks)	No
Content field contaminated	Yes (reasoning in content)	Sometimes (phase confusion)
Tool call JSON integrity	Broken (#1589)	Intact
Empty content risk	Low	High (#1602)
Multi-turn behavioral impact	False memory → stagnation loop	Clean

A/B test: Same model, same task (categorize 13 files), same hardware. Toggle OFF: 0/13 files moved, model enters verification loop with false memory of prior actions. Toggle ON: 13/13 files moved, clean completion.

Harmony parser architecture

LM Studio's Runtime settings show two components: GGUF Runtime (llama.cpp) for generation and Harmony (Windows) v0.3.6 for parsing. A llama.cpp collaborator confirmed LM Studio rolled their own parser and does not use llama.cpp's implementation.

Implementation	Language	Auditable
openai/harmony (reference)	Rust + PyO3	Yes (Apache 2.0)
llama.cpp #15181	C++	Yes (MIT)
LM Studio Harmony v0.3.6	Unknown	No

All bugs in this chain (#453, #827, #942, #1528, #1541, #1589, #1592, #1593) are in the third, closed-source implementation.

Cross-ecosystem evidence

Continue (VS Code code assistant) has an independent parser for system message tools that exhibits the same context-free pattern-matching flaw:

• Continue #11070 — Parser intercepts quoted tool syntax as real tool calls (same class as this bug)
• Continue #10783 / #10785 — Reasoning leaks into apply/edit and terminal output (upstream contamination from this bug; Continue's adapter correctly trusts the API contract)
• Testing showed Continue's parser normalizes whitespace before matching — spaced-out letters (T O O L _ N A M E :) still trigger interception. Not naive regex.

Raw llama.cpp also affected at the model layer: a user confirmed that tool-call-inside-reasoning occurs with the raw llama-server binary (no LM Studio). This is the model placing <tool_call> inside <think> — a training/template concern, not a parser bug. But it means the problem exists at three independent layers: model, LM Studio parser, and downstream harness parsers.

Community analysis

r/LocalLLaMA discussion connecting 13 months of isolated reports (#453 → #827 → #942 → #1592). 27K views, 107 upvotes, 45 comments.

[shanevcantwell]

llama.cpp just merged an automatic parser generator ggml-org/llama.cpp#18675 that extracts parsing logic directly from Jinja templates. It's phase-aware by construction. Reasoning/tools/content boundaries come from the template definition rather than stream scanning, which is the exact root cause here.

It also uses aldehir's PEG parser as the unified framework. Qwen 3.5 fix is specifically mentioned. "[A]rbitrary order of optional parameters" resolves tool call parsing issues like this and issue #1602

[tylerlucas]

I'm having the same issue: https://www.reddit.com/r/LocalLLaMA/comments/1rjhy83/comment/o90r3hn/

[will-lms]

Got a repro of poor behavior. Will look into resolving. Thanks for the report!