[GH-ISSUE #16351] generate chat title button should use TASK_MODEL instead of current chat model #17870

New Issue

GiteaMirror · 2026-04-19T23:45:55-05:00

GiteaMirror commented

2026-04-19 23:45:55 -05:00

Originally created by @tandav on GitHub (Aug 7, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/16351

Check Existing Issues

I have searched the existing issues and discussions.
I am using the latest version of Open WebUI.

Installation Method

Docker

Open WebUI Version

v0.6.18

Ollama Version (if applicable)

No response

Operating System

docker, ubuntu

Browser (if applicable)

Chrome

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

As far as I understand chat titles should be always be generated using TASK_MODEL model (gpt-4.1-mini in my case)

Actual Behavior

When pressing on Generate chat title button (see picture) the request is made using current chat model

Steps to Reproduce

Set TASK_MODEL to some model, e.g gpt-4.1-mini from the UI or using environment variable
create new chat with model different that in step 1
Click rename on some chat and then press Generate button
The title will be generated using chat's current model instead of TASK_MODEL (see the browser network tab and check request payload)

Logs & Screenshots

Here the JSON payload of the request, the o4-mini-deep-research is used in my case (chat's model)

{
"model": "o4-mini-deep-research",
"messages": [
...

Additional Information

No response

Originally created by @tandav on GitHub (Aug 7, 2025). Original GitHub issue: https://github.com/open-webui/open-webui/issues/16351 ### Check Existing Issues - [x] I have searched the existing issues and discussions. - [x] I am using the latest version of Open WebUI. ### Installation Method Docker ### Open WebUI Version v0.6.18 ### Ollama Version (if applicable) _No response_ ### Operating System docker, ubuntu ### Browser (if applicable) Chrome ### 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 As far as I understand chat titles should be always be generated using `TASK_MODEL` model (`gpt-4.1-mini` in my case) ### Actual Behavior When pressing on **Generate** chat title button (see picture) the request is made using current chat model ### Steps to Reproduce 1. Set TASK_MODEL to some model, e.g `gpt-4.1-mini` from the UI or using environment variable 2. create new chat with model different that in step 1 3. Click rename on some chat and then press **Generate** button 4. The title will be generated using chat's current model instead of TASK_MODEL (see the browser network tab and check request payload) ### Logs & Screenshots <img width="312" height="79" alt="Image" src="https://github.com/user-attachments/assets/892f5260-4247-4e4f-9351-1ffbe3ce4a83" /> Here the JSON payload of the request, the `o4-mini-deep-research` is used in my case (chat's model) { "model": "o4-mini-deep-research", "messages": [ ... ### Additional Information _No response_

GiteaMirror added the bug label 2026-04-19 23:45:55 -05:00

GiteaMirror closed this issue

2026-04-19 23:45:56 -05:00

GiteaMirror commented

2026-04-19 23:45:57 -05:00

@tjbck commented on GitHub (Aug 7, 2025):

it does.

@tjbck commented on GitHub (Aug 7, 2025): it does.

GiteaMirror commented

2026-04-19 23:45:58 -05:00

@ajitam commented on GitHub (Sep 23, 2025):

no it doesn't.
I try setting it up in UI and in ENV.
In any case "current model" is used.

@ajitam commented on GitHub (Sep 23, 2025): no it doesn't. I try setting it up in UI and in ENV. In any case "current model" is used.

GiteaMirror commented

2026-04-19 23:45:58 -05:00

@druellan commented on GitHub (Oct 3, 2025):

I also found this issue recently.
My test:

Make sure you have a task model selected in admin settings -> interface (Model-A)
Create a chat session with another model (Model-B)
Delete of disable that model (Model-B)
In the chat title, click on [...] and "rename"
Click on the magic wand to let the AI rename that chat

I get an error that the model can't be found and the title does not change, this aligns with the idea that OWUI is trying to use the current model (Model-B) and not the task model (Model-A).

@druellan commented on GitHub (Oct 3, 2025): I also found this issue recently. My test: - Make sure you have a task model selected in admin settings -> interface (Model-A) - Create a chat session with another model (Model-B) - Delete of disable that model (Model-B) - In the chat title, click on [...] and "rename" - Click on the magic wand to let the AI rename that chat I get an error that the model can't be found and the title does not change, this aligns with the idea that OWUI is trying to use the current model (Model-B) and not the task model (Model-A).

GiteaMirror commented

2026-04-19 23:45:59 -05:00

@tjbck commented on GitHub (Oct 3, 2025):

@ajitam did you check the code? it always overwrites the model from the backend.

@tjbck commented on GitHub (Oct 3, 2025): @ajitam did you check the code? it always overwrites the model from the backend.

GiteaMirror commented

2026-04-19 23:45:59 -05:00

@ajitam commented on GitHub (Oct 3, 2025):

@tjbck no I haven't checked the code, I'm relaying on my QS tests :)
In any case I solved my problem with setting fallback model because I was getting 429 from Bedrock.

I have a feeling that it has something to do how (in which order) settings are set.
But currently all I can offer is my test:

set task model to Model A
Use Model B
in inspector I see that Model B is used for title generation

@ajitam commented on GitHub (Oct 3, 2025): @tjbck no I haven't checked the code, I'm relaying on my QS tests :) In any case I solved my problem with setting fallback model because I was getting `429` from Bedrock. I have a feeling that it has something to do how (in which order) settings are set. But currently all I can offer is my test: - set task model to Model A - Use Model B - in inspector I see that Model B is used for title generation

GiteaMirror commented

2026-04-19 23:46:00 -05:00

@druellan commented on GitHub (Oct 5, 2025):

I was taking a look at seems that the frontend is the one sending the wrong model to the endpoint.

The problem is in src\lib\components\layout\Sidebar\ChatItem.svelte around line 290
const model = chat.chat.models.at(0) ?? chat.models.at(0) ?? '';
The code is seeking for the chat model, not the task model.

My fix is to do something like this:

const taskConfig = await getTaskConfig(localStorage.token);
const taskModel = taskConfig.TASK_MODEL ?? '';

But I'm using a call to the backend, not sure if there is a way to get the taskmodel without the extra call.

I confirmed this looking at the form_data variable in backend\open_webui\routers\tasks.py around line 159

@router.post("/title/completions")
async def generate_title(
    request: Request, form_data: dict, user=Depends(get_verified_user)
):

As far as I can see there is no override there, form_data["model"] has the same model passed from the frontend.

@druellan commented on GitHub (Oct 5, 2025): I was taking a look at seems that the frontend is the one sending the wrong model to the endpoint. The problem is in `src\lib\components\layout\Sidebar\ChatItem.svelte` around line 290 `const model = chat.chat.models.at(0) ?? chat.models.at(0) ?? '';` The code is seeking for the chat model, not the task model. My fix is to do something like this: ``` const taskConfig = await getTaskConfig(localStorage.token); const taskModel = taskConfig.TASK_MODEL ?? ''; ``` But I'm using a call to the backend, not sure if there is a way to get the taskmodel without the extra call. I confirmed this looking at the `form_data` variable in `backend\open_webui\routers\tasks.py` around line 159 ``` @router.post("/title/completions") async def generate_title( request: Request, form_data: dict, user=Depends(get_verified_user) ): ``` As far as I can see there is no override there, `form_data["model"]` has the same model passed from the frontend.

GiteaMirror referenced this issue

2026-04-20 05:28:37 -05:00

[PR #17870] [CLOSED] feat: Add Footnote Reference Support to Markdown #24582

GiteaMirror referenced this issue

2026-04-25 12:37:45 -05:00

[PR #17870] [CLOSED] feat: Add Footnote Reference Support to Markdown #40212

GiteaMirror referenced this issue

2026-04-29 22:57:49 -05:00

[PR #17870] [CLOSED] feat: Add Footnote Reference Support to Markdown #47630

GiteaMirror referenced this issue

2026-05-06 08:12:15 -05:00

[PR #17870] [CLOSED] feat: Add Footnote Reference Support to Markdown #63438