Chat history UI does not show summary of o1 model chat #2208

New Issue

2025-11-11T15:02:28-06:00

GiteaMirror commented

2025-11-11 15:02:28 -06:00

Originally created by @codehopper-uk on GitHub (Sep 26, 2024).

Bug Report

Installation Method

Helm install

helm list -n open-webui 
NAME            NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                  APP VERSION
open-webui      open-webui      8               2024-09-26 10:57:03.380747635 +0000 UTC deployed        open-webui-3.1.18      0.3.23

Environment

Open WebUI Version: [v0.3.23] according to helm release, but About on the UI says v0.3.30 (latest)
Ollama (if applicable): [e.g., v0.2.0, v0.1.32-rc1]
Operating System: image: ghcr.io/open-webui/open-webui
Browser (if applicable): Chrome Version 128.0.6613.138 (Official Build) (x86_64)

Confirmation:

I have read and followed all the instructions provided in the README.md.
I am on 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 the exact steps to reproduce the bug in the "Steps to Reproduce" section below.

Expected Behavior:

Chat history for o1 model queries to show summary of chat, as it does for other models eg 4o

Actual Behavior:

Chat history for o1 model with Chat Streaming off results in unlabeled/textless chat history.

Description

Bug Summary:
Chat history for o1 model with Chat Streaming off results in unlabeled/textless chat history. Chat Streaming is required to be turned off otherwise o1 models do not work as per issue 5490

Reproduction Details

Steps to Reproduce:

Open New chat
Open controls on top left > Advanced parameters > Turn off Stream Chat Response
Select any o1 model (mini or preview for example)
enter a query eg 2+2
the model responds as expected
the chat history does not update (as it does for other models that follow the above steps, eg 4o latest)

Logs and Screenshots

Screenshots/Screen Recordings (if applicable):

o1 model query with streaming off (notice unlabeled/empty chat history summary on left)
4o latest model query with streaming off

Note

If the bug report is incomplete or does not follow the provided instructions, it may not be addressed. Please ensure that you have followed the steps outlined in the README.md and troubleshooting.md documents, and provide all necessary information for us to reproduce and address the issue. Thank you!

Originally created by @codehopper-uk on GitHub (Sep 26, 2024). # Bug Report ## Installation Method Helm install ``` helm list -n open-webui NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION open-webui open-webui 8 2024-09-26 10:57:03.380747635 +0000 UTC deployed open-webui-3.1.18 0.3.23 ``` ## Environment - **Open WebUI Version:** [v0.3.23] according to helm release, but About on the UI says v0.3.30 (latest) - **Ollama (if applicable):** [e.g., v0.2.0, v0.1.32-rc1] - **Operating System:** image: ghcr.io/open-webui/open-webui - **Browser (if applicable):** Chrome Version 128.0.6613.138 (Official Build) (x86_64) **Confirmation:** - [x] I have read and followed all the instructions provided in the README.md. - [x] I am on the latest version of both Open WebUI and Ollama. - [ ] I have included the browser console logs. - [ ] I have included the Docker container logs. - [x] I have provided the exact steps to reproduce the bug in the "Steps to Reproduce" section below. ## Expected Behavior: Chat history for o1 model queries to show summary of chat, as it does for other models eg 4o ## Actual Behavior: Chat history for o1 model with Chat Streaming off results in unlabeled/textless chat history. ## Description **Bug Summary:** Chat history for o1 model with Chat Streaming off results in unlabeled/textless chat history. Chat Streaming is required to be turned off otherwise o1 models do not work as per issue [5490](https://github.com/open-webui/open-webui/issues/5490#issuecomment-2361248888) ## Reproduction Details **Steps to Reproduce:** - Open New chat - Open controls on top left > Advanced parameters > Turn off Stream Chat Response - Select any o1 model (mini or preview for example) - enter a query eg 2+2 - the model responds as expected - the chat history does not update (as it does for other models that follow the above steps, eg 4o latest) ## Logs and Screenshots **Screenshots/Screen Recordings (if applicable):** 1. o1 model query with streaming off (notice unlabeled/empty chat history summary on left) <img width="1427" alt="image" src="https://github.com/user-attachments/assets/5d7ed69e-91b1-458e-bec6-d1671ac6fa09"> 2. 4o latest model query with streaming off <img width="1427" alt="image" src="https://github.com/user-attachments/assets/91604360-7e65-4ed0-9394-d3b09b0c202e"> ## Note If the bug report is incomplete or does not follow the provided instructions, it may not be addressed. Please ensure that you have followed the steps outlined in the README.md and troubleshooting.md documents, and provide all necessary information for us to reproduce and address the issue. Thank you!

GiteaMirror added the non-core label 2025-11-11 15:02:28 -06:00

GiteaMirror closed this issue

2025-11-11 15:02:28 -06:00

GiteaMirror commented

2025-11-11 15:02:29 -06:00

@jonnywright commented on GitHub (Oct 4, 2024):

Same issue here but with different environment:

Bug Report

Installation Method

Docker via. docker compose v2 on a virtual host.

Environment

Open WebUI Version: v0.3.30
Ollama (if applicable): N/A
Operating System: Ubuntu Server 20.04
Browser (if applicable): Chrome 129.0.6668.71, Firefox 131.0

Confirmation:

I have read and followed all the instructions provided in the README.md.
I am on 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 the exact steps to reproduce the bug in the "Steps to Reproduce" section below.

@jonnywright commented on GitHub (Oct 4, 2024): ## Same issue here but with different environment: # Bug Report ## Installation Method Docker via. docker compose v2 on a virtual host. ## Environment - **Open WebUI Version:** v0.3.30 - **Ollama (if applicable):** N/A - **Operating System:** Ubuntu Server 20.04 - **Browser (if applicable):** Chrome 129.0.6668.71, Firefox 131.0 **Confirmation:** - [X] I have read and followed all the instructions provided in the README.md. - [X] I am on 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 the exact steps to reproduce the bug in the "Steps to Reproduce" section below.

GiteaMirror commented

2025-11-11 15:02:29 -06:00

@jorikvanveen commented on GitHub (Oct 18, 2024):

I made a hacky patch to fix this while we're waiting for a more permanent solution. It overrides the title generation model with 4o-mini whenever the original model string contains "o1".

diff --git a/backend/open_webui/main.py b/backend/open_webui/main.py
index 7086a3cc..91bf2ba5 100644
--- a/backend/open_webui/main.py
+++ b/backend/open_webui/main.py
@@ -1453,6 +1453,8 @@ async def generate_title(form_data: dict, user=Depends(get_verified_user)):
     # If the user has a custom task model, use that model
     task_model_id = get_task_model_id(model_id)
     print(task_model_id)
+    if "o1" in task_model_id:
+        task_model_id = "gpt-4o-mini"

     model = app.state.MODELS[task_model_id]

I have a repo with this patch applied here: https://github.com/jorikvanveen/open-webui. Do note that I will likely not be maintaining it so don't rely on it for anything important.

@jorikvanveen commented on GitHub (Oct 18, 2024): I made a hacky patch to fix this while we're waiting for a more permanent solution. It overrides the title generation model with 4o-mini whenever the original model string contains "o1". ```diff diff --git a/backend/open_webui/main.py b/backend/open_webui/main.py index 7086a3cc..91bf2ba5 100644 --- a/backend/open_webui/main.py +++ b/backend/open_webui/main.py @@ -1453,6 +1453,8 @@ async def generate_title(form_data: dict, user=Depends(get_verified_user)): # If the user has a custom task model, use that model task_model_id = get_task_model_id(model_id) print(task_model_id) + if "o1" in task_model_id: + task_model_id = "gpt-4o-mini" model = app.state.MODELS[task_model_id] ``` I have a repo with this patch applied here: https://github.com/jorikvanveen/open-webui. Do note that I will likely not be maintaining it so don't rely on it for anything important.

GiteaMirror commented

2025-11-11 15:02:29 -06:00

@Ryan526 commented on GitHub (Oct 28, 2024):

is there a cap set for max_completion_tokens on title generation? If there is simply removing it will make this work. Same issue I had on a different repo.

@Ryan526 commented on GitHub (Oct 28, 2024): is there a cap set for max_completion_tokens on title generation? If there is simply removing it will make this work. Same issue I had on a different repo.

GiteaMirror commented

2025-11-11 15:02:29 -06:00

@Ryan526 commented on GitHub (Oct 28, 2024):

is there a cap set for max_completion_tokens on title generation? If there is simply removing it will make this work. Same issue I had on a different repo.

https://github.com/open-webui/open-webui/blob/21b8ca345904005f4b87666e4e0ac5bb8df309ad/backend/open_webui/main.py#L1574

The easy way would be to just remove this line. Its not required in the payload and in most cases (besides o1 models) the total tokens used is still going to be below 50 using that default prompt. Reasoning tokens in the o1 models are blowing through all those tokens giving you no reply to make a title. Until they give us a way to control reasoning tokens for o1 models there isn't any other way of doing it other than setting a separate model when using o1 or setting max_completion_tokens to something like 5000+.

@Ryan526 commented on GitHub (Oct 28, 2024): > is there a cap set for max_completion_tokens on title generation? If there is simply removing it will make this work. Same issue I had on a different repo. https://github.com/open-webui/open-webui/blob/21b8ca345904005f4b87666e4e0ac5bb8df309ad/backend/open_webui/main.py#L1574 The easy way would be to just remove this line. Its not required in the payload and in most cases (besides o1 models) the total tokens used is still going to be below 50 using that default prompt. Reasoning tokens in the o1 models are blowing through all those tokens giving you no reply to make a title. Until they give us a way to control reasoning tokens for o1 models there isn't any other way of doing it other than setting a separate model when using o1 or setting `max_completion_tokens` to something like 5000+.

GiteaMirror commented

2025-11-11 15:02:30 -06:00

@Ryan526 commented on GitHub (Oct 28, 2024):

I was gonna do a pull request to remove the max_completion_tokens when using o1 models but I realized thats kind of pointless when you are able to change your task model in the admin panel.

@Ryan526 commented on GitHub (Oct 28, 2024): I was gonna do a pull request to remove the max_completion_tokens when using o1 models but I realized thats kind of pointless when you are able to change your task model in the admin panel. ![image](https://github.com/user-attachments/assets/51ec7f49-57df-4d41-b3e0-ad6c9e1985db)

GiteaMirror commented

2025-11-11 15:02:30 -06:00

@DmitriyAlergant commented on GitHub (Nov 28, 2024):

Frankly, the main issue here is a poor choice of a default for Task Model to 'same model' - especially given some non-intuitivity of this part of the admin UI, and where it is located (under Interface).

Instead of fixing "Making o1 work and don't fail for title generation", the right question is how to make sure people don't default to "same model", which can be o1 for all tasks in the first place. And that applies to all tasks not only Title Generation.

I would suggest replacing the "Current Model" option for TASK_MODEL_EXTERNAL(which is the default) to spell "Auto-Select". Which BTW won't even require any config database migrations; The default value is actually simply "". We only change how we render it to the user.

When the default option begins showing itself as Auto-Select, we are now authorized to implement a heuristic selection function, something along the lines of...

If gpt-4o-mini is in the list of available models (as a substring of model ID), use it
otherwise if 'flash' is in the list of available models (as a substring of model ID), use it
otherwise if 'haiku' is in the list of available models (as a substring of model ID), use it
otherwise if '8b' is in the list of available models (as a substring of model ID), use it - any 8b model
otherwise use current model if it does not have "o1" in its ID.
if current model has "o1" then use first model that does not

@tjbck thoughts? A PR would be trivial to raise (maybe I'd do this) but first wanted your input on the approach to avoid wasting effort

@DmitriyAlergant commented on GitHub (Nov 28, 2024): Frankly, the main issue here is a poor choice of a default for Task Model to 'same model' - especially given some non-intuitivity of this part of the admin UI, and where it is located (under Interface). Instead of fixing "Making o1 work and don't fail for title generation", the right question is how to make sure people don't default to "same model", which can be o1 for all tasks in the first place. And that applies to all tasks not only Title Generation. I would suggest replacing the "Current Model" option for TASK_MODEL_EXTERNAL(which is the default) to spell "**Auto-Select**". Which BTW won't even require any config database migrations; The default value is actually simply "". We only change how we render it to the user. When the default option begins showing itself as Auto-Select, we are now authorized to implement a heuristic selection function, something along the lines of... * If gpt-4o-mini is in the list of available models (as a substring of model ID), use it * otherwise if 'flash' is in the list of available models (as a substring of model ID), use it * otherwise if 'haiku' is in the list of available models (as a substring of model ID), use it * otherwise if '8b' is in the list of available models (as a substring of model ID), use it - any 8b model * otherwise use current model if it does not have "o1" in its ID. * if current model has "o1" then use first model that does not @tjbck thoughts? A PR would be trivial to raise (maybe I'd do this) but first wanted your input on the approach to avoid wasting effort