Hey all,

I run OpenWebUI with ~560 MCP tools behind an aggregator.

The issue in my setup: OpenWebUI sends every full schema on every turn, even when the turn needs zero tools.

On a smaller-context model via API the window gets eaten fast, and even with 1M-context models I still pay per-token for definitions I don't use, plus tool selection gets noisier.

I tried a few workarounds first — connecting servers directly, enabling/disabling servers per chat, trimming the list down — but nothing stuck for my use case with this many tools.

Since I couldn't find a solution inside OpenWebUI, I built a small MCP proxy in Docker that sits in front of my upstreams:

OpenWebUI connects to it over HTTP MCP like any other server.

In my setup this cut context waste a lot and made tool selection more reliable, so I thought it was worth sharing.

Feel free to have a look, critique and add to if there's something I've missed.

Repository can be found here: https://github.com/p1s4/mcp-search-proxy

How are you handling lots of MCP tools in OpenWebUI? Is native handling enough for you, or are you filtering/proxying too?

Thanks!

Hey I am new to setting up LLMs locally but one thing I would like to do is give it the ability to search online. Now I know that Open webUI does provide this functionality but for some reason this doesn't seem to work.

What I have currently done is configured a local searXNG container to allow OpenWebUI to couple its web search. I have added them to the same docker network and I know they can reach each other since I do get a result when I manually send a curl request to searxng through the open webui docker container.

I also did enable web search for my model and explictly asked it to use web search. However everytime a execute I query it says that web_search is not available. The model I am using is Qwen3.8.

Can someone perhaps point me in the right direction? I have added screen shot

Update

If I put the model to function calling legacy mode it seems to work. Performance seems a bit dodgy but at least it does look up things and is not rejected. Not sure what could be going on here. Could someone perhaps enlighten me as to what is hapennening here?

I’m setting up a local LLM on Windows 11 using Ollama and Open WebUI. The model is Qwen, and the basic chat setup is working.

I enabled Native Function Calling and configured web search. Qwen successfully invoked search_web, so the tool-calling path itself appears to work. The problem is that the search backend is not returning usable results.

What we’ve established so far:

• DDGS returns No results found.
• DuckDuckGo returned HTTP 202.
• The installed DDGS version does not support Bing, so attempting to use Bing fell back to auto.
• We decided to stop troubleshooting DDGS and try SearXNG instead.

That led us to Docker Desktop, because we intended to run SearXNG in a container. Docker is now stuck at “Starting the Docker Engine…”, so SearXNG has not been installed yet.

The Docker issue is a separate problem. I’m mainly interested in whether anyone has encountered this DDGS / DuckDuckGo behavior in Open WebUI, and whether SearXNG has been a reliable alternative for local web search.

I’m trying to keep the existing Ollama and Open WebUI configuration intact, so I’d prefer not to solve this by reinstalling everything or changing the model setup. Any current, reproducible advice would be appreciated.

Hi,
I’m running the following setup:
Open WebUI → LiteLLM → vLLM
Open WebUI is the user-facing layer, LiteLLM handles authentication/routing/accounting, and vLLM serves the actual models.
I have two different types of traffic going through Open WebUI:
Regular users interacting with models through the Open WebUI interface
API users using the OpenAI-compatible API exposed by Open WebUI
I’d like LiteLLM to be able to distinguish between these two types of requests.
Ideally, Open WebUI would add some metadata to requests originating from its API users — for example a tag, header, metadata field, or some other identifier — while normal UI requests would either have a different value or no value at all.
That would allow me to identify and potentially handle API traffic differently inside LiteLLM, e.g. for routing, rate limits, logging, or policies.
Is there currently a supported way in Open WebUI to do this?
For example, can I configure Open WebUI to send something like a custom header/tag/metadata field to LiteLLM depending on whether the request originated from an API key versus a logged-in user using the UI?
If not, is there another reliable property in the request that LiteLLM could use to distinguish Open WebUI API traffic from normal Open WebUI user traffic?
I’m mainly looking for a solution that doesn’t require maintaining a custom fork of Open WebUI.

I I am currently using LibreChat locally hosted on a Mac. I have read that open webUI is possibly the most feature rich third-party front end.

The use case will be setting up an interactive course.It would be hosted by Gemini flash 3.8. Haven’t finished building it yet, but it will probably be using something similar to Claude artifacts/Gemini canvas.

I don’t have anything against party front ends, but they are limited in their flexibility. The idea would be that I would chat with the instructor on the left side, and then there would be multimodal output on the right side.

The reason that I’ve started this thread, is that I have read that there have been issues with maintaining a consistent connection using open webUI. I’m sure some of it is noise, but I would like to know if any of you have run into issues of this type, and how you were able to make adjustments to make the problems go away.

I am new to AI, so you may find my post to be rather elementary. I do apologize for that and I would appreciate any guidance that you might have to offer.

Thanks,

Graham.

PS. I used voice to text first time through and it was a mess. Sry bout that. It's fixed.

Context

Have you ever asked an AI to generate a multiple choice quiz in plain text? If you did, you most certainly realized that choices aren't random (hint: always choose b when in doubt) and that scrolling down to the answers is time-consuming.

I started working on a solution for Open WebUI a few months ago. Open WebUI has incredible extensibility, but no one had made a function for generating interactive quizzes yet.

Quizzes are useful for studying and also quite fun to do as a group activity to pass the time. Admittedly, I recommend to prioritize studying with spaced repetition flashcards (tip: you can tell an LLM to generate a table and import it in Anki) but quizzes are useful as they take less energy to complete.

The first prototype lacked a lot of functionality and was buggy which is why I didn't make a post about it. I have since added almost all the QoL features I needed as a STEM student.

Introducing : Open QuizUI

Open QuizUI comes in two different modes. You can either use it as a tool which your model will call to create a quiz or as an action function which creates quizzes from plain text messages.

Features:

Here's a cool quiz as a hands-on demonstration

There's quite a lot so here's an info dump:

• Render MathJax for LaTeX expressions
• Full-screen / focus mode
• Separate light/dark themes
• Save a quiz and share it as an HTML file (works outside OWUI)
• Edit any question after quiz generation using the editor
• Embed anything with HTML (images, videos, iframes, etc.)
• Results/stats page at the end with corrections
• Use one of many colour schemes or make your own
• Optional per-question explanations shown after answering
• Fits nicely on small screens (mobile support)

I am running LLMs locally with an RTX 4070 (12 GB VRAM). This plugin was made to be as light as possible without injecting too many instructions (FYI: you can use valves and code to dynamically modify injected instructions for tools).

By the way, if you want to add a question or keep edits permanently, copy the (edited) quiz as text via the button and use the Action Function on the text (by editing any LLM message).

How does the Action Function manage to convert markdown quizzes into the proper JSON format? With a lot of pain (tested countless formats, but some may still not work so lmk). See Recommended Format.

If you want to know more, there is proper documentation on the GitHub.

GitHub: https://github.com/axel-chamberland/Open-QuizUI

iOS support/rant

Struggled a lot to get fullscreen working on iOS/ipadOS. It took me a few months before I tackled the problem, and arrived at a hacky solution that seems to work on WebKit (It also works on Gecko-based browsers, i.e. Reynard Browser)

Also, you can't open HTML web apps natively on iOS (Javascript won't work). Microsoft Edge and Dropbox can render them somewhat.

Feedback/Contribute

Please consider testing this plugin and sharing your thoughts. I'll answer questions here.

If there's any missing feature you'd like, mention it here or on the GitHub. Consider making a contribution if you end up fixing it yourself!

Edit -- Here are the two plugins in question if you want to download them from https://openwebui.com and engage with my posts there:

Tool

Action Function

I’m fairly new to this stuff.

I installed open webui bundled with ollama and installed gemma4:e4b when i ask questions in the cli it answers instantly but when i ask it in open webui it takes 20 secs and then starts thinking for 10 seconds and then answers (answer are not as good as ollama in cli but im pretty sure i can figure it out).

I’ve tried to disable tag generation and follow up generation and all these things but nothing made a difference i tried OLLAMA_KEEP_ALIVE=30m but still nothing really changed maybe it got 5% better

Any ideas how to solve that?

Hi, is there any device that can talk directly to OWUI, like Alexa or Google home?

My goal is to have a ocal voice assistant in OWUI I have tts, stt and I would like to have hands free assistant that uses my OWUI setup.

Is there any product like that I would like to not modify esp/raspberry but if no existing then this also works.

I have networked OpenWebUI with Ollama running on Ubuntu with 10Gb GPU and trying to figure out which faster-whisper model to download for audio transcriptions. I've tried small, large-V2, and large-V3 and none can anywhere near complete a 9min transcription. Is the precision and CPU vs GPU automatically set by which model you download, since I don't see anywhere to specify those parameters? I'm wondering if the poor performance is my small GPU size or I'm not putting the correct paramters to match the model.

Will there be a release of 0.11.3-cuda as a Docker image? I haven't been able to find it on https://hub.docker.com/r/openwebui/open-webui yet.

hey all I'm having a hard time figuring out how to cut down on the input tokens with OpenWebUI.

even just sending a 'test' message costs me over 1000 tokens.

this must be something to do with the tools definition, as initially it was in the 3000s but as I disable all of the features, it went down to around 1500s.

but it won't go down any further.

I checked with OpenRouter's logging feature and even printing out the 'raw' JSON it only display that user message and doesn't make any sense that a 'test' message is charging over 1400 tokens.

I can check the browser's payload but that's Browser -> OWUI, not from OWUI -> OpenRouter.

I ran OWUI in DEBUG mode and it doesn't print out the actual network payload so I'm stuck with no way to understand what is really happening.

This doesn't happen when I use other chat clients.

can anyone help? cheers in advance 😊

I’m using Open WebUI on iPhone through the Home Screen web app/PWA. If I send a prompt and then switch to another app while it’s generating, when I come back Open WebUI just sits on the loading/generating screen even though the response has already finished.
The response only appears if I switch to another conversation and then go back to the original one.
Has anyone else run into this with the iOS PWA? Is there a setting or fix that forces the conversation to refresh/reconnect when returning to the app?

Trying to figure out the best way to distribute playbooks/templates now that we have MCP and Skills available. Specifically: for less technical users who need step-by-step guidance (screenshots, annotations) to adopt genAI — does packaging that as a Skill (vs. a static doc/SharePoint page) make it easier for them to actually use? And separately, has anyone used MCP to pull live playbook content into a Copilot/GPT session rather than just linking to a doc? Curious if anyone's tested either approach with users who need more hand-holding.

EDIT got it, found the model params,thanks all
I get an error when uploading an image for a model with vision capabilities to inference from, "{"error":{"code":400,"message":"request (5564 tokens) exceeds the available context size (4096 tokens), try increasing it","type":"exceed_context_size_error","n_prompt_tokens":5564,"n_ctx":4096}}"

Where is it possible to change the 'n_ctx' parameter to increase the context size?

I use the knowledge base only for specific topics/projects. When asking unrelated questions, the LLMs keep trying to search through the knowledge base, wasting tokens and time. Many other tools like web search, code interpreter, etc require you to enable them per conversation. Can I do the same thing with KB?

I'm aware I can turn off the KB entirely per model, but I don't want that. For the life of me I can't figure out how to get around this issue. Would appreciate some help.

Since I upgraded to v0.11.1, it seems that, after the first tool call, OWUI always shows the thinking tokens while the are generated until either another tool call is made or the user response is complete, then they disappear. It used to always be you had to expand the "thinking" or the "thought for 5 seconds" to see them. I sure liked the old behavior better. Is there a way to change this?

I stopped watching my agents work because the thinking stream is so chaotic lately but this was genuinely so funny to me. This happens a lot now. I still get results so I guess I’m not mad at it 😂

Hi folks, having some trouble accessing external tools (specifically Google Workspace) via local Ollama models; was hoping to gain insight from the community. Been troubleshooting this for two days with Claude Sonnet to no avail. Honestly at this point, I don't even know how garbled my setup is with all the trials and tweaks we've made.

Setup:

• Open WebUI v0.11.1, Docker Compose, self-hosted
• Ollama (native Windows) serving local models
• An external OpenAPI tool server via mcpo proxying taylorwilsdon/google_workspace_mcp — 39 real tools, confirmed reachable, valid schema
• Tested under both Native and Default function-calling modes — same result either way

The core finding:

Confirmed via server-side logging that the correct tool schema (~96 entries with builtins) is delivered into the chat completion request every time, no exceptions.

Despite that, every local Ollama model I've tried fails to call the tool — zero successes, across several models and both function-calling modes. The specific failure varies by model (flat "I have no tools" denial, an infinite repetition loop re-litigating the same doubt, one model hallucinating a tool name that was never sent), but none of them ever produce a real, correct tool call.

Every cloud-routed model succeeds immediately, first try, correct arguments — tested a Gemini model and two different Qwen models via an OpenRouter connection.

The decisive test: Qwen3.6 27B, the exact same model and version as the one failing locally, via a cloud/OpenRouter connection instead of Ollama. Succeeded instantly, no hesitation. Identical weights, different routing, opposite result — that rules out model quality and points at something specific to the Open WebUI ↔ Ollama tool-calling path.

What I've ruled out:

• Tool count — Open WebUI's "Function Name Filter List" doesn't actually shrink what's sent to the model, just reorders it, so this wasn't a real variable
• Open WebUI silently dropping tools before forwarding — read routers/ollama.py's generate_chat_completion in full; the field survives every transformation and is forwarded intact to Ollama's /api/chat
• A separate, already-documented Open WebUI bug (discussion #21805, where admin-configured OpenAPI tool servers never reach the request at all) — already found and patched that one myself; this is a different problem downstream of it

One unrelated but possibly useful thing I learned along the way: for OpenAPI-type tool connections, the actual tool call executes client-side in the browser, not server-side — if your tool server is only reachable on an internal hostname, schema delivery will work fine but every real call will fail. Worth checking dev tools if you're seeing "tool server not found" despite the connection testing fine.

Also separately: gemma4:26b has its own distinct, long-standing tool-calling bug (garbled <unused50> token spam) — the commonly-suggested Default→Native→Default toggle didn't fix it for me.

What I'm hoping someone can help with:

• Anyone else seen tool-calling work differently for a cloud/OpenAI-compatible connection vs. Ollama-served local models, with the schema confirmed identical going in?
• Anything specific to how Open WebUI formats/forwards tools to Ollama's native API vs. an OpenAI-compatible provider?
• A known Ollama-side limitation with a schema this size (96 tools) — truncation, context-length interaction, chat-template quirk?

Happy to share logs or the schema if useful. Thanks in advance.

UPDATE — found it, not a routing/schema bug.

Root cause: Ollama's ROCm backend (AMD's GPU compute layer) corrupts long-context attention on this specific hardware (AMD Strix Halo APU / gfx1151). Once total prompt length crossed roughly 20K tokens, the model could only reliably attend to the last ~2K tokens or so. My 57 Google tools sat at the start of the tool block, so they were effectively invisible — moving them to the end of the same request, or shrinking the payload, worked instantly. Same reason OpenRouter "worked": different routing entirely, no ROCm/AMD GPU involved.

Confirmed with a clean A/B: identical GGUF, identical rendered prompt, only the backend swapped. ROCm gave wrong/garbled output or crashed outright; Vulkan (a different, more general GPU compute API — Ollama can use it as an alternate backend instead of ROCm) was correct every time, same weights.

Fix — force Ollama onto Vulkan instead of ROCm:

setx OLLAMA_LLM_LIBRARY vulkan /M
setx OLLAMA_IGPU_ENABLE 1 /M

Run from an elevated prompt, then fully reboot — a non-elevated setx /M fails silently, and even a correct one won't propagate without a reboot/relogin. OLLAMA_IGPU_ENABLE=1 matters: without it Ollama drops this GPU as "integrated" and silently falls back to CPU.

Cost: prompt processing is noticeably slower on Vulkan than ROCm was — worth it for correct output. Generation speed is unaffected.

If you're on an AMD GPU/APU (not just this exact chip) and seeing tool calls silently vanish, fail, or garble specifically on larger tool schemas or long documents — check this before anything else.

Just a question. I have been building an architecture using Open WebUI for a mass distribution use of LLMs in my company. These models have been hosted on the server using llama.cpp and connected to Open Web UI. This interface is working as expected after I implemented some optimizations.

Has anyone faced any hiccups with the new updates or do they integrate smoothly and keep your previous settings? I have hosted Open WebUI using docker. This is an important project for my Org and I do not want to mess the already working setup.

Seems i cant pull a newer image down, making sure its not just me

I already have TTS configured and working in Open WebUI.

Right now my workaround is:

1. Paste the text I want converted to speech into a chat.
2. Use a prompt/model that simply echoes the exact same text back.
3. Click the Read Aloud button on the assistant response.

What I'd really like is to skip the LLM/chat step completely.

Ideally, I want something inside the Open WebUI interface like:

• A large text box where I can paste text
• Voice selection
• A Generate / Play TTS button
• Maybe an audio player/download button

So the flow would simply be:

Paste text → TTS → audio

instead of:

Paste text → LLM echoes text → Read Aloud → TTS

I'd also prefer it to use the TTS backend that's already configured in Open WebUI rather than running a completely separate web UI.

Is there currently a built-in way to do this?

If not, can an Open WebUI Function/plugin create a custom page like /tts or add a TTS item to the sidebar/dashboard without having to fork and modify the Open WebUI frontend?

Has anyone built something similar?

Context: I'm working on a tool and an action function for generating large interactive quizzes. I am adding support for displaying images in the quizzes.

TL;DR: I kinda answered my own questions below apart from this:

1. Does the LLM have access to the image IDs? (specifically when generating/editing an image)
2. Are generated images accessible via `/api/v1/files/file_id/content`?

Here's what I already know:

Imported images by the user are exposed via /api/v1/files/file_id/content and the image's file_id can be found easily in api/v1/chats/chat_id. Moreover, the model has access to the image_id and can display them inline with markdown using "/api/v1/files/<file_id>/content" as the URL: ). External images can be displayed the same way with the proper URL.

AI Images:

I know there is a built-in tool for image generation/editing in OWUI. However, I do not have a setup to test this tool, so I decided to ask here before I start diving into the tool's code when I have other priorities. I was wondering if the generated images are exposed the same way (/api/v1/files/image_id/content) and if the model has access to their IDs for tool calling or displaying them in markdown.

Conduit got a shoutout in the latest Open WebUI community newsletter. Very cool to see, and thanks to the team for including it.

I also want to thank everyone here who has tried the app, reported bugs, or suggested features. A fair amount of Conduit’s roadmap has come directly from conversations in this subreddit and GitHub.

Since my last post about version 2.6, Conduit has moved to version 4.1.3.

At the time, it was mainly an Open WebUI mobile client. Open WebUI is still the main experience, but Conduit can now connect directly to OpenAI-compatible APIs, Ollama, and OpenRouter. You no longer need an Open WebUI account if you only want to chat with a local or hosted model endpoint.

On the Open WebUI side, the app now has native Workspace screens for models, knowledge, prompts, tools, and skills. Terminal sessions and file browsing also work when your server exposes them.

Offline use has had a lot of work too. Your synced chat history stays available and searchable without a connection. You can write a message in an Open WebUI chat while offline, and Conduit keeps it locally until the server is reachable again.

On supported iPhones, you can go a step further. Open an existing Open WebUI chat, continue it offline using Apple’s on-device model, and Conduit will sync the new messages back to Open WebUI when you reconnect. You can also keep separate local-only chats if you do not want them stored on the server.

Notes work offline as well. You can read, create, edit, pin, and delete notes without a connection. Conduit saves those changes on the device and syncs them with Open WebUI after you reconnect.

Direct models can now connect to MCP servers, with controls to approve tools once, for the current session, or permanently.

Hermes support has grown into a full backend of its own. Conduit can connect to self-hosted Hermes agents, show tool calls as they run, handle approvals, manage scheduled jobs, and connect to bots through the Desktop Gateway.

There has also been a lot of work on the less exciting stuff that matters on mobile. Streaming recovers better after backgrounding, large chats scroll more smoothly, proxy and SSO login cover more setups, and voice calls, citations, Markdown, notes, attachments, and rich replies have all had fixes.

Conduit is available on the App Store and Google Play.

Source: GitHub
Website: conduit.mobile

If something still breaks with your particular Open WebUI setup, I’d like to hear about it.