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.8.7
Ollama Version (if applicable)
No response
Operating System
Ubuntu
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
Model aliases defined in the Workspace to be usable from the /openai router.
Actual Behavior
When using the /openai proxy router, all the alias models return 404.
Steps to Reproduce
Add model
Add alias model in Workspace tab.
Send a prompt using http://localhost:3000/openai as your base url.
OpenWebUI will return 404, this is related to the openai proxy not resolving aliased models back to their base model before calling the inference backend.
Logs & Screenshots
N/a
Additional Information
No response
Originally created by @gaby on GitHub (Mar 2, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/22134
Originally assigned to: @Classic298 on GitHub.
### 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.8.7
### Ollama Version (if applicable)
_No response_
### Operating System
Ubuntu
### 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
Model aliases defined in the Workspace to be usable from the `/openai` router.
### Actual Behavior
When using the `/openai` proxy router, all the alias models return `404`.
### Steps to Reproduce
1. Add model
2. Add alias model in `Workspace` tab.
3. Send a prompt using `http://localhost:3000/openai` as your base url.
4. OpenWebUI will return 404, this is related to the openai proxy not resolving aliased models back to their base model before calling the inference backend.
### Logs & Screenshots
N/a
### Additional Information
_No response_
GiteaMirror
added the bug label 2026-05-21 02:01:08 -05:00
"Intended. Only /api/chat/completion should be used for internal models."
<!-- gh-comment-id:3986125588 -->
@Classic298 commented on GitHub (Mar 2, 2026):
"Intended. Only /api/chat/completion should be used for internal models."
@Classic298 @tjbck Why only chat completions though? The aliases allow us to use models from our code base without having to be updating the code all the time when new models get added.
<!-- gh-comment-id:3987802176 -->
@gaby commented on GitHub (Mar 3, 2026):
@Classic298 @tjbck Why only chat completions though? The aliases allow us to use models from our code base without having to be updating the code all the time when new models get added.
Without aliases we have to retag/release our software everytime a model changes. It also makes updating n8n very complicated since we have to change every single workflow.
<!-- gh-comment-id:3998260156 -->
@gaby commented on GitHub (Mar 4, 2026):
@tjbck @Classic298 Reconsideration:
Without aliases we have to retag/release our software everytime a model changes. It also makes updating n8n very complicated since we have to change every single workflow.
@gaby i will turn this into a discussion to give it a second life - we can discuss it there i think. I also think resolving workspace models could be a neat feature - now that i think about it more, this is more a feature request than a bug
<!-- gh-comment-id:3998538244 -->
@Classic298 commented on GitHub (Mar 4, 2026):
@gaby i will turn this into a discussion to give it a second life - we can discuss it there i think. I also think resolving workspace models could be a neat feature - now that i think about it more, this is more a feature request than a bug
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @gaby on GitHub (Mar 2, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/22134
Originally assigned to: @Classic298 on GitHub.
Check Existing Issues
Installation Method
Docker
Open WebUI Version
0.8.7
Ollama Version (if applicable)
No response
Operating System
Ubuntu
Browser (if applicable)
Firefox
Confirmation
README.md.Expected Behavior
Model aliases defined in the Workspace to be usable from the
/openairouter.Actual Behavior
When using the
/openaiproxy router, all the alias models return404.Steps to Reproduce
Workspacetab.http://localhost:3000/openaias your base url.Logs & Screenshots
N/a
Additional Information
No response
@Classic298 commented on GitHub (Mar 2, 2026):
will take a look here
@Classic298 commented on GitHub (Mar 2, 2026):
might be fixed by
@gaby
https://github.com/open-webui/open-webui/pull/22147
@Classic298 commented on GitHub (Mar 2, 2026):
testing wanted
@Classic298 commented on GitHub (Mar 2, 2026):
"Intended. Only /api/chat/completion should be used for internal models."
@gaby commented on GitHub (Mar 3, 2026):
@Classic298 @tjbck Why only chat completions though? The aliases allow us to use models from our code base without having to be updating the code all the time when new models get added.
@gaby commented on GitHub (Mar 4, 2026):
@tjbck @Classic298 Reconsideration:
Without aliases we have to retag/release our software everytime a model changes. It also makes updating n8n very complicated since we have to change every single workflow.
@Classic298 commented on GitHub (Mar 4, 2026):
@gaby i will turn this into a discussion to give it a second life - we can discuss it there i think. I also think resolving workspace models could be a neat feature - now that i think about it more, this is more a feature request than a bug