Classic298/open-webui-plugins: what the collection actually installs into Open WebUI
A curated collection of Open WebUI plugins - tools, skills, filters, pipes, actions and events that extend your AI chat experience.
At a glance
- What is it?
- A curated set of Open WebUI extensions covering tools, skills, filters, pipes, actions and events, distributed as self-contained folders rather than a package. The core judgement: it is a plugin catalogue with real infrastructure concerns (background cleanup, MCP Apps, vision bridging), not a framework, and its install model means each plugin must be evaluated on its own README.
- Who is it for?
- Adopt individual plugins from this collection if you already run Open WebUI and a specific gap matches one of the seven listed plugins, for example Prune for background cleanup or Vision Bridge to give a text-only model image access without core changes. Do not adopt the repository as a whole: it is a catalogue, not a dependency, and nothing here is versioned against a particular Open WebUI release.
- Can I use it commercially?
- Yes. BSD-3-Clause is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 8 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap this collection fills: Open WebUI ships a plugin API, not a plugin library
Open WebUI exposes extension points, and the README of this repository enumerates six of them: tools, skills, filters, pipes, actions and events. What it does not ship, according to this material, is a set of ready-made implementations. Classic298/open-webui-plugins is the answer to that gap. Each plugin lives in its own folder with a README explaining what it does, what components it includes, and how to set it up. That sentence is the whole distribution model. There is no package on an index, no import path, no shared runtime. The unit of adoption is the folder.
The audience is therefore narrow and specific. You need an Open WebUI instance you administer, because four of the six extension types install through the Admin Panel, and the remaining two install through Workspace. A user who only has a chat account cannot install a filter or a pipe. The collection also assumes you are comfortable reading a per-plugin README and deciding which of several components belong in which admin screen. The repository's own install instructions are three steps long, and step two is effectively "the README will guide you". That is honest about the shape of the project, but it also means the collection cannot be evaluated as a single artifact.
Seven plugins, three distinct mechanisms
The README table lists seven plugins, and they do not share an architecture. It is worth separating them by mechanism rather than by feature.
The first group renders something in the chat. Inline Visualizer v2 is a Tool plus a Skill that lets the model draw interactive charts, dashboards, diagrams and mini-apps inside the conversation, appearing live while the answer streams, with theme matching and clickable bars or nodes. It supports hand-written SVG/HTML and named libraries: Chart.js, D3, Vega-Lite, ECharts, Plotly, vis-network and Tone.js. Inline Visualizer is marked LEGACY (v1) and renders once the answer finishes rather than during streaming. Email Composer is a Tool that produces an email card in the chat with editable rich text, To/CC/BCC, priority, and export as .eml or handoff to a mail app.
The second group intercepts or injects content. Vision Bridge is a Filter plus a Tool: a text-only model, given an attached image, asks a separate vision model to inspect it on demand and can return with new questions about the same image later. Keep reasoning_content is a Filter that feeds a reasoning model its own prior chain of thought back, aimed at DeepSeek, Kimi, MiMo and vLLM models, and it addresses a specific failure string quoted in the README: reasoning_content is missing, breaking mid-tool-call.
The third group hooks system lifecycle. Prune is an Event that removes old chats, inactive users and orphaned files in the background, slowly enough that a live instance never notices, dry-run by default, with an admin page at /prune. Interface Defaults is also an Event, and it exists because Open WebUI's Default Interface Settings page cannot push defaults onto existing users. It adds that push, a factory reset, and defaults for settings that page cannot reach: notifications, keyboard shortcuts, memory, the personal system prompt and the speech/voice block.
MCP App Bridge stands somewhat apart. It is a Tool that connects an MCP server and renders that server's tools as an embedded interactive panel where the model called them, supporting MCP Apps (SEP-1865), with the README stating no middleware and no core changes are needed.
Installing: two admin screens, no build step
The install path is defined by the plugin type table. Tools and Skills go to Workspace, specifically Workspace then Tools, and Workspace then Skills. Filters, Pipes, Actions and Events go to the Admin Panel, under Functions. The repository's own three-step procedure is to open the plugin folder and read its README, identify the components it lists and where each installs, then follow the README because some plugins are a single file while others are multi-component.
There is no install command in the supplied material, no pip invocation, no docker compose service to add. That is a consequence of how Open WebUI loads extensions: you paste or upload a file into the relevant admin screen. The practical implication is that upgrades are manual. When this repository publishes v1.0.36, nothing on your instance updates itself. You reinstall the component. The release cadence visible here is roughly weekly: v1.0.34 on 2026-08-20, v1.0.35 on 2026-08-25, v1.0.36 on 2026-09-01. Whether those releases touch every plugin or only one is not stated in the supplied material, so a changelog check per plugin is the only way to know if your installed copy is behind.
The one concrete route the material does give is /prune. Prune registers an admin page at that path, which is consistent with the README's note that Events can register routes and serve standalone pages. That is a design decision worth noticing: a plugin is not limited to transforming messages, it can add an HTTP surface to your instance.
Prune is the only plugin here with a real operational blast radius
Most of these plugins fail visibly. A chart does not render, an email card looks wrong, a vision call returns nothing useful. Prune is different, because it deletes data. The README describes it as cleaning out old chats, inactive users and orphaned files automatically in the background, and it lists two mitigations: dry-run by default, and an admin page at /prune for previewing and running cleanups manually. It also states the plugin is safe across replicas, which matters if you run more than one Open WebUI container behind a load balancer, because a naive cleanup job would race against itself.
The phrasing slowly that a live instance never notices is a design intent, not a guarantee, and the material does not quantify it. There is no retention window documented here, no valve or config key for defining what old or inactive means, and no statement about whether deletion is soft or hard. Those are the questions to answer from the plugin's own README before enabling it, because the default state (dry-run) is the only thing standing between an unconfigured install and irreversible removal. If you cannot state your retention policy in concrete terms, this is the wrong plugin to enable first.
Vision Bridge and Keep reasoning_content are narrow fixes with narrow failure modes
These two are the most interesting entries because each targets a specific, named breakage rather than adding a feature.
Vision Bridge exists because a text-only model cannot see an attached image. The mechanism is a two-model conversation: the text model asks a separate vision model to look at the picture, on demand, and can come back with follow-up questions about the same image. The limitation is inherent to the design. Every image inspection is an extra model call to a second model, so latency and cost are paid twice, and the quality of the answer depends on the vision model you point it at, not on the model you are chatting with. The README says no core changes, which is the trade: you get image access without patching Open WebUI, and you accept a relay.
Keep reasoning_content is narrower still. It feeds a reasoning model its own prior chain of thought back so that DeepSeek, Kimi, MiMo and vLLM models stay coherent across tool calls and follow-up turns. The README names the exact symptom it repairs: reasoning_content is missing. A filter that re-injects prior reasoning is doing something the model provider arguably should do, and it will be redundant, or possibly harmful, on a model that already preserves its own reasoning. The plugin is scoped to a list of model families, and outside that list there is no stated reason to install it.
MCP App Bridge versus plain MCP tool calling
The obvious alternative to MCP App Bridge is calling MCP tools the ordinary way: the model invokes a tool, gets text or JSON back, and narrates the result. MCP App Bridge changes the return path. According to the README, connecting an MCP server means its tools bring their own interactive interface, rendered as an embedded panel right where the model called them, and it implements MCP Apps (SEP-1865) with no middleware and no core changes.
The difference is where the interface lives. In plain tool calling, the server's output is data the model must describe. With this bridge, the server ships UI and Open WebUI renders it inline in the conversation. That is a better fit for tools whose value is a widget rather than a value: a map, a form, a picker. It is a worse fit when the tool's output is a number, because you have added a rendering layer for nothing. The README's no middleware claim is the strongest part of the pitch, since it means you are not standing up a proxy service between Open WebUI and each MCP server. What the material does not say is how the embedded panel is sandboxed, which is the first thing to check if you intend to connect a third-party MCP server.
Interface Defaults and the licensing and upkeep picture
Interface Defaults is the plugin most likely to be adopted by an administrator rather than a power user, because it addresses an administrative gap: Open WebUI's Default Interface Settings page cannot push defaults onto existing users. This plugin adds that push, plus a factory reset, plus defaults for notifications, keyboard shortcuts, memory, the personal system prompt and the speech/voice block. The factory reset is the part to read carefully. A plugin that can reset user interface state across an instance is powerful and easy to misfire, and the material does not describe a scope selector or a dry-run equivalent.
On licensing, the repository is BSD-3-Clause. That is a permissive licence, and it means you can use, modify and redistribute the code provided the copyright notice and licence text are retained and you do not use the project's name to endorse derived work. It says nothing about the Open WebUI instance you install into, which carries its own licence, and it says nothing about the MCP servers or model providers a plugin like MCP App Bridge or Vision Bridge connects to. Those are separate agreements. This is a description of the licence text, not legal advice.
Upkeep is the underrated cost here. Three releases in the three weeks before the last push, each one requiring a manual reinstall of whichever component changed, across an admin surface that has no dependency resolution. If you install four plugins from this collection, you have four independent upgrade paths and four READMEs to re-read. That is the price of a folder-based distribution, and it is the reason to install the smallest number of these that solves your problem.
Editorial conclusion
Adopt individual plugins from this collection if you already run Open WebUI and a specific gap matches one of the seven listed plugins, for example Prune for background cleanup or Vision Bridge to give a text-only model image access without core changes. Do not adopt the repository as a whole: it is a catalogue, not a dependency, and nothing here is versioned against a particular Open WebUI release. Before installing anything, read the individual plugin README to confirm the component type and its install location, since a tool goes to Workspace, a filter or pipe goes to Admin Panel, and events register routes and can serve standalone pages such as /prune.
Community notes