LocalAI version:
4.5.6
Environment, CPU architecture, OS, and Version:
Linux marvin 7.0.14-arch1-1 #1 SMP PREEMPT_DYNAMIC Sat, 27 Jun 2026 16:15:10 +0000 x86_64 GNU/Linux
Describe the bug
Setting reasoning_effort: none without explicitly setting reasoning.disable does not have the desired effect.
To Reproduce
Set reasoning_effort: none in a model.yaml without explicitly setting any value for reasoning.disable.
Make the first request to a model with no reasoning effort or explicit reasoning_effort = "none" param in the request, and reasoning.disable gets set to true.
This would work as intended, except that it still needs to probe for the media marker, which then updates reasoning.disable to true in memory, and is returned with that value for the next request. The probe does not actually change this value. The post-probe UpdateModelConfig saves the result from ApplyReasoningEffort, which should not be connected.
One the next request, the reasoning effort gets passed through, but now reasoning.disable is set to true (as if set by the operator) so the reasoning_effort param has no effect.
Expected behavior
If I set reasoning_effort: none in model.yaml and do not set any value for reasoning.disable, I expect none to be the default, but to retain the ability to request extra thinking via the reasoning_effort request param.
LocalAI version:
4.5.6
Environment, CPU architecture, OS, and Version:
Linux marvin 7.0.14-arch1-1 #1 SMP PREEMPT_DYNAMIC Sat, 27 Jun 2026 16:15:10 +0000 x86_64 GNU/Linux
Describe the bug
Setting
reasoning_effort: nonewithout explicitly settingreasoning.disabledoes not have the desired effect.To Reproduce
Set
reasoning_effort: nonein a model.yaml without explicitly setting any value forreasoning.disable.Make the first request to a model with no reasoning effort or explicit
reasoning_effort = "none"param in the request, andreasoning.disablegets set to true.This would work as intended, except that it still needs to probe for the media marker, which then updates
reasoning.disableto true in memory, and is returned with that value for the next request. The probe does not actually change this value. The post-probe UpdateModelConfig saves the result from ApplyReasoningEffort, which should not be connected.One the next request, the reasoning effort gets passed through, but now
reasoning.disableis set to true (as if set by the operator) so thereasoning_effortparam has no effect.Expected behavior
If I set reasoning_effort: none in model.yaml and do not set any value for reasoning.disable, I expect none to be the default, but to retain the ability to request extra thinking via the reasoning_effort request param.