Describe the issue
The Qwen3 model natively supports disabling its internal block generation via API parameters like "reasoning": false or "chat_template_kwargs": {"enable_thinking": false}. While these parameters work on Ollama and Azure deployments, Foundry Local's /v1/chat/completions API completely strips or ignores them. Passing reasoning disable flags, tuning sampler parameters (e.g., Temperature 0.7, Presence Penalty 1.5), or injecting prompt workarounds (/no_think or empty blocks) all fail. The API passes the request to the runtime in its default state, causing the model to generate massive (2,000+ token) blocks that severely delay response times (up to 4.5 minutes for simple queries).
(Impact: Developers cannot programmatically disable reasoning mode for fast agentic execution on Foundry Local.)
To reproduce
1. Load a Qwen3 chat model (we tested qwen3.5-4b) on Foundry Local.
2. Send a /v1/chat/completions request with either "reasoning": false or "chat_template_kwargs": {"enable_thinking": false} set.
3. Compare against the same model/parameters on Ollama or Azure; reasoning is suppressed there.
4. On Foundry Local, observe the model still emitting a large ... block (2,000+ tokens observed) regardless of the flag.
5. Additional things we tried that also failed: tuning sampler parameters (Temperature 0.7, Presence Penalty 1.5) to discourage long reasoning, and prompt-level workarounds (/no_think suffix, injecting an empty block into the prompt). None suppressed the behavior.
(Impact measured: simple queries that should return in a few seconds instead took up to 4.5 minutes due to the unsuppressable reasoning pass.)
Urgency
Medium, not a crash, but blocks fast agentic use cases; I had to add a 20s hard timeout wrapper as a workaround.
Platform and architecture
Windows X64
OS Version
Windows 11
Installation type
Released package/binary
Foundry Local version
0.10.2
API or surface area
REST API
Hardware acceleration/backend
CPU
Backend/runtime version
No response
Describe the issue
The Qwen3 model natively supports disabling its internal block generation via API parameters like "reasoning": false or "chat_template_kwargs": {"enable_thinking": false}. While these parameters work on Ollama and Azure deployments, Foundry Local's /v1/chat/completions API completely strips or ignores them. Passing reasoning disable flags, tuning sampler parameters (e.g., Temperature 0.7, Presence Penalty 1.5), or injecting prompt workarounds (/no_think or empty blocks) all fail. The API passes the request to the runtime in its default state, causing the model to generate massive (2,000+ token) blocks that severely delay response times (up to 4.5 minutes for simple queries).
(Impact: Developers cannot programmatically disable reasoning mode for fast agentic execution on Foundry Local.)
To reproduce
1. Load a Qwen3 chat model (we tested qwen3.5-4b) on Foundry Local.
2. Send a /v1/chat/completions request with either "reasoning": false or "chat_template_kwargs": {"enable_thinking": false} set.
3. Compare against the same model/parameters on Ollama or Azure; reasoning is suppressed there.
4. On Foundry Local, observe the model still emitting a large ... block (2,000+ tokens observed) regardless of the flag.
5. Additional things we tried that also failed: tuning sampler parameters (Temperature 0.7, Presence Penalty 1.5) to discourage long reasoning, and prompt-level workarounds (/no_think suffix, injecting an empty block into the prompt). None suppressed the behavior.
(Impact measured: simple queries that should return in a few seconds instead took up to 4.5 minutes due to the unsuppressable reasoning pass.)
Urgency
Medium, not a crash, but blocks fast agentic use cases; I had to add a 20s hard timeout wrapper as a workaround.
Platform and architecture
Windows X64
OS Version
Windows 11
Installation type
Released package/binary
Foundry Local version
0.10.2
API or surface area
REST API
Hardware acceleration/backend
CPU
Backend/runtime version
No response