[GH-ISSUE #24869] issue: Hidden base models are still shown in Automations model selector when required for Workspace Models #123727

New Issue

2026-05-21T03:12:18-05:00

GiteaMirror commented

2026-05-21 03:12:18 -05:00

Originally created by @michimalek-besitec on GitHub (May 18, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/24869

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

0.9.2

Ollama Version (if applicable)

No response

Operating System

Ubuntu

Browser (if applicable)

No response

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

Hidden base models should not appear in user-facing model selectors, including the Automations model selector.

If a user has access to a Workspace Model, they should be able to use that Workspace Model without needing direct visibility of the underlying base model.

Example:

User should see: Besitec Assist
User should see: Besitec Assist Advanced
User should not see: llm-besitec-assist
User should not see: llm-besitec-assist-advanced

Actual Behavior

Workspace Models require the underlying base models to be public/accesssible for normal users. If the base models are not public/accesssible, the Workspace Models fail with:

Model not found

When the base models are made public and hidden:

The Workspace Models work.
The base models are hidden from the normal chat model selector.
The same hidden base models still appear in the Automations model selector.

This exposes technical LiteLLM base model aliases to users in Automations, even though they are intended to be hidden implementation details.

Steps to Reproduce

Configure LiteLLM model aliases in OpenWebUI Admin Settings, for example:
- llm-besitec-assist
- llm-besitec-assist-advanced
Create Workspace Models on top of those base models:
- Besitec Assist → base model: llm-besitec-assist
- Besitec Assist Advanced → base model: llm-besitec-assist-advanced
Make the Workspace Models available to normal users.
Set the underlying LiteLLM base models to not public / not accessible.
Log in as a normal user and try to use Besitec Assist.
The request fails with:

Model not found
Make the LiteLLM base models public but hidden.
Confirm that the hidden base models are no longer shown in the normal chat model selector.
Open Automations.
Create a new automation.
Open the model selector inside the Automation creation modal.
Observe that the hidden base models still appear as selectable models.

Logs & Screenshots

Admin Settings → Models
Shows the LiteLLM base models, including hidden/public base models.
Automations → New Automation → Model Selector
Shows hidden base models appearing in the Automation model selector.

Relevant error when base models are not public/accesssible:

Model not found

Additional Information

This setup is used in an enterprise OpenWebUI deployment with LiteLLM as the model gateway.

The intended architecture is:

LiteLLM provides technical model aliases and provider routing.
OpenWebUI Workspace Models provide user-facing assistant presets.
Normal users should interact only with Workspace Models.
Technical LiteLLM base models should remain hidden from user-facing model selectors.

Example setup:

LiteLLM base models:

llm-besitec-assist
llm-besitec-assist-advanced

Workspace Models:

Besitec Assist → llm-besitec-assist
Besitec Assist Advanced → llm-besitec-assist-advanced

The current behavior creates a governance issue:

If base models are private, Workspace Models fail for normal users.
If base models are public and hidden, Workspace Models work, but hidden technical models still appear in Automations.

This makes it difficult to cleanly separate user-facing assistant presets from internal base models / routing aliases.

A possible fix would be one of the following:

Respect the hidden flag in all user-facing model selectors, including Automations.
Allow Workspace Models to execute even when the user does not have direct visibility of the underlying base model.
Add separate visibility controls, such as:
- available as direct chat model
- available as Workspace Model base
- available in Automations
- admin-only
- hidden from users

Originally created by @michimalek-besitec on GitHub (May 18, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/24869 ### 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 0.9.2 ### Ollama Version (if applicable) _No response_ ### Operating System Ubuntu ### Browser (if applicable) _No response_ ### 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 Hidden base models should not appear in user-facing model selectors, including the Automations model selector. If a user has access to a Workspace Model, they should be able to use that Workspace Model without needing direct visibility of the underlying base model. Example: - User should see: `Besitec Assist` - User should see: `Besitec Assist Advanced` - User should not see: `llm-besitec-assist` - User should not see: `llm-besitec-assist-advanced` ### Actual Behavior Workspace Models require the underlying base models to be public/accesssible for normal users. If the base models are not public/accesssible, the Workspace Models fail with: `Model not found` When the base models are made public and hidden: - The Workspace Models work. - The base models are hidden from the normal chat model selector. - The same hidden base models still appear in the Automations model selector. This exposes technical LiteLLM base model aliases to users in Automations, even though they are intended to be hidden implementation details. ### Steps to Reproduce 1. Configure LiteLLM model aliases in OpenWebUI Admin Settings, for example: - `llm-besitec-assist` - `llm-besitec-assist-advanced` 2. Create Workspace Models on top of those base models: - `Besitec Assist` → base model: `llm-besitec-assist` - `Besitec Assist Advanced` → base model: `llm-besitec-assist-advanced` 3. Make the Workspace Models available to normal users. 4. Set the underlying LiteLLM base models to not public / not accessible. 5. Log in as a normal user and try to use `Besitec Assist`. 6. The request fails with: `Model not found` 7. Make the LiteLLM base models public but hidden. 8. Confirm that the hidden base models are no longer shown in the normal chat model selector. 9. Open Automations. 10. Create a new automation. 11. Open the model selector inside the Automation creation modal. 12. Observe that the hidden base models still appear as selectable models. ### Logs & Screenshots 1. Admin Settings → Models Shows the LiteLLM base models, including hidden/public base models. 2. Automations → New Automation → Model Selector Shows hidden base models appearing in the Automation model selector. Relevant error when base models are not public/accesssible: `Model not found` ### Additional Information This setup is used in an enterprise OpenWebUI deployment with LiteLLM as the model gateway. The intended architecture is: - LiteLLM provides technical model aliases and provider routing. - OpenWebUI Workspace Models provide user-facing assistant presets. - Normal users should interact only with Workspace Models. - Technical LiteLLM base models should remain hidden from user-facing model selectors. Example setup: LiteLLM base models: - `llm-besitec-assist` - `llm-besitec-assist-advanced` Workspace Models: - `Besitec Assist` → `llm-besitec-assist` - `Besitec Assist Advanced` → `llm-besitec-assist-advanced` The current behavior creates a governance issue: - If base models are private, Workspace Models fail for normal users. - If base models are public and hidden, Workspace Models work, but hidden technical models still appear in Automations. This makes it difficult to cleanly separate user-facing assistant presets from internal base models / routing aliases. A possible fix would be one of the following: 1. Respect the hidden flag in all user-facing model selectors, including Automations. 2. Allow Workspace Models to execute even when the user does not have direct visibility of the underlying base model. 3. Add separate visibility controls, such as: - available as direct chat model - available as Workspace Model base - available in Automations - admin-only - hidden from users

GiteaMirror added the bug label 2026-05-21 03:12:18 -05:00

GiteaMirror commented

2026-05-21 03:12:20 -05:00

@owui-terminator[bot] commented on GitHub (May 18, 2026):

🔍 Related Issues Found

I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions:

🟣 #24829 issue: Public workspace model alias fails with "model not found" when base model is private (regression from v0.8.6)
This is the closest match: it reports the same 'model not found' failure when a public workspace model depends on a private base model. Your issue extends that behavior to hidden base models and specifically notes the Automations selector exposing them.
by mikisseth · bug
🟣 #23946 issue: 400 Model not found for Workspace Models whose base models are not available to the user
This earlier bug also describes '400 Model not found' for workspace models when the underlying base model is not available to the user. It matches the core access-control problem behind your report, even though it does not mention Automations.
by itsHenry35 · bug
🟢 #24074 enh: automations
This is the Automations feature issue, which is the subsystem where you observed the hidden base models leaking into the model selector. It is relevant for the UI side of the problem, even though it is broader and not about visibility filtering specifically.
by tjbck

💡 If your issue is a duplicate, please close it and add any additional details to the existing issue instead.

This comment was generated automatically. React with 👍 if helpful, 👎 if not.

@owui-terminator[bot] commented on GitHub (May 18, 2026):  🔍 **Related Issues Found** I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions: 1. 🟣 [#24829](https://github.com/open-webui/open-webui/issues/24829) **issue: Public workspace model alias fails with "model not found" when base model is private (regression from v0.8.6)** *This is the closest match: it reports the same 'model not found' failure when a public workspace model depends on a private base model. Your issue extends that behavior to hidden base models and specifically notes the Automations selector exposing them.* *by mikisseth · `bug`* 2. 🟣 [#23946](https://github.com/open-webui/open-webui/issues/23946) **issue: 400 Model not found for Workspace Models whose base models are not available to the user** *This earlier bug also describes '400 Model not found' for workspace models when the underlying base model is not available to the user. It matches the core access-control problem behind your report, even though it does not mention Automations.* *by itsHenry35 · `bug`* 3. 🟢 [#24074](https://github.com/open-webui/open-webui/issues/24074) **enh: automations** *This is the Automations feature issue, which is the subsystem where you observed the hidden base models leaking into the model selector. It is relevant for the UI side of the problem, even though it is broader and not about visibility filtering specifically.* *by tjbck* --- 💡 If your issue is a duplicate, please close it and add any additional details to the existing issue instead. *This comment was generated automatically.* React with 👍 if helpful, 👎 if not.

GiteaMirror commented

2026-05-21 03:12:22 -05:00

@michimalek-besitec commented on GitHub (May 18, 2026):

This is not a duplicate #24829 is definetly related, but my issue extends this current limitation.

@michimalek-besitec commented on GitHub (May 18, 2026): This is not a duplicate #24829 is definetly related, but my issue extends this current limitation.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/open-webui#123727