github-starred/ollama
2
0
Fork 0
mirror of https://github.com/ollama/ollama.git synced 2026-07-16 21:25:46 -05:00
Code Issues 16.9k Packages Projects Releases 122 Wiki Activity

[GH-ISSUE #16016] Feature Request: option to enable/disable thinking/reasoning in the UI #87885

New Issue
Open
opened 2026-05-10 06:31:28 -05:00 by GiteaMirror · 12 comments
GiteaMirror commented 2026-05-10 06:31:28 -05:00
Owner
Copy Link

Originally created by @numbworks on GitHub (May 6, 2026).
Original GitHub issue: https://github.com/ollama/ollama/issues/16016

Hello ollama devs!

Thank you for your amazing work!

It would be good to have an option to enable/disable thinking/reasoning for all the models in the UI, perhaps in Settings.

This feature is already available in the ollama CLI.

For reference, I attach a UI mockup about how I envision the feature.

Disabling the thinking in models such as gemma4:e4b would shorten the response time by 2x-5x.

Thanks!

Image
Originally created by @numbworks on GitHub (May 6, 2026). Original GitHub issue: https://github.com/ollama/ollama/issues/16016 Hello ollama devs! Thank you for your amazing work! It would be good to have **an option to enable/disable thinking/reasoning for all the models in the UI**, perhaps in Settings. This feature is already available in the ollama CLI. For reference, I attach a UI mockup about how I envision the feature. Disabling the thinking in models such as `gemma4:e4b` would shorten the response time by 2x-5x. Thanks! <img width="1093" height="860" alt="Image" src="https://github.com/user-attachments/assets/a53d7dfb-b618-4511-ab20-49bbf1c9160e" />
GiteaMirror added the feature request label 2026-05-10 06:31:28 -05:00
GiteaMirror commented 2026-05-10 06:31:48 -05:00
Author
Owner
Copy Link

@patmakesapps commented on GitHub (May 7, 2026):

I'd like to take a stab at this. My plan is to add a Reasoning/Thinking toggle to the Settings panel that persists to config and passes the thinking option through to the API. Does this align with how the team would want it implemented, or is there a preferred approach for per-model vs. global settings?

<!-- gh-comment-id:4400217367 --> @patmakesapps commented on GitHub (May 7, 2026): I'd like to take a stab at this. My plan is to add a Reasoning/Thinking toggle to the Settings panel that persists to config and passes the thinking option through to the API. Does this align with how the team would want it implemented, or is there a preferred approach for per-model vs. global settings?
GiteaMirror commented 2026-05-10 06:31:49 -05:00
Author
Owner
Copy Link

@patmakesapps commented on GitHub (May 7, 2026):

I started working on this and have a first implementation in progress.

So far I added a global Reasoning/Thinking toggle in Settings and wired it into chat requests so that when
the setting is disabled the UI sends think: false. I also updated the backend request construction so
the explicit false value is preserved instead of being dropped. Current status:

  1. Settings toggle is added
    2 Setting is persisted through the existing settings API
  2. Chat requests now pass through think: false
  3. Frontend tests are passing locally

One thing I’m still checking is the enable path across different model families. The current UI already
has model-specific thinking behavior for some models, and I want to make sure this setting behaves
correctly for all supported models before opening a PR.

<!-- gh-comment-id:4400593478 --> @patmakesapps commented on GitHub (May 7, 2026): I started working on this and have a first implementation in progress. So far I added a global Reasoning/Thinking toggle in Settings and wired it into chat requests so that when the setting is disabled the UI sends `think: false`. I also updated the backend request construction so the explicit `false` value is preserved instead of being dropped. Current status: 1) Settings toggle is added 2 Setting is persisted through the existing settings API 3) Chat requests now pass through `think: false` 4) Frontend tests are passing locally One thing I’m still checking is the enable path across different model families. The current UI already has model-specific thinking behavior for some models, and I want to make sure this setting behaves correctly for all supported models before opening a PR.
GiteaMirror commented 2026-05-10 06:31:51 -05:00
Author
Owner
Copy Link

@numbworks commented on GitHub (May 7, 2026):

@patmakesapps
Thanks for taking ownership of this! I apprecciate your time and work!

<!-- gh-comment-id:4400817386 --> @numbworks commented on GitHub (May 7, 2026): @patmakesapps Thanks for taking ownership of this! I apprecciate your time and work!
GiteaMirror commented 2026-05-10 06:31:54 -05:00
Author
Owner
Copy Link

@patmakesapps commented on GitHub (May 7, 2026):

@patmakesapps
Thanks for taking ownership of this! I apprecciate your time and work!

Of course 🤜🏻 I will follow up once I've done a bit more work and testing. Probably sometime tomorrow or this weekend

<!-- gh-comment-id:4401315736 --> @patmakesapps commented on GitHub (May 7, 2026): > @patmakesapps > Thanks for taking ownership of this! I apprecciate your time and work! Of course 🤜🏻 I will follow up once I've done a bit more work and testing. Probably sometime tomorrow or this weekend
GiteaMirror commented 2026-05-10 06:31:57 -05:00
Author
Owner
Copy Link

@rick-github commented on GitHub (May 8, 2026):

https://github.com/ollama/ollama/pull/15217

<!-- gh-comment-id:4405065382 --> @rick-github commented on GitHub (May 8, 2026): https://github.com/ollama/ollama/pull/15217
GiteaMirror commented 2026-05-10 06:31:58 -05:00
Author
Owner
Copy Link

@patmakesapps commented on GitHub (May 8, 2026):

#15217
i took a look at the comments thread after clicking https://github.com/ollama/ollama/pull/15217 in yourprevious comment and I will be handling the issues you called out.

<!-- gh-comment-id:4405972240 --> @patmakesapps commented on GitHub (May 8, 2026): > [#15217](https://github.com/ollama/ollama/pull/15217) i took a look at the comments thread after clicking https://github.com/ollama/ollama/pull/15217 in yourprevious comment and I will be handling the issues you called out.
GiteaMirror commented 2026-05-10 06:32:00 -05:00
Author
Owner
Copy Link

@patmakesapps commented on GitHub (May 8, 2026):

@numbworks @rick-github https://github.com/ollama/ollama/pull/16042

<!-- gh-comment-id:4406215820 --> @patmakesapps commented on GitHub (May 8, 2026): @numbworks @rick-github https://github.com/ollama/ollama/pull/16042
GiteaMirror commented 2026-05-10 06:32:01 -05:00
Author
Owner
Copy Link

@levicki commented on GitHub (May 8, 2026):

@patmakesapps

I'd like to take a stab at this. My plan is to add a Reasoning/Thinking toggle to the Settings panel that persists to config and passes the thinking option through to the API. Does this align with how the team would want it implemented, or is there a preferred approach for per-model vs. global settings?

This shouldn't be a global toggle or at least not only a global toggle.

This should be something you can enable/disable in each chat with global setting affecting the starting default.

So:

  • If a global thinking is off all chats start with thinking off
  • If a global thinking is on all chats start with thinking on if model supports it
  • You can then override thinking per chat
  • There should also be an option to not send previous thinking with the next query

Please don't just do the global toggle.

Also if I am reading this correctly:

When the setting is disabled, the app backend forces think: false for chat requests so thinking is disabled globally for thinking-capable models. This makes the setting authoritative even when the frontend does not send an explicit think value.

Does that mean if I use another frontend (such as OpenWebUI) thinking will still be disabled regardless of what I set in it? If yes, then that's just horrible because it breaks user expectation that they can configure model behavior from their frontend. Please clarify.

<!-- gh-comment-id:4407520358 --> @levicki commented on GitHub (May 8, 2026): @patmakesapps > I'd like to take a stab at this. My plan is to add a Reasoning/Thinking toggle to the Settings panel that persists to config and passes the thinking option through to the API. Does this align with how the team would want it implemented, or is there a preferred approach for per-model vs. global settings? This shouldn't be a global toggle or at least not only a global toggle. This should be something you can enable/disable in each chat with global setting affecting the starting default. So: - If a global thinking is off all chats start with thinking off - If a global thinking is on all chats start with thinking on if model supports it - You can then override thinking per chat - There should also be an option to not send previous thinking with the next query Please don't just do the global toggle. Also if I am reading this correctly: > When the setting is disabled, the app backend forces think: false for chat requests so thinking is disabled globally for thinking-capable models. This makes the setting authoritative even when the frontend does not send an explicit think value. Does that mean if I use another frontend (such as OpenWebUI) thinking will still be disabled regardless of what I set in it? If yes, then that's just horrible because it breaks user expectation that they can configure model behavior from their frontend. Please clarify.
GiteaMirror commented 2026-05-10 06:32:01 -05:00
Author
Owner
Copy Link

@numbworks commented on GitHub (May 8, 2026):

@levicki

This shouldn't be a global toggle or at least not only a global toggle.
This should be something you can enable/disable in each chat with global setting affecting the starting default.

Your request is fair, but I think that, in average, the user who is interested in thinking will keep it always enabled, while the user who is not interested will keep it always disabled.

Should the user who is never interested in thinking disable the toggle in every chat then?
It sounds like a quite poor user experience.

Perhaps a compromise could be that in the global settings the user express the default value he wants for the thinking toggle in the chats, and then in single chats he can change idea and override the global setting on demand.

<!-- gh-comment-id:4407945352 --> @numbworks commented on GitHub (May 8, 2026): @levicki > This shouldn't be a global toggle or at least not only a global toggle. > This should be something you can enable/disable in each chat with global setting affecting the starting default. Your request is fair, but I think that, in average, the user who is interested in thinking will keep it always enabled, while the user who is not interested will keep it always disabled. Should the user who is never interested in thinking disable the toggle in every chat then? It sounds like a quite poor user experience. Perhaps a compromise could be that in the global settings the user express the default value he wants for the thinking toggle in the chats, and then in single chats he can change idea and override the global setting on demand.
GiteaMirror commented 2026-05-10 06:32:02 -05:00
Author
Owner
Copy Link

@SFBorland commented on GitHub (May 8, 2026):

For some prompts I'd like it enabled and others, disabled. So not sure global only is the best case, just my opinion.

<!-- gh-comment-id:4408072399 --> @SFBorland commented on GitHub (May 8, 2026): For some prompts I'd like it enabled and others, disabled. So not sure global only is the best case, just my opinion.
GiteaMirror commented 2026-05-10 06:32:02 -05:00
Author
Owner
Copy Link

@patmakesapps commented on GitHub (May 8, 2026):

Thanks, that feedback makes sense.

To clarify one point...the think: false enforcement I added is only in the desktop app UI backend path,
not in the core Ollama server API. It should not affect other frontends like OpenWebUI that talk directly to Ollama.

I agree the better behavior is probably: global setting = default for new chats, with a per-chat
override when the selected model supports thinking controls. That also lines up with what @numbworks suggested as a compromise.

I’ll revise the PR in that direction and look separately at the previous-thinking carryover behavior so I understand the current flow before changing it.

<!-- gh-comment-id:4408440243 --> @patmakesapps commented on GitHub (May 8, 2026): Thanks, that feedback makes sense. To clarify one point...the `think: false` enforcement I added is only in the desktop app UI backend path, not in the core Ollama server API. It should not affect other frontends like OpenWebUI that talk directly to Ollama. I agree the better behavior is probably: global setting = default for new chats, with a per-chat override when the selected model supports thinking controls. That also lines up with what @numbworks suggested as a compromise. I’ll revise the PR in that direction and look separately at the previous-thinking carryover behavior so I understand the current flow before changing it.
GiteaMirror commented 2026-05-10 06:32:02 -05:00
Author
Owner
Copy Link

@levicki commented on GitHub (May 8, 2026):

Perhaps a compromise could be that in the global settings the user express the default value he wants for the thinking toggle in the chats, and then in single chats he can change idea and override the global setting on demand.

If you re-read what I wrote that's exactly what I proposed.

To clarify one point...the think: false enforcement I added is only in the desktop app UI backend path,
not in the core Ollama server API.

Thank God...

I agree the better behavior is probably: global setting = default for new chats, with a per-chat
override when the selected model supports thinking controls.

Yeah, that's what I suggested to but he somehow misread it.

<!-- gh-comment-id:4409398239 --> @levicki commented on GitHub (May 8, 2026): > Perhaps a compromise could be that in the global settings the user express the default value he wants for the thinking toggle in the chats, and then in single chats he can change idea and override the global setting on demand. If you re-read what I wrote that's exactly what I proposed. > To clarify one point...the think: false enforcement I added is only in the desktop app UI backend path, not in the core Ollama server API. Thank God... > I agree the better behavior is probably: global setting = default for new chats, with a per-chat override when the selected model supports thinking controls. Yeah, that's what I suggested to but he somehow misread it.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
amd
api
app
bug
build
cli
cloud
compatibility
context-length
create
docker
documentation
embeddings
feature request
feedback wanted
good first issue
gpt-oss
gpu
harmony
help wanted
image
install
intel
js
launch
linux
macos
memory
mlx
model
needs more info
networking
nvidia
ollama.com
performance
pull-request
Mirrored from GitHub Pull Request
 python
question
registry
rendering
thinking
tools
top
vulkan
windows
wsl
No Label feature request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/ollama#87885
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?