github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-05-06 02:48:13 -05:00
Code Issues 1.1k Packages Projects Releases 126 Wiki Activity

[GH-ISSUE #18950] issue: /api/models endpoint slow & very heavy with larger instances #57393

New Issue
Closed
opened 2026-05-05 20:54:18 -05:00 by GiteaMirror · 14 comments
GiteaMirror commented 2026-05-05 20:54:18 -05:00
Owner
Copy Link

Originally created by @taylorwilsdon on GitHub (Nov 5, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/18950

Originally assigned to: @tjbck on GitHub.

Check Existing Issues

  • I have searched for any existing and/or related issues.
  • I have searched for any existing and/or related discussions.
  • I am using the latest version of Open WebUI.

Installation Method

Git Clone

Open WebUI Version

v0.6.34

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

Loading the base route ({yourowuihost.com/}) should load quickly and the necessary metadata for the models picker should just be ID, display name, link etc

Actual Behavior

An enormous payload (in my case, 4.3mb) is returned that includes the entire system prompt for all 350+ models, base64 encoded images for every single one etc.

Interestingly, we have gotten reports from users who aren't admins and can't see all models that their load times are even slower even though the payload is smaller. Potentially due to filtering before it responds?

Steps to Reproduce

Load your OWUI instance with 300 models configured

Logs & Screenshots

Image

Additional Information

No response

Originally created by @taylorwilsdon on GitHub (Nov 5, 2025). Original GitHub issue: https://github.com/open-webui/open-webui/issues/18950 Originally assigned to: @tjbck 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 am using the latest version of Open WebUI. ### Installation Method Git Clone ### Open WebUI Version v0.6.34 ### 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 Loading the base route ({yourowuihost.com/}) should load quickly and the necessary metadata for the models picker should just be ID, display name, link etc ### Actual Behavior An enormous payload (in my case, 4.3mb) is returned that includes the entire system prompt for all 350+ models, base64 encoded images for every single one etc. Interestingly, we have gotten reports from users who aren't admins and can't see all models that their load times are even slower even though the payload is smaller. Potentially due to filtering before it responds? ### Steps to Reproduce Load your OWUI instance with 300 models configured ### Logs & Screenshots <img width="2836" height="1710" alt="Image" src="https://github.com/user-attachments/assets/4759a99b-2770-499e-b5b5-a696e0a054fc" /> ### Additional Information _No response_
GiteaMirror added the bug label 2026-05-05 20:54:18 -05:00
GiteaMirror commented 2026-05-05 20:54:20 -05:00
Author
Owner
Copy Link

@silentoplayz commented on GitHub (Nov 6, 2025):

Related - https://github.com/open-webui/open-webui/issues/17266

<!-- gh-comment-id:3494680591 --> @silentoplayz commented on GitHub (Nov 6, 2025): Related - https://github.com/open-webui/open-webui/issues/17266
GiteaMirror commented 2026-05-05 20:54:21 -05:00
Author
Owner
Copy Link

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

I believe we can just drop profile_image_urls and that should reduce the size of the response significantly

<!-- gh-comment-id:3509262683 --> @tjbck commented on GitHub (Nov 10, 2025): I believe we can just drop profile_image_urls and that should reduce the size of the response significantly
GiteaMirror commented 2026-05-05 20:54:22 -05:00
Author
Owner
Copy Link

@adam-skalicky commented on GitHub (Nov 11, 2025):

I believe the issue is the lack of optimization of the get_filtered_models function in utils/models.py which is invoked as part of /api/models for non-admin users when bypass is not enabled.
https://github.com/open-webui/open-webui/blob/main/backend/open_webui/utils/models.py#L352C5-L352C24

It is invoking has_access for every model without providing the group_id list causing a DB hit to get a group list for the user for each model.

If you examine the get_models_by_user_id function in models/models.py it preloads the user group IDs prior to looping through the models.
https://github.com/open-webui/open-webui/blob/main/backend/open_webui/models/models.py#L206

Testing the runtime out locally with stubbed responses, I see a ~4.7s response time in our environment with 400+ models with a simulated 10ms delay on the group fetch, but preloading the group IDs brings this to ~0.2s.

I think /api/models should either move to using the get_models_by_user_id function or get_filtered_models should be updated to preload the group IDs.

<!-- gh-comment-id:3514493527 --> @adam-skalicky commented on GitHub (Nov 11, 2025): I believe the issue is the lack of optimization of the `get_filtered_models` function in `utils/models.py` which is invoked as part of /api/models for non-admin users when bypass is not enabled. https://github.com/open-webui/open-webui/blob/main/backend/open_webui/utils/models.py#L352C5-L352C24 It is invoking `has_access` for every model without providing the `group_id` list causing a DB hit to get a group list for the user for each model. If you examine the `get_models_by_user_id` function in `models/models.py` it preloads the user group IDs prior to looping through the models. https://github.com/open-webui/open-webui/blob/main/backend/open_webui/models/models.py#L206 Testing the runtime out locally with stubbed responses, I see a ~4.7s response time in our environment with 400+ models with a simulated 10ms delay on the group fetch, but preloading the group IDs brings this to ~0.2s. I think /`api/models` should either move to using the `get_models_by_user_id` function or `get_filtered_models` should be updated to preload the group IDs.
GiteaMirror commented 2026-05-05 20:54:24 -05:00
Author
Owner
Copy Link

@adam-skalicky commented on GitHub (Nov 11, 2025):

I see get_filtered_models has additional logic that get_models_by_user_id would not have without a bit of refactoring. I will create a PR to suggest the group pre-seed for has_access like get_models_by_user_id

<!-- gh-comment-id:3514504000 --> @adam-skalicky commented on GitHub (Nov 11, 2025): I see `get_filtered_models` has additional logic that `get_models_by_user_id` would not have without a bit of refactoring. I will create a PR to suggest the group pre-seed for has_access like `get_models_by_user_id`
GiteaMirror commented 2026-05-05 20:54:24 -05:00
Author
Owner
Copy Link

@adam-skalicky commented on GitHub (Nov 11, 2025):

See https://github.com/open-webui/open-webui/pull/19097 for the improvement

<!-- gh-comment-id:3514509656 --> @adam-skalicky commented on GitHub (Nov 11, 2025): See https://github.com/open-webui/open-webui/pull/19097 for the improvement
GiteaMirror commented 2026-05-05 20:54:24 -05:00
Author
Owner
Copy Link

@luke-wren commented on GitHub (Nov 19, 2025):

We use Entra Id SSO so the user's avatars are synced, these are 1024x1024 images in a base64 encoded jpeg string.

This means various API endpoints which include the "user" object are hugely bloated, our tools API endpoint returns a payload over 100MB!

Luckily for our users this isn't noticeable since its mostly just the admin endpoints that include this info.

I've observed this on the following endpoints:

  • /api/v1/tools
  • /api/v1/models
  • /api/v1/models/list
  • /api/v1/tools/list
  • /api/v1/prompts/list
  • /api/v1/knowledge/list
  • /api/v1/users

Suggestions:

  • Rather than return images as base64 in API endpoints, return an image path.
    or/and
  • Don't include user avatars in API responses.
<!-- gh-comment-id:3553831871 --> @luke-wren commented on GitHub (Nov 19, 2025): We use Entra Id SSO so the user's avatars are synced, these are 1024x1024 images in a base64 encoded jpeg string. This means various API endpoints which include the "user" object are hugely bloated, our tools API endpoint returns a payload over 100MB! Luckily for our users this isn't noticeable since its mostly just the admin endpoints that include this info. I've observed this on the following endpoints: - /api/v1/tools - /api/v1/models - /api/v1/models/list - /api/v1/tools/list - /api/v1/prompts/list - /api/v1/knowledge/list - /api/v1/users Suggestions: - Rather than return images as base64 in API endpoints, return an image path. or/and - Don't include user avatars in API responses.
GiteaMirror commented 2026-05-05 20:54:25 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Nov 19, 2025):

@luke-haynes-wren

from your second suggestion: do you mean NOT setting user's avatars?

This is possible, by setting OAUTH_UPDATE_PICTURE_ON_LOGIN to false and setting OAUTH_PICTURE_CLAIM to ""

If OAUTH_PICTURE_CLAIM is set to '' (empty string), then the OAuth picture claim is disabled and the user profile pictures will not be saved.

<!-- gh-comment-id:3553841643 --> @Classic298 commented on GitHub (Nov 19, 2025): @luke-haynes-wren from your second suggestion: do you mean NOT setting user's avatars? This is possible, by setting OAUTH_UPDATE_PICTURE_ON_LOGIN to false and setting OAUTH_PICTURE_CLAIM to "" If OAUTH_PICTURE_CLAIM is set to '' (empty string), then the OAuth picture claim is disabled and the user profile pictures will not be saved.
GiteaMirror commented 2026-05-05 20:54:25 -05:00
Author
Owner
Copy Link

@zhenanekh-pixel commented on GitHub (Nov 19, 2025):

When will nano banana 2 start working?

<!-- gh-comment-id:3553847092 --> @zhenanekh-pixel commented on GitHub (Nov 19, 2025): When will nano banana 2 start working?
GiteaMirror commented 2026-05-05 20:54:26 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Nov 19, 2025):

@zhenanekh-pixel

already working perfectly with this setup:

https://docs.openwebui.com/getting-started/env-configuration#gemini

For openrouter support OR direct model integration support (not via image-editing in admin panel) you need to wait for 0.6.37

<!-- gh-comment-id:3553861499 --> @Classic298 commented on GitHub (Nov 19, 2025): @zhenanekh-pixel already working **perfectly** with this setup: https://docs.openwebui.com/getting-started/env-configuration#gemini For openrouter support OR direct model integration support (not via image-editing in admin panel) you need to wait for 0.6.37
GiteaMirror commented 2026-05-05 20:54:26 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Nov 19, 2025):

@zhenanekh-pixel
and please keep it on topic, this issue is unrelated to gemini image edit

<!-- gh-comment-id:3553866930 --> @Classic298 commented on GitHub (Nov 19, 2025): @zhenanekh-pixel and please keep it on topic, this issue is unrelated to gemini image edit
GiteaMirror commented 2026-05-05 20:54:27 -05:00
Author
Owner
Copy Link

@luke-wren commented on GitHub (Nov 19, 2025):

@luke-haynes-wren

from your second suggestion: do you mean NOT setting user's avatars?

This is possible, by setting OAUTH_UPDATE_PICTURE_ON_LOGIN to false and setting OAUTH_PICTURE_CLAIM to ""

If OAUTH_PICTURE_CLAIM is set to '' (empty string), then the OAuth picture claim is disabled and the user profile pictures will not be saved.

I like that users avatars are synced, it keeps things cohesive across the org.

My suggestion was to omit the users avatar from API responses as this makes up about 95% of the overall payload size (in our case). Eg in the image below.

Image

In most cases, the avatar returned in the API isn't displayed on the page so isn't needed anyway.

<!-- gh-comment-id:3554870261 --> @luke-wren commented on GitHub (Nov 19, 2025): > [@luke-haynes-wren](https://github.com/luke-haynes-wren) > > from your second suggestion: do you mean NOT setting user's avatars? > > This is possible, by setting OAUTH_UPDATE_PICTURE_ON_LOGIN to false and setting OAUTH_PICTURE_CLAIM to "" > > If OAUTH_PICTURE_CLAIM is set to '' (empty string), then the OAuth picture claim is disabled and the user profile pictures will not be saved. I like that users avatars are synced, it keeps things cohesive across the org. My suggestion was to omit the users avatar from API responses as this makes up about 95% of the overall payload size (in our case). Eg in the image below. <img width="1707" height="688" alt="Image" src="https://github.com/user-attachments/assets/bb781917-539c-4146-9eb7-1e4c98130575" /> In most cases, the avatar returned in the API isn't displayed on the page so isn't needed anyway.
GiteaMirror commented 2026-05-05 20:54:27 -05:00
Author
Owner
Copy Link

@adam-skalicky commented on GitHub (Nov 19, 2025):

I think this is drifting a little off topic. The original issue relates to the model endpoint being slow which is fixed in dev.

That said, I do think there's a wholistic conversation to be had about metadata image handling that should happen in another thread. User data and model images are all base64 encoded and passed as json which is fine for a one off but can dominate objects when used ubiquitously. Assuming all images are not sensitive, maybe we should serve them from the file system via a UUID and dedicated fetch endpoint that simply looks for a live token.

Either way, I feel this issue is resolved. @taylorwilsdon perhaps we close this out in favour of another thread?

<!-- gh-comment-id:3555015726 --> @adam-skalicky commented on GitHub (Nov 19, 2025): I think this is drifting a little off topic. The original issue relates to the model endpoint being slow which is fixed in dev. That said, I do think there's a wholistic conversation to be had about metadata image handling that should happen in another thread. User data and model images are all base64 encoded and passed as json which is fine for a one off but can dominate objects when used ubiquitously. Assuming all images are not sensitive, maybe we should serve them from the file system via a UUID and dedicated fetch endpoint that simply looks for a live token. Either way, I feel this issue is resolved. @taylorwilsdon perhaps we close this out in favour of another thread?
GiteaMirror commented 2026-05-05 20:54:28 -05:00
Author
Owner
Copy Link

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

profile_image_url in meta field is also dropped for models endpoint, @taylorwilsdon let us know if that addresses the issue!

<!-- gh-comment-id:3560964119 --> @tjbck commented on GitHub (Nov 21, 2025): profile_image_url in `meta` field is also dropped for models endpoint, @taylorwilsdon let us know if that addresses the issue!
GiteaMirror commented 2026-05-05 20:54:28 -05:00
Author
Owner
Copy Link

@taylorwilsdon commented on GitHub (Nov 21, 2025):

profile_image_url in meta field is also dropped for models endpoint, @taylorwilsdon let us know if that addresses the issue!

Hell yeah excited to take it for a spin, we've seen dramatic performance increases from the dev branch already this is icing on the cake

<!-- gh-comment-id:3561034525 --> @taylorwilsdon commented on GitHub (Nov 21, 2025): > profile_image_url in `meta` field is also dropped for models endpoint, @taylorwilsdon let us know if that addresses the issue! Hell yeah excited to take it for a spin, we've seen dramatic performance increases from the dev branch already this is icing on the cake
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#57393
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?