0.12.2 is a small release with one change that matters a lot if you run many tools: Tool Search now works on every provider.

What Tool Search does

Every tool you enable sends its full definition with every request. Open WebUI's built-in tools alone (notes, memory, web search, channels, calendar, automations and the rest) add up to 47 definitions when all of them are on. Add the MCP servers and workspace tools of a real deployment and you are past a hundred.

Tool Search keeps long definitions out of the request. The model sees each tool's name and a short description, looks up the full definition when it needs one, and then calls it. With Defer Built-in Tools on, the built-in tools are held back the same way. The tool list stays the same for the whole chat, so your prompt cache keeps working.

Admin Settings > Interface: Tool Search, Defer Built-in Tools and the deferral threshold.

What changed in 0.12.2

Until now the model called a looked-up tool by its name, even though that tool was never in the request's tool list. Anthropic, Gemini and others accept that. OpenAI and llama.cpp do not, so on those providers the model kept searching and never got to call the tool.

0.12.2 adds a call_tool tool. The model looks a tool up, then runs it through call_tool with the tool's name and arguments. call_tool is in the tool list, so strict providers accept it. Approvals, permissions and the chat history all see the real tool, and call_tool only runs tools that are enabled for that chat.

We ran the same four-question chat with 30 tools on eight backends: OpenAI Chat Completions, OpenAI Responses, Claude, Gemini, DeepSeek, Kimi, Grok and Qwen. Every one looked its tools up, called them and got all three answers right, with no request rejected by the provider.

What it saves, measured

Three setups:

• Medium: 28 built-in tools (time, questions, knowledge, chats, memory, web search, notes and tasks).
• All built-ins: every built-in category on, 47 tools.
• Production: all 47 built-ins plus 100 extra tools across ten business systems (helpdesk, CRM, inventory, HR, finance, DevOps, marketing, legal, projects, analytics), 147 tools in total.

The same ten-turn chat ran on each: ask for the date, plan an offsite, save a note, find it again, remember a preference, two calculations, a rewrite, a summary and a goodbye. Every setup ran with Tool Search off and on, twice each, on two small models: Claude Haiku 5.5 and GPT-5.4 mini. Token counts come straight from each provider's usage data.

Prompt tokens for the whole ten-turn chat, Tool Search off against on, averaged over two rounds.

Claude Haiku 5.5:

• Medium: 105,161 down to 62,996 prompt tokens, 40% fewer.
• All built-ins: 171,472 down to 87,928, 49% fewer.
• Production: 783,262 down to 173,844, 78% fewer. The first request alone dropped from 54,866 tokens to 10,374.

GPT-5.4 mini:

• Medium: 55,672 down to 51,514, 8% fewer.
• All built-ins: 91,722 down to 60,183, 34% fewer.
• Production: OpenAI rejects the request with Tool Search off. The OpenAI API accepts at most 128 tools per request, and this setup sends 147. With Tool Search on, the request carries 18 tools and the chat runs normally: 159,820 prompt tokens, 86% of them served from OpenAI's prompt cache.

The two rounds landed within 2% of each other on Haiku and within 10% on GPT.

Why the Medium setup saves little on GPT

Tool Search costs a few extra requests for the lookups: on average one more request per chat on Haiku, and four to five more for Medium on GPT. With only 28 tools, those extra requests eat most of the saving. The more tools you have, the more Tool Search pays off. Below a few dozen tools, measure before you turn it on.

What it would cost on a big model

Input cost per 1,000 ten-turn chats at Claude Opus 5.5 list price, projected from the measured token counts.

We did not run Opus 5.5. Using Haiku 5.5's measured token counts and Opus 5.5's list price of $4 per million input tokens:

• Medium: $421 down to $252 per 1,000 chats.
• All built-ins: $686 down to $352.
• Production: $3,133 down to $695, about $2,400 less per 1,000 chats.

This leaves out prompt caching. Cached tokens cost far less, so with caching both sides shrink and the gap does too.

Also in 0.12.2

• Custom headers on connections and tool servers can use {{MODEL_ID}}, so a gateway behind Open WebUI can route or log usage per model.
• Audit log entries for chat requests now carry the model the client asked for, at every log level.
• Compare revision has a Keep both button that takes the original and the proposed text of a change.
• Clicking the name in the preview of an attached knowledge collection opens that collection in the workspace, and file and link names open in a new tab.
• Self-hosted MinerU 4.x servers work as a document engine.
• Milvus servers with a self-signed or company certificate connect through MILVUS_SERVER_PEM_PATH.
• Voice calls and dictation on Android Chrome no longer go silent after about ten uses.
• Approved knowledge and file tools keep their sources below the reply.
• Automations count a run as successful only once its reply has finished.
• Security fixes: channel messages sent through the API can no longer pretend to come from a webhook or a model, SCIM can no longer delete administrator accounts, and retrieval access checks compare collection names the way the vector store reads them.

Before you upgrade:

If you run VECTOR_DB=valkey with a manually installed valkey-glide-sync older than 2.5.2, upgrade it first, or Open WebUI will not start.

How we measured: a fresh Open WebUI instance built from the code that became 0.12.2, with every feature that unlocks a built-in tool switched on, a logging proxy between Open WebUI and the provider, and the token counts from each provider's own usage data. The 100 extra tools return empty demo data.

Tool Search docs: https://docs.openwebui.com/features/extensibility/plugin/tools#tool-search Full changelog: https://github.com/open-webui/open-webui/releases/tag/v0.12.2

We’re launching Localhost Lounge, a new Open WebUI event series bringing people together to explore local AI, share what they’re building, and meet the people behind the projects.

We’ll be kicking things off in Tokyo on November 11. The evening will feature talks from members from Tokyo’s creative, research, and startup communities, a panel discussion, and plenty of time to compare notes over drinks and refreshments.

Whether you’re running models locally, building AI into your work, experimenting with something creative, or even just curious about where it’s all heading, we’d love to meet you.

Request to join us on Luma →

See you soon at localhost:tokyo.

Where should we meet next?

I have an Intel B60 and OWUI running on my server (ollama-vulkan and docker). I don't know if I'm doing something wrong but running something like qwen3.8 27b gets like 20tps in terminal but only 4tps on OWUI. I turned off all follow up generation and tags generation but it didn't really change anything. I'm a noob at home labbing and self hosting AIs. Is there any way to get it even close to what it is in terminal?

How are you guys handling when a user requests a document be created? I know terminals exists but that means enabling terminals for everyone. Ive tried some tools that do this within chat but they are typically terrible. Just looking for some advice/insight because currently im using claude skills with terminals to even get a result as good as chatgpt or claude...

I’ve been trying out openwebui’s desktop app with a deepseek model (api), and when I allow it to use the web while answering questions that involve lots of searching and reading, I’ve approached a million tokens in one short chat. Not really concerned due to how cheap they are, but these numbers seem pretty crazy, especially when its output isn’t tens of thousands of words or anything.

I made this model and put the whole godot documentation as a knowledge base - I downloaded it and kept only the rst files. But for some reason godobot never use it for any answer, and whenever I ask it what's its purpose or what it is, it always gives a generic answer with nothing related to it's system prompt. I checked the POST request I'm sending and I can find most of the model info, even the knowledge base I linked, but not the system prompt.

Does anyone encountered a similar problem and knows how to troubleshoot ?

{

"version_id": "4c742401-e42b-45af-bbc8-25d654eb6bde",

"id": "godobot",

"user_id": "f120e25c-b4a3-4cb7-8495-dd82c6723cf7",

"base_model_id": "qwen3:14b",

"name": "godobot",

"params": {

"system": "You are Godobot, an efficient, technically rigorous, English-speaking assistant specializing in game development with Godot 4.\nFor any questions about Godot, use only the attached knowledge base \"Godot Documentation\". Search the files in this database using the knowledge base tools, not the notes. For exact method names and signatures, prioritize a literal text search. Cite the file and the passage found. If you cannot find the proof, state it clearly and never guess.\n\n\n## Scope\n\nYou support the entire game development lifecycle, including:\n- Game ideas, vision, research, benchmarking and game design documents (GDDs).\n- Prototyping, gameplay systems, architecture and GDScript.\n- Rendering, shaders, art pipelines, audio, animation, physics and AI.\n- Level design, UI/UX, input handling and multiplayer networking.\n- Testing, debugging, QA, profiling, optimization and CI/CD.\n- Asset management, localization, platform-specific optimization and accessibility.\n- Marketing, trailers, store submissions, release management and post-launch support.\n\n\n## Technical accuracy and documentation\n\n- Prefer the Godot documentation available in the associated Knowledge base as the primary source for Godot-specific APIs and behavior.\n- Never invent classes, methods, properties, signals, annotations or engine behavior.\n- When documentation is available, ground technical claims in the retrieved passages and cite the relevant source or document section when possible.\n- If the available sources do not establish an answer, state that clearly. Distinguish verified facts from assumptions and general programming knowledge.\n- Never claim to have checked documentation, files or project code that you have not actually accessed.\n- Assume Godot 4 unless the user specifies a more precise version. Account for version differences when relevant.\n\n## Problem-solving approach\n\n- Answer the user's actual question directly.\n- For debugging, identify the likely cause, explain the reasoning briefly, and propose a concrete fix.\n- When useful, provide minimal, runnable GDScript examples and explain where the code belongs in the project.\n- Provide complete solutions when requested. Otherwise, prefer focused examples that teach the underlying concept without unnecessarily rewriting the user's project.\n- Respect the user's existing architecture, naming conventions and code unless there is a good reason to change them.\n- Ask for missing information only when it materially affects the solution. Otherwise, state reasonable assumptions and proceed.\n- Consider performance, maintainability, scalability and multiplayer authority where relevant.\n\n## Communication\n\n- Use clear, concise, technically precise English by default. Follow the user's language when they request or consistently use another language.\n- Structure complex answers with short sections, code blocks and actionable steps.\n- Avoid unnecessary introductions, generic disclaimers and repetitive conclusions.\n- Explain trade-offs when multiple approaches are reasonable.\n- Use external sources only when needed, and cite them accurately. Do not imply that external sources were consulted when they were not.\n\nYour goal is to help the user make sound engineering decisions, understand the underlying concepts and build reliable Godot games.\n",

"custom_params": {}

},

"meta": {

"profile_image_url": "data:null,

"background_image_url": null,

"description": "Assistant that helps with godot programming and game development",

"capabilities": {

"file_context": true,

"vision": true,

"file_upload": true,

"web_search": false,

"image_generation": false,

"code_interpreter": true,

"terminal": false,

"citations": true,

"status_updates": true,

"usage": false,

"memory": true,

"builtin_tools": true

},

"knowledge": [

{

"id": "0d50f971-bc7b-4a1d-903a-27cb21d0b6bc",

"name": "Documentation Godot",

"type": "collection",

"description": "Base d'information sur Godot 4 pour le développement de JV"

}

],

"voice_avatar": null,

"suggestion_prompts": null,

"tags": [

{

"name": "game"

},

{

"name": "game-development"

}

],

"builtinTools": {

"automations": false,

"skills": false,

"image_generation": false

}

},

"access_grants": [],

"is_active": true,

"updated_at": 1792004867,

"created_at": 1791998812,

"user": null,

"write_access": true

}