mirror of
https://github.com/open-webui/open-webui.git
synced 2026-07-16 06:03:26 -05:00
[GH-ISSUE #2863] feat: Endpoint information presented with model (and used in search) #83783
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/open-webui#83783
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 @VertexMachine on GitHub (Jun 5, 2024).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/2863
Is your feature request related to a problem? Please describe.
When using multiple endpoints it's getting hard to distinguish between each of them if they host the same models. Here is example when you search for gpt4 and use both OpenAI API and OpenRouter:
Here is another example from workspace tab showing name clash between OpenRouter and Infermatics:
Another potential issue with current implementation: if unique key in the code is model id (which is a model name) - there is potential for name clash if multiple endpoints use the same model id. This is not something I encountered yet and it's not what this feature suggestion is about (but might be related and might need separate task).
Describe the solution you'd like
Providing endpoint name with the model name. Providing also endpoint name in the model details tab. It could be made by adding endpoint name as a tag for example.
Describe alternatives you've considered
Right now I've manually tagged one endpoint, which allows me to see which models are theirs:
Additional context
n/a
Edit: clarified that model id is right now for me a potential issue, not the actual issue I've already encountered.
@justinh-rahb commented on GitHub (Jun 5, 2024):
Unfortunately, if we were to change the model IDs... every existing model config anyone has customized will break and revert back to the default as shown in your list. Not saying you haven't identified a genuine issue, but the proposed fix is going to be a non-starter.
@VertexMachine commented on GitHub (Jun 5, 2024):
It's not necessary to break everything with proper configuration management. Encounter old config => either try to auto upgrade or ask/inform user about problem (if not possible to auto upgrade). Also... sometimes you have to just break backwards compatibility, e.g., like open-webui did with modelfiles (which you provided guide for users on how to upgrade :D ).
@VertexMachine commented on GitHub (Jun 5, 2024):
But also there are two issues here. The model id clash is potential problem that I haven't encountered yet. Distinguishing between models from different APIs that are named very similar - is issue that can be tackled differently (e.g. with eg. tags or other improvement in UX)
Edit: I just mentioned potential model id name clash as I realized it can be an issue while describing the feature. I will update the description I made previously to make it clear. It probably should be separate issue on it's own.
@tjbck commented on GitHub (Jun 5, 2024):
One workaround for id clash issue would be using a manifold pipeline proxy, which I believe should be the recommended solution.
@justinh-rahb commented on GitHub (Jun 6, 2024):
True, putting your OpenAI endpoints in as manifold pipelines would give them a unique prefix 👌
@MicahZoltu commented on GitHub (Oct 9, 2024):
How does one do any of the workarounds described here (manifold whatevers and manually tagged endpoints)?
I pay for access to a large collection of models through a couple different services with different pricing/billing systems. I would prefer to use models from A over B when they both offer the same model, but I currently can't figure out which models are from which service. I don't mind a workaround, but the current situation is a pretty big problem for me.
@tjbck commented on GitHub (Nov 19, 2024):
Admins can now hover over the model selector to check the model id.
In conjunction with the connections prefix id feature, this issue is essentially resolved.