feat: Allow Editing of Reasoning/Thinking Section in Chat Mode #5939

New Issue

GiteaMirror · 2025-11-11T16:39:29-06:00

GiteaMirror commented

2025-11-11 16:39:29 -06:00

Originally created by @OracleToes on GitHub (Aug 1, 2025).

Check Existing Issues

I have searched the existing issues and discussions.

Problem Description

Currently, when interacting with an LLM in the Open WebUI chat interface, the model's reasoning process is displayed within a collapsible "thinking" section (using <details> and <think> tags). While this section can be opened to view the live token stream during the reasoning process, the contents cannot be directly edited when attempting to modify a message. In edit mode, the reasoning section appears as a placeholder like <details id="__DETAIL_0__"/>. This prevents users from refining or correcting the LLM's thought process within the context of an ongoing conversation.
This functionality is available in the Open WebUI playground, suggesting it's technically feasible but not implemented in the chat interface.

I am aware of #9034 and #9044 but for those running local models, this limitation is irrelevant.

Desired Solution you'd like

The ideal solution should enable direct editing of the content within the <details> or <think> tags during message modification in the Open WebUI chat interface. This would provide users, especially those running local models, with greater control over the LLM's thought process.

Allowing this editing would facilitate correction of errors or logical flaws within the reasoning steps, and enable much finer control/steering of the model.

I find this to be important because even if you're running local models, time is still a valuable resourceBeing able to stop the model after it's already generated a good chunk of reasoning is often better than regenerating the entire response.

Alternatives Considered

This could be a toggle in the Admin Panel, so that it can be disabled for those who want to restrict this function for their users.

Additional Context

When manually typing out a <think> section and then submitting the message, the browser running the webui tab will lock up and become unresponsive.

Originally created by @OracleToes on GitHub (Aug 1, 2025). ### Check Existing Issues - [x] I have searched the existing issues and discussions. ### Problem Description Currently, when interacting with an LLM in the Open WebUI chat interface, the model's reasoning process is displayed within a collapsible "thinking" section (using `<details>` and `<think>` tags). While this section can be opened to view the live token stream during the reasoning process, the contents cannot be directly edited when attempting to modify a message. In edit mode, the reasoning section appears as a placeholder like `<details id="__DETAIL_0__"/>`. This prevents users from refining or correcting the LLM's thought process within the context of an ongoing conversation. This functionality is available in the Open WebUI playground, suggesting it's technically feasible but not implemented in the chat interface. I am aware of #9034 and #9044 but for those running local models, this limitation is irrelevant. ### Desired Solution you'd like The ideal solution should enable direct editing of the content within the `<details>` or `<think>` tags during message modification in the Open WebUI chat interface. This would provide users, especially those running local models, with greater control over the LLM's thought process. Allowing this editing would facilitate correction of errors or logical flaws within the reasoning steps, and enable much finer control/steering of the model. I find this to be important because even if you're running local models, time is still a valuable resourceBeing able to stop the model after it's already generated a good chunk of reasoning is often better than _**regenerating the entire response**_. ### Alternatives Considered This could be a toggle in the Admin Panel, so that it can be disabled for those who want to restrict this function for their users. ### Additional Context When manually typing out a `<think>` section and then submitting the message, the browser running the webui tab will lock up and become unresponsive.

GiteaMirror commented

2025-11-11 16:39:29 -06:00

@jdwx commented on GitHub (Aug 19, 2025):

I have run into a similar issue. However, because thinking/details aren't carried forward to future generation requests, implementation of this would probably also need some way to differentiate between regenerating the whole response (including reasoning) and regenerating the message content starting after the reasoning section, reusing the existing reasoning. (Which might also be generally useful with reasoning models.)

@jdwx commented on GitHub (Aug 19, 2025): I have run into a similar issue. However, because thinking/details aren't carried forward to future generation requests, implementation of this would probably also need some way to differentiate between regenerating the whole response (including reasoning) and regenerating the message content starting **after** the reasoning section, reusing the existing reasoning. (Which might also be generally useful with reasoning models.)

GiteaMirror commented

2025-11-11 16:39:30 -06:00

@Classic298 commented on GitHub (Aug 19, 2025):

Allowing this editing would facilitate correction of errors or logical flaws within the reasoning steps, and enable much finer control/steering of the model.

But how, since the reasoning is never sent back to the model. Any edits are irrelevant as the reasoning text of old responses is never sent to the model.

What would be the usecase for this? I really do not see it.

@Classic298 commented on GitHub (Aug 19, 2025): > Allowing this editing would facilitate correction of errors or logical flaws within the reasoning steps, and enable much finer control/steering of the model. But how, since the reasoning is never sent back to the model. Any edits are irrelevant as the reasoning text of old responses is never sent to the model. What would be the usecase for this? I really do not see it.

GiteaMirror commented

2025-11-11 16:39:30 -06:00

@jdwx commented on GitHub (Aug 19, 2025):

@Classic298 I am, and I believe OracleToes is also, referring to editing thinking for the current response, the one where the thinking is still part of the context, because it's all part of the same response.

User: How many R's in raspberry?

Assistant: <thinking>Hmm, the user seems to be asking about the storage of single-board computers.</thinking> Well, recent models of the Pi can support quite a bit of RAM, which can hold a lot of R's! The specifics vary by model. Was there a particular model you're interested in?

What I think we're asking for is the ability to edit the thinking to:

Assistant: <thinking>Hmm, the user seems to be asking about the spelling of the name of the fruit.</thinking>

And then have "Regenerate" pick up from there. Or, if you prefer, "Continue Response" from that point. (Although I would really, really like the option to keep the thinking and regenerate the rest of the response.)

This is obviously a simple, contrived example, but it's incredibly painful to see a large model spend 90 seconds "reasoning," get one detail backwards that tanks the response, and have no way to fix it that doesn't involve regenerating the whole response, waiting though another 90 seconds of thinking, and hoping it doesn't make the same mistake again.

I guess it technically doesn't have to be limited to the current response, but you're right that editing the thinking of any response but the current response would have no effect unless you branch the conversation there, making it "current" again. In which case it might be quite important.

Does that make sense?

@jdwx commented on GitHub (Aug 19, 2025): @Classic298 I am, and I believe OracleToes is also, referring to editing thinking for the current response, the one where the thinking **is** still part of the context, because it's all part of the same response. ``` User: How many R's in raspberry? Assistant: <thinking>Hmm, the user seems to be asking about the storage of single-board computers.</thinking> Well, recent models of the Pi can support quite a bit of RAM, which can hold a lot of R's! The specifics vary by model. Was there a particular model you're interested in? ``` What I think we're asking for is the ability to edit the thinking to: ``` Assistant: <thinking>Hmm, the user seems to be asking about the spelling of the name of the fruit.</thinking> ``` And then have "Regenerate" pick up from there. Or, if you prefer, "Continue Response" from that point. (Although I would really, really like the option to keep the thinking and regenerate the rest of the response.) This is obviously a simple, contrived example, but it's incredibly painful to see a large model spend 90 seconds "reasoning," get one detail backwards that tanks the response, and have no way to fix it that doesn't involve regenerating the whole response, waiting though another 90 seconds of thinking, and hoping it doesn't make the same mistake again. I guess it technically doesn't have to be limited to the current response, but you're right that editing the thinking of any response but the current response would have no effect **unless** you branch the conversation there, making it "current" again. In which case it might be quite important. Does that make sense?

GiteaMirror commented

2025-11-11 16:39:30 -06:00

@jdwx commented on GitHub (Aug 19, 2025):

Actually, I just tested this, and it does seem like if you edit the response at all and then select continue response, that the previous thinking is completely discarded and the response is continued without any reasoning at all.

Is that intentional? It makes perfect sense that the reasoning text of old responses isn't sent to the model. But the reasoning text of the current response is quite a different matter.

Losing it as well is certainly not what I would have expected, nor the behavior I would want.

@jdwx commented on GitHub (Aug 19, 2025): Actually, I just tested this, and it **does** seem like if you edit the response at all and then select continue response, that the previous thinking is completely discarded and the response is continued without any reasoning at all. Is that intentional? It makes perfect sense that the reasoning text of **old** responses isn't sent to the model. But the reasoning text of the current response is quite a different matter. Losing it as well is certainly not what I would have expected, nor the behavior I would want.

GiteaMirror commented

2025-11-11 16:39:30 -06:00

@Classic298 commented on GitHub (Aug 20, 2025):

And then have "Regenerate" pick up from there. Or, if you prefer, "Continue Response" from that point. (Although I would really, really like the option to keep the thinking and regenerate the rest of the response.)

Regenerate would regenerate it - totally new, with any old generated messages obviously discarded.

Continue Response - conceptually it makes sense, but when would this be usable? In scenarios of external models (openai connectivity) this isn't possible at all.

And for local models (ollama) it would only even be feasible if you have a very slow model (like 1 token per second) and you are actually able to click the stop button in time to stop the response.

@Classic298 commented on GitHub (Aug 20, 2025): > And then have "Regenerate" pick up from there. Or, if you prefer, "Continue Response" from that point. (Although I would really, really like the option to keep the thinking and regenerate the rest of the response.) Regenerate would regenerate it - totally new, with any old generated messages obviously discarded. Continue Response - conceptually it makes sense, but when would this be usable? In scenarios of external models (openai connectivity) this isn't possible at all. And for local models (ollama) it would only even be feasible if you have a very slow model (like 1 token per second) and you are actually able to click the stop button in time to stop the response.

GiteaMirror commented

2025-11-11 16:39:30 -06:00

@rgaricano commented on GitHub (Aug 20, 2025):

maybe a workaround to test could be send to llm:
regenerate response but using this modified thinking: xxxxxx

When I tried this way (qwen3:8b) model responses are faster and showing in details the new thinking that I sent.
Test it, and if it work in this way maybe could be interesting some integration for modify thinking and regenerate new responses just using it.
Maybe an inconvenient could be the different use of thinking/reasoning tags by models.

@rgaricano commented on GitHub (Aug 20, 2025): maybe a workaround to test could be send to llm: _regenerate response but using this modified thinking: xxxxxx_ When I tried this way (qwen3:8b) model responses are faster and showing in details the new thinking that I sent. Test it, and if it work in this way maybe could be interesting some integration for modify thinking and regenerate new responses just using it. Maybe an inconvenient could be the different use of thinking/reasoning tags by models.

GiteaMirror commented

2025-11-11 16:39:30 -06:00

@jdwx commented on GitHub (Aug 20, 2025):

I will be the first to admit I have literally never used Open WebUI with a closed model provider like OpenAI. I use it with local models, usually on llama.cpp, ik_llama.cpp, or VLLM. So it sounds like maybe there is some difference of perspective.

In the local model context, <think> is just another token that appears in the response. So there is no problem at all with sending a chat continuation API call with <think>...</think>-enclosed content in the response being continued. I do it all the time in programs that access the API directly. I find myself missing this capability when I'm using Open WebUI.

As far as I can tell, the core of this request is the ability to easily get from this conversation:

User: Hey, can you answer some questions for me?

Assistant: Sure! Go ahead when you're ready.

User: How many R's in raspberry?

Assistant: <think>Hmm, the user seems to be asking about the storage of single-board computers.</think> Well, recent models of the Pi can support quite a bit of RAM, which can hold a lot of R's! The specifics vary by model. Was there a particular model you're interested in?

to this API submission to http://my.server:12345/v1/chat/completions:

{
   ...generation params...
  "messages": [
    {
      "role": "system",
      "content": "You are a helpful assistant."
    },
    {
      "role": "user",
      "content": "Hey, can you answer some questions for me?"
    },
    {
      "role": "assistant",
      "content": "Sure! Go ahead when you're ready."
    },
    {
      "role": "user",
      "content": "How many R's in raspberry?"
    },
    {
      "role": "assistant",
      "content": "<think>Hmm, the user seems to be asking about the spelling of the name of the fruit.</think>"
    },
  ]
}

@jdwx commented on GitHub (Aug 20, 2025): I will be the first to admit I have literally never used Open WebUI with a closed model provider like OpenAI. I use it with local models, usually on llama.cpp, ik_llama.cpp, or VLLM. So it sounds like maybe there is some difference of perspective. In the local model context, `<think>` is just another token that appears in the response. So there is no problem at all with sending a chat continuation API call with `<think>...</think>`-enclosed content in the response being continued. I do it all the time in programs that access the API directly. I find myself missing this capability when I'm using Open WebUI. As far as I can tell, the core of this request is the ability to easily get from this conversation: > User: Hey, can you answer some questions for me? > > Assistant: Sure! Go ahead when you're ready. > > User: How many R's in raspberry? > > Assistant: `<think>`Hmm, the user seems to be asking about the storage of single-board computers.`</think>` Well, recent models of the Pi can support quite a bit of RAM, which can hold a lot of R's! The specifics vary by model. Was there a particular model you're interested in? to this API submission to http://my.server:12345/v1/chat/completions: ```json { ...generation params... "messages": [ { "role": "system", "content": "You are a helpful assistant." }, { "role": "user", "content": "Hey, can you answer some questions for me?" }, { "role": "assistant", "content": "Sure! Go ahead when you're ready." }, { "role": "user", "content": "How many R's in raspberry?" }, { "role": "assistant", "content": "<think>Hmm, the user seems to be asking about the spelling of the name of the fruit.</think>" }, ] } ```

GiteaMirror referenced this issue

2025-11-11 18:00:26 -06:00

[PR #5940] [MERGED] fix: sort the list of TTS voices and reformat the names #8586

GiteaMirror referenced this issue

2026-04-20 03:43:18 -05:00

[PR #5940] [MERGED] fix: sort the list of TTS voices and reformat the names #21790

GiteaMirror referenced this issue

2026-04-25 10:54:45 -05:00

[PR #5940] [MERGED] fix: sort the list of TTS voices and reformat the names #37420

GiteaMirror referenced this issue

2026-04-29 19:03:51 -05:00

[PR #5940] [MERGED] fix: sort the list of TTS voices and reformat the names #44838