When an MCP tool server could not be reached for a tool call (server restarted, connection reset by a proxy or load balancer, a request timing out), the whole chat was cancelled as if the user had pressed stop, and the log only said "Task was cancelled!". Now only that tool call fails, the model gets the connection error as the tool result and the reply finishes, and the underlying connection error is logged. The MCP SDK cancels whatever task opened the session when a single request fails, so each MCP session now runs in its own task instead of the chat's.
Fixes#33268
Choosing Add Details, More Concise, or typing a suggestion under a reply sent the model your original question followed straight by the bare instruction, with the reply itself missing, so it answered the instruction on its own (for example "OK, I'll keep answers shorter") instead of rewriting that reply. The model now receives the reply it is being asked to change, so it returns a shorter, more detailed or altered version of it. Plain Try Again and temporary chats were not affected.
Fixes#33083
* fix: built-in tool toggles show while their feature is off
The model editor listed the Memory, Notes, Channels, Notifications, Web Search, Image Generation, Code Interpreter, Automations, Calendar and Sub-agents built-in tools even when the admin had turned that feature off for the whole instance, where those toggles do nothing. Each of them is now hidden while its feature is off, and the choices saved on a model are kept for when it is turned back on. The server now also reports whether sub-agents are on, and saving the Sub-agents settings updates the editor without a reload.
Refs #32830
* refac: name the feature switch map like the rest of the codebase
Uses the same name the model capabilities change uses for its matching map.
* refac: keep each tool's feature switch next to its label
Each built-in tool now carries its feature switch alongside its label and description, so the list is defined in one place.
* fix: Terminal capability shows while no terminal server exists
The Terminal capability showed in the model editor even when the admin had set up no terminal server and direct integrations were off, which is the default, so it did nothing. It now shows only when an enabled terminal server exists or users can add their own through direct integrations, and the value saved on a model is kept. The server now reports whether any enabled terminal server exists, since the editor itself only sees the servers the current user can access and a model can be shared with other users.
Refs #32830
* fix: hide the default terminal picker when no terminal is available
The model editor still showed the default terminal line when no terminal server or direct integration was available. It now follows the same rule as the Terminal capability.
Tool servers and Open Terminal connections a user added in their Integrations settings kept loading and were still used in every chat after the admin turned Direct Integrations off, which only hid the settings tab. They are now ignored while Direct Integrations is off, for admins and users alike, and the server ignores them even when a request still includes them. The saved connections stay in each user's settings and come back as soon as the switch is turned on again.
Settings > Interface offered the title, follow-up and chat tag auto-generation switches even when the admin turned those generations off, so switching them did nothing. Each switch now only shows while its generation is on. The settings for keeping and inserting follow-up prompts stay, because they still apply to follow-ups saved in existing chats. Saved choices are kept and apply again once the admin turns the generation back on.
Refs #32830
Editing a WebP image (an uploaded one, or one generated by a provider that returns WebP) failed in the Docker image. Python only learns the WebP type from a system file the image does not ship, so the picture went to the image provider labelled with no type at all, and providers rejected it. WebP is now registered at startup like the other types Open WebUI already sets, so the provider receives it as image/webp.
Fixes#32899
Picking a model control option, such as a Thinking level, needed both the Allow Chat Controls and Allow Chat Params permissions, so admins had to hand out the Advanced Parameters panel just to let people pick a preset. Model control picks now work for anyone with access to the model and are saved per model to their account. Allow Chat Controls still hides the Chat Controls panel and Allow Chat Params still hides the Advanced Parameters panel, in the chat and in personal Settings. Parameters a person saves to their account are no longer filtered by these two permissions, since any chat message could already set any parameter without them.
Fixes#32626
The audit log only showed which model a request used inside the logged request body, which is cut off at MAX_BODY_LOG_SIZE, so the model went missing whenever a long prompt came before it. Audit entries for chat and completion requests, including the OpenAI, Ollama and Anthropic-compatible endpoints, now carry a model_id field with the model the client asked for, at every AUDIT_LOG_LEVEL and however long the request is. Other requests log it as null.
Fixes#30097
After a server upgrade, browsers could keep reusing their cached copy of the old app page for days, since it was sent with no caching instructions. That old page points at files the new version no longer has, so the app reloads into the same cached page and loops until a hard refresh. The app page now tells the browser to check for a newer version on every visit, which is a tiny request when nothing changed. Other files are cached as before, and an admin-set CACHE_CONTROL still takes precedence.
Fixes#31630
Notification targets subscribed to Chat failed stayed silent when the provider answered a chat with an error status, such as a 500, or could not be reached at all. Those failures show up as an error in the chat, but only a few uncommon failures were announced to the targets. Now these failures notify Chat failed targets too, with the error text and a link to the chat.
Fixes#32003
A user who had picked an option in a model control (the per-model selector in the chat input, for example High on a Thinking control) could not chat any more once the admin switched off Allow Chat Controls or Allow Chat Params for them. Every message failed with "You cannot change model parameters.", and the user could not clear the saved selection because the selector is hidden for them. When either permission is off, the saved selection is now skipped when sending, so messages go through with the model's default options, and it applies again if the permission comes back.
Fixes#31995
Automation runs, timers and sub-agents stopped getting a reply after the shared chats rework: the chat shows an empty answer and the run fails with `409 Message already exists or has an invalid ID.` Each of them creates the empty answer before asking the model, and the backend began refusing to fill an answer that is already in the chat; the server-side API flow in the docs and API calls without a user message broke the same way. Such an empty answer is now filled in again when it belongs to the same user and answers the same message, and API calls without a user message work as before, saving the reply on its own as the docs describe. A firing timer or sub-agent also no longer cancels the chat's other timers that are set to stop when the user writes next. Answers that are already finished, or that belong to another user in a shared chat, are still refused.
Fixes#32066
With ENABLE_CUSTOM_MODEL_FALLBACK on, a workspace model whose base model is gone should be answered by the first default model. That worked for plain API calls, but every chat sent from the web UI failed with "Model not found" for users and "Model '' was not found" for admins, and no model was called.
Web UI chats carry a chat id and a socket session, so the request is split into one task per selected model. Each task was rebuilt with the originally requested model id, which dropped the fallback chosen earlier in the handler. The task for the requested model now keeps the fallback model when one was chosen. The chat still records the workspace model the user picked.
Tested end to end against a mock upstream, as user and admin, in new and existing chats: before, every web UI send with such a model errored; after, the default model answers. Healthy models, workspace models with a valid base and multi-model sends behave as before, and with the fallback disabled the chat still fails with "Model not found".
Fixes#31345
Ejecting a loaded model from the model selector failed with a certificate error on llama.cpp and Ollama connections served over HTTPS with a self-signed or internal CA, even though chatting with the same connection worked. The unload request skipped the AIOHTTP_CLIENT_SESSION_SSL setting and always verified against the default system certificates, so setting it to a CA bundle or to false had no effect there. It now uses that setting, the same way chat requests to the connection already do.
Fixes#31371
ENABLE_ORJSON has shipped as an option since v0.11.0 (2026-07-27), five releases and two months ago, and orjson is already installed with every instance. The only two problems ever found with it (rare line break characters splitting a stream, and extra encoding options being ignored) were fixed in v0.11.1 and nothing has come up since. The regression suite at https://github.com/open-webui/tests now runs 222 tests with the option on and off side by side, on SQLite, Postgres, several workers sharing one Redis with some on and some off, and in the browser: chats, completions for every provider format, tool calls, citations, all workspace and admin data, exports and imports, notes and live socket updates behave the same, and every API response is byte for byte identical. The only differences were in how non-English text gets saved to the database, where the standard encoder is the one with bugs (missed searches and too small size limits). Turning it on by default gives every instance the speedup measured in #27583 (live socket updates encode 17x and decode 3x faster), and ENABLE_ORJSON=false keeps the old encoder.
With WEBSOCKET_MANAGER=redis and several instances or workers, an instance only subscribed to Redis once a browser tab had connected to it. Until then, when a tool or Function asked the user something (a confirmation or an input dialog) and the user's tab was connected to another instance, the user's reply never reached the tool and it waited until it timed out. Every instance now subscribes at startup, so the reply arrives whichever instance the tab is on.
With tool approval set to ask, the result of an approved tool call was dropped from the chat once the reply finished, so the model no longer saw it in later turns. When the model then asked for a second tool, the first call went back to waiting for approval, and approving it again ran the tool a second time. Approved results now stay in the chat and each tool runs once.
Related to #31499
Timothy Jaeryang Baek
Classic298andGitHub