github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-05-06 10:58:17 -05:00
Code Issues 1.3k Packages Projects Releases 126 Wiki Activity

[GH-ISSUE #19194] issue: Prefix ID doesn't reliably show up in model names. #18804

New Issue
Closed
opened 2026-04-20 01:02:00 -05:00 by GiteaMirror · 4 comments
GiteaMirror commented 2026-04-20 01:02:00 -05:00
Owner
Copy Link

Originally created by @MicahZoltu on GitHub (Nov 15, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/19194

Check Existing Issues

  • 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

v0.6.15

Ollama Version (if applicable)

0.9.3

Operating System

Windows

Browser (if applicable)

Firefox

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

Prefix ID setting on a connection adds a prefix to all models for that connection.

Actual Behavior

Prefix ID sometimes adds a prefix to models, and sometimes doesn't.

Steps to Reproduce

  1. Add an external connection with a prefix ID of Apple
  2. Add an external connection with a prefix ID of Banana
  3. Add a local connection with a prefix ID of Cherry
  4. Look at your models list in the admin settings.
  5. Notice that the prefix ID shows up in the name for Apple, but not for Banana or Cherry.
  6. Look at your models drop down in a new chat.
  7. Notice that the prefix ID for all models shows on tooltip, but the prefix ID also shows in the primary model name for models coming from Apple.

Logs & Screenshots

In the following screenshots from the model drop down list in a new chat, the models are from two connections, one with PPQ prefix ID and the other with Together prefix ID. Each connection also has a tag associated with it that shows up correctly. Notice that the Together prefix shows up in both versions of the model name, while the PPQ prefix only shows up in the tooltip.
Image
Image
Image

The following screenshot shows the model list in the admin panel while searching for specific models. Notice that you cannot search for models by connection in that list for PPQ (nothing shows up) but you cannot search for models by prefix ID in that list.
Image
Image
Image
Image
Image

Additional Information

Similar problems have been reported and discussed in #7999, #8941, and #9819 but they all end with the same response which is discussing manually added models. The issue being described here occurs when you do not manually specify any model IDs in the list.

This has been a bug for several versions, and after speaking on Discord with some people I have explicitly decided not to update to latest because I currently use the tagging system as a workaround, and tagging behavior has changed in latest version so IIUC my tag workaround will no longer work. I believe the bug is likely still present in latest version though, since I haven't seen any fixes for it and it has been present for some time.

I have left out docker container logs and browser console logs because there doesn't appear to be anything relevant in them. If there are specific container/browser logs that would help please let me know and I can get them.

It is worth noting that I believe the prefix ID system used to work as expected, where the prefix ID would show up in the model name in every list, which meant you could search by it and easily see it.

Separately, some people have mentioned that the intended behavior may be that the prefix does not show up in the primary name but only in the tooltip. I believe this behavior goes against user expectations, and degrades the usability of the system because the model search feature currently does not search over the model ID, it only searches over the model name.

The primary thing being reported here is the inconsistency where some connections add the prefix ID to the model name + model ID, while other connections add the prefix ID only to the model ID. At the least, this inconsistency should be fixed. Ideally, it would be fixed so the prefix ID is included in both the name and the ID so that it will be included in search results and readily visible in various model lists without needing to hover over every entry.

This is particularly problematic when you have a large number of models coming from a diverse array of sources and there is a lot of overlap between them. The source is often a very important part of the model selection process, and should be made readily visible to users during any model selection.

Originally created by @MicahZoltu on GitHub (Nov 15, 2025). Original GitHub issue: https://github.com/open-webui/open-webui/issues/19194 ### 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 v0.6.15 ### Ollama Version (if applicable) 0.9.3 ### Operating System Windows ### Browser (if applicable) Firefox ### 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 Prefix ID setting on a connection adds a prefix to all models for that connection. ### Actual Behavior Prefix ID sometimes adds a prefix to models, and sometimes doesn't. ### Steps to Reproduce 1. Add an external connection with a prefix ID of Apple 2. Add an external connection with a prefix ID of Banana 3. Add a local connection with a prefix ID of Cherry 4. Look at your models list in the admin settings. 5. **Notice that the prefix ID shows up in the name for Apple, but not for Banana or Cherry.** 6. Look at your models drop down in a new chat. 7. **Notice that the prefix ID for all models shows on tooltip, but the prefix ID also shows in the primary model name for models coming from Apple.** ### Logs & Screenshots In the following screenshots from the model drop down list in a new chat, the models are from two connections, one with `PPQ` prefix ID and the other with `Together` prefix ID. Each connection *also* has a tag associated with it that shows up correctly. Notice that the `Together` prefix shows up in both versions of the model name, while the `PPQ` prefix only shows up in the tooltip. <img width="330" height="85" alt="Image" src="https://github.com/user-attachments/assets/24b4356f-6209-4427-9418-3005a6b48c03" /> <img width="332" height="120" alt="Image" src="https://github.com/user-attachments/assets/507bd504-fa78-43e5-b9fc-0141d1c1e90c" /> <img width="337" height="119" alt="Image" src="https://github.com/user-attachments/assets/f0aeea18-82bb-4c0d-a03e-c1d4b2bfc7cd" /> The following screenshot shows the model list in the admin panel while searching for specific models. Notice that you cannot search for models by connection in that list for PPQ (nothing shows up) but you cannot search for models by prefix ID in that list. <img width="276" height="624" alt="Image" src="https://github.com/user-attachments/assets/73a08463-b751-4008-8487-751f3a7a4cc3" /> <img width="138" height="83" alt="Image" src="https://github.com/user-attachments/assets/91537a7d-b571-495e-84f9-b75fa041ba91" /> <img width="418" height="413" alt="Image" src="https://github.com/user-attachments/assets/765a1c13-788c-4804-a397-81039b64399a" /> <img width="249" height="173" alt="Image" src="https://github.com/user-attachments/assets/0c5647dc-4b83-4600-abe6-5404671f99a8" /> <img width="128" height="77" alt="Image" src="https://github.com/user-attachments/assets/c435faa9-f1d2-4707-9bed-f8da6d30a73a" /> ### Additional Information Similar problems have been reported and discussed in #7999, #8941, and #9819 but they all end with the same response which is discussing manually added models. The issue being described here occurs when you do not manually specify any model IDs in the list. This has been a bug for several versions, and after speaking on Discord with some people I have explicitly decided not to update to latest because I currently use the tagging system as a workaround, and tagging behavior has changed in latest version so IIUC my tag workaround will no longer work. I believe the bug is likely still present in latest version though, since I haven't seen any fixes for it and it has been present for some time. I have left out docker container logs and browser console logs because there doesn't appear to be anything relevant in them. If there are specific container/browser logs that would help please let me know and I can get them. It is worth noting that I believe the prefix ID system used to work as expected, where the prefix ID would show up in the model name in every list, which meant you could search by it and easily see it. Separately, some people have mentioned that the intended behavior may be that the prefix does not show up in the primary name but only in the tooltip. I believe this behavior goes against user expectations, and degrades the usability of the system because the model search feature currently does not search over the model ID, it only searches over the model name. The primary thing being reported here is the inconsistency where some connections add the prefix ID to the model name + model ID, while other connections add the prefix ID only to the model ID. At the least, this inconsistency should be fixed. Ideally, it would be fixed so the prefix ID is included in both the name and the ID so that it will be included in search results and readily visible in various model lists without needing to hover over every entry. This is particularly problematic when you have a large number of models coming from a diverse array of sources and there is a lot of overlap between them. The source is often a very important part of the model selection process, and should be made readily visible to users during any model selection.
GiteaMirror added the bug label 2026-04-20 01:02:00 -05:00
GiteaMirror commented 2026-04-20 01:02:06 -05:00
Author
Owner
Copy Link

@vmesel commented on GitHub (Nov 16, 2025):

I'm working on a fix for this issue.

<!-- gh-comment-id:3538655234 --> @vmesel commented on GitHub (Nov 16, 2025): I'm working on a fix for this issue.
GiteaMirror commented 2026-04-20 01:02:08 -05:00
Author
Owner
Copy Link

@vmesel commented on GitHub (Nov 16, 2025):

@MicahZoltu, please check if #19209 solves your issue

<!-- gh-comment-id:3538708258 --> @vmesel commented on GitHub (Nov 16, 2025): @MicahZoltu, please check if #19209 solves your issue
GiteaMirror commented 2026-04-20 01:02:09 -05:00
Author
Owner
Copy Link

@tjbck commented on GitHub (Nov 16, 2025):

Intended behaviour.

<!-- gh-comment-id:3539424250 --> @tjbck commented on GitHub (Nov 16, 2025): Intended behaviour.
GiteaMirror commented 2026-04-20 01:02:11 -05:00
Author
Owner
Copy Link

@MicahZoltu commented on GitHub (Nov 17, 2025):

@tjbck Can you explain what the intended behavior is? Right now it feels like the feature randomly works sometimes and randomly doesn't other times. Perhaps this isn't in fact random and there is something that triggers one behavior vs the other, but that is not at all clear from the behavior or the documentation what causes one behavior vs the other.

Is it possible you mistook this issue for a similar feature request that others have requested in the past?

<!-- gh-comment-id:3539647484 --> @MicahZoltu commented on GitHub (Nov 17, 2025): @tjbck Can you explain what the intended behavior is? Right now it feels like the feature randomly works sometimes and randomly doesn't other times. Perhaps this isn't in fact random and there is something that triggers one behavior vs the other, but that is not at all clear from the behavior or the documentation what causes one behavior vs the other. Is it possible you mistook this issue for a similar feature request that others have requested in the past?
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
confirmed
confirmed issue
core
documentation
enhancement
good first issue
help wanted
non-core
pull-request
Mirrored from GitHub Pull Request
 python
question
testing wanted
No Label bug
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/open-webui#18804
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?