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
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.
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.
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)
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
Start with a clean Open WebUI v0.9.4 installation (bare metal, pip install, Python 3.11)
Connect to a llama.cpp backend serving any LLM
Configure the model with function_calling: native in the model params
Add MCP tools via a server (e.g., mcpo proxy)
Disable all filters/functions (short term memory, chat clipper, etc.)
Send a simple chat message to the model
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-15 16:20:09 -05:00
@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:
🟣#23749perf: 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
🟣#23962issue: 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
🟣#22805issue: 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
🟣#17808issue: 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.
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.
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?
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
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
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 @savantskie on GitHub (May 10, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/24549
Check Existing Issues
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
README.md.Expected Behavior
Actual Behavior
user_idandmodel_id), but Open WebUI either:user_idandmodel_idarguments from the tool call before sending to the MCP server, causing HTTP 422 validation errors<tool_call>blocks are not recognized as native function calls)Steps to Reproduce
function_calling: nativein the model paramsLogs & Screenshots
No logs showed any errors
Additional Information
pip install -r requirements.txt --break-system-packagesnpm run buildafter the upgrade/mcpo/openapi.jsonuser_idandmodel_idas required parameters<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@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:
🟣 #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
🟣 #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🟣 #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🟣 #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.
@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.
@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?
@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
@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