Describe the bug
Command Mode is unreliable with some local reasoning-capable models. In my setup, models like qwen3.5:9b and gemma4:12b often fail in a way that looks silent: the model starts reasoning, but the final tool call either never gets executed or gets lost before FluidVoice can use it.
I also found that the reasoning settings in the UI do not behave consistently across providers/models. On my local OpenAI-compatible server, reasoning_effort = none reliably changes the stream into a simpler, working format, but enable_thinking = false does not seem to have the same effect. Some values also appear to be available in FluidVoice but are rejected by the backend.
To Reproduce
Steps to reproduce the behavior:
- Use a local OpenAI-compatible provider.
- Select a reasoning-capable model such as qwen3.5:9b or gemma4:12b.
- Enable Command Mode.
- Try a task that should trigger a tool call, such as checking files or running a terminal command.
- Leave AI streaming enabled.
- Observe that the model may stream reasoning first and then fail to complete the command reliably.
- Change the reasoning settings between reasoning_effort and enable_thinking.
- Observe that the behavior is not consistent across settings.
Expected behavior
FluidVoice should either:
- preserve streamed tool calls even when the model emits reasoning first, or
- map reasoning settings consistently so the selected model behaves correctly and predictably.
Screenshots
Optional.
Environment:
- macOS Version: Tahoe 26.5
- App Version: 1.6.0
- Architecture: Apple Silicon
Additional context
On my setup, reasoning_effort = none is the only setting that reliably makes some models behave in a Granite-like way. enable_thinking did not reliably change the stream behavior. In logs, the raw stream sometimes contains a valid tool call, but Command Mode still ends up with empty content or no usable tool call, which suggests a
streaming/parser issue in FluidVoice rather than only a model quality issue.
Crash Logs
No crash. The app stays alive, but Command Mode fails or appears stuck.
Describe the bug
Command Mode is unreliable with some local reasoning-capable models. In my setup, models like qwen3.5:9b and gemma4:12b often fail in a way that looks silent: the model starts reasoning, but the final tool call either never gets executed or gets lost before FluidVoice can use it.
I also found that the reasoning settings in the UI do not behave consistently across providers/models. On my local OpenAI-compatible server, reasoning_effort = none reliably changes the stream into a simpler, working format, but enable_thinking = false does not seem to have the same effect. Some values also appear to be available in FluidVoice but are rejected by the backend.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
FluidVoice should either:
Screenshots
Optional.
Environment:
Additional context
On my setup, reasoning_effort = none is the only setting that reliably makes some models behave in a Granite-like way. enable_thinking did not reliably change the stream behavior. In logs, the raw stream sometimes contains a valid tool call, but Command Mode still ends up with empty content or no usable tool call, which suggests a
streaming/parser issue in FluidVoice rather than only a model quality issue.
Crash Logs
No crash. The app stays alive, but Command Mode fails or appears stuck.