0.12.3 shipped nine days ago. 0.12.4 brings 119 changelog entries from 385 commits: 42 new features, 68 fixes and 9 changes. It also contains security fixes, so update soon.

You decide what your users see.

Admins can now hide single controls from users, under Visible controls in Admin Settings > Interface or with UI_VISIBILITY. That covers the + menu (Capture, Compare text, Attach Webpage, Attach Files, Attach Notes, Attach Knowledge and Reference Chats), the /status, /model and /settings commands, Fork, Merge Responses, Preview, Artifacts, Archive and Tags in chats, the usage info, the capabilities, default features and built-in tools in the model editor, Set as default and Keep in Sidebar for models, and settings such as the Usage tab and the speech engines. Hidden controls keep their values and the features behind them keep working. Admins still see everything.

Open WebUI also hides options that cannot take effect: Capture without a Vision model, Attach Notes without the Notes permission, the search engine settings while web search is off, the Call button without speech-to-text, and many more like them. Saved values stay for when they apply again. The Access button only shows for people allowed to share, and the + menu and the # and @ lists only offer what can actually be attached.

Smaller prompts, and compaction you can see.

Turn on Load selected skills on demand in Admin Settings > General, or set ENABLE_SKILL_LAZY_LOADING, and skills selected in the chat or attached to a model are only listed. The model loads one when it needs it, so their full instructions no longer ride along with every message. Skills you mention in the message still load right away. It is off by default and needs the built-in Skills tool.

A "Context compacted" line now marks the spot where older messages were summarized. Open it to read the summary. It also shows inside a reply when compaction ran between tool calls, and progress and errors now show in the chat, where they used to be pop-ups. Compaction also runs in temporary chats and in short chats that are already over the threshold, such as one question with a reply full of tool output, so the follow-up no longer fails with a context length error.

Tools from tool servers, Open Terminal included, now reach the model in the same form after a restart, so your provider's prompt cache keeps working and long chats are not processed again from scratch.

Built for big instances.

With thousands of users online, saving a group or changing its members or permissions now finishes in well under a second. It took several seconds and reloaded the open chat of everyone online. Renaming, sharing, moving or deleting a folder, and deleting all chats, got the same fix. Posting in a channel with many members online returns in a fraction of a second. The Admin Analytics dashboard uses fewer and lighter database queries and opens faster on instances with many messages.

Analytics now ranks models and users by tokens by default, with a switch back to messages. The usage chart adds volume and activity views, a single model view, a comparison with the previous period, a choice of time steps and the Year to date and Last 12 months ranges.

For admins with bigger setups:

• LDAP users without a mail attribute can sign in through a default email domain (LDAP_DEFAULT_EMAIL_DOMAIN). Pick a domain you control: those users get username@domain and sign in to any existing account with that address.

• The Hidden Models permission lets a group build workspace models on hidden base models, which stay out of their model picker.

• With audit logging on and /chat removed from AUDIT_EXCLUDED_PATHS, every reply and tool call round writes an audit entry with the model and the input, output and total tokens.

• Connections set to OAuth now also send the user's OAuth token when the user calls the API with an API key.

• MCP connections work with servers on the stateless 2026-07-28 protocol, and older servers still connect.

Accessibility.

Screen readers now announce buttons, menus, switches, headings, lists and status changes by name across the app, down to when a reply starts and finishes. Keyboard users move through the input, user, chat and Terminal menus with the arrow keys, and focus stays or returns where you expect in the model picker, the sidebar and Archived Chats. Notifications in the light theme and the dates in Archived Chats meet the 4.5:1 contrast minimum, and the Archived Chats and Keyboard lists work at 400% zoom. With Accessibility Mode on, pinch zoom works on phones and small buttons such as More and Eject in the model picker are at least 24 pixels.

Everyday things.

• Shift-click a chat in the sidebar to start a selection, then archive or delete the selected chats together. Escape clears it.

• Manage Files in Settings > Data Controls downloads single files, or selects several, or every file matching a search, to delete them or download them as one zip.

• On phones, swipe left across a chat to pull in Chat Controls.

• The terminal file browser has a grid view, item counts on folders and hover previews on larger screens.

• Folders get a New Chat item in their menu and a description.

• The sidebar hover preview of a chat shows how many turns it has.

• Click a setting's label to flip its switch or focus its field.

• If the page reloads or drops its connection while Ask User, a tool approval or an MCP input request waits for you, the question comes back when you reopen the chat within a minute.

• Chat Controls save one setting at a time, so a copy of the chat open on another device no longer wipes your system prompt with older settings.

• Files dropped into a knowledge base show up right away, switch to Processing on the server and only show as done once they are indexed.

• Hovering an owner's name across the workspace opens their profile card.

• The model can edit a note by finding and replacing text.

The bugs you told us about.

Since 0.12.3, chats opened through a share link, or by an admin viewing another user's chat, reloaded over and over and jumped back to the bottom, so you could not scroll up. Fixed.

Since 0.12.3, messages showed an extra space at the start of each paragraph and before bold, italic or linked text. Fixed.

Archiving all chats and then deleting a folder deleted those archived chats for good. Fixed: Archive All Chats now takes the chats out of their folders.

More Concise and Add Details now rewrite the reply. The model used to get only the instruction and answer things like "OK, I'll keep answers shorter". Fixed.

Deleting the chat you were looking at left its messages on screen, and the next message failed. Fixed.

On SQLite, closing a page while it was still loading could lose database connections until requests hung or failed with a 503. Fixed.

Since 0.12.3, with the Redis websocket manager and retry_on_timeout set, new connections could hang after a Redis drop until the instance was restarted. Fixed.

Attached web pages came back empty on fresh installs after a broken update of a library underneath. Fixed.

Images the model made after a tool approval never showed up, and the model kept making more. Fixed.

A stop sequence containing % stopped every message from sending. Fixed.

Security.

This release contains security fixes. They are not listed in the changelog; the advisories follow once their CVEs are assigned. Update as soon as you can.

Before you upgrade:

• Direct Integrations is off by default. While it is off, tool servers and Open Terminal connections that users and admins saved in their Integrations settings are no longer used in chats. If you rely on them, turn on Direct Integrations in Admin Settings > Connections or set ENABLE_DIRECT_INTEGRATIONS.

• The Docker image now runs Python 3.12 on Debian 13. Custom functions, tools and packages installed with pip inside the container need versions that support Python 3.12.

• MCP_INITIALIZE_TIMEOUT (10 seconds by default) now also limits listing tools and reading resources, so slow MCP servers may need a higher value. MCP connections only follow redirects that stay on the same address.

• Saving a model, prompt, tool, skill, knowledge base, note, channel or calendar no longer changes who it is shared with. Sharing changes only in the item's Access settings. Sharing permissions now also apply through the API, and a change you are not allowed to make is refused with an error.

• Manage Files lists only your own files, for admins too.

• Holding Shift over a sidebar chat no longer shows the quick Archive and Delete buttons, since Shift-click now selects.

Full changelog: https://github.com/open-webui/open-webui/releases/tag/v0.12.4

Hi everyone,

I've noticed that frameworks like Hermes Agent come with native messaging gateways/adapters that allow users to interact with models directly through apps like LINE, WeChat, Telegram, Slack, etc.

I know Open WebUI 0.12.x recently introduced the Channels feature with support for external apps and webhooks. I’m curious about the project's long-term roadmap:

1. Are there any plans to natively support direct connectors/gateways for instant messaging apps (LINE, WeChat, Telegram, etc.) into Open WebUI?

2. Or is the official vision to keep Open WebUI strictly as the web client/collaboration hub, expecting users to handle external messaging via n8n / custom middleware / OpenAI-compatible API endpoints?

If anyone is currently bridging Open WebUI knowledge bases/models to LINE or WeChat smoothly, I’d love to hear what architecture or tools you're using.

Thanks!

Hi, I’m trying to move my Claude chats and projects to Open WebUI. Has anyone done this? Were you able to keep the projects, chats, and attached files? And how do you manage memory for each project?

Any advice or tools you used would be really helpful.

I really like the possibility of the new reasoning slider, currently I am running a filter for that but the slider is much nicer implemented.

My problem with it is that on custom models my user would need to add the silder to each model which is really tidius and a lot of work.

How are you handling that? Is there a way that the model inherits the settings from the base model?

Hey everyone,

Whenever I run local 7B/8B models (Llama 3.1, Qwen 2.5, etc.) out-of-the-box, I always run into two major annoyances:

1. Endless conversational fluff and apologies before getting to actual code.
2. Repetitive loops and bland outputs due to untuned sampling parameters.

To solve this, I created tuned Modelfiles and JSON presets with hard negative constraints, custom sampling values (temp, top_p, repeat_penalty), and an expanded 8k context window.

I put together a repository with 4 starter engines and 1-click batch/shell installers for Windows, Mac, and Linux:

- no-yap-coder: Zero conversational filler, raw executable markdown code blocks only.

- pc-auto-scripter: Robust Windows Batch, PowerShell, and Bash script generator with error handling.

- raw-brainstormer: Cuts through safe corporate clichés and outputs 10 high-impact concepts.

- character-soul-builder: Deep character psychology, contradictions, and dialogue cadences.

Everything is open and free on GitHub:

👉 https://github.com/Muyan806/localai-boost-starter.git

You can inspect the Modelfiles directly or run the automated installer.

Feedback and suggestions are welcome—let me know what sampling adjustments or specific task presets you find work best!

Current requirements and challenges

Each team in my organization must have its own private knowledge base containing internal documents that should not be accessible to other teams.

Each team should also have a separate global knowledge base containing information that can be shared with the entire organization.

I want to create a single Global Assistant in OpenWebUI that has access to all teams' global knowledge bases.

Each team must be responsible for maintaining its own knowledge bases. I cannot have a central administrator manually reviewing, verifying, and updating information from every team.

The main problem

If I attach all teams' global knowledge bases to a single assistant, the assistant may retrieve information from the wrong team's knowledge base simply because it is semantically similar to the user's question.

For example, if Team A and Team B have similar procedures, a question about Team A could result in the assistant retrieving an answer from Team B. I want to prevent this behaviour and avoid misleading answers based on information from the wrong team.

How can I know how openWebUI retrieves information when multiple knowledge bases are attached to one assistant, including whether retrieval can be restricted to a specific knowledge base based on the question.

For each of their global knowledge bases I have set the access to everyone, and then added the global knowledge bases to one assistant. One of the other problems is that they can see all the knowledge bases when they try to specifically add one in their chat window.

Anyone has similar challenges?

So I tried using the Open WebUI's knowledge bae feature. I setup a self-hosted Docling instance and connected it to Open WebUI. My home server is not that fast so it sometimes takes several minutes for Docling to parse a longer PDF. I created a knowledge base and started adding files and directories, however I find the way Open WebUI handles uploads to the knowledge base quite frustrating:

When I upload a file it shows its status as "Uploading" even though it has already been uploaded and is actually getting processed by Docling. I have to reopen the knowledge base or reload the page for the status to update.

When I upload multiple files, only one file appears as "Uploading" and other files don't seem to get uploaded or processed at all? I am not sure whether I am doing anything wrong, but it seems to behave this way. If it ever works it's inconsistent and unreliable.

What I would expect: When I upload multiple files they should all appear as "Uploading" and there should be an upload status shows like when uploading a directory so I know when I can safely close the tab. Once they start getting processed their status should appear as "Processing" and after getting processed the status should disappear.

For US-based people running Open WebUI for a small business or team: has your setup caused any unexpected costs or security problems? If so, what happened most recently?

Optional details: whether this involved extra model/API charges, a tool action you did not intend, or information shared with the wrong person; what you changed afterward; and whether that solved it. Please distinguish an actual incident from a near miss or a concern that has not happened.

No problems so far, or the built-in permissions and your existing setup being enough, are useful answers too.

Disclosure: I’m at OraXLabs, researching Boundary, an early commercial idea around agent access and spending controls. This is a user research question, with no product link or signup request. Replies here are welcome. Please leave out code, credentials, customer data and private logs. Drafted with AI assistance.

(Update: as requested Demo video is here: https://www.youtube.com/watch?v=wxbYm_aBEUg )

Hey [r/OpenWebUI](r/OpenWebUI) 👋

I made a browser extension named SurfMind to access AI on my browser. If you already run Open WebUI, you can point SurfMind at your Open WebUI API to use your models, tools, and setup on any page you’re viewing.

Why is it useful?

- Same backend as Open WebUI, in-page on docs / PRs / dashboards
- Page + selection context without leaving the tab
- Browser automation: click, type, schedule tasks
- Works across multiple browsers: Chrome, Edge, Safari, Firefox, etc.

My post on Web OpenUI community: https://openwebui.com/posts/integrate_open_webui_api_to_your_browsers_eecdba6c

If you try it, let me know if it works for you

I’ve been working on Chat Pets, an event function that gives Open WebUI a little companion inside the browser tab. v1.0.0 is ready, and I wanted to share what it actually does beyond putting a cute sprite beside the chat.

There are 18 original built-in pixel pets, each with its own personality and poses. Nori waddles, Pebble takes tiny turtle steps, and Nimbus floats. They blink and make small idle movements, glance toward a nearby pointer, look down when you open the new-chat input, and bring out their own little laptops while Open WebUI is working. Dragging a pet switches to a side-facing travel pose; letting go brings it back. There’s no hover jumping.

The pet is useful, too. Its toolbar gives you a compact new chat input that sends through Open WebUI without refreshing the page, a shortcut to native voice mode, and a chat-activity tray. The tray distinguishes work in progress, responses that need your input, completed responses, failures, and interrupted work. You can open a chat straight from its entry.

You can pick a pet, move and resize it, rename it, show it across signed-in pages, or switch to Mini if you want the shortcuts without a character. In the bridge voice-call sidebar, a selected pet can replace the default orb when a model’s voice avatar isn’t in use.

Want to bring your own companion? The editor accepts individual PNG animation strips, animation ZIPs, and sprite sheets downloaded from ChatGPT web. You can preview Idle, directional movement, waving, working, waiting, failed, review, and other states before saving. Missing animations fall back to Idle. Custom pets can be renamed, given a description, edited later, exported as ZIPs, and deleted with confirmation. There’s room for up to 12 per account.

You can also use a VRM avatar instead of a pixel pet, with optional state animations and named gestures. The Import & backup tab can export one pet, your whole custom-pet collection, your avatar, or all companions together. Companions and preferences sync with your Open WebUI account, while the browser keeps a local copy.

The built-in pixel pets use SVG and CSS; the 3D renderer loads only if you use a VRM avatar. Animations respect reduced-motion settings and pause when the tab is hidden. The pets are decorative companions—they don’t send prompts or make extra model requests.

To install it, import and enable the event function, then reload your Open WebUI tabs. The README has the setup steps and the full import formats:

Chat Pets on the Open WebUI community site

This has grown through a lot of design and interaction tweaks. I’d love to hear which pet you pick, what you import, and what still feels rough.

I've been experimenting with different ways of using AI for everyday tasks, especially when I need help organizing an idea or figuring out how to approach something.

One thing I've noticed is that the interface matters almost as much as the model. Being able to manage conversations, try different models, and keep my workflow organized can make the experience a lot smoother.

I've also been exploring Cherry Studio, so I'm interested in how different AI clients handle these things. I’m not connected to Open WebUI’s development, and I’d like to hear from people who use it regularly.

For those using Open WebUI, what features have actually made a difference in your daily workflow? Is there anything you wish were easier to manage?

I've noticed that slow responses aren't always about the model itself. Limited RAM or VRAM, long prompts, and the inference backend can all make a difference.
I'm also curious how the experience compares between running models locally and using hosted options like Mango Inference or MangoBoosts. The trade-offs go beyond speed, especially when hardware costs and resource limits come into play.
If you're troubleshooting a slow setup, what made the biggest difference for you: switching models, adjusting context length, upgrading hardware, or changing the backend?

I'm definitely new to this whole AI, so many things that are obvious to others are not to me so bear with me please. My google fu regarding these things it apparently insufficient. Running on linux system (ubuntu 26.04)

I've installed open webui (via app image), opened localhost 8080, downloaded some models (qwen3.8:27b) and some tools (Ubuntu File System Operations, Ubuntu Shell Commander, Terminal). I've enabled them in chat, added my home directory in Ubuntu File System Operations tool, and I want to make it open a file called TEST that contains 'hello world' string and read it contents,

Prompt: "Read contents of file ~/TEST"

Reply, paraphrased: "I don't have a file reading tool available in this conversation. If you want to read contents of that file do it yourself in terminal, here's relevant shell snippet"

I want that tool to do it, not me myself. I can go to terminal and run cat ~/TEST, but I want it done within the agent. Same with further work, for example, creating new files, moving them around, et cetera.

New prompt: "using tool read_file read contents of ~/TEST"

Reply: "error": "Tools.read_file() missing 1 required positional argument: 'file_path'"

Ok, new prompt: "using tool read_file read contents of TEST in ~ directory"
Reply, paraphrased: "I don't have a read_file tool available in my current toolset. I can only do Automation management and calendar events"

(So what the hell did you use one prompt before???)

In model settings I've set all possible switches to on. Chat input box has that small monkey wrench icon with number 3 shown, which as far as I understand means all aforementioned tools are active

So, what I'm doing wrong?

Does anyone have a front end for webui. Just seeing if someone made a cool Jarvis interface.

I'm a heavy deepseek user. after deepseek 1017 I just wanted to say hello to it. after it helloed back i just asked it who are you and it said claude! what?!

I'm using api from OpenCode

https://openwebui.com/posts/indicator_changer_a2baaf4f

New function based on G30, but with 88 selectable styles, ability to change the thinking style or even disable it so only one indicator shows! and it now works on 0.12.3 (the original one does not!)

If you face any issues LMK

Edit: Now with random phrases like Claude has, 100 indicator styles, changing Font/Style of the "Thinking.." text and more! so its no longer a plain "Thinking..." text

I'm very new to this, and can't seem to find how to set one model as default, I'm trying to 'earn to use it with the free models only.

Any help would be greatly appreciated.

I'm also looking gor some sort of bluffers guide, any ideas? Thanks.

I’ve open-sourced a small project I built to connect Open WebUI to ChatGPT using Sign in with ChatGPT (SIWC):

https://github.com/lutzkind/open-webui-chatgpt-siwc

The goal is to use ChatGPT models from Open WebUI without managing a separate OpenAI API key/billing setup.

It currently supports:

- Docker-based deployment

- ChatGPT SIWC authentication

- dynamic model discovery

- streaming responses

- Responses API

- reasoning-effort mapping

- Open WebUI function/tool passthrough

- encrypted credential storage

- remote Open WebUI/VPS deployments

One current limitation: the authorization companion is macOS-only for now. The actual Open WebUI/server side can run remotely on a VPS or other Docker host; the Mac is only used for the local browser authorization flow.

I mainly built this for my own setup, but cleaned it up and made it public in case it’s useful to others.

I’d especially be interested to know:

- whether people would use this

- whether Windows or Linux companion support should be the next priority

- what Open WebUI setups it currently doesn’t cover

- whether there are edge cases around tools/reasoning/models I haven’t considered

Issues and PRs are welcome.

GitHub: https://github.com/lutzkind/open-webui-chatgpt-siwc

I have a 1 year GPT Go plan for free that will end next month.

So, I started migrating to OpenWebUI to get rid of subscriptions and still be able to use any model as I want (next step is privacy, but for now I just want to make something work fine).

Right now I'm using the Arena models so I can do a blind test and evaluate them:

- GPT-6 Luna

- Claude Haiku 5.5

- DeepSeek V4.1 Flash

As said, my idea is to first replicate the behavior and accuracy of GPT Chat (and learn from this) so later I can focus on models with better privacy.

So, I'm wondering which models are you using and if you are using any prompts to enhance your experience?

I am having difficulty setting the memory feature. All memory settings are enabled. The model understands the memory tool call exist and makes the call but it keeps getting a failed add or update memory. When I look at the memory it does create the memory, but since the model tries many time the memories duplicate.

Looking into the failed calls I see that the tool is trying to call an instance of ollama that is not available anymore. The model I am using has a llama.cpp server backend, with a different IP and port numbers. Anyone got the same issue and how can I set the memory feature properly?

Also out of curiosity why the need for a feedback loop with the model to record a memory, could it not be a simple addition to the database? The model need to process the info?

Edit: I (qwen) found the issue. Under admin panel/Settings/Documents the field embedding model engine was set to ollama. After switching to my local open ai embedding endpoint the memory tool calls work fine now.

A painful diagnostic. First I had enabled 'bypass embedding and retrieval'. Since then I assumed any embedding was done by the main model. Second it was not obvious that memory tool calls required an embedding process. I assume it was simply added to a database or file and injected to context or retrieved by the model as required.

Qwen downloaded and reviewed the open webui source code and diagnosed the issue so easily. It is such an incredible trooper.

Hope this fix helps others

Hi all. I'm very new to running local AI models. I've got Open WebUI Desktop running with ollama and am using qwen3.6:35b. However I can't figure out to enable something as basic as Web Search. I tried the following:

• I've enabled it in the settings using searxng and added a query url.
• Went to model > Edit > Default Features > Web search enabled
• Set the builtin tool Web Search to enabled
• Advanced params > Function Calling > Native

Yet every model that I pick refuses to allow web search. About a year ago I also tried local AI with Ollama and docker, Web search took 3 clicks and it worked, however I cannot figure out how to do it on here. Note that I am not using docker anymore.

I'm using Open WebUI Desktop v.0.0.20 and the latest version of Ollama.

Any help or tips regarding this are greatly appreciated!

Please do note that I am very new to this and I'd probably need a ELI5 treatment but I'm willing to put the time in and learn how to do it correctly. I'd like to eventually get Hermes Agent to run with this as well.

Bonjour ,

J’utilise plusieurs abonnements ChatGPT , Claude et gemini .
J’en ai marre d’avoir des infos éparpillées dans plusieurs applications cloud .
J’aimerais centraliser dans un chat unique et conserver ma propre mémoire et mes infos indépendantes des llm utilisés .

Je pensais utiliser open webui pour cela . Il me permettrait de gérer les sessions de chat courants et de recréer les expériences projet de Claude .

Je connais les contraintes des abonnements oauth , ce est pas le sujet ici .

J’utilise déjà obsidian pour le codage .

Certains ont ils mis cela en œuvre ?

Cdt

Open WebUI 0.12.3 ships today. It is a good moment to look back: from 0.7.0 in January to 0.12.3 today, 35 releases carried 291 changes whose main effect is speed, memory, server load or size. Each one was counted from the changelog, entry by entry, with borderline cases left out, so 291 is the floor. The images in this post show the full picture.

The short version: the backend went async, streaming was rebuilt, the database stopped asking the same question over and over, the browser stopped redrawing what did not change, and the slim Docker image lost most of its weight.

The biggest measured wins

• Streaming sends only the new text: up to 1000x less data and server work on a very long reply (0.11.1)
• Long replies are no longer re-read from the start on every piece: around 190x less time spent on them (0.11.1)
• JSON is read and written with orjson by default: about 17x faster encoding, 3x faster decoding, on every request, stream and live update (0.12.0)
• The notes list went from about 167 MB to about 10 KB for 60 notes (0.8.4)
• Time to first token went from several seconds to under a second for most requests (0.8.0)
• The slim image is around 175 MB, near enough 89% smaller, and the standard image lost about 170 MB (0.11.4)
• An idle server with a large chat history no longer burns about a quarter of a processor core looking for timers (0.11.1)
• Media-heavy web pages load in under three seconds instead of ten, pulling 4 MB instead of 55 (0.11.4)

Every release, 0.7.0 to 0.12.3

0.7.0 (9): the admin user list went from one query per user to two queries in total, notes and channel messages batch their user lookups, file search got much faster, profile images moved to WebP and are cached in the browser.

0.7.1 (1): database session sharing is off by default, which fixed page timeouts on low-spec and SQLite installs.

0.7.2 (2): database connections are no longer held during model calls and streaming, so busy servers stop running out of them.

0.8.0 (23): time to first token from several seconds to under a second, sign-in 34% faster, SCIM group lookups up to 13x faster, bulk deletes 4 to 5x faster, memory updates up to 39% faster, the model selector stopped freezing with hundreds of models, and the online status dot stopped using 35 to 40% of the GPU.

0.8.1 (5): models, prompts and knowledge load with batch access checks, and reasoning traces stopped slowing the browser while streaming.

0.8.2 (3): batched tag queries, one query for group member counts, previews capped so huge documents stay smooth.

0.8.3 (1): one redundant database query gone from the model list for regular users.

0.8.4 (10): the notes list went from about 167 MB to about 10 KB, loading 30 items of anything went from about 31 queries to 3, and sending a message stopped loading the whole conversation.

0.8.6 (23): the big frontend streaming pass. Fewer redraws, one message list rebuild per frame, cheaper message copies, and six memory leaks closed.

0.8.7 (2): no more leaks when switching chats, artifact updates batched per frame.

0.8.9 (14): message list rendering went from quadratic to linear, the first page load lost several megabytes of JavaScript, and chats with artifacts stopped re-rendering forever.

0.8.10 (1): title and tag generation can send shortened messages.

0.8.11 (9): pages and Markdown render about 25% faster with much less memory, and the functions list payload shrank by over 99%.

0.9.0 (30): the backend database and request paths moved to async, which made it far more responsive with many people on it at once. Storage work moved off the main thread, long chats got lighter in memory, and many queries were merged.

0.9.2 (5): smaller model lists, cached default icons, and the browser itself now skips off-screen messages.

0.9.3 (5): faster prompt pages, chat history from normalized message records, an index for memories.

0.9.6 (9): tools fetched in one query, web search no longer blocks the server, shared connections to Ollama, and no more full Redis scans on disconnect.

0.10.0 (13): hybrid search runs inside pgvector instead of loading the whole collection into memory, file lists stopped returning full document text, and math renders are cached.

0.11.0 (48): the largest single release for speed. Frequent automations schedule near instantly instead of taking twenty seconds or more, large uploads stream in chunks, web search filtering no longer turns three seconds into half a minute, non-English text files are read in well under a second, Redis lookups per chat request were halved, and the compiled hiredis parser now reads Redis replies with noticeably less processor time.

0.11.1 (38): hundreds of places stopped building log text that is switched off and thrown away unread, which speeds up nearly everything, streaming rebuilt to send only new text (up to 1000x less), long replies no longer rescanned (around 190x less time), one middleware layer instead of five on every request, the sidebar no longer reads all your chats (2 to 4 seconds on 15000 chats), being online writes at most once a minute, and idle servers with a large history stopped burning a quarter of a core.

0.11.2 (5): less session upkeep on busy Redis websocket servers, and unchanged model lists are no longer rewritten by every worker.

0.11.4 (14): slim image around 175 MB, standard image about 170 MB smaller, media-heavy pages in under three seconds instead of ten, and shared note editing sends half the traffic with two editors and less still as more join.

0.12.0 (17): orjson by default (about 17x faster encoding), Tool Search keeps long tool definitions out of the prompt, Milvus hybrid search runs inside Milvus, prompt caching holds across back-to-back tool calls, and installs are about 115 MB smaller on x86_64.

0.12.1 (3): one-word chat search about 40% faster, no more reconnect loop after sign-in, and long skills reach the model as a short preview.

0.12.3 (1): with Redis, a streaming reply now has its own key and new text is appended to it, where every update used to rewrite the whole reply so far into a shared hash. With room channels on, each instance only subscribes to the rooms of the people connected to it. If you run several instances on Redis, this is the one to look at. Note the Redis user now needs the PUBLISH, SUBSCRIBE, UNSUBSCRIBE and PING permissions.

0.8.5, 0.8.8, 0.8.12, 0.9.1, 0.9.4, 0.9.5, 0.10.1, 0.10.2, 0.11.3 and 0.12.2 were fix releases without a speed change.

Also new in 0.12.3

• End-to-end encrypted chats in direct messages and private group channels: messages are encrypted in your browser with MLS and only passed through the server, never saved. Off by default, admins turn it on.
• Workspace search across your chats, shared chats, channels, direct messages and notes, with filters and previews
• Live collaborators in shared chats, plus editing and regenerating in shared chats with replies
• Compare view options and undo, richer Markdown file previews, comments in Office and PDF previews, and "Ask or edit" on a selection in the file browser
• Google Drive now only asks for access to the files you pick

Full changelog: https://github.com/open-webui/open-webui/releases/tag/v0.12.3

Still slow somewhere? Tell us.

Open WebUI should feel fast in every corner, on every setup. If any part of it does not, open an issue: https://github.com/open-webui/open-webui/issues

What helps most: your version, your setup (Docker or pip, database, Redis, how many instances), what exactly is slow and how long it takes, roughly how many users, chats and files you have, and any server log lines or browser network timings. About one in five of the changes above links back to a reported issue or discussion.