github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-07-16 23:21:44 -05:00
Code Issues 2.4k Packages Projects Releases 129 Wiki Activity

[GH-ISSUE #24549] issue: extreme slowness, and mcp tool use broken #107321

New Issue
Closed
opened 2026-05-18 06:05:19 -05:00 by GiteaMirror · 5 comments
GiteaMirror commented 2026-05-18 06:05:19 -05:00
Owner
Copy Link

Originally created by @savantskie on GitHub (May 10, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/24549

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

Git Clone

Open WebUI Version

0.9.4

Ollama Version (if applicable)

No response

Operating System

Ubuntu 22.04

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

  • Response times should be comparable to v0.9.0 (a few seconds with no active filters)
  • MCP tool calls should execute correctly with all required parameters preserved
  • No excessive CPU/system load after the model finishes responding

Actual Behavior

  1. Extreme latency: Response times increased dramatically (up to ~1 minute) compared to identical setup in v0.9.0 where responses came in seconds. This occurred with ALL functions/filters disabled.
  2. High post-response CPU usage: After the model finishes generating text, there is significant sustained CPU usage that slows down the entire system. This was not present in v0.9.0.
  3. MCP tool calls failing: The model generates tool call arguments correctly (confirmed via the response text showing the model outputting user_id and model_id), but Open WebUI either:
    • Strips the user_id and model_id arguments from the tool call before sending to the MCP server, causing HTTP 422 validation errors
    • Or fails to parse the tool call format the model generates (Qwen-style XML <tool_call> blocks are not recognized as native function calls)
  4. Downgrading to v0.9.0 resolves all issues: Reverting to the v0.9.0 fork restored normal response times, normal CPU usage, and working MCP tool calls.

Steps to Reproduce

  1. Start with a clean Open WebUI v0.9.4 installation (bare metal, pip install, Python 3.11)
  2. Connect to a llama.cpp backend serving any LLM
  3. Configure the model with function_calling: native in the model params
  4. Add MCP tools via a server (e.g., mcpo proxy)
  5. Disable all filters/functions (short term memory, chat clipper, etc.)
  6. Send a simple chat message to the model
  7. Observe the response time and tool call behavior

Logs & Screenshots

No logs showed any errors

Additional Information

  • Running bare metal (not Dockerized) using pip install -r requirements.txt --break-system-packages
  • Frontend was rebuilt with npm run build after the upgrade
  • MCP server is served via mcpo proxy which exposes tools via OpenAPI at /mcpo/openapi.json
  • Tool schemas in the MCP OpenAPI spec correctly include user_id and model_id as required parameters
  • The issue is not related to any custom filters or functions - all were disabled during testing
  • The service was restarted multiple times during debugging with no change in behavior
  • Even with the model sending the XML <tool_call> format (which was being preserved in response text), Open WebUI did not execute the tool calls or properly route them to the MCP server
  • For tracking of tool calls and debugging, and model user isolation, I have to have 'model_id' and 'user_id' passed as arguments. Works in 0.9.0, does not work in 0.9.4 using mcpo
Originally created by @savantskie on GitHub (May 10, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/24549 ### 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 Git Clone ### Open WebUI Version 0.9.4 ### Ollama Version (if applicable) _No response_ ### Operating System Ubuntu 22.04 ### 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 - Response times should be comparable to v0.9.0 (a few seconds with no active filters) - MCP tool calls should execute correctly with all required parameters preserved - No excessive CPU/system load after the model finishes responding ### Actual Behavior 1. **Extreme latency**: Response times increased dramatically (up to ~1 minute) compared to identical setup in v0.9.0 where responses came in seconds. This occurred with ALL functions/filters disabled. 2. **High post-response CPU usage**: After the model finishes generating text, there is significant sustained CPU usage that slows down the entire system. This was not present in v0.9.0. 3. **MCP tool calls failing**: The model generates tool call arguments correctly (confirmed via the response text showing the model outputting `user_id` and `model_id`), but Open WebUI either: - Strips the `user_id` and `model_id` arguments from the tool call before sending to the MCP server, causing HTTP 422 validation errors - Or fails to parse the tool call format the model generates (Qwen-style XML `<tool_call>` blocks are not recognized as native function calls) 4. **Downgrading to v0.9.0 resolves all issues**: Reverting to the v0.9.0 fork restored normal response times, normal CPU usage, and working MCP tool calls. ### Steps to Reproduce 1. Start with a clean Open WebUI v0.9.4 installation (bare metal, pip install, Python 3.11) 2. Connect to a llama.cpp backend serving any LLM 3. Configure the model with `function_calling: native` in the model params 4. Add MCP tools via a server (e.g., mcpo proxy) 5. Disable all filters/functions (short term memory, chat clipper, etc.) 6. Send a simple chat message to the model 7. Observe the response time and tool call behavior ### Logs & Screenshots No logs showed any errors ### Additional Information - Running bare metal (not Dockerized) using `pip install -r requirements.txt --break-system-packages` - Frontend was rebuilt with `npm run build` after the upgrade - MCP server is served via mcpo proxy which exposes tools via OpenAPI at `/mcpo/openapi.json` - Tool schemas in the MCP OpenAPI spec correctly include `user_id` and `model_id` as required parameters - The issue is not related to any custom filters or functions - all were disabled during testing - The service was restarted multiple times during debugging with no change in behavior - Even with the model sending the XML `<tool_call>` format (which was being preserved in response text), Open WebUI did not execute the tool calls or properly route them to the MCP server - For tracking of tool calls and debugging, and model user isolation, I have to have 'model_id' and 'user_id' passed as arguments. Works in 0.9.0, does not work in 0.9.4 using mcpo
GiteaMirror added the bug label 2026-05-18 06:05:19 -05:00
GiteaMirror commented 2026-05-18 06:05:24 -05:00
Author
Owner
Copy Link

@owui-terminator[bot] commented on GitHub (May 10, 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. 🟣 #23749 perf: MCP tool server reconnects on every message causing 15-20s silent delay
    This matches the reported extreme latency: it documents MCP tool servers being reconnected and re-listed on every message, causing a 15–20s silent delay before the model is even called. That aligns closely with the slowdown and MCP-tool-enabled performance regression in the new issue.
    by DSavaliya-gh

  2. 🟣 #23962 issue: High CPU usage after a query
    This is a direct performance regression report after updating to a nearby version, describing high CPU usage after a query completes. It is relevant to the new issue’s post-response CPU spike, even though it is not MCP-specific.
    by vk2r · bug

  3. 🟣 #22805 issue: Streamable-HTTP MCP Tool Server unable to call tools and causing hang-up on chat response
    This issue describes MCP tool servers connecting and loading tools but then failing to make the tool call and hanging the chat response. That is very similar to the new report that MCP tool calls are not being executed correctly in v0.9.4.
    by ggeorge-git · bug

  4. 🟣 #17808 issue: unexpected MCP tool response handling
    This older MCP issue discusses a mismatch in how MCP results are handled versus mcpo, with direct MCP returning the full content array and causing models to fail to produce usable output. It is relevant because the new issue also contrasts mcpo working in v0.9.0 versus broken MCP/tool handling in v0.9.4.
    by dlamoris · bug

💡 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.

<!-- gh-comment-id:4416272062 --> @owui-terminator[bot] commented on GitHub (May 10, 2026): <!-- terminator-bot:related-issues-reply --> 🔍 **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. 🟣 [#23749](https://github.com/open-webui/open-webui/issues/23749) **perf: MCP tool server reconnects on every message causing 15-20s silent delay** *This matches the reported extreme latency: it documents MCP tool servers being reconnected and re-listed on every message, causing a 15–20s silent delay before the model is even called. That aligns closely with the slowdown and MCP-tool-enabled performance regression in the new issue.* *by DSavaliya-gh* 2. 🟣 [#23962](https://github.com/open-webui/open-webui/issues/23962) **issue: High CPU usage after a query** *This is a direct performance regression report after updating to a nearby version, describing high CPU usage after a query completes. It is relevant to the new issue’s post-response CPU spike, even though it is not MCP-specific.* *by vk2r · `bug`* 3. 🟣 [#22805](https://github.com/open-webui/open-webui/issues/22805) **issue: Streamable-HTTP MCP Tool Server unable to call tools and causing hang-up on chat response** *This issue describes MCP tool servers connecting and loading tools but then failing to make the tool call and hanging the chat response. That is very similar to the new report that MCP tool calls are not being executed correctly in v0.9.4.* *by ggeorge-git · `bug`* 4. 🟣 [#17808](https://github.com/open-webui/open-webui/issues/17808) **issue: unexpected MCP tool response handling** *This older MCP issue discusses a mismatch in how MCP results are handled versus mcpo, with direct MCP returning the full content array and causing models to fail to produce usable output. It is relevant because the new issue also contrasts mcpo working in v0.9.0 versus broken MCP/tool handling in v0.9.4.* *by dlamoris · `bug`* --- 💡 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-18 06:05:24 -05:00
Author
Owner
Copy Link

@savantskie commented on GitHub (May 10, 2026):

None of those issues are related, I just read them all, and I do not use mcphub, i use my own mcp server which works in every other program/instance, my mcp server is not streamable it is already through mcpo, and I no longer have the chat, but the model eventually started leaking tool calls into message to user. So none of those match my situation.

<!-- gh-comment-id:4416291971 --> @savantskie commented on GitHub (May 10, 2026): None of those issues are related, I just read them all, and I do not use mcphub, i use my own mcp server which works in every other program/instance, my mcp server is not streamable it is already through mcpo, and I no longer have the chat, but the model eventually started leaking tool calls into message to user. So none of those match my situation.
GiteaMirror commented 2026-05-18 06:05:25 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (May 10, 2026):

0.9.0 is not latest, please report on latest version - also cannot reproduce with openrouter. Are you certain that this isn't a llamacpp issue for you?

<!-- gh-comment-id:4416303224 --> @Classic298 commented on GitHub (May 10, 2026): 0.9.0 is not latest, please report on latest version - also cannot reproduce with openrouter. Are you certain that this isn't a llamacpp issue for you?
GiteaMirror commented 2026-05-18 06:05:26 -05:00
Author
Owner
Copy Link

@savantskie commented on GitHub (May 11, 2026):

was a typo, was meant to be 0.9.4, and no it isn't a llama.cpp thing, because in every other frontend it works

<!-- gh-comment-id:4416843931 --> @savantskie commented on GitHub (May 11, 2026): was a typo, was meant to be 0.9.4, and no it isn't a llama.cpp thing, because in every other frontend it works
GiteaMirror commented 2026-05-18 06:05:27 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (May 11, 2026):

Ok please reopen with steps to reproduce and more environment details. For now i cannot reproduce at all

<!-- gh-comment-id:4417868202 --> @Classic298 commented on GitHub (May 11, 2026): Ok please reopen with steps to reproduce and more environment details. For now i cannot reproduce at all
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#107321
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?