mirror of
https://github.com/open-webui/open-webui.git
synced 2026-05-07 03:18:23 -05:00
[GH-ISSUE #13648] feat: Disambiguate models with identical names from different sources in workspace model configuration #16982
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/open-webui#16982
Reference in New Issue
Block a user
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?
Originally created by @Geequlim on GitHub (May 7, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/13648
Check Existing Issues
Problem Description
When creating a model in a workspace, the base model is configured using only the model name. This causes a problem when multiple external sources (e.g., knowledge bases or APIs) provide models with the same name. The system cannot distinguish which version of the model to use, leading to confusion or incorrect behavior.
For example:
External Knowledge Base A provides a model named google/gemma-3-27b-it via its API, intended for answering knowledge type A.
External Knowledge Base B also provides a model named google/gemma-3-27b-it, but intended for knowledge type B.
Since the workspace model configuration only uses the model name, it's not possible to specify which provider's version should be used.
Desired Solution you'd like
Introduce a way to distinguish models by including additional metadata in the base model configuration—such as the source provider, a unique identifier, or a namespace. This would allow users to specify exactly which source's model should be used, even when model names are identical.
Alternatives Considered
Manually renaming models when importing them (e.g., appending a suffix like -from-A or -from-B), though this is error-prone and not scalable.
Using different workspaces for different providers, but this breaks unified model management and increases complexity.
Additional Context
This feature would greatly help teams using multiple external knowledge providers who might rely on popular open-source models with the same names. Supporting disambiguation at the system level would improve robustness and reduce configuration errors in multi-source environments.
@Classic298 commented on GitHub (May 7, 2025):
You can add a provider prefix
Admin settings > connections > edit the connection
there you can add a prefix (custom name) which will be added in front of every single model you fetch from this provider.