I have searched for all existing open AND closed issues and discussions for similar requests. I have found none that is comparable to my request.
Verify Feature Scope
I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions.
Problem Description
Qwen released their new gen model series Qwen3.5, which support use args "chat_template_kwargs": {"enable_thinking": false} to switch thinking model in single model.
Desired Solution you'd like
Will open-webui have a plan to support this kind of model with a toggle button in chat UI?
Now I use some tricks to switch thinking/non-thing modes.
The single model which can be toggled with args may become a new standard for other models.
Alternatives Considered
No response
Additional Context
No response
Originally created by @krpr on GitHub (Feb 26, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/21893
### Check Existing Issues
- [x] I have searched for all existing **open AND closed** issues and discussions for similar requests. I have found none that is comparable to my request.
### Verify Feature Scope
- [x] I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions.
### Problem Description
Qwen released their new gen model series Qwen3.5, which support use args ```"chat_template_kwargs": {"enable_thinking": false}``` to switch thinking model in single model.
### Desired Solution you'd like
Will open-webui have a plan to support this kind of model with a toggle button in chat UI?
Now I use some tricks to switch thinking/non-thing modes.
The single model which can be toggled with args may become a new standard for other models.
### Alternatives Considered
_No response_
### Additional Context
_No response_
Search for duplicates there's been 5 exactly the same questions in the last few days
Also you can build it yourself using a toggle filter plugin
<!-- gh-comment-id:3964648755 -->
@Classic298 commented on GitHub (Feb 26, 2026):
Search for duplicates there's been 5 exactly the same questions in the last few days
Also you can build it yourself using a toggle filter plugin
@Classic298 The problem is, those are not applied when using the API. They only get applied when using the Web UI.
I ran into this same problem while using Minimax-M2.5 and Kimi-K2.5. All these new models rely on chat_template_kwargs.
<!-- gh-comment-id:4015314506 -->
@gaby commented on GitHub (Mar 7, 2026):
@Classic298 The problem is, those are not applied when using the API. They only get applied when using the Web UI.
I ran into this same problem while using Minimax-M2.5 and Kimi-K2.5. All these new models rely on `chat_template_kwargs`.
@gaby i don't understand. Inlet() part of filter IS applied when going via Api.
Also when going via api wouldn't it be better to have 1 model without thinking and the other model with thinking? Would be much easier than having to specify thinking Parameter at request time all of the time
<!-- gh-comment-id:4016065828 -->
@Classic298 commented on GitHub (Mar 7, 2026):
@gaby i don't understand. Inlet() part of filter IS applied when going via Api.
Also when going via api wouldn't it be better to have 1 model without thinking and the other model with thinking? Would be much easier than having to specify thinking Parameter at request time all of the time
@Classic298 Maybe it was fixed, it didn't used to be applied during API calls.
Yes our plan is to have the base model then add a workspace model with reasoning tweaked.
<!-- gh-comment-id:4016679848 -->
@gaby commented on GitHub (Mar 7, 2026):
@Classic298 Maybe it was fixed, it didn't used to be applied during API calls.
Yes our plan is to have the base model then add a workspace model with reasoning tweaked.
but for a thinking filter you only need inlet anyways
<!-- gh-comment-id:4016686679 -->
@Classic298 commented on GitHub (Mar 7, 2026):
Inlet() is always applied outlet() is not
but for a thinking filter you only need inlet anyways
Also when going via api wouldn't it be better to have 1 model without thinking and the other model with thinking? Would be much easier than having to specify thinking Parameter at request time all of the time
Nothing would be easier than a simple toggle in the prompt box to turn it on or off. It should be an option. Switching models is way more heavyweight than just toggling a switch.
<!-- gh-comment-id:4020175500 -->
@rickross commented on GitHub (Mar 8, 2026):
> Also when going via api wouldn't it be better to have 1 model without thinking and the other model with thinking? Would be much easier than having to specify thinking Parameter at request time all of the time
Nothing would be easier than a simple toggle in the prompt box to turn it on or off. It should be an option. Switching models is way more heavyweight than just toggling a switch.
Search for duplicates there's been 5 exactly the same questions in the last few days
In fact, I did search, and every answer is so complicated. It's totally unclear what to do? Why isn't there just a simple way to add either a correct version of this chat_template_kwargs or to toggle enable_thinking on and off? Learning to write a plugin for the OpenWebUI framework is way harder than adjusting/editing something in the prompt template, but there's no clear way to do that.
And if the question has come up five times in the last few days, isn't that a pretty serious clue that it's something that needs to be addressed?
<!-- gh-comment-id:4020179173 -->
@rickross commented on GitHub (Mar 8, 2026):
> Search for duplicates there's been 5 exactly the same questions in the last few days
In fact, I did search, and every answer is so complicated. It's totally unclear what to do? Why isn't there just a simple way to add either a correct version of this chat_template_kwargs or to toggle enable_thinking on and off? Learning to write a plugin for the OpenWebUI framework is way harder than adjusting/editing something in the prompt template, but there's no clear way to do that.
And if the question has come up five times in the last few days, isn't that a pretty serious clue that it's something that needs to be addressed?
I agree with @rickross I've been using Open-WebUI for over a year and still don't know what to do exactly.
This should be an extra field in the UI config for the model.
<!-- gh-comment-id:4020183428 -->
@gaby commented on GitHub (Mar 8, 2026):
I agree with @rickross I've been using Open-WebUI for over a year and still don't know what to do exactly.
This should be an extra field in the UI config for the model.
a simple toggle in the prompt box to turn it on or off
<!-- gh-comment-id:4020185946 -->
@Classic298 commented on GitHub (Mar 8, 2026):
@rickross as i said above, use a filter
a filter allows exactly this
> a simple toggle in the prompt box to turn it on or off
Why isn't there just a simple way to add either a correct version of this chat_template_kwargs or to toggle enable_thinking on and off?
There is. It's called filter
<!-- gh-comment-id:4020186289 -->
@Classic298 commented on GitHub (Mar 8, 2026):
> Why isn't there just a simple way to add either a correct version of this chat_template_kwargs or to toggle enable_thinking on and off?
There is. It's called filter
Learning to write a plugin for the OpenWebUI framework is way harder than adjusting/editing something in the prompt template, but there's no clear way to do that.
Give the AI the filter docs and build one yourself, it's a single prompt. You dont need to learn anything
It's a 20 lines filter (at max)
Alternatively: search on openwebui.com there are some thinking filters like this already
<!-- gh-comment-id:4020187033 -->
@Classic298 commented on GitHub (Mar 8, 2026):
> Learning to write a plugin for the OpenWebUI framework is way harder than adjusting/editing something in the prompt template, but there's no clear way to do that.
Give the AI the filter docs and build one yourself, it's a single prompt. You dont need to learn anything
It's a 20 lines filter (at max)
Alternatively: search on openwebui.com there are some thinking filters like this already
And if the question has come up five times in the last few days, isn't that a pretty serious clue that it's something that needs to be addressed?
No because a builtin toggle directly from Open WebUI makes no sense here!
Different inference providers require different thinking parameters, name their body parameters differently - different models have different thinking options
This is something the plugin system was LITERALLY made for and the toggle filters were literally created for (even the example in the docs is for a thinking toggle filter example)
<!-- gh-comment-id:4020189811 -->
@Classic298 commented on GitHub (Mar 8, 2026):
> And if the question has come up five times in the last few days, isn't that a pretty serious clue that it's something that needs to be addressed?
No because a builtin toggle directly from Open WebUI makes no sense here!
**Different inference providers require different thinking parameters, name their body parameters differently - different models have different thinking options**
This is something the plugin system was LITERALLY made for and the toggle filters were literally created for (even the example in the docs is for a thinking toggle filter example)
Give the AI the filter docs and build one yourself, it's a single prompt. You dont need to learn anything It's a 20 lines filter (at max)
Alternatively: search on openwebui.com there are some thinking filters like this already
Look, I downloaded a Docker image to run OpenWebUI. I didn't clone the Git repo, and I don't want to learn to be an OpenWebUI developer. I'm just a user asking a reasonable question. And apparently there are several others who have the same problem. So why not just be responsive to users and make it easy? What's the upside of insisting that everybody has to learn to write filters?
<!-- gh-comment-id:4020192166 -->
@rickross commented on GitHub (Mar 8, 2026):
> Give the AI the filter docs and build one yourself, it's a single prompt. You dont need to learn anything It's a 20 lines filter (at max)
>
> Alternatively: search on openwebui.com there are some thinking filters like this already
Look, I downloaded a Docker image to run OpenWebUI. I didn't clone the Git repo, and I don't want to learn to be an OpenWebUI developer. I'm just a user asking a reasonable question. And apparently there are several others who have the same problem. So why not just be responsive to users and make it easy? What's the upside of insisting that everybody has to learn to write filters?
@rickross you dont need to clone the git repo to develop a filter.
its a single prompt
Look, i will even do it for you............................... give me 10 minutes......................................
<!-- gh-comment-id:4020194209 -->
@Classic298 commented on GitHub (Mar 8, 2026):
@rickross you dont need to clone the git repo to develop a filter.
its a single prompt
Look, i will even do it for you............................... give me 10 minutes......................................
<!-- gh-comment-id:4020195434 -->
@Classic298 commented on GitHub (Mar 8, 2026):
well no i won't do it for you
i found this in the community
https://openwebui.com/posts/thinking_toggle_one_click_reasoning_control_for_ll_bb3f66ad
use this
<!-- gh-comment-id:4020196999 -->
@Classic298 commented on GitHub (Mar 8, 2026):
or this
https://openwebui.com/posts/qwen_3_disable_thinking_toggle_v2_305023ed
@Classic298 Why do i have to login/create an account to see a filter?
This stuff should be in the docs.
<!-- gh-comment-id:4020197713 -->
@gaby commented on GitHub (Mar 8, 2026):
@Classic298 Why do i have to login/create an account to see a filter?
This stuff should be in the docs.
<!-- gh-comment-id:4020198455 -->
@Classic298 commented on GitHub (Mar 8, 2026):
@gaby this is in the docs. https://docs.openwebui.com/features/extensibility/plugin/functions/filter
If you just give an AI the Filter docs page it is able to one-shot build a thinking filter for you
<!-- gh-comment-id:4020199196 -->
@Classic298 commented on GitHub (Mar 8, 2026):
If you just give an AI the Filter docs page it is able to one-shot build a thinking filter for you
I don't want/need users to have to decide wether they have to enable a toggle or not. I just want this to be transparent to users.
Why are filters/functions now behind a Login wall? They used to be public.
<!-- gh-comment-id:4020204764 -->
@gaby commented on GitHub (Mar 8, 2026):
I don't want/need users to have to decide wether they have to enable a toggle or not. I just want this to be transparent to users.
Why are filters/functions now behind a Login wall? They used to be public.
@gaby i dont understand? the whole point of this discussion is to introduce a chat-sided toggle to individually control the thinking ON or OFF.
Why do you now say you dont want users to decide the thinking?
<!-- gh-comment-id:4020209180 -->
@Classic298 commented on GitHub (Mar 8, 2026):
@gaby i dont understand? the whole point of this discussion is to introduce a chat-sided toggle to individually control the thinking ON or OFF.
Why do you now say you dont want users to decide the thinking?
I just want the required field added with each request, not a toggle in the Web UI.
<!-- gh-comment-id:4020216794 -->
@gaby commented on GitHub (Mar 8, 2026):
I'm making two models:
- qwen3.5
- qwen3.5-instant
I just want the required field added with each request, not a toggle in the Web UI.
Ok in that case, why not use the Advanced Parameters of the model? you can configure thinking levels there right in the UI
Or, if that doesn't work because the inference engine/inference provider is looking for a different thinking parameter, add it using a filter
filter inlet() and make it so that your qwen3.5 model gets thinking parameter added to the request body and the qwen3.5-instant does not
problem solved
<!-- gh-comment-id:4020218935 -->
@Classic298 commented on GitHub (Mar 8, 2026):
Ok in that case, why not use the Advanced Parameters of the model? you can configure thinking levels there right in the UI
Or, if that doesn't work because the inference engine/inference provider is looking for a different thinking parameter, add it using a filter
filter inlet() and make it so that your qwen3.5 model gets thinking parameter added to the request body and the qwen3.5-instant does not
problem solved
@Classic298 With these new models the advanced parameters do not work. Models like kimi-k2.5, glm-5, minimax-m2.5, and qwen3.5 require the following in extra_body:
Setting in Advanced Parameters the thinking, or reasoning effort fields has no effect.
<!-- gh-comment-id:4020224569 -->
@gaby commented on GitHub (Mar 8, 2026):
@Classic298 With these new models the advanced parameters do not work. Models like kimi-k2.5, glm-5, minimax-m2.5, and qwen3.5 require the following in `extra_body`:
`"chat_template_kwargs": {"enable_thinking": false}`
Setting in Advanced Parameters the thinking, or reasoning effort fields has no effect.
add custom param with name chat_template_kwargs and value {"enable_thinking": true}
that should already work
<!-- gh-comment-id:4020231527 -->
@Classic298 commented on GitHub (Mar 8, 2026):
@gaby open the model in the UI
expand the advanced parameters section
scroll down
click on add custom parameter
add custom param with name `chat_template_kwargs` and value {"enable_thinking": true}
that should already work
I can test again tomorrow, but as of Friday it wasn't working with latest Open-WebUI and vLLM 0.17.0-rc
Will report back
<!-- gh-comment-id:4020239712 -->
@gaby commented on GitHub (Mar 8, 2026):
It does not, the `chat_template_kwargs` has to be inside the `extra_body`.
https://huggingface.co/Qwen/Qwen3.5-35B-A3B#instruct-or-non-thinking-mode
I can test again tomorrow, but as of Friday it wasn't working with latest Open-WebUI and vLLM 0.17.0-rc
Will report back
and if that doesn't work for you (but it absolutely should work because custom parameters are added and merged into the model request and sent to the model provider)
then here is an example filter that also does the same thing
Expample filter
"""
title: Thinking Mode Filter
author: Classic298
version: 0.2.0
description: Injects chat_template_kwargs to control thinking mode for a list of defined models.
"""
from pydantic import BaseModel, Field
from typing import Optional
class Filter:
class Valves(BaseModel):
thinking_model_ids: str = Field(
default="qwen3.5, kimi-k2.5, glm-5, minimax-m2.5",
description="Comma-separated list of model IDs that should have thinking enabled. All other models this filter is attached to will have thinking disabled.",
)
def __init__(self):
self.valves = self.Valves()
def inlet(self, body: dict, __user__: Optional[dict] = None) -> dict:
model_id = body.get("model", "")
thinking_ids = {
mid.strip() for mid in self.valves.thinking_model_ids.split(",") if mid.strip()
}
enable_thinking = model_id in thinking_ids
body["chat_template_kwargs"] = {"enable_thinking": enable_thinking}
return body
<!-- gh-comment-id:4020240874 -->
@Classic298 commented on GitHub (Mar 8, 2026):
and if that doesn't work for you (but it absolutely should work because custom parameters are added and merged into the model request and sent to the model provider)
then here is an example filter that also does the same thing
<details>
<summary>Expample filter</summary>
```
"""
title: Thinking Mode Filter
author: Classic298
version: 0.2.0
description: Injects chat_template_kwargs to control thinking mode for a list of defined models.
"""
from pydantic import BaseModel, Field
from typing import Optional
class Filter:
class Valves(BaseModel):
thinking_model_ids: str = Field(
default="qwen3.5, kimi-k2.5, glm-5, minimax-m2.5",
description="Comma-separated list of model IDs that should have thinking enabled. All other models this filter is attached to will have thinking disabled.",
)
def __init__(self):
self.valves = self.Valves()
def inlet(self, body: dict, __user__: Optional[dict] = None) -> dict:
model_id = body.get("model", "")
thinking_ids = {
mid.strip() for mid in self.valves.thinking_model_ids.split(",") if mid.strip()
}
enable_thinking = model_id in thinking_ids
body["chat_template_kwargs"] = {"enable_thinking": enable_thinking}
return body
```
</details>
@gaby ok in that case try the filter i posted here it injects into extra_body
<!-- gh-comment-id:4020243164 -->
@Classic298 commented on GitHub (Mar 8, 2026):
@gaby ok in that case try the filter i posted here it injects into extra_body
PS: @gaby did you try the advanced parameters? whatever you add there also should get added to extra_body - did you try it?
Because i think there is a misunderstanding on your end.
extra_body is not a JSON field in the HTTP request, it's a parameter of the OpenAI Python SDK client, which merges its contents into the top-level request body before sending over the wire.
<!-- gh-comment-id:4020245556 -->
@Classic298 commented on GitHub (Mar 8, 2026):
PS: @gaby did you try the advanced parameters? whatever you add there also should get added to extra_body - did you try it?
Because i think there is a misunderstanding on your end.
extra_body is not a JSON field in the HTTP request, it's a parameter of the OpenAI Python SDK client, which merges its contents into the top-level request body before sending over the wire.
Ok in that case, why not use the Advanced Parameters of the model? you can configure thinking levels there right in the UI
First thing It tried, but the Open WebUI custom-param widget is stringifying the nested JSON.
chat_template_kwargs: "{"enable_thinking": false}"
<!-- gh-comment-id:4020268771 -->
@rickross commented on GitHub (Mar 8, 2026):
> Ok in that case, why not use the Advanced Parameters of the model? you can configure thinking levels there right in the UI
First thing It tried, but the Open WebUI custom-param widget is stringifying the nested JSON.
chat_template_kwargs: "{\"enable_thinking\": false}"
@rickross Good catch on the stringification — but the backend already handles that. Custom parameter values that are JSON strings are automatically parsed back into objects before being merged into the request body (payload.py L96-103). So even though the UI shows it as a string, the actual HTTP request sent to your inference engine will have it as a proper nested object:
So custom parameters should work for this use case. If it doesn't, something else may be going on — would be great to see the actual request body being sent (enable DEBUG logging).
Alternatively, the filter I posted above also works and gives you more control.
<!-- gh-comment-id:4020287749 -->
@Classic298 commented on GitHub (Mar 8, 2026):
@rickross Good catch on the stringification — but the backend already handles that. Custom parameter values that are JSON strings are automatically parsed back into objects before being merged into the request body ([payload.py L96-103](https://github.com/open-webui/open-webui/blob/dev/backend/open_webui/utils/payload.py#L96-L103)). So even though the UI shows it as a string, the actual HTTP request sent to your inference engine will have it as a proper nested object:
```json
{
"model": "qwen3.5",
"messages": [...],
"chat_template_kwargs": {"enable_thinking": false}
}
```
So custom parameters should work for this use case. If it doesn't, something else may be going on — would be great to see the actual request body being sent (enable DEBUG logging).
Alternatively, the filter I posted above also works and gives you more control.
<!-- gh-comment-id:4027688417 -->
@gaby commented on GitHub (Mar 9, 2026):
@Classic298 I can confirm that adding a custom parameter with:
- key: `chat_template_kwargs`
- value: `{"enable_thinking": false}`
Solved the issue.
I got other issues now, but there's a ticket for those already. See https://github.com/open-webui/open-webui/discussions/22230#discussioncomment-16010991
I use LM Studio as backend and this method still not working for me, qwen3.5 still in thinking mode.
<!-- gh-comment-id:4031519374 -->
@kukalikuk commented on GitHub (Mar 10, 2026):
> [@Classic298](https://github.com/Classic298) I can confirm that adding a custom parameter with:
>
> * key: `chat_template_kwargs`
> * value: `{"enable_thinking": false}`
>
> Solved the issue.
>
> I got other issues now, but there's a ticket for those already. See [#22230 (reply in thread)](https://github.com/open-webui/open-webui/discussions/22230#discussioncomment-16010991)
I use LM Studio as backend and this method still not working for me, qwen3.5 still in thinking mode.
@kukalikuk did you try the filter above? does lmstudio require other parameters?
<!-- gh-comment-id:4031607603 -->
@Classic298 commented on GitHub (Mar 10, 2026):
@kukalikuk did you try the filter above? does lmstudio require other parameters?
@kukalikuk did you try the filter above? does lmstudio require other parameters?
I tried so many filter and function from openwebui and gemini made. All failed. The only thing that worked is injecting {%- set enable_thinking = false -%} as first line in jinja template in LM Studio. But that means turning of thinking mode completely for all api call to that model.
I also tried adding that kwargs into advance parameter into chat control (qwen3.5 still thinking) and also in model advance parameter (qwen3.5 keep thinking)
<!-- gh-comment-id:4031687312 -->
@kukalikuk commented on GitHub (Mar 10, 2026):
> [@kukalikuk](https://github.com/kukalikuk) did you try the filter above? does lmstudio require other parameters?
I tried so many filter and function from openwebui and gemini made. All failed. The only thing that worked is injecting {%- set enable_thinking = false -%} as first line in jinja template in LM Studio. But that means turning of thinking mode completely for all api call to that model.
I also tried adding that kwargs into advance parameter into chat control (qwen3.5 still thinking) and also in model advance parameter (qwen3.5 keep thinking)
and if that doesn't work for you (but it absolutely should work because custom parameters are added and merged into the model request and sent to the model provider)
then here is an example filter that also does the same thing
Expample filter
Tried this filter, enable it globally and qwen3.5 is still in thinking mode
<!-- gh-comment-id:4031810386 -->
@kukalikuk commented on GitHub (Mar 10, 2026):
> and if that doesn't work for you (but it absolutely should work because custom parameters are added and merged into the model request and sent to the model provider)
>
> then here is an example filter that also does the same thing
>
> Expample filter
Tried this filter, enable it globally and qwen3.5 is still in thinking mode
{%- set enable_thinking = false -%} as first line in jinja template
<!-- gh-comment-id:4031824398 -->
@kukalikuk commented on GitHub (Mar 10, 2026):
> what parameter does lm studio require?
{%- set enable_thinking = false -%} as first line in jinja template
I think the issue is the stringification I mentioned above. I am using LM Studio, and the stringified version is what it received from Open-WebUI. The advanced parameter solution described above does not work because of this.
I also ended up setting the parameter in the jinja template on the model side, but it would be better if it didn't have to be hard-coded.
<!-- gh-comment-id:4031904707 -->
@rickross commented on GitHub (Mar 10, 2026):
> what parameter does lm studio require?
I think the issue is the stringification I mentioned above. I am using LM Studio, and the stringified version is what it received from Open-WebUI. The advanced parameter solution described above does not work because of this.
I also ended up setting the parameter in the jinja template on the model side, but it would be better if it didn't have to be hard-coded.
@rickross the backend handles it - it should not be sent as a string, did you manage to catch the request? It should definitely NOT be stringified, the backend handles it as described above.
<!-- gh-comment-id:4031926691 -->
@Classic298 commented on GitHub (Mar 10, 2026):
@rickross the backend handles it - it should not be sent as a string, did you manage to catch the request? It should definitely NOT be stringified, the backend handles it as described above.
And if you know what parameter is needed, at last, the Filter should be able to definitely do it
<!-- gh-comment-id:4031928902 -->
@Classic298 commented on GitHub (Mar 10, 2026):
And if you know what parameter is needed, at last, the Filter should be able to definitely do it
And if you know what parameter is needed, at last, the Filter should be able to definitely do it
That is also what gemini suggested and the fact that it didn't work is what made us here.
<!-- gh-comment-id:4035190078 -->
@kukalikuk commented on GitHub (Mar 10, 2026):
> And if you know what parameter is needed, at last, the Filter should be able to definitely do it
That is also what gemini suggested and the fact that it didn't work is what made us here.
a simple toggle in the prompt box to turn it on or off
@Classic298
Toggles are not working anymore 😂 spent good few hours trying to solve this problem two days ago, was completely dumbfounded, created an issue https://github.com/open-webui/open-webui/issues/24019#issuecomment-4311408933
still trying to figure it out, but I do think what was proposed before (toggle to switch between thinking and not thinking mode as a function) will not work. Perhaps it can work as function to disable thinking, but tbh it is quite ugly with toggle functionality disabled.
<!-- gh-comment-id:4311569468 -->
@AIWintermuteAI commented on GitHub (Apr 24, 2026):
> [@rickross](https://github.com/rickross) as i said above, use a filter
>
> a filter allows exactly this
>
> > a simple toggle in the prompt box to turn it on or off
@Classic298
Toggles are not working anymore 😂 spent good few hours trying to solve this problem two days ago, was completely dumbfounded, created an issue
https://github.com/open-webui/open-webui/issues/24019#issuecomment-4311408933
still trying to figure it out, but I do think what was proposed before (toggle to switch between thinking and not thinking mode as a function) will not work. Perhaps it can work as function to disable thinking, but tbh it is quite ugly with toggle functionality disabled.
I just commented - what's the question/issue? They still work you just click on the icon now to toggle them on and off.
You can call it "Enable thinking" - disable to disable, enable to enable
<!-- gh-comment-id:4311584138 -->
@Classic298 commented on GitHub (Apr 24, 2026):
I just commented - what's the question/issue? They still work you just click on the icon now to toggle them on and off.
You can call it "Enable thinking" - disable to disable, enable to enable
@AIWintermuteAI commented on GitHub (Apr 24, 2026):
The only way it currently can work is "Disable thinking", since thinking is enabled by default for thinking models.
And then switching between thinking and not thinking mode would require multiple button presses
in this situation I'd need to press on integrations to restore thinking to the model.
I'm not saying it does not work - you can walk on crutches if necessary. It's just it is not convenient or well-thought. I am a software engineer and work with LLMs. But I run open webui instance for my family members, who are much less tech savy. So having a toggle there would help with awareness of that feature.
<!-- gh-comment-id:4311848461 -->
@AIWintermuteAI commented on GitHub (Apr 24, 2026):
The only way it currently can work is "Disable thinking", since thinking is enabled by default for thinking models.
And then switching between thinking and not thinking mode would require multiple button presses
<img width="610" height="384" alt="Image" src="https://github.com/user-attachments/assets/7aa1e431-804e-4747-819a-9e8edd4158ce" />
in this situation I'd need to press on integrations to restore thinking to the model.
I'm not saying it does not work - you can walk on crutches if necessary. It's just it is not convenient or well-thought. I am a software engineer and work with LLMs. But I run open webui instance for my family members, who are much less tech savy. So having a toggle there would help with awareness of that feature.
Someone already created feature request for this
https://github.com/open-webui/open-webui/discussions/17574
I know it's an open source project and I'm not paying you for the development, so make of it what you will.
You can also disable thinking by default and let users enable it with the filter. I'll update the docs herefore but it doesn't have to be the way you did it.
<!-- gh-comment-id:4312423276 -->
@Classic298 commented on GitHub (Apr 24, 2026):
You can also disable thinking by default and let users enable it with the filter. I'll update the docs herefore but it doesn't have to be the way you did it.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @krpr on GitHub (Feb 26, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/21893
Check Existing Issues
Verify Feature Scope
Problem Description
Qwen released their new gen model series Qwen3.5, which support use args
"chat_template_kwargs": {"enable_thinking": false}to switch thinking model in single model.Desired Solution you'd like
Will open-webui have a plan to support this kind of model with a toggle button in chat UI?
Now I use some tricks to switch thinking/non-thing modes.
The single model which can be toggled with args may become a new standard for other models.
Alternatives Considered
No response
Additional Context
No response
@Classic298 commented on GitHub (Feb 26, 2026):
Search for duplicates there's been 5 exactly the same questions in the last few days
Also you can build it yourself using a toggle filter plugin
@gaby commented on GitHub (Mar 7, 2026):
@Classic298 The problem is, those are not applied when using the API. They only get applied when using the Web UI.
I ran into this same problem while using Minimax-M2.5 and Kimi-K2.5. All these new models rely on
chat_template_kwargs.@Classic298 commented on GitHub (Mar 7, 2026):
@gaby i don't understand. Inlet() part of filter IS applied when going via Api.
Also when going via api wouldn't it be better to have 1 model without thinking and the other model with thinking? Would be much easier than having to specify thinking Parameter at request time all of the time
@gaby commented on GitHub (Mar 7, 2026):
@Classic298 Maybe it was fixed, it didn't used to be applied during API calls.
Yes our plan is to have the base model then add a workspace model with reasoning tweaked.
@Classic298 commented on GitHub (Mar 7, 2026):
Inlet() is always applied outlet() is not
but for a thinking filter you only need inlet anyways
@rickross commented on GitHub (Mar 8, 2026):
Nothing would be easier than a simple toggle in the prompt box to turn it on or off. It should be an option. Switching models is way more heavyweight than just toggling a switch.
@rickross commented on GitHub (Mar 8, 2026):
In fact, I did search, and every answer is so complicated. It's totally unclear what to do? Why isn't there just a simple way to add either a correct version of this chat_template_kwargs or to toggle enable_thinking on and off? Learning to write a plugin for the OpenWebUI framework is way harder than adjusting/editing something in the prompt template, but there's no clear way to do that.
And if the question has come up five times in the last few days, isn't that a pretty serious clue that it's something that needs to be addressed?
@gaby commented on GitHub (Mar 8, 2026):
I agree with @rickross I've been using Open-WebUI for over a year and still don't know what to do exactly.
This should be an extra field in the UI config for the model.
@Classic298 commented on GitHub (Mar 8, 2026):
@rickross as i said above, use a filter
a filter allows exactly this
@Classic298 commented on GitHub (Mar 8, 2026):
There is. It's called filter
@Classic298 commented on GitHub (Mar 8, 2026):
Give the AI the filter docs and build one yourself, it's a single prompt. You dont need to learn anything
It's a 20 lines filter (at max)
Alternatively: search on openwebui.com there are some thinking filters like this already
@Classic298 commented on GitHub (Mar 8, 2026):
No because a builtin toggle directly from Open WebUI makes no sense here!
Different inference providers require different thinking parameters, name their body parameters differently - different models have different thinking options
This is something the plugin system was LITERALLY made for and the toggle filters were literally created for (even the example in the docs is for a thinking toggle filter example)
@rickross commented on GitHub (Mar 8, 2026):
Look, I downloaded a Docker image to run OpenWebUI. I didn't clone the Git repo, and I don't want to learn to be an OpenWebUI developer. I'm just a user asking a reasonable question. And apparently there are several others who have the same problem. So why not just be responsive to users and make it easy? What's the upside of insisting that everybody has to learn to write filters?
@Classic298 commented on GitHub (Mar 8, 2026):
@rickross you dont need to clone the git repo to develop a filter.
its a single prompt
Look, i will even do it for you............................... give me 10 minutes......................................
@Classic298 commented on GitHub (Mar 8, 2026):
well no i won't do it for you
i found this in the community
https://openwebui.com/posts/thinking_toggle_one_click_reasoning_control_for_ll_bb3f66ad
use this
@Classic298 commented on GitHub (Mar 8, 2026):
or this
https://openwebui.com/posts/qwen_3_disable_thinking_toggle_v2_305023ed
@gaby commented on GitHub (Mar 8, 2026):
@Classic298 Why do i have to login/create an account to see a filter?
This stuff should be in the docs.
@Classic298 commented on GitHub (Mar 8, 2026):
@gaby this is in the docs. https://docs.openwebui.com/features/extensibility/plugin/functions/filter
@Classic298 commented on GitHub (Mar 8, 2026):
If you just give an AI the Filter docs page it is able to one-shot build a thinking filter for you
@Classic298 commented on GitHub (Mar 8, 2026):
@gaby commented on GitHub (Mar 8, 2026):
I don't want/need users to have to decide wether they have to enable a toggle or not. I just want this to be transparent to users.
Why are filters/functions now behind a Login wall? They used to be public.
@Classic298 commented on GitHub (Mar 8, 2026):
@gaby i dont understand? the whole point of this discussion is to introduce a chat-sided toggle to individually control the thinking ON or OFF.
Why do you now say you dont want users to decide the thinking?
@gaby commented on GitHub (Mar 8, 2026):
I'm making two models:
I just want the required field added with each request, not a toggle in the Web UI.
@Classic298 commented on GitHub (Mar 8, 2026):
Ok in that case, why not use the Advanced Parameters of the model? you can configure thinking levels there right in the UI
Or, if that doesn't work because the inference engine/inference provider is looking for a different thinking parameter, add it using a filter
filter inlet() and make it so that your qwen3.5 model gets thinking parameter added to the request body and the qwen3.5-instant does not
problem solved
@gaby commented on GitHub (Mar 8, 2026):
@Classic298 With these new models the advanced parameters do not work. Models like kimi-k2.5, glm-5, minimax-m2.5, and qwen3.5 require the following in
extra_body:"chat_template_kwargs": {"enable_thinking": false}Setting in Advanced Parameters the thinking, or reasoning effort fields has no effect.
@Classic298 commented on GitHub (Mar 8, 2026):
@gaby open the model in the UI
expand the advanced parameters section
scroll down
click on add custom parameter
add custom param with name
chat_template_kwargsand value {"enable_thinking": true}that should already work
@gaby commented on GitHub (Mar 8, 2026):
It does not, the
chat_template_kwargshas to be inside theextra_body.https://huggingface.co/Qwen/Qwen3.5-35B-A3B#instruct-or-non-thinking-mode
I can test again tomorrow, but as of Friday it wasn't working with latest Open-WebUI and vLLM 0.17.0-rc
Will report back
@Classic298 commented on GitHub (Mar 8, 2026):
and if that doesn't work for you (but it absolutely should work because custom parameters are added and merged into the model request and sent to the model provider)
then here is an example filter that also does the same thing
Expample filter
@Classic298 commented on GitHub (Mar 8, 2026):
@gaby ok in that case try the filter i posted here it injects into extra_body
@Classic298 commented on GitHub (Mar 8, 2026):
of course adjust the model list as you need.
@Classic298 commented on GitHub (Mar 8, 2026):
PS: @gaby did you try the advanced parameters? whatever you add there also should get added to extra_body - did you try it?
Because i think there is a misunderstanding on your end.
extra_body is not a JSON field in the HTTP request, it's a parameter of the OpenAI Python SDK client, which merges its contents into the top-level request body before sending over the wire.
@gaby commented on GitHub (Mar 8, 2026):
@Classic298 i will try tomorrow and report back 💪
@rickross commented on GitHub (Mar 8, 2026):
First thing It tried, but the Open WebUI custom-param widget is stringifying the nested JSON.
chat_template_kwargs: "{"enable_thinking": false}"
@Classic298 commented on GitHub (Mar 8, 2026):
@rickross Good catch on the stringification — but the backend already handles that. Custom parameter values that are JSON strings are automatically parsed back into objects before being merged into the request body (payload.py L96-103). So even though the UI shows it as a string, the actual HTTP request sent to your inference engine will have it as a proper nested object:
So custom parameters should work for this use case. If it doesn't, something else may be going on — would be great to see the actual request body being sent (enable DEBUG logging).
Alternatively, the filter I posted above also works and gives you more control.
@gaby commented on GitHub (Mar 9, 2026):
@Classic298 I can confirm that adding a custom parameter with:
chat_template_kwargs{"enable_thinking": false}Solved the issue.
I got other issues now, but there's a ticket for those already. See https://github.com/open-webui/open-webui/discussions/22230#discussioncomment-16010991
@kukalikuk commented on GitHub (Mar 10, 2026):
I use LM Studio as backend and this method still not working for me, qwen3.5 still in thinking mode.
@Classic298 commented on GitHub (Mar 10, 2026):
@kukalikuk did you try the filter above? does lmstudio require other parameters?
@kukalikuk commented on GitHub (Mar 10, 2026):
I tried so many filter and function from openwebui and gemini made. All failed. The only thing that worked is injecting {%- set enable_thinking = false -%} as first line in jinja template in LM Studio. But that means turning of thinking mode completely for all api call to that model.
I also tried adding that kwargs into advance parameter into chat control (qwen3.5 still thinking) and also in model advance parameter (qwen3.5 keep thinking)
@Classic298 commented on GitHub (Mar 10, 2026):
what parameter does lm studio require?
@kukalikuk commented on GitHub (Mar 10, 2026):
Tried this filter, enable it globally and qwen3.5 is still in thinking mode
@kukalikuk commented on GitHub (Mar 10, 2026):
{%- set enable_thinking = false -%} as first line in jinja template
@rickross commented on GitHub (Mar 10, 2026):
I think the issue is the stringification I mentioned above. I am using LM Studio, and the stringified version is what it received from Open-WebUI. The advanced parameter solution described above does not work because of this.
I also ended up setting the parameter in the jinja template on the model side, but it would be better if it didn't have to be hard-coded.
@Classic298 commented on GitHub (Mar 10, 2026):
@rickross the backend handles it - it should not be sent as a string, did you manage to catch the request? It should definitely NOT be stringified, the backend handles it as described above.
@Classic298 commented on GitHub (Mar 10, 2026):
And if you know what parameter is needed, at last, the Filter should be able to definitely do it
@kukalikuk commented on GitHub (Mar 10, 2026):
That is also what gemini suggested and the fact that it didn't work is what made us here.
@AIWintermuteAI commented on GitHub (Apr 24, 2026):
@Classic298
Toggles are not working anymore 😂 spent good few hours trying to solve this problem two days ago, was completely dumbfounded, created an issue
https://github.com/open-webui/open-webui/issues/24019#issuecomment-4311408933
still trying to figure it out, but I do think what was proposed before (toggle to switch between thinking and not thinking mode as a function) will not work. Perhaps it can work as function to disable thinking, but tbh it is quite ugly with toggle functionality disabled.
@Classic298 commented on GitHub (Apr 24, 2026):
I just commented - what's the question/issue? They still work you just click on the icon now to toggle them on and off.
You can call it "Enable thinking" - disable to disable, enable to enable
@AIWintermuteAI commented on GitHub (Apr 24, 2026):
The only way it currently can work is "Disable thinking", since thinking is enabled by default for thinking models.
And then switching between thinking and not thinking mode would require multiple button presses
in this situation I'd need to press on integrations to restore thinking to the model.
I'm not saying it does not work - you can walk on crutches if necessary. It's just it is not convenient or well-thought. I am a software engineer and work with LLMs. But I run open webui instance for my family members, who are much less tech savy. So having a toggle there would help with awareness of that feature.
Someone already created feature request for this
https://github.com/open-webui/open-webui/discussions/17574
I know it's an open source project and I'm not paying you for the development, so make of it what you will.
@Classic298 commented on GitHub (Apr 24, 2026):
You can also disable thinking by default and let users enable it with the filter. I'll update the docs herefore but it doesn't have to be the way you did it.