I have searched for any existing and/or related issues.
I have searched for any existing and/or related discussions.
I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!).
I am using the latest version of Open WebUI.
Installation Method
Docker
Open WebUI Version
0.9.2
Ollama Version (if applicable)
No response
Operating System
Ubuntu 25.10
Browser (if applicable)
No response
Confirmation
I have read and followed all instructions in README.md.
I am using the latest version of both Open WebUI and Ollama.
I have included the browser console logs.
I have included the Docker container logs.
I have provided every relevant configuration, setting, and environment variable used in my setup.
I have clearly listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc).
I have documented step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation. My steps:
Start with the initial platform/version/OS and dependencies used,
Specify exact install/launch/configure commands,
List URLs visited, user input (incl. example values/emails/passwords if needed),
Describe all options and toggles enabled or changed,
Include any files or environmental changes,
Identify the expected and actual result at each stage,
Ensure any reasonably skilled user can follow and hit the same issue.
Expected Behavior
Openwebui sends a request for a model-generated chat name reusing the current context, this allows the KV cache to kick in and returns the name really quickly.
Actual Behavior
Openwebui sends a completely new context, with the full conversation history shoved into a single, user-role message. This results in a KV cache miss, so the model needs to re-compute the title from the conversation as a whole, from scratch. Here's the request I see in logs:
{"model":"qwen3.6-35b-a3b","messages":[{"role":"user","content":"### Task:\nGenerate a concise, 3-5 word title with ... <Truncated in logs> ...ntext bar fills red at >90% usage.\n</chat_history>"}],"stream":false,"think":false,"temperature":0.7,"top_p":0.8,"top_k":20,"min_p":0,"frequency_penalty":1.05,"presence_penalty":1.5,"extra_body":{"chat_template_kwargs":{"enable_thinking":false}},"enable_thinking":false,"max_tokens":1000}
Simply sending forking the current conversation context with a user request to generate the chat name would be much faster.
Steps to Reproduce
Start a chat.
Look at your server logs
Wait for the initial response to finish stream
See now the second, clean-context request
Logs & Screenshots
{
"model": "qwen3.6-35b-a3b",
"messages": [
{
"role": "user",
"content": "### Task:\nGenerate a concise, 3-5 word title with ... <Truncated in logs> ...ntext bar fills red at >90% usage.\n</chat_history>"
}
],
"stream": false,
"think": false,
"temperature": 0.7,
"top_p": 0.8,
"top_k": 20,
"min_p": 0,
"frequency_penalty": 1.05,
"presence_penalty": 1.5,
"extra_body": {
"chat_template_kwargs": {
"enable_thinking": false
}
},
"enable_thinking": false,
"max_tokens": 1000
}
Additional Information
No response
Originally created by @luispabon on GitHub (Apr 26, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/24159
### Check Existing Issues
- [x] I have searched for any existing and/or related issues.
- [x] I have searched for any existing and/or related discussions.
- [x] I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!).
- [x] I am using the latest version of Open WebUI.
### Installation Method
Docker
### Open WebUI Version
0.9.2
### Ollama Version (if applicable)
_No response_
### Operating System
Ubuntu 25.10
### Browser (if applicable)
_No response_
### Confirmation
- [x] I have read and followed all instructions in `README.md`.
- [x] I am using the latest version of **both** Open WebUI and Ollama.
- [x] I have included the browser console logs.
- [x] I have included the Docker container logs.
- [x] I have **provided every relevant configuration, setting, and environment variable used in my setup.**
- [x] I have clearly **listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup** (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc).
- [x] I have documented **step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation**. My steps:
- Start with the initial platform/version/OS and dependencies used,
- Specify exact install/launch/configure commands,
- List URLs visited, user input (incl. example values/emails/passwords if needed),
- Describe all options and toggles enabled or changed,
- Include any files or environmental changes,
- Identify the expected and actual result at each stage,
- Ensure any reasonably skilled user can follow and hit the same issue.
### Expected Behavior
Openwebui sends a request for a model-generated chat name reusing the current context, this allows the KV cache to kick in and returns the name really quickly.
### Actual Behavior
Openwebui sends a completely new context, with the full conversation history shoved into a single, user-role message. This results in a KV cache miss, so the model needs to re-compute the title from the conversation as a whole, from scratch. Here's the request I see in logs:
```json
{
"model": "qwen3.6-35b-a3b",
"messages": [
{
"role": "user",
"content": "### Task:\nGenerate a concise, 3-5 word title with ... <Truncated in logs> ...ntext bar fills red at >90% usage.\n</chat_history>"
}
],
"stream": false,
"think": false,
"temperature": 0.7,
"top_p": 0.8,
"top_k": 20,
"min_p": 0,
"frequency_penalty": 1.05,
"presence_penalty": 1.5,
"extra_body": {
"chat_template_kwargs": {
"enable_thinking": false
}
},
"enable_thinking": false,
"max_tokens": 1000
}
```
Simply sending forking the current conversation context with a user request to generate the chat name would be much faster.
### Steps to Reproduce
1. Start a chat.
2. Look at your server logs
3. Wait for the initial response to finish stream
4. See now the second, clean-context request
### Logs & Screenshots
```
{
"model": "qwen3.6-35b-a3b",
"messages": [
{
"role": "user",
"content": "### Task:\nGenerate a concise, 3-5 word title with ... <Truncated in logs> ...ntext bar fills red at >90% usage.\n</chat_history>"
}
],
"stream": false,
"think": false,
"temperature": 0.7,
"top_p": 0.8,
"top_k": 20,
"min_p": 0,
"frequency_penalty": 1.05,
"presence_penalty": 1.5,
"extra_body": {
"chat_template_kwargs": {
"enable_thinking": false
}
},
"enable_thinking": false,
"max_tokens": 1000
}
```
### Additional Information
_No response_
GiteaMirror
added the bug label 2026-05-06 00:19:54 -05:00
Your assumption that still existent KV cache would help is only the case if you are talking to the exact same LLM/GPU worker again and the cache not being already flushed. When using external API or use internal load balanced setups this will not necessarily be the case. Afaik even directly talking to llama.cpp will flush the KV even before OWUI can send the title generation task to it.
Also OWUI documentation clearly states that for such simple tasks a separate super fast and non reasoning task model should be used.
For example gemma3:1B is absolutely sufficient for such a use case.
To use a reasoning LLM just for title / tag generation is a bad and pointless strategy.
<!-- gh-comment-id:4322952829 -->
@TomTheWise commented on GitHub (Apr 26, 2026):
Your assumption that still existent KV cache would help is only the case if you are talking to the exact same LLM/GPU worker again and the cache not being already flushed. When using external API or use internal load balanced setups this will not necessarily be the case. Afaik even directly talking to llama.cpp will flush the KV even before OWUI can send the title generation task to it.
Also OWUI documentation clearly states that for such simple tasks a separate super fast and non reasoning task model should be used.
For example gemma3:1B is absolutely sufficient for such a use case.
To use a reasoning LLM just for title / tag generation is a bad and pointless strategy.
A lot of us don't have the capacity to run more than one model locally. I'd dare say a silent majority of openwebui users run it against local llms on resource constrained machines running just the 1 model without complicated multi model routing setups.
<!-- gh-comment-id:4323212777 -->
@luispabon commented on GitHub (Apr 26, 2026):
A lot of us don't have the capacity to run more than one model locally. I'd dare say a silent majority of openwebui users run it against local llms on resource constrained machines running just the 1 model without complicated multi model routing setups.
Your assumption that still existent KV cache would help is only the case if you are talking to the exact same LLM/GPU worker again and the cache not being already flushed. When using external API or use internal load balanced setups this will not necessarily be the case. Afaik even directly talking to llama.cpp will flush the KV even before OWUI can send the title generation task to it.
Also OWUI documentation clearly states that for such simple tasks a separate super fast and non reasoning task model should be used. For example gemma3:1B is absolutely sufficient for such a use case.
To use a reasoning LLM just for title / tag generation is a bad and pointless strategy.
Btw; the documentation suggests that a simpler model would be sufficient. However, this is not the case when using the Code Interpreter tool. This tool relies on the task model, and its performance suffers either failing or producing lower quality responses if the task model is too basic.
I recall seeing a mention in an issue thread that the Code Interpreter functionality should use the main model instead. Unfortunately, it appears that this suggestion was overlooked.
Just because of this, I'm serving a mid sized model to maintain the code interpreter tool's quality as a task model.
<!-- gh-comment-id:4335094832 -->
@ctcanbol commented on GitHub (Apr 28, 2026):
> Your assumption that still existent KV cache would help is only the case if you are talking to the exact same LLM/GPU worker again and the cache not being already flushed. When using external API or use internal load balanced setups this will not necessarily be the case. Afaik even directly talking to llama.cpp will flush the KV even before OWUI can send the title generation task to it.
>
> Also OWUI documentation clearly states that for such simple tasks a separate super fast and non reasoning task model should be used. For example gemma3:1B is absolutely sufficient for such a use case.
>
> To use a reasoning LLM just for title / tag generation is a bad and pointless strategy.
Btw; the documentation suggests that a simpler model would be sufficient. However, this is not the case when using the Code Interpreter tool. This tool relies on the task model, and its performance suffers either failing or producing lower quality responses if the task model is too basic.
I recall seeing a mention in an issue thread that the Code Interpreter functionality should use the main model instead. Unfortunately, it appears that this suggestion was overlooked.
Just because of this, I'm serving a mid sized model to maintain the code interpreter tool's quality as a task model.
Im very sure that code interpreter is NOT done with task model. Maybe it was a bug many versions ago?
For code interpreter to work best you should activate it in the Model and also activate native tool calling.
Ministral-3 was absolute useless, gpt-oss:20b and now gemma4:26b-a4b are quite capable of creating and running good code.
The used task model meanwhile is gemma3:1B since all the time which would absolutely fail to deliver.
Code interpreter manually (telling the Modle to generate but not run the code) generates the code wi the in a python tag so yourself can run it - definitely generated by the main model.
Code interpreter automatically is a tool call by that model (it writes the code and passes it to the tool, and uses the results).
This is co formed as in reasoning you can see how it thinks about code structure and stuff like what color do you want, what values and so on - code interpreter then has this stuff. I have no Clou how this would fit if code interpreter would be then run from the tiny 1B task model.
As code interpreter is being started you can see in the typical Token Generation speed of the man model how the code ist written - the tiny task model would throw it all I. There near instantly.
So maybe that code interpreter being generated by the task model was a bug long time ago?
<!-- gh-comment-id:4336560724 -->
@TomTheWise commented on GitHub (Apr 28, 2026):
Im very sure that code interpreter is NOT done with task model. Maybe it was a bug many versions ago?
For code interpreter to work best you should activate it in the Model and also activate native tool calling.
Ministral-3 was absolute useless, gpt-oss:20b and now gemma4:26b-a4b are quite capable of creating and running good code.
The used task model meanwhile is gemma3:1B since all the time which would absolutely fail to deliver.
Code interpreter manually (telling the Modle to generate but not run the code) generates the code wi the in a python tag so yourself can run it - definitely generated by the main model.
Code interpreter automatically is a tool call by that model (it writes the code and passes it to the tool, and uses the results).
This is co formed as in reasoning you can see how it thinks about code structure and stuff like what color do you want, what values and so on - code interpreter then has this stuff. I have no Clou how this would fit if code interpreter would be then run from the tiny 1B task model.
As code interpreter is being started you can see in the typical Token Generation speed of the man model how the code ist written - the tiny task model would throw it all I. There near instantly.
So maybe that code interpreter being generated by the task model was a bug long time ago?
I use a separate smaller model for this, but I think this issue still raises a very legitimate point. The default behavior in OWUI is to use the same model, and enabling cache hits would be a huge improvement for most users.
<!-- gh-comment-id:4354255549 -->
@alexlach commented on GitHub (Apr 30, 2026):
I use a separate smaller model for this, but I think this issue still raises a very legitimate point. The default behavior in OWUI is to use the same model, and enabling cache hits would be a huge improvement for most users.
Im very sure that code interpreter is NOT done with task model. Maybe it was a bug many versions ago? For code interpreter to work best you should activate it in the Model and also activate native tool calling. Ministral-3 was absolute useless, gpt-oss:20b and now gemma4:26b-a4b are quite capable of creating and running good code. The used task model meanwhile is gemma3:1B since all the time which would absolutely fail to deliver.
Code interpreter manually (telling the Modle to generate but not run the code) generates the code wi the in a python tag so yourself can run it - definitely generated by the main model. Code interpreter automatically is a tool call by that model (it writes the code and passes it to the tool, and uses the results). This is co formed as in reasoning you can see how it thinks about code structure and stuff like what color do you want, what values and so on - code interpreter then has this stuff. I have no Clou how this would fit if code interpreter would be then run from the tiny 1B task model. As code interpreter is being started you can see in the typical Token Generation speed of the man model how the code ist written - the tiny task model would throw it all I. There near instantly.
So maybe that code interpreter being generated by the task model was a bug long time ago?
I don't know in which version it's changed but you are right. I checked 0.9 code base and it's using main model now. Maybe it's fixed when interface admin menu revamped, i don't know but i'm happy it's fixed, thanks for the heads up!
And thumbs up for the OP 👍🏻
<!-- gh-comment-id:4354336627 -->
@ctcanbol commented on GitHub (Apr 30, 2026):
> Im very sure that code interpreter is NOT done with task model. Maybe it was a bug many versions ago? For code interpreter to work best you should activate it in the Model and also activate native tool calling. Ministral-3 was absolute useless, gpt-oss:20b and now gemma4:26b-a4b are quite capable of creating and running good code. The used task model meanwhile is gemma3:1B since all the time which would absolutely fail to deliver.
>
> Code interpreter manually (telling the Modle to generate but not run the code) generates the code wi the in a python tag so yourself can run it - definitely generated by the main model. Code interpreter automatically is a tool call by that model (it writes the code and passes it to the tool, and uses the results). This is co formed as in reasoning you can see how it thinks about code structure and stuff like what color do you want, what values and so on - code interpreter then has this stuff. I have no Clou how this would fit if code interpreter would be then run from the tiny 1B task model. As code interpreter is being started you can see in the typical Token Generation speed of the man model how the code ist written - the tiny task model would throw it all I. There near instantly.
>
> So maybe that code interpreter being generated by the task model was a bug long time ago?
I don't know in which version it's changed but you are right. I checked 0.9 code base and it's using main model now. Maybe it's fixed when interface admin menu revamped, i don't know but i'm happy it's fixed, thanks for the heads up!
And thumbs up for the OP 👍🏻
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 @luispabon on GitHub (Apr 26, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/24159
Check Existing Issues
Installation Method
Docker
Open WebUI Version
0.9.2
Ollama Version (if applicable)
No response
Operating System
Ubuntu 25.10
Browser (if applicable)
No response
Confirmation
README.md.Expected Behavior
Openwebui sends a request for a model-generated chat name reusing the current context, this allows the KV cache to kick in and returns the name really quickly.
Actual Behavior
Openwebui sends a completely new context, with the full conversation history shoved into a single, user-role message. This results in a KV cache miss, so the model needs to re-compute the title from the conversation as a whole, from scratch. Here's the request I see in logs:
Simply sending forking the current conversation context with a user request to generate the chat name would be much faster.
Steps to Reproduce
Logs & Screenshots
Additional Information
No response
@TomTheWise commented on GitHub (Apr 26, 2026):
Your assumption that still existent KV cache would help is only the case if you are talking to the exact same LLM/GPU worker again and the cache not being already flushed. When using external API or use internal load balanced setups this will not necessarily be the case. Afaik even directly talking to llama.cpp will flush the KV even before OWUI can send the title generation task to it.
Also OWUI documentation clearly states that for such simple tasks a separate super fast and non reasoning task model should be used.
For example gemma3:1B is absolutely sufficient for such a use case.
To use a reasoning LLM just for title / tag generation is a bad and pointless strategy.
@luispabon commented on GitHub (Apr 26, 2026):
A lot of us don't have the capacity to run more than one model locally. I'd dare say a silent majority of openwebui users run it against local llms on resource constrained machines running just the 1 model without complicated multi model routing setups.
@ctcanbol commented on GitHub (Apr 28, 2026):
Btw; the documentation suggests that a simpler model would be sufficient. However, this is not the case when using the Code Interpreter tool. This tool relies on the task model, and its performance suffers either failing or producing lower quality responses if the task model is too basic.
I recall seeing a mention in an issue thread that the Code Interpreter functionality should use the main model instead. Unfortunately, it appears that this suggestion was overlooked.
Just because of this, I'm serving a mid sized model to maintain the code interpreter tool's quality as a task model.
@TomTheWise commented on GitHub (Apr 28, 2026):
Im very sure that code interpreter is NOT done with task model. Maybe it was a bug many versions ago?
For code interpreter to work best you should activate it in the Model and also activate native tool calling.
Ministral-3 was absolute useless, gpt-oss:20b and now gemma4:26b-a4b are quite capable of creating and running good code.
The used task model meanwhile is gemma3:1B since all the time which would absolutely fail to deliver.
Code interpreter manually (telling the Modle to generate but not run the code) generates the code wi the in a python tag so yourself can run it - definitely generated by the main model.
Code interpreter automatically is a tool call by that model (it writes the code and passes it to the tool, and uses the results).
This is co formed as in reasoning you can see how it thinks about code structure and stuff like what color do you want, what values and so on - code interpreter then has this stuff. I have no Clou how this would fit if code interpreter would be then run from the tiny 1B task model.
As code interpreter is being started you can see in the typical Token Generation speed of the man model how the code ist written - the tiny task model would throw it all I. There near instantly.
So maybe that code interpreter being generated by the task model was a bug long time ago?
@alexlach commented on GitHub (Apr 30, 2026):
I use a separate smaller model for this, but I think this issue still raises a very legitimate point. The default behavior in OWUI is to use the same model, and enabling cache hits would be a huge improvement for most users.
@ctcanbol commented on GitHub (Apr 30, 2026):
I don't know in which version it's changed but you are right. I checked 0.9 code base and it's using main model now. Maybe it's fixed when interface admin menu revamped, i don't know but i'm happy it's fixed, thanks for the heads up!
And thumbs up for the OP 👍🏻