mirror of
https://github.com/open-webui/docs.git
synced 2026-07-19 14:43:33 -04:00
Document v0.10.3: sub-agents, timers, notifications and shortcuts
Add feature pages for the four features this release introduces: - Sub-agents, covering delegation, foreground and background runs, the admin limits and what a sub-agent deliberately cannot do. - Timers, including that they are gated by the Sub-agents setting rather than having one of their own. - Notifications, covering webhook targets, the four subscribable events, away and always delivery, and migration from the old single webhook. - Keyboard shortcuts, with the fifteen rebindable defaults. Document the new configuration: the seven SUBAGENTS_* variables, TIMER_POLL_INTERVAL, USER_PERMISSIONS_ACCESS_GRANTS_ALLOW_GROUPS and ENABLE_PLUGINS, and add delegate_task, timer and notify to the builtin tool tables. Correct what the release made wrong: the title-generation prompt no longer asks for emojis, per-model compaction thresholds are now bounded by a cap rather than by the global threshold, replace_note_content takes range operations, the Webhooks page still described the removed single webhook field, and the Archived Chats path moved. Admin settings are now a section of the Settings dialog rather than a page of their own, so rewrite the paths accordingly, and record the access-grant sharing permissions, the note-chat tool overrides and the new Anthropic token-counting endpoints. Update the schema reference for the chat_message.meta column, and bring the version notes and pinned image examples up to v0.10.3.
This commit is contained in:
+3
-3
@@ -214,7 +214,7 @@ Models frequently:
|
||||
|
||||
**To verify which model you're actually using:**
|
||||
1. Check the model selector in the Open WebUI interface
|
||||
2. Look at the **Admin Panel > Settings > Connections** to confirm your API endpoints
|
||||
2. Look at the **Settings > Admin > AI > Connections** to confirm your API endpoints
|
||||
3. Check your provider's dashboard/logs for the actual API calls being made
|
||||
|
||||
Asking the model itself is **not** a valid way to diagnose routing issues. If you suspect a configuration problem, check your connection settings and API keys instead.
|
||||
@@ -240,8 +240,8 @@ This is also why the same model accessed through different interfaces might give
|
||||
By default, these tasks use the **same model** you're chatting with. If you're using an expensive API model (like GPT-4 or Claude), this can significantly increase your costs.
|
||||
|
||||
**To reduce API costs:**
|
||||
1. Go to **Admin Panel > Settings > Interface** (for title/tag generation settings)
|
||||
2. Configure a **Task Model** under **Admin Panel > Settings > Models** to use a smaller, cheaper model (like GPT-4o-mini) or a local model for background tasks
|
||||
1. Go to **Settings > Admin > Experience > Interface** (for title/tag generation settings)
|
||||
2. Configure a **Task Model** under **Settings > Admin > AI > Models** to use a smaller, cheaper model (like GPT-4o-mini) or a local model for background tasks
|
||||
3. Disable features you don't need (auto-title, auto-tags, etc.)
|
||||
|
||||
:::tip Cost-Saving Recommendation
|
||||
|
||||
@@ -28,7 +28,7 @@ You can configure the admin webhook in two ways:
|
||||
#### Option 1: Through the Admin Panel
|
||||
|
||||
1. Log in as an administrator.
|
||||
2. Navigate to **Admin Panel > Settings > General**.
|
||||
2. Navigate to **Settings > Admin > System > General**.
|
||||
3. Locate the **"Webhook URL"** field.
|
||||
4. Enter the webhook URL provided by your external service (e.g., Discord, Slack).
|
||||
5. Click **"Save"**.
|
||||
@@ -53,9 +53,13 @@ When a new user signs up, Open WebUI will send a `POST` request to the configure
|
||||
}
|
||||
```
|
||||
|
||||
## 2. User Webhook: Chat Response Notifications
|
||||
## 2. User Webhook: Notification Targets
|
||||
|
||||
This webhook allows individual users to receive a notification when a model has finished generating a response to their prompt. It's particularly useful for long-running tasks where you might navigate away from the Open WebUI tab.
|
||||
This webhook lets individual users be notified when something they care about happens, such as a model finishing a long response, a channel message arriving, or a calendar alert firing. It is useful when you have navigated away from the Open WebUI tab.
|
||||
|
||||
Each user configures one or more **notification targets** in **Settings > Notifications**, and chooses per target which events it receives and whether it fires only while they are away or always. The model can also send a notification itself through the `notify` tool.
|
||||
|
||||
See **[Notifications](/features/chat-conversations/chat-features/notifications)** for the full feature: targets, the four subscribable events, delivery modes, URL masking, and the `notify` tool.
|
||||
|
||||
### Use Case
|
||||
|
||||
@@ -63,7 +67,7 @@ This webhook allows individual users to receive a notification when a model has
|
||||
|
||||
### How it Works
|
||||
|
||||
The notification is only sent if you are **not actively using the WebUI**. If you have the tab open and focused, the webhook will not be triggered, preventing unnecessary notifications.
|
||||
With the default **away** delivery, a notification is only sent if you are **not actively using the WebUI**, so you are not pinged about something you are already watching. Setting a target to **always** sends regardless. Channel messages are always delivered, since they come from someone else.
|
||||
|
||||
### Enabling/Disabling User Webhooks
|
||||
|
||||
@@ -72,36 +76,24 @@ User webhooks are disabled by default. Administrators can enable this feature fo
|
||||
This can be done in two ways:
|
||||
|
||||
1. **Directly in the Admin Panel:**
|
||||
- Go to **Admin Panel > Settings > General > Features**.
|
||||
- Go to **Settings > Admin > System > General > Features**.
|
||||
- Toggle the switch for **"User Webhooks"**.
|
||||
|
||||
2. **Using Environment Variables:**
|
||||
- Set the environment variable `ENABLE_USER_WEBHOOKS` to `False` in your backend configuration. This will globally disable the feature and hide the setting from user profiles.
|
||||
|
||||
Users also need the `features.webhooks` permission ([`USER_PERMISSIONS_FEATURES_USER_WEBHOOKS`](/reference/env-configuration#user_permissions_features_user_webhooks)); admins always have it.
|
||||
|
||||
### Configuration
|
||||
|
||||
1. Click on your profile picture in the bottom-left corner to open the settings menu.
|
||||
2. Navigate to **Settings > Account**.
|
||||
3. Locate the **"Notification Webhook"** field.
|
||||
4. Enter your personal webhook URL.
|
||||
5. Click **"Save"**.
|
||||
2. Navigate to **Settings > Notifications**.
|
||||
3. Add a target with your webhook URL, and pick the events it should receive.
|
||||
4. Use **Send Test** to confirm it works.
|
||||
|
||||
### Payload Format
|
||||
|
||||
When a chat response is ready and you are inactive, Open WebUI will send a `POST` request to your webhook URL with a JSON payload containing details about the chat.
|
||||
|
||||
**Payload Example:**
|
||||
|
||||
```json
|
||||
{
|
||||
"event": "chat_response",
|
||||
"chat": {
|
||||
"id": "abc-123-def-456",
|
||||
"title": "My Awesome Conversation",
|
||||
"last_message": "This is the prompt I submitted."
|
||||
}
|
||||
}
|
||||
```
|
||||
:::info Upgrading from the old Notification Webhook field
|
||||
The single **Notification Webhook** field under **Settings > Account** has been replaced by targets. An existing URL is migrated automatically into a target subscribed to all events, so notifications keep arriving without any action.
|
||||
:::
|
||||
|
||||
## 3. Channel Webhooks: External Message Integration
|
||||
|
||||
|
||||
@@ -43,9 +43,9 @@ Name each key descriptively (e.g., "CI Pipeline", "Monitoring Bot") to track usa
|
||||
### Step 1: Enable API Keys Globally (Admin)
|
||||
|
||||
1. Log in as an **administrator**
|
||||
2. Open **Admin Panel > Settings > General**
|
||||
2. Open **Settings > Admin > System > General**
|
||||
3. Scroll to the **Authentication** section
|
||||
4. Toggle **Enable API Keys** on
|
||||
4. Toggle **API Keys** on
|
||||
5. Click **Save**
|
||||
|
||||
:::info
|
||||
@@ -154,7 +154,7 @@ Periodically delete old keys and generate new ones, especially for long-lived in
|
||||
|
||||
**Can't see the API Keys section in Settings > Account?**
|
||||
|
||||
- **Check the global toggle:** Verify that an admin has enabled API keys in **Admin Panel > Settings > General > Enable API Keys**. See [`ENABLE_API_KEYS`](/reference/env-configuration#enable_api_keys).
|
||||
- **Check the global toggle:** Verify that an admin has enabled API keys in **Settings > Admin > System > General > API Keys**. See [`ENABLE_API_KEYS`](/reference/env-configuration#enable_api_keys).
|
||||
- **Check your permissions (non-admin users):** Verify that your account or group has the **API Keys** feature permission under **Features Permissions**. See [`USER_PERMISSIONS_FEATURES_API_KEYS`](/reference/env-configuration#user_permissions_features_api_keys).
|
||||
|
||||
**Getting `401 Unauthorized` responses?**
|
||||
|
||||
@@ -50,7 +50,7 @@ Some permissions are **dependent** on others (e.g., you cannot import models if
|
||||
| **Prompts Access** | **(Parent)** Access the **Prompts** workspace to manage custom system prompts. |
|
||||
| **Prompts Import** | *(Requires Prompts Access)* Ability to import prompts. |
|
||||
| **Prompts Export** | *(Requires Prompts Access)* Ability to export prompts. |
|
||||
| **Tools Access** | **(Parent)** Access the **Tools** workspace to manage functions/tools. |
|
||||
| **Tools Access** | **(Parent)** Access the **Tools** workspace to manage functions/tools. Hidden, along with its Import and Export sub-toggles, when [`ENABLE_PLUGINS`](/reference/env-configuration#enable_plugins) is `false`, since the Tools workspace does not exist in that case. |
|
||||
| **Tools Import** | *(Requires Tools Access)* Ability to import tools. |
|
||||
| **Tools Export** | *(Requires Tools Access)* Ability to export tools. |
|
||||
|
||||
@@ -82,6 +82,8 @@ Controls what users can share with the community or make public.
|
||||
| **Folders Sharing** | Ability to share a chat folder (and the chats inside it) with specific users or groups, with read or write access. Subfolders inherit the share, and folders cannot be shared publicly. Admins are always exempt. |
|
||||
| **Chats Public Sharing** | *(Requires Share Chat)* Ability to make a chat share link reachable by anyone (including unauthenticated visitors). When disabled, users can still share chats with specific users or groups via the access-control selector, but the "Public" option is hidden for non-admins. Admins are always exempt. |
|
||||
| **Calendars Public Sharing** | *(Requires Features > Calendar)* Ability to make a calendar publicly readable or writable by every user with the Calendar feature. When disabled, wildcard access grants are stripped from calendar create/update payloads; owners can still share with specific users or groups. Admins are always exempt. |
|
||||
| **Allow Sharing With Users** | Ability to share a resource with **specific individual users** ([`USER_PERMISSIONS_ACCESS_GRANTS_ALLOW_USERS`](/reference/env-configuration#user_permissions_access_grants_allow_users)). When disabled, individual-user grants are stripped from create/update payloads; group and public sharing are unaffected. Admins are always exempt. |
|
||||
| **Allow Sharing With Groups** | Ability to share a resource with **groups** ([`USER_PERMISSIONS_ACCESS_GRANTS_ALLOW_GROUPS`](/reference/env-configuration#user_permissions_access_grants_allow_groups)). When disabled, group grants are stripped from create/update payloads; individual-user and public sharing are unaffected. Admins are always exempt. Set this per group: the global default currently does not persist, see the [note in the reference](/reference/env-configuration#user_permissions_access_grants_allow_groups). |
|
||||
|
||||
### 3. Chat Permissions
|
||||
Controls the features available to the user inside the chat interface.
|
||||
@@ -160,7 +162,7 @@ Controls access to user settings areas.
|
||||
|
||||
For API key creation:
|
||||
|
||||
1. **Global Toggle Required**: The feature must be enabled globally in **Admin Settings > General > Enable API Keys**. If this is off, *no one* can generate keys.
|
||||
1. **Global Toggle Required**: The feature must be enabled globally in **Admin Settings > General > API Keys**. If this is off, *no one* can generate keys.
|
||||
2. **Permission Check for Non-Admins**: Users with the `user` role must have the `features.api_keys` permission.
|
||||
3. **Admins Are Exempt from `features.api_keys`**: Users with the `admin` role can generate API keys when API keys are globally enabled, even without that specific permission.
|
||||
|
||||
|
||||
@@ -163,7 +163,7 @@ spec:
|
||||
- **Use Secrets Management**: Never hardcode `WEBUI_ADMIN_PASSWORD` in Docker Compose files or Dockerfiles. Use Docker secrets, Kubernetes secrets, or environment variable injection.
|
||||
- **Strong Passwords**: Use a strong, unique password for production deployments.
|
||||
- **Change After Setup**: Consider changing the admin password through the UI after initial deployment for enhanced security.
|
||||
- **Automatic Signup Disable**: After admin creation, sign-up is automatically disabled. You can re-enable it later via **Admin Panel > Settings > General** if needed.
|
||||
- **Automatic Signup Disable**: After admin creation, sign-up is automatically disabled. You can re-enable it later via **Settings > Admin > System > General** if needed.
|
||||
:::
|
||||
|
||||
:::info Behavior Details
|
||||
|
||||
@@ -263,7 +263,7 @@ The global alert polling window is configurable via [`CALENDAR_ALERT_LOOKAHEAD_M
|
||||
| [`SCHEDULER_POLL_INTERVAL`](/reference/env-configuration#scheduler_poll_interval) | `10` | Seconds between scheduler ticks (shared with automations) |
|
||||
| [`CALENDAR_ALERT_LOOKAHEAD_MINUTES`](/reference/env-configuration#calendar_alert_lookahead_minutes) | `10` | Default alert window in minutes for upcoming events |
|
||||
|
||||
Calendar can also be toggled from **Admin Panel > Settings > General** under the Features section.
|
||||
Calendar can also be toggled from **Settings > Admin > System > General** under the Features section.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -137,7 +137,7 @@ If you want a one-click path from a chat message into a channel, the community *
|
||||
Channels must be enabled by an administrator before use.
|
||||
:::
|
||||
|
||||
1. Navigate to **Admin Panel > Settings > General**
|
||||
1. Navigate to **Settings > Admin > System > General**
|
||||
2. Toggle **Channels** on and save
|
||||
3. Channels appear in the sidebar. Click **(+)** to create your first one
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@ For a complete list of all Open WebUI environment variables, see the [Environmen
|
||||
The following is a summary of the environment variables for speech to text (STT) and text to speech (TTS).
|
||||
|
||||
:::tip UI Configuration
|
||||
Most of these settings can also be configured in the **Admin Panel → Settings → Audio** tab. Environment variables take precedence on startup but can be overridden in the UI.
|
||||
Most of these settings can also be configured in the **Settings → Admin → Experience → Audio** tab. Environment variables take precedence on startup but can be overridden in the UI.
|
||||
:::
|
||||
|
||||
## Speech To Text (STT) Environment Variables
|
||||
|
||||
+1
-1
@@ -214,7 +214,7 @@ To use Chatterbox TTS API with Open WebUI, follow these steps:
|
||||
- API Key: `none`
|
||||
- TTS Model: `tts-1` or `tts-1-hd`
|
||||
- TTS Voice: Name of the voice you've cloned (can also include aliases, defined in the frontend)
|
||||
- Response splitting: `Paragraphs`
|
||||
- Response Splitting: `Paragraphs`
|
||||
|
||||
:::info
|
||||
|
||||
|
||||
@@ -120,7 +120,7 @@ services:
|
||||
|
||||
## Response Splitting
|
||||
|
||||
When reading long responses, Open WebUI can split text into chunks before sending them to the TTS engine. This is configured in **Admin Panel > Settings > Audio** under **Response Splitting**.
|
||||
When reading long responses, Open WebUI can split text into chunks before sending them to the TTS engine. This is configured in **Settings > Admin > Experience > Audio** under **Response Splitting**.
|
||||
|
||||
| Option | Description |
|
||||
|--------|-------------|
|
||||
|
||||
+1
-1
@@ -150,7 +150,7 @@ docker run -d -p 8000:8000 -v voices:/app/voices -v config:/app/config --name op
|
||||
|
||||

|
||||
|
||||
Open the Open WebUI settings and navigate to the TTS Settings under **Admin Panel > Settings > Audio**. Add the following configuration:
|
||||
Open the Open WebUI settings and navigate to the TTS Settings under **Settings > Admin > Experience > Audio**. Add the following configuration:
|
||||
|
||||
- **API Base URL**: `http://host.docker.internal:8000/v1`
|
||||
- **API Key**: `sk-111111111` (Note that this is a dummy API key, as `openedai-speech` doesn't require an API key. You can use whatever you'd like for this field, as long as it is filled.)
|
||||
|
||||
@@ -7,7 +7,7 @@ title: "Automations"
|
||||
|
||||
Automations let you schedule prompts to run automatically at recurring times. Each run creates a chat and executes through the normal chat completion pipeline, so model defaults, tools, filters, and other pipeline behavior still apply.
|
||||
|
||||
Automations can be enabled or disabled globally by an administrator via the [`ENABLE_AUTOMATIONS`](/reference/env-configuration#enable_automations) environment variable or the **Admin Panel > Settings > General** toggle. When disabled, the automation worker stops processing, API endpoints return `403`, and the sidebar entry is hidden.
|
||||
Automations can be enabled or disabled globally by an administrator via the [`ENABLE_AUTOMATIONS`](/reference/env-configuration#enable_automations) environment variable or the **Settings > Admin > System > General** toggle. When disabled, the automation worker stops processing, API endpoints return `403`, and the sidebar entry is hidden.
|
||||
|
||||
## What You Can Automate
|
||||
|
||||
|
||||
@@ -9,11 +9,11 @@ To enable community sharing, follow these steps:
|
||||
|
||||
1. Navigate to the **Admin Panel** page as an **Admin**.
|
||||
2. Click on the **Settings** tab.
|
||||
3. Toggle on **Enable Community Sharing** within the **General** settings tab.
|
||||
3. Toggle on **Community Sharing** within the **General** settings tab.
|
||||
|
||||
:::note
|
||||
|
||||
**Note:** Only Admins can toggle the **Enable Community Sharing** option. If this option is toggled off, users and Admins will not see the **Share to Open WebUI Community** option for sharing their chats. Community sharing must be enabled by an Admin for users to share chats to the Open WebUI community.
|
||||
**Note:** Only Admins can toggle the **Community Sharing** option. If this option is toggled off, users and Admins will not see the **Share to Open WebUI Community** option for sharing their chats. Community sharing must be enabled by an Admin for users to share chats to the Open WebUI community.
|
||||
|
||||
:::
|
||||
|
||||
|
||||
@@ -37,7 +37,7 @@ The Code Interpreter is a model capability that enables LLMs to write and execut
|
||||
|
||||
**Global Configuration (Admin Panel):**
|
||||
|
||||
These settings can be configured at **Admin Panel → Settings → Code Execution**:
|
||||
These settings can be configured at **Settings → Admin → Tools → Code Execution**:
|
||||
- Enable/disable code interpreter
|
||||
- Select engine: **Pyodide (legacy)** or **Jupyter (legacy)** (for full Python and shell access, use [Open Terminal](/features/open-terminal) instead)
|
||||
- Configure Jupyter connection settings
|
||||
|
||||
@@ -45,8 +45,38 @@ Open WebUI provides a comprehensive set of chat features designed to enhance you
|
||||
|
||||
- **[✅ Task Management](./task-management.mdx)**: Let agentic models keep a structured task/todo list in chat for multi-step workflows and transparent progress tracking.
|
||||
|
||||
- **[🤖 Sub-agents](./subagents.mdx)**: Let a model delegate focused work to parallel sub-agents that run the same model and tools, and report back.
|
||||
|
||||
- **[⏰ Timers](./timers.mdx)**: One-shot timers that send a prompt back into the chat when they fire, so a model can pick something up later.
|
||||
|
||||
- **[🔔 Notifications](./notifications.mdx)**: Per-user webhook targets that notify you when a chat finishes or fails, a channel message arrives, or a calendar alert triggers, plus a `notify` tool the model can call.
|
||||
|
||||
- **[⌨️ Keyboard Shortcuts](./keyboard-shortcuts.mdx)**: Rebindable shortcuts for the common actions, managed in **Settings > Keyboard**.
|
||||
|
||||
- **Skill Mentions**: Use `$` in the chat input to mention and activate [Skills](/features/workspace/skills) on-the-fly, injecting their manifests into the conversation.
|
||||
|
||||
- **Chat Input Commands**: Typing a trigger character in the chat input opens a suggestion menu:
|
||||
|
||||
| Trigger | Offers |
|
||||
|---|---|
|
||||
| `/` | Built-in commands (below), plus your [Prompts](/features/workspace/prompts) and [Skills](/features/workspace/skills) |
|
||||
| `@` | Models to switch to, plus attachable context: knowledge bases, collections, files, folders, and web or YouTube URLs |
|
||||
| `#` | Attach knowledge and files |
|
||||
| `$` | Mention and activate skills |
|
||||
| `:` | Emoji |
|
||||
|
||||
`/` and `@` used to offer only prompts and only models respectively; both now cover much more.
|
||||
|
||||
- **Built-in Slash Commands**: three commands act on the current chat. They only appear once the chat has messages, and are typed on their own rather than sent to the model:
|
||||
|
||||
| Command | What it does |
|
||||
|---|---|
|
||||
| `/compact` | Compacts the conversation now, instead of waiting for it to cross the threshold. Only offered when [Context Compaction](/troubleshooting/context-window#the-built-in-option-context-compaction) is enabled, and not while a response is generating. It reports what happened: the context was compacted, or it was skipped because the chat is too short, empty, or compaction is disabled. |
|
||||
| `/status` | Opens a status panel for the chat showing **Context usage**, **Queued messages**, **Tasks** currently running, and the **Chat ID**. |
|
||||
| `/fork` | Copies the conversation up to the current message into a new chat, so you can branch off without disturbing the original. |
|
||||
|
||||
`/fork` requires the **Chat Import** permission (`chat.import`, allowed by default; admins always pass). The command still appears in the menu without it, and reports **Access prohibited** when run.
|
||||
|
||||
- **Writing & Content Blocks**: Responses from models that include colon-fence blocks (e.g., `:::writing`, `:::code_execution`, `:::search_results`) are automatically rendered as formatted content in a styled container with a copy button. This is commonly used by newer OpenAI models to distinguish different types of output (prose, code results, search results) from the main response text.
|
||||
|
||||
- **Structured Response Editing**: Clicking the edit icon on an assistant response that contains tool calls, reasoning blocks, or code-interpreter output opens a structured editor instead of a plain textarea. Each output item (text, thought, tool call, code block, web/file/computer search) becomes its own collapsible field, and a **JSON** toggle exposes the underlying [OpenAI Responses API](https://platform.openai.com/docs/api-reference/responses) payload for direct editing. Reasoning/thinking blocks are editable here too. The previous textarea editor reduced them to a non-editable `<details>` placeholder. Plain text-only responses keep the original textarea behavior. Editing rewrites the message's `output` array; Open WebUI re-derives the displayed `content` (including `<details>` blocks for thoughts and tool calls) on save, so the rendered message stays consistent.
|
||||
|
||||
@@ -0,0 +1,54 @@
|
||||
---
|
||||
sidebar_position: 16
|
||||
title: "Keyboard Shortcuts"
|
||||
---
|
||||
|
||||
# Keyboard Shortcuts
|
||||
|
||||
Open WebUI ships with keyboard shortcuts for the things you do constantly, and most of them can be **rebound to keys you prefer**. Shortcuts are per user and stored with your settings.
|
||||
|
||||
Manage them in **Settings > Keyboard**. Each configurable shortcut can be reassigned individually, or left unassigned, and a **Reset Defaults** button restores **all** of them at once. There is no per-shortcut reset.
|
||||
|
||||
`Cmd` below means the `Ctrl` key on Windows and Linux. On macOS it means the `Command` key specifically: `Ctrl` is treated as its own modifier there and does not stand in for `Cmd`, so `Ctrl+K` will not open search on a Mac, only `Cmd+K` will.
|
||||
|
||||
## Configurable Shortcuts
|
||||
|
||||
These fifteen can be rebound:
|
||||
|
||||
| Action | Default |
|
||||
|---|---|
|
||||
| New chat | `Cmd+Shift+O` |
|
||||
| New temporary chat | `Cmd+Shift+'` |
|
||||
| Delete chat | `Cmd+Shift+Backspace` |
|
||||
| Open model selector | `Cmd+Shift+M` |
|
||||
| Toggle dictation | `Cmd+Shift+L` |
|
||||
| Search | `Cmd+K` |
|
||||
| Open settings | `Cmd+.` |
|
||||
| Show shortcuts | `Cmd+/` |
|
||||
| Toggle sidebar | `Cmd+Shift+S` |
|
||||
| Close modal | `Escape` |
|
||||
| Focus input | `Shift+Escape` |
|
||||
| Generate message pair | `Cmd+Shift+Enter` |
|
||||
| Regenerate response | `Cmd+R` |
|
||||
| Copy last code block | `Cmd+Shift+;` |
|
||||
| Copy last response | `Cmd+Shift+C` |
|
||||
|
||||
Anything not listed here is fixed and cannot be reassigned.
|
||||
|
||||
:::info Changes in this release
|
||||
Shortcuts used to be a fixed list shown in a modal. They are now rebindable and live in **Settings > Keyboard**; the separate shortcuts modal is gone.
|
||||
|
||||
One default changed: **Delete chat** is now `Cmd+Shift+Backspace` only. It previously also responded to `Delete`.
|
||||
:::
|
||||
|
||||
## Chat Input Triggers
|
||||
|
||||
Distinct from shortcuts, typing one of these characters in the chat input opens a suggestion menu. See [Chat Features](/features/chat-conversations/chat-features/) for the full list.
|
||||
|
||||
| Trigger | Offers |
|
||||
|---|---|
|
||||
| `/` | Commands, prompts and skills |
|
||||
| `@` | Models, knowledge, files, folders and URLs |
|
||||
| `#` | Knowledge and files |
|
||||
| `$` | Skills |
|
||||
| `:` | Emoji |
|
||||
@@ -28,7 +28,7 @@ In a Multi-Model Chat, your prompt is sent to two or more selected models at the
|
||||
|
||||
Admins can control access to Multi-Model Chats on a per-role or per-group basis.
|
||||
|
||||
* **Location**: Admin Panel > Settings > General > User Permissions > Chat > **Multiple Models**
|
||||
* **Location**: Settings > Admin > System > General > User Permissions > Chat > **Multiple Models**
|
||||
* **Environment Variable**: `USER_PERMISSIONS_CHAT_MULTIPLE_MODELS` (Default: `True`)
|
||||
|
||||
If disabled, users will not see the "plus" button in the model selector and cannot initiate multi-model sessions.
|
||||
@@ -59,7 +59,7 @@ Merging takes the outputs from all your active models and sends them (along with
|
||||
|
||||
The merging process relies on the backend **Tasks** system.
|
||||
|
||||
* **Task Model**: The specific model used to perform the merger can be configured in **Admin Panel > Settings > Tasks**. We recommend using a highly capable model (like GPT-5.1 or Claude Sonnet 4.5) as the task model for the best results.
|
||||
* **Task Model**: The specific model used to perform the merger can be configured in **Settings > Admin > Experience > Interface > Tasks**. We recommend using a highly capable model (like GPT-5.1 or Claude Sonnet 4.5) as the task model for the best results.
|
||||
* **Prompt Template**: The system uses a specialized prompt template to instruct the AI on how to synthesize the answers.
|
||||
|
||||
:::info Experimental
|
||||
|
||||
@@ -0,0 +1,93 @@
|
||||
---
|
||||
sidebar_position: 15
|
||||
title: "Notifications"
|
||||
---
|
||||
|
||||
# Notifications
|
||||
|
||||
Notifications send a webhook to somewhere you actually watch, such as Slack, Discord or your own endpoint, when something happens in Open WebUI that you care about. Each user sets up their own **targets** and chooses which events reach them, so a long answer, a channel message or a calendar alert can find you after you have moved on.
|
||||
|
||||
Notifications are **off by default** and are opt-in twice over: an administrator enables the feature, and each user adds their own targets.
|
||||
|
||||
This is **outbound webhooks only**. The **Browser Notifications** and **Notification Sound** toggles on the same settings page are separate, unrelated, and handled by your browser.
|
||||
|
||||
:::note "Always Play Notification Sound" no longer has a toggle
|
||||
A separate **Always Play Notification Sound** setting used to sit under **Settings > Interface**. Its control is gone, but the setting is still honoured: if you had it switched on, sounds keep playing always rather than only when you are away, and there is currently no way to switch it back off from the interface.
|
||||
:::
|
||||
|
||||
## Enabling Notifications
|
||||
|
||||
| Requirement | Where |
|
||||
|---|---|
|
||||
| [`ENABLE_USER_WEBHOOKS`](/reference/env-configuration#enable_user_webhooks) enabled (default: off) | **Settings > Admin > System > General**, the **User Webhooks** toggle |
|
||||
| The `features.webhooks` permission ([`USER_PERMISSIONS_FEATURES_USER_WEBHOOKS`](/reference/env-configuration#user_permissions_features_user_webhooks), default: off) | **Admin Panel > Users > Groups > Permissions** |
|
||||
|
||||
Admins always hold the permission. While the feature is off, the endpoints report the feature as absent rather than forbidden, so it stays hidden rather than looking blocked.
|
||||
|
||||
## Targets
|
||||
|
||||
A target is a webhook URL plus the events it should receive. Set them up in **Settings > Notifications**. You can have several, for example a work Slack for channel messages and a personal endpoint for finished chats, and one is marked the default.
|
||||
|
||||
Each target has:
|
||||
|
||||
- **A URL**, validated when saved. It is **masked when read back**, showing only the scheme, host and the last few characters, so a stored webhook secret is not handed out again by the API or shown in full in the interface. Saving a masked URL unchanged keeps the stored one.
|
||||
- **Events** it subscribes to.
|
||||
- **Enabled**, to pause a target without deleting it.
|
||||
- **Automatic Delivery**, either `away` or `always`.
|
||||
|
||||
Use **Send Test** to fire a test notification and confirm the endpoint works.
|
||||
|
||||
### Events
|
||||
|
||||
Four events can be subscribed to:
|
||||
|
||||
| Event | Fires when |
|
||||
|---|---|
|
||||
| `chat.finished` | A chat response finishes generating. |
|
||||
| `chat.failed` | A chat response fails. |
|
||||
| `channel.message` | A message arrives in a channel you receive notifications for. |
|
||||
| `calendar.alert` | A calendar event alert triggers. |
|
||||
|
||||
### Delivery: away or always
|
||||
|
||||
- **`away`** (the default) only sends when you are **not currently active**, so you are not pinged about things you are already watching. You count as active if you have used Open WebUI in roughly the last three minutes.
|
||||
- **`always`** sends regardless.
|
||||
|
||||
`channel.message` is the exception: it does not check activity and is delivered either way, since a message from someone else is worth having even while you are online.
|
||||
|
||||
## The `notify` Tool
|
||||
|
||||
When the **Notifications** builtin tools category is enabled on a model, the model can send you a notification itself by calling `notify`, with a message, an optional title, and an optional target id. Leaving the target empty uses your default target.
|
||||
|
||||
This is deliberately separate from event subscriptions:
|
||||
|
||||
:::info `notify` ignores events and delivery mode
|
||||
A notification the model sends goes to an enabled target whether or not that target subscribes to any event, and whether or not you are currently active. Event subscriptions and `away` delivery only govern **automatic** notifications. If you do not want the model notifying you, disable the target or turn off the **Notifications** category for the model.
|
||||
:::
|
||||
|
||||
Pairing this with [Timers](/features/chat-conversations/chat-features/timers) is the usual way to be told about something later: the timer fires a prompt back into the chat, and the model calls `notify` when it has an answer.
|
||||
|
||||
## Upgrading From the Old Notification Webhook
|
||||
|
||||
Earlier versions had a single **Notification Webhook** URL under **Settings > Account** that fired on chat responses. That field is replaced by targets, and an existing URL is **migrated automatically** into a target subscribed to all four events, so notifications keep arriving without any action.
|
||||
|
||||
Two changes are worth knowing about:
|
||||
|
||||
- Channel and calendar notifications are no longer sent straight from those features. They now flow through the notification system, so a target's event subscriptions and delivery mode decide whether they reach you.
|
||||
- Notification settings now live in **Settings > Notifications** rather than **Settings > Account**.
|
||||
|
||||
## Managing Notifications from Chat
|
||||
|
||||
### Available tools
|
||||
|
||||
| Tool | Purpose |
|
||||
|---|---|
|
||||
| `notify` | Send a notification to one of your configured targets. |
|
||||
|
||||
### Requirements
|
||||
|
||||
- [`ENABLE_USER_WEBHOOKS`](/reference/env-configuration#enable_user_webhooks) enabled.
|
||||
- The `features.webhooks` permission (admins always pass).
|
||||
- The **Notifications** builtin tools category enabled on the model.
|
||||
- Native function calling, in a chat started from the interface.
|
||||
- At least one enabled target.
|
||||
@@ -0,0 +1,94 @@
|
||||
---
|
||||
sidebar_position: 13
|
||||
title: "Sub-agents"
|
||||
---
|
||||
|
||||
# Sub-agents
|
||||
|
||||
Sub-agents let a model hand a focused piece of work to a second agent that runs in parallel, then use the result to continue. The model decides when to delegate by calling the `delegate_task` builtin tool; you do not drive it manually.
|
||||
|
||||
A sub-agent is a full chat completion of its own. It runs with the same model, tools, skills and filters as the chat that spawned it, works through the task on its own, and hands back its final answer as the tool result. The work happens in a separate chat that is kept out of your chat list, so the parent conversation stays readable.
|
||||
|
||||
Sub-agents are disabled by default. An administrator enables them with the [`ENABLE_SUBAGENTS`](/reference/env-configuration#enable_subagents) environment variable or the **Settings > Admin > AI > Sub-agents** toggle. They are off by default because every delegation is an extra model call, and a single reply can start several at once.
|
||||
|
||||
## Why Delegate
|
||||
|
||||
Delegation buys focus and parallelism:
|
||||
|
||||
- **A clean context per task.** The sub-agent gets the task and only the context handed to it, instead of the whole conversation, so a long chat does not dilute the work.
|
||||
- **Real parallelism.** When a model requests several delegations in one reply, they run at the same time rather than one after another.
|
||||
- **A short answer back.** Only the sub-agent's final result returns to the parent chat. The intermediate tool calls, searches and dead ends stay in the sub-agent's own chat.
|
||||
|
||||
Typical uses are researching several questions at once, working through a task that needs many tool calls, and doing a self-contained job whose intermediate steps do not belong in the main thread.
|
||||
|
||||
## Foreground and Background
|
||||
|
||||
**Foreground** is the default. The parent chat waits for the sub-agent and receives its answer as the tool result, the same as any other tool call.
|
||||
|
||||
**Background** must be enabled separately with [`SUBAGENTS_BACKGROUND_ENABLED`](/reference/env-configuration#subagents_background_enabled). The model gets an immediate handle instead of an answer and carries on. When the sub-agent finishes, its result is posted back into the parent chat and **the chat continues on its own, without you sending anything**. The result appears as a collapsible "Background sub-agent finished" row. If the parent chat is busy at that moment, the result waits and is delivered when the chat is free.
|
||||
|
||||
While background is disabled, the `background` option is stripped from the tool definition entirely, so the model cannot ask for it.
|
||||
|
||||
## Enable Sub-agents
|
||||
|
||||
Sub-agents need three things to line up:
|
||||
|
||||
1. **Globally enabled**: [`ENABLE_SUBAGENTS`](/reference/env-configuration#enable_subagents), or **Settings > Admin > AI > Sub-agents**.
|
||||
2. **Enabled for the model**: the **Sub-agents** category under **Builtin Tools** in **Workspace > Models > Edit**, on by default once the feature is on.
|
||||
3. **Native function calling in the UI**: builtin tools are only injected for chats started in the interface, and only in Native mode. Legacy function calling and direct API callers never receive `delegate_task`.
|
||||
|
||||
There is no per-user permission for sub-agents. Once enabled for a model, anyone who can use that model can trigger delegation through it.
|
||||
|
||||
## Admin Limits
|
||||
|
||||
Configure these in **Settings > Admin > AI > Sub-agents**, or with the matching environment variables:
|
||||
|
||||
| Setting | Variable | Default | Purpose |
|
||||
|---|---|---|---|
|
||||
| Max concurrent | [`SUBAGENTS_MAX_CONCURRENT`](/reference/env-configuration#subagents_max_concurrent) | `20` | Foreground sub-agents at once. Extra ones wait for a slot. `-1` is unlimited. |
|
||||
| Max background | [`SUBAGENTS_MAX_ASYNC`](/reference/env-configuration#subagents_max_async) | `20` | Background sub-agents at once. Extra ones are refused immediately. `-1` is unlimited. |
|
||||
| Max iterations | [`SUBAGENTS_MAX_ITERATIONS`](/reference/env-configuration#subagents_max_iterations) | `30` | Tool-call loops one sub-agent may run before it is stopped. |
|
||||
| Max output | [`SUBAGENTS_MAX_OUTPUT`](/reference/env-configuration#subagents_max_output) | `30000` | Characters returned to the parent. Longer results are truncated. |
|
||||
| System prompt | [`SUBAGENTS_SYSTEM_PROMPT`](/reference/env-configuration#subagents_system_prompt) | Built-in | Added on top of the model's own system prompt. |
|
||||
|
||||
Three limits are worth understanding before changing them:
|
||||
|
||||
- **They count per worker process, not per deployment.** With multiple workers or replicas, the real ceiling is the limit multiplied by the number of processes.
|
||||
- **Max concurrent only takes effect at startup.** It is read when the first delegation runs and is not re-read afterwards, so changing it needs a restart. Max background applies immediately.
|
||||
- **`0` is not a way to switch delegation off.** Setting either concurrency limit to `0` falls back to the default of 20 rather than blocking anything. Use `-1` for unlimited, a positive number for a real limit, and [`ENABLE_SUBAGENTS`](/reference/env-configuration#enable_subagents) to turn the feature off.
|
||||
|
||||
## What a Sub-agent Cannot Do
|
||||
|
||||
Sub-agents are deliberately narrower than the chat that starts them:
|
||||
|
||||
- **No recursion.** A sub-agent cannot delegate again, so delegation cannot fan out without bound.
|
||||
- **No memory writes.** It can read memories but cannot add, change or delete them, keeping delegated work from quietly rewriting your personalization.
|
||||
- **No direct connections.** Models served through a direct connection cannot delegate.
|
||||
- **No code interpreter in the background**, unless the engine is Jupyter, since the browser-based Pyodide engine needs a live session.
|
||||
- **No external tool servers in the background.** A foreground sub-agent inherits the chat's OpenAPI and MCP tool servers; a background one does not. If a delegated task depends on an external tool server, keep it in the foreground.
|
||||
|
||||
## Cost
|
||||
|
||||
Every delegation is another full chat completion, with the same model and tools, and may loop up to the iteration limit. One reply can start several at once, and each background result restarts the parent chat to process it, which is another turn.
|
||||
|
||||
The defaults are permissive: 20 concurrent sub-agents, each allowed 30 tool-call loops. On a metered API, raise the limits deliberately rather than by habit.
|
||||
|
||||
## Managing Sub-agents from Chat
|
||||
|
||||
### Available tools
|
||||
|
||||
| Tool | Purpose |
|
||||
|---|---|
|
||||
| `delegate_task` | Delegate a task to a parallel sub-agent and return its result. |
|
||||
|
||||
`delegate_task` takes the `task` to perform, optional `context` to carry across (decisions, file paths, findings), and `background` when background sub-agents are enabled.
|
||||
|
||||
### Requirements
|
||||
|
||||
- [`ENABLE_SUBAGENTS`](/reference/env-configuration#enable_subagents) enabled.
|
||||
- The **Sub-agents** builtin tools category enabled on the model.
|
||||
- Native function calling, in a chat started from the interface.
|
||||
|
||||
:::info The Sub-agents category also controls timers
|
||||
The `timer` tool is injected by the same category and the same [`ENABLE_SUBAGENTS`](/reference/env-configuration#enable_subagents) toggle. Turning sub-agents off also removes timers.
|
||||
:::
|
||||
@@ -0,0 +1,77 @@
|
||||
---
|
||||
sidebar_position: 14
|
||||
title: "Timers"
|
||||
---
|
||||
|
||||
# Timers
|
||||
|
||||
Timers let a model come back to you later. The model calls the `timer` builtin tool with a prompt and a time, and when that time arrives the prompt is sent back into the same chat and answered, as if you had typed it yourself.
|
||||
|
||||
They are useful for anything with a natural wait in it: checking on a long-running job in ten minutes, following up on a decision tomorrow, or reminding you about something the conversation already has the context for. Because the timer replays into the original chat, the model still has the whole conversation to work from.
|
||||
|
||||
Timers are **one-shot**. For anything recurring, use [Automations](/features/chat-conversations/chat-features/automations), which are built for schedules.
|
||||
|
||||
## Enabling Timers
|
||||
|
||||
Timers have **no toggle of their own**. They are part of the **Sub-agents** feature and are enabled by [`ENABLE_SUBAGENTS`](/reference/env-configuration#enable_subagents), which is off by default.
|
||||
|
||||
:::warning Timers are enabled by the Sub-agents setting
|
||||
The `timer` tool is injected alongside `delegate_task` and shares its gate: [`ENABLE_SUBAGENTS`](/reference/env-configuration#enable_subagents) plus the per-model **Sub-agents** builtin tools category. There is no separate Timers category or permission, so **turning Sub-agents off also removes timers**, and turning timers on means turning Sub-agents on.
|
||||
:::
|
||||
|
||||
As with other builtin tools, they also require native function calling in a chat started from the interface, and they are unavailable for direct connections and inside sub-agent chats.
|
||||
|
||||
## Setting a Timer
|
||||
|
||||
The model sets a timer with a prompt, a time, and optionally the events that should cancel it. Times are given either as a **relative offset** or as an **RFC 3339 timestamp that must include an explicit timezone**. A timestamp without a timezone is rejected rather than guessed at, and the time must be in the future.
|
||||
|
||||
Relative offsets are forgiving about phrasing: `10s`, `5m`, `1h`, `2d` all work, as do `+10s`, `in 10 seconds`, `5 minutes` and `2 hours`. Units are seconds, minutes, hours and days.
|
||||
|
||||
Timers fire close to their stated time: the scheduler checks every second. [`TIMER_POLL_INTERVAL`](/reference/env-configuration#timer_poll_interval) can raise that interval, trading punctuality for less idle polling, but it cannot go below one second.
|
||||
|
||||
## What Happens When a Timer Fires
|
||||
|
||||
The prompt is appended to the original chat as a message, the chat reloads on its own, and the model answers using the model, workspace tools, skills, filters and settings the chat had when the timer was set. That configuration is captured up front, so later changes to the chat do not alter what a pending timer does.
|
||||
|
||||
One gap to know about: **external tool servers (OpenAPI and MCP) are not carried across**. They are not part of what a timer captures, so a fired timer runs without them even if the chat had them attached. Keep that in mind for a prompt whose whole job depends on an external tool server.
|
||||
|
||||
A timer never interrupts you: if the chat is busy generating when the timer comes due, it waits and fires once the chat is free.
|
||||
|
||||
Firing a timer does **not** notify you by itself. It produces a reply in the chat. To be told about it elsewhere, pair timers with [Notifications](/features/chat-conversations/chat-features/notifications), so the timer's prompt leads the model to call `notify`.
|
||||
|
||||
## Cancelling a Timer
|
||||
|
||||
A timer can carry `cancel_on` events, and is cancelled if one happens first:
|
||||
|
||||
| Event | Meaning |
|
||||
|---|---|
|
||||
| `chat.read` | You open and read the chat. |
|
||||
| `chat.user_message` | You send a message in the chat yourself. |
|
||||
|
||||
This is what makes "remind me in an hour unless I get to it" work: if you come back on your own, the reminder never arrives.
|
||||
|
||||
:::info There is no UI for pending timers
|
||||
Timers cannot be listed, inspected or cancelled from the interface. A timer without `cancel_on` events will fire. The only visible trace is the collapsible **Timer** row that appears in the chat when it goes off.
|
||||
:::
|
||||
|
||||
## Operator Notes
|
||||
|
||||
- **Timers survive restarts.** They are stored in the database, not in memory, and the scheduler resumes on boot. A timer whose time passed while the server was down fires shortly after startup rather than being skipped, so it arrives late rather than never.
|
||||
- **Pending timers still fire if Sub-agents is later disabled.** The setting gates *creating* timers, not the scheduler. Turning it off stops new timers, it does not cancel ones already set.
|
||||
- **The scheduler claims up to 10 due timers per poll.** This is a batching limit rather than a per-user cap, so a backlog drains a few at a time.
|
||||
- **There is no limit on how many timers a user can set**, how far ahead, or how close together. Automations have [`AUTOMATION_MAX_COUNT`](/reference/env-configuration#automation_max_count) and [`AUTOMATION_MIN_INTERVAL`](/reference/env-configuration#automation_min_interval); timers have no equivalent.
|
||||
- **Each fired timer costs a model call**, since it produces a real reply in the chat.
|
||||
|
||||
## Managing Timers from Chat
|
||||
|
||||
### Available tools
|
||||
|
||||
| Tool | Purpose |
|
||||
|---|---|
|
||||
| `timer` | Set a one-shot timer that sends a prompt back into this chat when it fires. |
|
||||
|
||||
### Requirements
|
||||
|
||||
- [`ENABLE_SUBAGENTS`](/reference/env-configuration#enable_subagents) enabled.
|
||||
- The **Sub-agents** builtin tools category enabled on the model.
|
||||
- Native function calling, in a chat started from the interface.
|
||||
@@ -9,12 +9,13 @@ Open WebUI allows you to archive conversations to declutter your sidebar while p
|
||||
|
||||
1. Click on your **profile name** or avatar in the bottom-left corner of the sidebar.
|
||||
2. Select **Settings** from the menu.
|
||||
3. Navigate to the **Data Controls** tab.
|
||||
4. Locate the **Archived Chats** row and click the **Manage** button.
|
||||
3. Open the **Archived Chats** tab, under **Data**.
|
||||
|
||||
Archived chats used to sit behind a **Manage** button on the **Data Controls** tab. They now have a tab of their own in the same **Data** group.
|
||||
|
||||
## Dashboard Features
|
||||
|
||||
The **Archived Chats** modal provides tools to manage your archived conversations:
|
||||
The **Archived Chats** view provides tools to manage your archived conversations:
|
||||
|
||||
- **Search**: Quickly find archived chats by title using the search bar.
|
||||
- **Restore**: Bring an archived chat back to your main sidebar.
|
||||
|
||||
@@ -36,7 +36,7 @@ With **Direct Connections**, the browser communicates directly with the API prov
|
||||
## Prerequisites
|
||||
|
||||
1. **Admin Enablement**: The administrator must enable this feature globally.
|
||||
* **Admin Panel > Settings > Connections > Direct Connections**: Toggle **On**.
|
||||
* **Settings > Admin > AI > Connections > Direct Connections**: Toggle **On**.
|
||||
* Alternatively, set the environment variable: `ENABLE_DIRECT_CONNECTIONS=true`.
|
||||
2. **CORS Configuration**: Since the browser is making the request, the API provider must have **Cross-Origin Resource Sharing (CORS)** configured to allow requests from your Open WebUI domain.
|
||||
* *Note: Many strict providers (like official OpenAI) might block direct browser requests due to CORS policies. This feature is often best used with flexible providers or internal API gateways.*
|
||||
|
||||
@@ -42,9 +42,9 @@ Once you have ComfyUI installed and running, you can connect it to Open WebUI fr
|
||||
|
||||
This feature uses a language model to automatically generate more detailed and creative prompts based on your initial input, which can lead to better image results.
|
||||
|
||||
The **Image Prompt Generation** toggle is located in **Admin Panel > Settings > Images** under the "Image Generation" section, **before** selecting the image generation engine.
|
||||
The **Image Prompt Generation** toggle is located in **Settings > Admin > Experience > Images** under the "Image Generation" section, **before** selecting the image generation engine.
|
||||
|
||||
To customize the prompt template used for generation, go to **Admin Panel > Settings > Interface > Tasks**.
|
||||
To customize the prompt template used for generation, go to **Settings > Admin > Experience > Interface > Tasks**.
|
||||
|
||||

|
||||
|
||||
|
||||
@@ -19,7 +19,7 @@ If your model is configured with **Native Function Calling** (see the [**Central
|
||||
|
||||
### How it works:
|
||||
- **Requirements**:
|
||||
- **Image Generation** must be enabled globally in **Admin Panel → Settings → Images**
|
||||
- **Image Generation** must be enabled globally in **Settings → Admin → Experience → Images**
|
||||
- The model must have the **Image Generation** capability enabled
|
||||
- **No Chat Toggle Needed**: With Native Mode, the `generate_image` tool is automatically included when the model has the `image_generation` capability. You don't need to manually toggle it on per chat.
|
||||
- **Natural Language**: You can simply ask the model: *"Generate an image of a cybernetic forest."*
|
||||
|
||||
@@ -73,7 +73,7 @@ These are set automatically by the memory tools; you do not need to assign them
|
||||
## Enabling Memory Tools
|
||||
|
||||
1. **Administrative Enablement**: Ensure the Memory feature is [enabled globally](#administrative-controls) by an administrator and that you have the required permissions.
|
||||
2. **Native Mode (Agentic Mode)**: Enable **Native Function Calling** in the model's advanced parameters (**Admin Panel > Settings > Models > Model Specific Settings > Advanced Parameters**).
|
||||
2. **Native Mode (Agentic Mode)**: Enable **Native Function Calling** in the model's advanced parameters (**Settings > Admin > AI > Models > Model Specific Settings > Advanced Parameters**).
|
||||
3. **Quality Models Required**: To unlock these features effectively, use frontier models with strong reasoning capabilities (e.g., GPT-5, Claude 4.5 Sonnet, Gemini 3 Flash, MiniMax M2.5) for the best experience. Small local models may not effectively manage memories autonomously.
|
||||
4. **Per-Model Category Toggle**: Ensure the **Memory** category is enabled for the model in **Workspace > Models > Edit > Builtin Tools** (enabled by default).
|
||||
|
||||
@@ -87,7 +87,7 @@ Administrators have full control over the Memory feature, including the ability
|
||||
|
||||
### Global Toggle
|
||||
The Memory feature can be toggled on or off for the entire instance. When disabled, the "Personalization" tab is hidden from all users, and the memory-related API endpoints are blocked.
|
||||
- **Admin UI**: Admin Panel > Settings > General > Features > **Memories**
|
||||
- **Admin UI**: Settings > Admin > System > General > Features > **Memories**
|
||||
- **Environment Variable**: [`ENABLE_MEMORIES`](/reference/env-configuration#enable_memories) (Default: `True`)
|
||||
|
||||
### Granular Permissions
|
||||
@@ -102,7 +102,7 @@ Administrators can also control Memory access on a per-role or per-group basis f
|
||||
|
||||
### Memory System Context
|
||||
By default Open WebUI injects the user's stored memories into the model's system context so the model is aware of them on every turn. This injection can be turned off independently of the memory tools: when disabled, the model can still add, update and delete memories on request, but remembered information is no longer added to the prompt automatically.
|
||||
- **Admin UI**: Admin Panel > Settings > General > **Memory System Context** (shown when Memories is enabled)
|
||||
- **Admin UI**: Settings > Admin > System > General > **Memory System Context** (shown when Memories is enabled)
|
||||
- **Environment Variable**: [`ENABLE_MEMORY_SYSTEM_CONTEXT`](/reference/env-configuration#enable_memory_system_context) (Default: `True`)
|
||||
|
||||
## Privacy & Security
|
||||
|
||||
@@ -43,7 +43,7 @@ This documentation provides a step-by-step guide to integrating Mistral OCR with
|
||||
|
||||
### Optional: Send PDFs as Base64
|
||||
|
||||
By default, Open WebUI uploads a PDF to Mistral's file store and then runs OCR on it. Enabling **Use Base64** in **Admin Panel → Settings → Documents** (or [`MISTRAL_OCR_USE_BASE64=true`](/reference/env-configuration#mistral_ocr_use_base64)) instead sends the PDF **inline as a base64 data URL** in a single request, skipping the separate upload step. This helps in proxy or air-gapped setups, or when the upload step fails; the trade-off is a larger single request.
|
||||
By default, Open WebUI uploads a PDF to Mistral's file store and then runs OCR on it. Enabling **Use Base64** in **Settings → Admin → Tools → Documents** (or [`MISTRAL_OCR_USE_BASE64=true`](/reference/env-configuration#mistral_ocr_use_base64)) instead sends the PDF **inline as a base64 data URL** in a single request, skipping the separate upload step. This helps in proxy or air-gapped setups, or when the upload step fails; the trade-off is a larger single request.
|
||||
|
||||
## Verifying Mistral OCR
|
||||
|
||||
|
||||
@@ -109,7 +109,7 @@ When enabled, documents are first split by markdown headers (H1-H6). This preser
|
||||
|
||||
:::tip
|
||||
|
||||
Use the **Chunk Min Size Target** setting (found in **Admin Panel > Settings > Documents**) to intelligently merge small sections after markdown splitting, improving retrieval coherence and reducing the total number of vectors in your database.
|
||||
Use the **Chunk Min Size Target** setting (found in **Settings > Admin > Tools > Documents**) to intelligently merge small sections after markdown splitting, improving retrieval coherence and reducing the total number of vectors in your database.
|
||||
|
||||
:::
|
||||
|
||||
|
||||
@@ -29,8 +29,8 @@ For comprehensive information about all built-in agentic tools (including web se
|
||||
|
||||
To unlock these features, your model must support native tool calling and have strong reasoning capabilities (e.g., GPT-5, Claude 4.5 Sonnet, Gemini 3 Flash, MiniMax M2.5). Administrator-level configuration for these built-in system tools is handled via the [**Central Tool Calling Guide**](/features/extensibility/plugin/tools#tool-calling-modes-default-vs-native).
|
||||
|
||||
1. **Enable Web Search Globally**: Ensure a search engine is configured in **Admin Panel → Settings → Web Search**.
|
||||
2. **Enable Model Capability**: In **Admin Panel → Settings → Models**, select your model and enable the **Web Search** capability.
|
||||
1. **Enable Web Search Globally**: Ensure a search engine is configured in **Settings → Admin → Tools → Web Search**.
|
||||
2. **Enable Model Capability**: In **Settings → Admin → AI → Models**, select your model and enable the **Web Search** capability.
|
||||
3. **Enable Default Feature**: In the same model settings, under **Default Features**, check **Web Search**. This controls whether the `search_web` and `fetch_url` tools are available by default in new chat sessions.
|
||||
4. **Confirm Native Mode (Agentic Mode)**:
|
||||
* Native is the default tool-calling mode as of v0.10.0, so this is already active unless the model was switched to Legacy. In the same model settings, under **Advanced Parameters**, make sure **Function Calling** is set to `Native` (not `Legacy`).
|
||||
|
||||
@@ -22,7 +22,7 @@ import DocCardList from '@theme/DocCardList';
|
||||
Let Open WebUI search the live web and fetch pages, then ground its answers in what it finds. Choose a provider, toggle search on per chat, and have the model cite or save what it retrieves.
|
||||
|
||||
:::tip Require confirmation before searching
|
||||
Admins can require users to **confirm before a web search runs**, so a query is never sent to an external provider unintentionally. Enable it in **Admin Panel → Settings → Web Search** (or via [`ENABLE_WEB_SEARCH_CONFIRMATION`](/reference/env-configuration#enable_web_search_confirmation)); the prompt text is set by [`WEB_SEARCH_CONFIRMATION_CONTENT`](/reference/env-configuration#web_search_confirmation_content).
|
||||
Admins can require users to **confirm before a web search runs**, so a query is never sent to an external provider unintentionally. Enable it in **Settings → Admin → Tools → Web Search** (or via [`ENABLE_WEB_SEARCH_CONFIRMATION`](/reference/env-configuration#enable_web_search_confirmation)); the prompt text is set by [`WEB_SEARCH_CONFIRMATION_CONTENT`](/reference/env-configuration#web_search_confirmation_content).
|
||||
:::
|
||||
|
||||
<DocCardList />
|
||||
|
||||
@@ -54,7 +54,7 @@ Brave's free tier API enforces a strict limit of **1 request per second**. If yo
|
||||
|
||||
**Recommended configuration for free tier users:**
|
||||
|
||||
- Set "Concurrent Requests" in Admin Panel > Settings > Web Search to `1`. Alternatively use environment variables:
|
||||
- Set "Concurrent Requests" in Settings > Admin > Tools > Web Search to `1`. Alternatively use environment variables:
|
||||
- Set `WEB_SEARCH_CONCURRENT_REQUESTS: 1` to ensure requests are processed sequentially rather than in parallel.
|
||||
|
||||
**Automatic retry behavior:**
|
||||
|
||||
@@ -36,7 +36,7 @@ Having issues with web search? Check out the [Web Search Troubleshooting Guide](
|
||||
1. Get an API key:
|
||||
- **Hosted**: sign up at [firecrawl.dev](https://firecrawl.dev) and copy the key from your dashboard.
|
||||
- **Self-hosted**: use the key from your own Firecrawl instance.
|
||||
2. In Open WebUI, open **Admin Panel > Settings > Web Search**.
|
||||
2. In Open WebUI, open **Settings > Admin > Tools > Web Search**.
|
||||
3. Toggle **Enable Web Search** on.
|
||||
4. Select **Firecrawl** from the **Web Search Engine** dropdown (engine value `firecrawl`).
|
||||
5. Paste your key into the **Firecrawl API Key** field.
|
||||
|
||||
@@ -47,7 +47,7 @@ Ensure you have:
|
||||
### 2. Configure Open WebUI
|
||||
|
||||
1. Log in to Open WebUI with an admin account.
|
||||
2. Open **Admin Panel → Settings → Web Search**.
|
||||
2. Open **Settings → Admin → Tools → Web Search**.
|
||||
3. Enable **Web Search** by toggling it **On**.
|
||||
4. Select **linkup** from the **Web Search Engine** dropdown.
|
||||
5. Paste your Linkup API key into the **Linkup API Key** field.
|
||||
|
||||
@@ -40,7 +40,7 @@ Obtain an API key for the Microsoft Web IQ API from your Microsoft API provider
|
||||
### 2. Configure Open WebUI
|
||||
|
||||
1. Log in to Open WebUI with an admin account.
|
||||
2. Open **Admin Panel → Settings → Web Search**.
|
||||
2. Open **Settings → Admin → Tools → Web Search**.
|
||||
3. Enable **Web Search** by toggling it **On**.
|
||||
4. Select **microsoft_web_iq** from the **Web Search Engine** dropdown.
|
||||
5. Paste your API key into the **Microsoft Web IQ API Key** field.
|
||||
|
||||
@@ -41,7 +41,7 @@ Having issues with web search? Check out the [Web Search Troubleshooting Guide](
|
||||
### 2. Configure Open WebUI
|
||||
|
||||
1. Log in to Open WebUI with an admin account.
|
||||
2. Open **Admin Panel → Settings → Web Search**.
|
||||
2. Open **Settings → Admin → Tools → Web Search**.
|
||||
3. Enable **Web Search** by toggling it **On**.
|
||||
4. Select **serphouse** from the **Web Search Engine** dropdown.
|
||||
5. Paste your SERPHouse API key into the **SERPHouse API Key** field.
|
||||
|
||||
@@ -68,7 +68,7 @@ For a streamlined setup using Docker:
|
||||
|
||||
2. **Connect to Open WebUI:**
|
||||
|
||||
- Navigate to the **Admin Panel > Settings > Connections** section in Open WebUI.
|
||||
- Navigate to the **Settings > Admin > AI > Connections** section in Open WebUI.
|
||||
- When you're on this page, you can press the `+` button to add another connection.
|
||||
- Set the API URL to `http://localhost:9099` and the API key to `0p3n-w3bu!`.
|
||||
- Once you've added your pipelines connection and verified it, you will see an icon appear within the API Base URL field for the added connection. When hovered over, the icon itself will be labeled `Pipelines`. Your pipelines should now be active.
|
||||
@@ -81,7 +81,7 @@ If your Open WebUI is running in a Docker container, replace `localhost` with `h
|
||||
|
||||
3. **Manage Configurations:**
|
||||
|
||||
- In the admin panel, go to **Admin Panel > Settings > Pipelines** tab.
|
||||
- In the admin panel, go to **Settings > Admin > Tools > Pipelines** tab.
|
||||
- Select your desired pipeline and modify the valve values directly from the WebUI.
|
||||
|
||||
:::tip
|
||||
|
||||
@@ -100,12 +100,14 @@ Open WebUI emits **170+ events** spanning every subsystem. Each name is namespac
|
||||
| **System** | `system.startup.started`, `system.startup.completed`, `system.shutdown.started`, `system.shutdown.completed` |
|
||||
| **Auth** | `auth.signup`, `auth.login`, `auth.logout`, `auth.password_changed`, `auth.api_key.created` |
|
||||
| **Users & groups** | `user.created`, `user.deleted`, `user.role_updated`, `user.permissions_updated`, `group.member_added` |
|
||||
| **Chats & messages** | `chat.created`, `chat.deleted`, `chat.shared`, `chat.archived`, `chat.compacted`, `message.created`, `message.reaction_added` |
|
||||
| **Chats & messages** | `chat.created`, `chat.deleted`, `chat.shared`, `chat.archived`, `chat.compacted`, `chat.finished`, `chat.failed`, `message.created`, `message.reaction_added` |
|
||||
| **Models & prompts** | `model.created`, `model.updated`, `model.access_updated`, `prompt.created` |
|
||||
| **Knowledge & files** | `knowledge.created`, `knowledge.file.added`, `knowledge.reindexed`, `file.uploaded`, `file.deleted` |
|
||||
| **Plugins** | `tool.created`, `function.enabled`, `function.valves_updated`, `tool.valves_updated`, `skill.created` |
|
||||
| **Config** | `config.updated`, `config.models.updated`, `config.connections.updated`, `config.webhook.updated` |
|
||||
| **Other** | `channel.*`, `calendar.*`, `automation.*`, `memory.*`, `note.*`, `image.*`, `audio.*`, `terminal.*`, `feedback.*` |
|
||||
| **Other** | `channel.*`, `calendar.*`, `automation.*`, `memory.*`, `note.*`, `image.*`, `audio.*`, `terminal.*`, `feedback.*`, `notification.*` |
|
||||
|
||||
A subset of these also drive user-facing [Notifications](/features/chat-conversations/chat-features/notifications): `chat.finished`, `chat.failed`, `channel.message` and `calendar.alert` are the four events a user can subscribe a webhook target to.
|
||||
|
||||
The authoritative, complete list is exposed by the backend event catalog and shown in **Admin Settings > Events** when configuring webhooks.
|
||||
|
||||
|
||||
@@ -734,7 +734,7 @@ class Filter:
|
||||
The hashed user UUID is added as a top-level body parameter and forwarded directly to OpenAI's API; no PII is sent, just an opaque hash.
|
||||
|
||||
:::warning Cannot Inject HTTP Headers
|
||||
Filters can only modify the **request body** (`form_data`). Outbound HTTP headers are constructed separately and cannot be influenced from a filter. To add custom headers to API requests, use the **Admin Panel → Settings → Connections → OpenAI API** headers configuration.
|
||||
Filters can only modify the **request body** (`form_data`). Outbound HTTP headers are constructed separately and cannot be influenced from a filter. To add custom headers to API requests, use the **Settings → Admin → AI → Connections → OpenAI API** headers configuration.
|
||||
:::
|
||||
|
||||
#### Injecting OpenAI-Style `tools` From a Filter
|
||||
|
||||
@@ -142,7 +142,7 @@ For the full mode policy, model requirements, and configuration, see the [**Tool
|
||||
|
||||
You can configure the function calling mode in two places:
|
||||
|
||||
1. **Administrator Level**: Go to **Admin Panel > Settings > Models > Model Specific Settings > Advanced Parameters > Function Calling** (set to "Native" or "Legacy").
|
||||
1. **Administrator Level**: Go to **Settings > Admin > AI > Models > Model Specific Settings > Advanced Parameters > Function Calling** (set to "Native" or "Legacy").
|
||||
2. **Per-request basis**: Set `params.function_calling = "native"` or `"legacy"` in Chat Controls > Advanced Params.
|
||||
|
||||
If the model seems to be unable to call the tool, make sure it is enabled (either via the Model page or via the `+` sign next to the chat input field).
|
||||
|
||||
@@ -132,10 +132,10 @@ Why it is legacy:
|
||||
Since v0.10.0 Native is the default, so you never need to "turn Native on". The only tool-calling switch you might need to make is the reverse: forcing **Legacy** back on for models that depended on the old prompt-injection behavior and cannot be moved to a stronger Native-capable model. Set **Function Calling** to `Legacy` at whichever scope you need (mirrors the Native controls [below](#how-to-enable-native-mode-agentic-mode)):
|
||||
|
||||
1. **Every model at once (global default, fastest)**:
|
||||
* Navigate to **Admin Panel → Settings → Models**.
|
||||
* Navigate to **Settings → Admin → AI → Models**.
|
||||
* Click the **Settings** button at the **top right** of the models list to open **global model parameters** (they apply to *every* model, current and future, unless a specific model overrides them).
|
||||
* Under **Model Parameters**, set **Function Calling** to `Legacy`, then Save. Every model that has not set its own value now runs Legacy. You do **not** need to edit them one by one.
|
||||
2. **Per-Model Override**: edit a specific model in **Admin Panel → Settings → Models** and set **Function Calling** to `Legacy` under **Model Parameters**. Overrides the global default for that model only.
|
||||
2. **Per-Model Override**: edit a specific model in **Settings → Admin → AI → Models** and set **Function Calling** to `Legacy` under **Model Parameters**. Overrides the global default for that model only.
|
||||
3. **Per-Chat Override**: inside a chat, open **Chat Controls → Advanced Params** and set **Function Calling** to `Legacy` for that chat only.
|
||||
|
||||
:::info Prefer environment variables? Use `DEFAULT_MODEL_PARAMS`
|
||||
@@ -167,12 +167,12 @@ Native Mode (also called **Agentic Mode**) leverages the model's built-in capabi
|
||||
Native Mode is the **default** as of v0.10.0, so new and existing models use it unless they are explicitly set to Legacy. You can still set `Function Calling` explicitly (to pin Native, or to switch a model to Legacy) at these levels:
|
||||
|
||||
1. **Pin Native for Every Model (optional, since Native is already the default)**:
|
||||
* Navigate to **Admin Panel → Settings → Models**.
|
||||
* Navigate to **Settings → Admin → AI → Models**.
|
||||
* Click the **Settings** button at the **top right** of the models list. This opens **global model parameters**, which apply to *every* model in your instance (current and future) unless a specific model overrides them.
|
||||
* Under **Model Parameters**, set **Function Calling** to `Native`.
|
||||
* Save. This only re-asserts the existing default; you would normally leave it unset. Use it if you want the value pinned explicitly rather than relying on the default.
|
||||
2. **Per-Model Override**:
|
||||
* In **Admin Panel → Settings → Models**, pick a specific model and click its edit button.
|
||||
* In **Settings → Admin → AI → Models**, pick a specific model and click its edit button.
|
||||
* Under **Model Parameters**, set **Function Calling** to `Native`. This value overrides the global default for that model only.
|
||||
* Use this when a specific model needs different parameters; otherwise prefer the global setting.
|
||||
3. **Per-Chat Override**:
|
||||
@@ -180,7 +180,7 @@ Native Mode is the **default** as of v0.10.0, so new and existing models use it
|
||||
* Under **Advanced Params**, set **Function Calling** to `Native`. Applies to that chat only.
|
||||
|
||||
:::tip Set any parameter globally, once, for all models
|
||||
The **global model parameters** panel (the **Settings** button at the top right of **Admin Panel → Settings → Models**) lets you configure any model parameter (`function_calling`, temperature, top_p, max_tokens, etc.) **once, for every model in your Open WebUI instance**, current and future, unless a specific model overrides it. For tool calling specifically you rarely need it: Native is already the default. The one tool-calling switch you would set here is `Function Calling = Legacy`, to move a whole instance back to Legacy (see [How to switch all models to Legacy](#enable-legacy-for-all-models)).
|
||||
The **global model parameters** panel (the **Settings** button at the top right of **Settings → Admin → AI → Models**) lets you configure any model parameter (`function_calling`, temperature, top_p, max_tokens, etc.) **once, for every model in your Open WebUI instance**, current and future, unless a specific model overrides it. For tool calling specifically you rarely need it: Native is already the default. The one tool-calling switch you would set here is `Function Calling = Legacy`, to move a whole instance back to Legacy (see [How to switch all models to Legacy](#enable-legacy-for-all-models)).
|
||||
:::
|
||||
|
||||
:::info Prefer environment variables? Use `DEFAULT_MODEL_PARAMS`
|
||||
@@ -280,11 +280,11 @@ Legacy Mode is **not** a supported workaround even for DeepSeek; it is unsupport
|
||||
| `replace_memory_content` | Updates an existing memory record by its unique ID. |
|
||||
| `delete_memory` | Deletes a memory by its ID. |
|
||||
| `list_memories` | Lists all stored memories for the user with content and dates. |
|
||||
| **Notes** | *Requires `ENABLE_NOTES` AND per-model "Notes" category enabled (default: on).* |
|
||||
| **Notes** | *Requires `ENABLE_NOTES` AND per-model "Notes" category enabled (default: on) AND the user's `features.notes` permission. Inside a note-attached chat these three checks are skipped and the note tools are always injected; see the note below.* |
|
||||
| `search_notes` | Search the user's notes by title and content. |
|
||||
| `view_note` | Get the full markdown content of a specific note. |
|
||||
| `write_note` | Create a new private note for the user. |
|
||||
| `replace_note_content` | Update an existing note's content or title. |
|
||||
| `replace_note_content` | Update an existing note, replacing the whole content or applying range edits to part of it. |
|
||||
| **Chat History** | *Requires per-model "Chat History" category enabled (default: on).* |
|
||||
| `search_chats` | Simple text search across chat titles and message content. Returns matching chat IDs and snippets. |
|
||||
| `view_chat` | Reads and returns the full message history of a specific chat by ID. |
|
||||
@@ -312,6 +312,11 @@ Legacy Mode is **not** a supported workaround even for DeepSeek; it is unsupport
|
||||
| **Time Tools** | *Requires per-model "Time & Calculation" category enabled (default: on).* |
|
||||
| `get_current_timestamp` | Get the current UTC Unix timestamp and ISO date. |
|
||||
| `calculate_timestamp` | Calculate relative timestamps (e.g., "3 days ago"). |
|
||||
| **Sub-agents** | *Requires [`ENABLE_SUBAGENTS`](/reference/env-configuration#enable_subagents) enabled (default: off) AND per-model "Sub-agents" category enabled (default: on). Never injected into a sub-agent itself, or for direct connections. This category gates `timer` as well; there is no separate Timers category.* |
|
||||
| `delegate_task` | Delegate a focused task to a parallel sub-agent running the same model and tools, and return its result. See [Sub-agents](/features/chat-conversations/chat-features/subagents). |
|
||||
| `timer` | Set a one-shot timer that sends a prompt back into this chat when it fires, producing a new reply. See [Timers](/features/chat-conversations/chat-features/timers). |
|
||||
| **Notifications** | *Requires [`ENABLE_USER_WEBHOOKS`](/reference/env-configuration#enable_user_webhooks) enabled (default: off) AND the user holding the `features.webhooks` permission (admins always pass) AND per-model "Notifications" category enabled (default: on).* |
|
||||
| `notify` | Send a notification to one of the user's configured webhook targets. See [Notifications](/features/chat-conversations/chat-features/notifications). |
|
||||
|
||||
#### Knowledge Tool Availability (At a Glance)
|
||||
|
||||
@@ -369,7 +374,7 @@ When [`ENABLE_KB_EXEC`](/reference/env-configuration#enable_kb_exec) is set, Ope
|
||||
| `search_notes` | `query` (required), `count` (default: 5), `start_timestamp`, `end_timestamp` | Array of `{id, title, snippet, updated_at}` |
|
||||
| `view_note` | `note_id` (required) | `{id, title, content, updated_at, created_at}` |
|
||||
| `write_note` | `title` (required), `content` (required) | `{status: "success", id}` |
|
||||
| `replace_note_content` | `note_id` (required), `content` (required), `title` (optional) | `{status: "success", id, title}` |
|
||||
| `replace_note_content` | `note_id` (required), `content` (optional; the new markdown for a whole-note update), `operations` (optional; range edits, each `{"action": "replace", "content": ...}` or `{"action": "replace_range", "start", "end", "content", "expected"}`), `title` (optional) | `{status: "success", id, title, updated_at, applied_operation_count}`. Errors carry a machine-readable `code` (`not_found`, `write_access_denied`, `invalid_range`, `range_out_of_bounds`, `expected_mismatch`, `overlapping_operations`, `content_required`, …) |
|
||||
| **Chat History** | | |
|
||||
| `search_chats` | `query` (required), `count` (default: 5), `start_timestamp`, `end_timestamp` | Array of `{id, title, snippet, updated_at}` |
|
||||
| `view_chat` | `chat_id` (required) | `{id, title, messages: [{role, content}]}` |
|
||||
@@ -397,6 +402,25 @@ When [`ENABLE_KB_EXEC`](/reference/env-configuration#enable_kb_exec) is set, Ope
|
||||
| **Time Tools** | | |
|
||||
| `get_current_timestamp` | None | `{current_timestamp, current_iso}` |
|
||||
| `calculate_timestamp` | `days_ago`, `weeks_ago`, `months_ago`, `years_ago` (all default: 0) | `{current_timestamp, current_iso, calculated_timestamp, calculated_iso}` |
|
||||
| **Sub-agents** | | |
|
||||
| `delegate_task` | `task` (required), `context` (optional; decisions, findings or file paths to carry across), `background` (default: false; the parameter is removed from the schema entirely unless [`SUBAGENTS_BACKGROUND_ENABLED`](/reference/env-configuration#subagents_background_enabled) is on) | Foreground: the sub-agent's final answer as text, truncated at [`SUBAGENTS_MAX_OUTPUT`](/reference/env-configuration#subagents_max_output). Background: a JSON handle `{status: "dispatched", delegation_id, subagent_chat_id, mode, task}`, with the result posted into the parent chat later. Errors are returned as an `Error: ...` string rather than raised |
|
||||
| `timer` | `prompt` (required; sent back into the chat when the timer fires), `at` (required; a relative offset such as `10s`, `5m`, `1h`, `2d`, `+10s` or `in 10 seconds`, or an RFC 3339 timestamp that **must** carry an explicit timezone; must be in the future), `cancel_on` (optional list of `chat.read`, `chat.user_message`) | `{"status": "set", "at": "<RFC 3339 UTC>", "cancel_on": [...]}` as a JSON string. Errors are returned as a plain `Error: ...` string, not JSON |
|
||||
| **Notifications** | | |
|
||||
| `notify` | `message` (required; the notification body), `target` (optional target **id**; empty uses the default target), `title` (optional) | `Notification sent to {target_id}.`, or `Notification failed: {reason}` |
|
||||
|
||||
:::warning Builtin tools behave differently inside a note-attached chat
|
||||
|
||||
The chat opened from a note is an internal chat of type `note`, and builtin tools are gated differently there. Two separate overrides apply:
|
||||
|
||||
**The note tools are always injected.** `search_notes`, `view_note`, `write_note` and `replace_note_content` load regardless of the `notes.enable` config, the model's **Notes** category, and the user's `features.notes` permission. Turning notes off by any of those three controls does not remove them there.
|
||||
|
||||
**The whole builtin-tool surface is force-enabled.** A note chat activates builtin tools even when the request would not normally qualify: without a UI session, with `function_calling` set to legacy, and **even when the model's `builtin_tools` capability is switched off**. So a model an administrator deliberately configured without builtin tools still receives them (memory, web search, code interpreter, image generation and the rest, subject to each category's own gate) inside a note chat. If you rely on that capability toggle to keep tools away from a model, it does not hold in this one context.
|
||||
|
||||
Separately, `view_note` and `replace_note_content` **short-circuit access control for admins**: an admin reads or rewrites any note without the owner or grant check other users are subject to. Consistent with admins being root-equivalent elsewhere, but worth knowing if you relied on the previous behaviour, where admins were checked like everyone else.
|
||||
|
||||
Note attachments are also injected: every non-image file on the note is added as retrieval context on **every** message in that chat.
|
||||
|
||||
:::
|
||||
|
||||
:::info Automatic Timezone Detection
|
||||
Open WebUI automatically detects and stores your timezone when you log in. This allows time-related tools and features to provide accurate local times without any manual configuration. Your timezone is determined from your browser settings.
|
||||
@@ -554,7 +578,7 @@ This means users can disable web search (or image generation, or code interprete
|
||||
:::
|
||||
|
||||
:::tip Full Agentic Experience
|
||||
For the best out-of-the-box agentic experience, administrators can enable **Web Search**, **Image Generation**, and **Code Interpreter** as default features for a model. In the **Admin Panel > Settings > Models**, find the **Model Specific Settings** for your target model and toggle these three on under **Default Features**. This ensures they are active in every new chat by default, so users get the full tool-calling experience without manually enabling each toggle. Users can still turn them off per-chat if needed.
|
||||
For the best out-of-the-box agentic experience, administrators can enable **Web Search**, **Image Generation**, and **Code Interpreter** as default features for a model. In the **Settings > Admin > AI > Models**, find the **Model Specific Settings** for your target model and toggle these three on under **Default Features**. This ensures they are active in every new chat by default, so users get the full tool-calling experience without manually enabling each toggle. Users can still turn them off per-chat if needed.
|
||||
:::
|
||||
|
||||
:::tip Builtin Tools vs File Context
|
||||
|
||||
@@ -164,7 +164,7 @@ Administrators can control sharing via environment variables or the Admin Panel:
|
||||
* `USER_PERMISSIONS_NOTES_ALLOW_SHARING` for internal sharing
|
||||
* `USER_PERMISSIONS_NOTES_ALLOW_PUBLIC_SHARING` for public links
|
||||
|
||||
These can also be configured in **Admin Panel > Settings > Users > Default Permissions**.
|
||||
These can also be configured in **Admin Panel > Users > Groups > Default Permissions**.
|
||||
|
||||
### Quick creation
|
||||
|
||||
|
||||
@@ -56,6 +56,14 @@ Images display inline at a comfortable size.
|
||||
|
||||

|
||||
|
||||
### HTML
|
||||
|
||||
HTML files render in a **sandboxed** iframe. Scripts and downloads work, but the page is given a unique origin of its own, so it cannot read cookies or `localStorage`, and same-origin requests back to Open WebUI fail.
|
||||
|
||||
That isolation is the point: a previewed file is untrusted content, and giving it your origin would let it act as you. A page that needs same-origin behaviour will fail quietly rather than with an error, which is usually the explanation when a preview looks broken but the file is fine.
|
||||
|
||||
If you understand the risk and need it, the per-user **Settings > Interface > iframe Sandbox Allow Same Origin** toggle grants it. It is **off by default** and applies to every embedded iframe, not just this preview. See [Rich UI](/features/extensibility/plugin/development/rich-ui#sandbox-and-security) for the full trade-off.
|
||||
|
||||
---
|
||||
|
||||
## Uploading files
|
||||
|
||||
@@ -154,7 +154,7 @@ To download new base models, go to **Settings > Connections > Ollama** or type `
|
||||
|
||||
## Global Model Defaults (Admin)
|
||||
|
||||
Administrators can set baseline capabilities and parameters that apply to all models via **Admin Panel > Settings > Models > ⚙️ (gear icon)**.
|
||||
Administrators can set baseline capabilities and parameters that apply to all models via **Settings > Admin > AI > Models > ⚙️ (gear icon)**.
|
||||
|
||||
- **Default Model Metadata** (`DEFAULT_MODEL_METADATA`): Baseline capabilities (vision, web search, file context, code interpreter, builtin tools). Per-model overrides always win on conflicts.
|
||||
- **Default Model Params** (`DEFAULT_MODEL_PARAMS`): Baseline inference parameters (temperature, top_p, max_tokens, function_calling). Per-model values take precedence when explicitly set. This value is loaded from the environment as JSON; invalid JSON is ignored and falls back to `{}`.
|
||||
@@ -251,4 +251,4 @@ Model presets configure behavior through system prompts and tool bindings. They
|
||||
|
||||
### Fallback requires configuration
|
||||
|
||||
If a base model becomes unavailable, the preset will fail unless `ENABLE_CUSTOM_MODEL_FALLBACK` is set to `True` and a default model is configured in Admin Panel > Settings > Models.
|
||||
If a base model becomes unavailable, the preset will fail unless `ENABLE_CUSTOM_MODEL_FALLBACK` is set to `True` and a default model is configured in Settings > Admin > AI > Models.
|
||||
|
||||
@@ -617,7 +617,7 @@ If your deployment does not use Tools or Functions at all, remove the surface co
|
||||
ENABLE_PLUGINS=false
|
||||
```
|
||||
|
||||
This is stronger than [Safe Mode](#safe-mode). Safe Mode deactivates all Functions but leaves the feature in place; `ENABLE_PLUGINS=false` hides the workspace **Tools** and admin **Functions** pages, makes their endpoints return empty, and skips every plugin execution path (filters, actions, pipe functions, built-in native tool-calling and code-interpreter detection). OpenAPI and MCP tool servers configured through connections are unaffected. Setting this off removes the arbitrary-code-execution surface these features carry, so use it whenever the feature is not needed.
|
||||
This is stronger than [Safe Mode](#safe-mode). Safe Mode deactivates all Functions but leaves the feature in place; `ENABLE_PLUGINS=false` hides the workspace **Tools** and admin **Functions** pages, makes their listing endpoints return empty, and stops those plugins loading and running, so filters, actions and pipe functions are skipped and user-authored tools are never offered to a model.
|
||||
|
||||
### Code execution
|
||||
|
||||
|
||||
@@ -38,7 +38,7 @@ There are two plugin families: **Tools** and **Functions**.
|
||||
| **Built-in** | System tools that ship with Open WebUI. Enable in the admin panel, no install needed. | Web Search, Code Interpreter, Image Generation, Memory, Notes, Knowledge retrieval |
|
||||
| **Custom** | | |
|
||||
| ↳ Tool | Code you write yourself or install from the [community site](https://openwebui.com/). Manage in **Workspace > Tools**. | Langfuse / OpenLit observability, Home Assistant, arXiv / PubMed lookups, Wolfram Alpha, Jira / Linear, SQL queries |
|
||||
| ↳ Tool server | External services connected via **MCP** or **OpenAPI**. Configure in **Admin Panel > Settings > Tools**. | Your own microservices, third-party APIs, existing MCP servers |
|
||||
| ↳ Tool server | External services connected via **MCP** or **OpenAPI**. Configure in **Settings > Admin > Tools**. | Your own microservices, third-party APIs, existing MCP servers |
|
||||
|
||||
**Functions** run at the platform level and modify how Open WebUI itself behaves. There are three types:
|
||||
|
||||
@@ -95,7 +95,7 @@ Every time Open WebUI needs a short piece of "thinking" for a UI feature (writin
|
||||
|
||||
These run in the background, so they are easy to overlook. A dedicated task model is a small change that makes a noticeable difference.
|
||||
|
||||
**Fix:** In **Admin Panel > Settings > Interface**, set a dedicated Task Model. There are two fields, because the right choice depends on what your main chat model is:
|
||||
**Fix:** In **Settings > Admin > Experience > Interface**, set a dedicated Task Model. There are two fields, because the right choice depends on what your main chat model is:
|
||||
|
||||
:::tip Recommended task models
|
||||
- **Task Model (External)**: Set to a fast, cheap, *non-reasoning* cloud model like `gpt-5-nano`, `gemini-2.5-flash-lite`, or `llama-3.1-8b-instant`.
|
||||
@@ -168,7 +168,7 @@ None of these matter for "a single user with a handful of PDFs." All of them sta
|
||||
|
||||
If you just want RAG to work well out of the box, these settings are a solid general-purpose starting point. They are not fine-tuned for every use case, but they will produce noticeably better results than the defaults for most document types.
|
||||
|
||||
Set these in **Admin Panel > Settings > Documents**:
|
||||
Set these in **Settings > Admin > Tools > Documents**:
|
||||
|
||||
| Setting | Default | Recommended value | Why |
|
||||
|---------|---------|-------------------|-----|
|
||||
@@ -205,7 +205,7 @@ It is a built-in tool, so there is nothing to install. The one decision is **whi
|
||||
- **Self-hosted, no API key.** Run your own search backend and keep every query in-house. [**SearXNG**](/features/chat-conversations/web-search/providers/searxng) is the usual pick.
|
||||
- **Commercial APIs.** [**Tavily**](/features/chat-conversations/web-search/providers/tavily), [**Brave**](/features/chat-conversations/web-search/providers/brave), [**Exa AI**](/features/chat-conversations/web-search/providers/exa), [**Perplexity Search**](/features/chat-conversations/web-search/providers/perplexity_search), [**Firecrawl**](/features/chat-conversations/web-search/providers/firecrawl) and others trade an API key (and usually a bill) for higher-quality, AI-tuned results.
|
||||
|
||||
**Enable it:** go to **Admin Panel > Settings > Web Search**, toggle **Enable Web Search**, then pick your provider and paste its key or config. In any chat, switch web search on for a message with the **+** button in the prompt field.
|
||||
**Enable it:** go to **Settings > Admin > Tools > Web Search**, toggle **Enable Web Search**, then pick your provider and paste its key or config. In any chat, switch web search on for a message with the **+** button in the prompt field.
|
||||
|
||||
:::tip Native function calling does the rest
|
||||
Native is the default tool-calling mode now, so once web search is enabled the model decides on its own when a question needs the live web and runs the search as a tool. You do not have to flip the toggle every time; it is there for when you want to force a fresh lookup.
|
||||
|
||||
@@ -17,7 +17,7 @@ Open WebUI is multi-user from day one. Even if you are the only person using it,
|
||||
|
||||
| | |
|
||||
| :--- | :--- |
|
||||
| **Location** | Profile avatar > **Admin Settings**, or **Admin Panel > Settings** |
|
||||
| **Location** | Profile avatar > **Settings**, then the **Admin** section |
|
||||
| **Access** | Administrators only |
|
||||
| **Scope** | The entire instance and all users |
|
||||
|
||||
|
||||
@@ -49,9 +49,9 @@ Visit [http://localhost:3000](http://localhost:3000).
|
||||
For production environments, pin a specific version instead of using floating tags:
|
||||
|
||||
```bash
|
||||
docker pull ghcr.io/open-webui/open-webui:v0.10.1
|
||||
docker pull ghcr.io/open-webui/open-webui:v0.10.1-cuda
|
||||
docker pull ghcr.io/open-webui/open-webui:v0.10.1-ollama
|
||||
docker pull ghcr.io/open-webui/open-webui:v0.10.3
|
||||
docker pull ghcr.io/open-webui/open-webui:v0.10.3-cuda
|
||||
docker pull ghcr.io/open-webui/open-webui:v0.10.3-ollama
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
@@ -31,9 +31,9 @@ The `:main` tag always points to the **latest build**. It's convenient but can i
|
||||
For stability, pin a specific release tag:
|
||||
|
||||
```
|
||||
ghcr.io/open-webui/open-webui:v0.10.1
|
||||
ghcr.io/open-webui/open-webui:v0.10.1-cuda
|
||||
ghcr.io/open-webui/open-webui:v0.10.1-ollama
|
||||
ghcr.io/open-webui/open-webui:v0.10.3
|
||||
ghcr.io/open-webui/open-webui:v0.10.3-cuda
|
||||
ghcr.io/open-webui/open-webui:v0.10.3-ollama
|
||||
```
|
||||
|
||||
Browse all available tags on the [GitHub releases page](https://github.com/open-webui/open-webui/releases).
|
||||
|
||||
@@ -244,6 +244,35 @@ All models configured in Open WebUI are accessible through this endpoint, includ
|
||||
**Tool Use:** The Anthropic Messages endpoint supports tool use (`tools` and `tool_choice` parameters). Tool calls from the upstream model are translated into Anthropic-format `tool_use` content blocks in both streaming and non-streaming responses.
|
||||
:::
|
||||
|
||||
#### Counting Tokens
|
||||
|
||||
A companion to the Messages API that reports how many input tokens a request would use, without running it. This mirrors Anthropic's own token-counting endpoint, so SDKs that pre-flight a request for budgeting or context-fitting work unchanged.
|
||||
|
||||
- **Endpoints**: `POST /api/v1/messages/count_tokens`, `POST /api/message/count_tokens`
|
||||
- **Authentication**: same as the Messages API
|
||||
- **Returns**: `{"input_tokens": <int>}`
|
||||
|
||||
```bash
|
||||
curl -X POST http://localhost:3000/api/v1/messages/count_tokens \
|
||||
-H "x-api-key: YOUR_API_KEY" \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{
|
||||
"model": "gpt-4o",
|
||||
"messages": [
|
||||
{
|
||||
"role": "user",
|
||||
"content": "Why is the sky blue?"
|
||||
}
|
||||
]
|
||||
}'
|
||||
```
|
||||
|
||||
The count is obtained from the upstream provider behind the resolved connection, so the provider must implement token counting. If it does not, or answers unexpectedly, the request fails with a `502`.
|
||||
|
||||
:::info Reported `input_tokens` are now real
|
||||
The Messages API previously always reported `input_tokens: 0` in the streaming `message_start` block. Input tokens are now counted up front and reported in both streaming and non-streaming responses. If counting fails the request still succeeds, so clients should treat the value as best-effort rather than guaranteed.
|
||||
:::
|
||||
|
||||
### 🔧 Filter and Function Behavior with API Requests
|
||||
|
||||
When using the API endpoints directly, filters (Functions) behave differently than when requests come from the web interface.
|
||||
|
||||
@@ -10,7 +10,7 @@ This tutorial is a community contribution and is not supported by the Open WebUI
|
||||
:::
|
||||
|
||||
> [!WARNING]
|
||||
> This documentation reflects schema changes up to Open WebUI v0.10.0.
|
||||
> This documentation reflects schema changes up to Open WebUI v0.10.3.
|
||||
|
||||
## Open-WebUI Internal SQLite Database
|
||||
|
||||
@@ -246,6 +246,7 @@ The `chat_message` table is the **normalized per-message store** for chat conver
|
||||
| files | JSON | nullable | Attached files |
|
||||
| sources | JSON | nullable | Retrieval/citation sources |
|
||||
| embeds | JSON | nullable | Embedded artifacts |
|
||||
| meta | JSON | nullable | Message metadata; marks internal sub-agent and timer messages (added in v0.10.3) |
|
||||
| done | Boolean | default=True | Whether generation completed |
|
||||
| status_history | JSON | nullable | Streamed status updates during generation |
|
||||
| error | JSON | nullable | Error payload when generation failed |
|
||||
@@ -259,6 +260,7 @@ Things to know about the chat_message table:
|
||||
- Deleting a chat cascades to delete its messages (`chat_id` foreign key with `ON DELETE CASCADE`).
|
||||
- Composite indexes back the common access patterns: (`chat_id`, `parent_id`), (`model_id`, `created_at`), and (`user_id`, `created_at`).
|
||||
- `context_summary` was added in v0.10.0 (migration `4c5ce3d2f27f`) to store a summary of the message's context.
|
||||
- `meta` was added in v0.10.3 (migration `856c5b02fb54`). It carries per-message metadata and is what marks the messages Open WebUI injects on a user's behalf, such as a [sub-agent](/features/chat-conversations/chat-features/subagents) result or a fired [timer](/features/chat-conversations/chat-features/timers), so the interface can render them differently from a message the user typed.
|
||||
|
||||
## Automation Table
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ As new variables are introduced, this page will be updated to reflect the growin
|
||||
|
||||
:::info
|
||||
|
||||
This page is up-to-date with Open WebUI release version [v0.10.0](https://github.com/open-webui/open-webui/releases/tag/v0.10.0), but is still a work in progress to later include more accurate descriptions, listing out options available for environment variables, defaults, and improving descriptions.
|
||||
This page is up-to-date with Open WebUI release version [v0.10.3](https://github.com/open-webui/open-webui/releases/tag/v0.10.3), but is still a work in progress to later include more accurate descriptions, listing out options available for environment variables, defaults, and improving descriptions.
|
||||
|
||||
:::
|
||||
|
||||
@@ -311,7 +311,7 @@ is also being used and set to `True`. **Never disable this if OAUTH/SSO is not b
|
||||
- Type: `int`
|
||||
- Default: `("") empty string`
|
||||
- Description: Sets the maximum number of files processing allowed per folder.
|
||||
- Persistence: This environment variable is a `ConfigVar` variable. It can be configured in the **Admin Panel > Settings > General > Folder Max File Count**. Default is none (empty string) which is unlimited.
|
||||
- Persistence: This environment variable is a `ConfigVar` variable. It can be configured in the **Settings > Admin > System > General > Folder Max File Count**. Default is none (empty string) which is unlimited.
|
||||
|
||||
#### `ENABLE_AUTOMATIONS`
|
||||
|
||||
@@ -352,11 +352,72 @@ is also being used and set to `True`. **Never disable this if OAUTH/SSO is not b
|
||||
|
||||
:::
|
||||
|
||||
#### `ENABLE_SUBAGENTS`
|
||||
|
||||
- Type: `bool`
|
||||
- Default: `False`
|
||||
- Description: Enables **sub-agents**, letting a model delegate a focused task to a parallel sub-agent through the `delegate_task` builtin tool. The sub-agent runs a full chat completion of its own using the same model, tools and skills, and returns its final answer to the parent chat. Off by default because each delegation costs additional model calls. Also gates the `timer` tool, which shares the same **Sub-agents** builtin category. Can be set in **Settings > Admin > AI > Sub-agents**. See [Sub-agents](/features/chat-conversations/chat-features/subagents).
|
||||
- Persistence: This environment variable is a `ConfigVar` variable.
|
||||
|
||||
#### `SUBAGENTS_BACKGROUND_ENABLED`
|
||||
|
||||
- Type: `bool`
|
||||
- Default: `False`
|
||||
- Description: Allows sub-agents to run in the **background**. The model then returns immediately with a dispatch handle instead of waiting, and when the sub-agent finishes, its result is posted back into the parent chat, which continues on its own without the user sending a message. When this is off, the `background` parameter is removed from the tool schema entirely, so the model cannot request it.
|
||||
- Persistence: This environment variable is a `ConfigVar` variable.
|
||||
|
||||
#### `SUBAGENTS_MAX_CONCURRENT`
|
||||
|
||||
- Type: `int`
|
||||
- Default: `20`
|
||||
- Description: Maximum number of foreground sub-agents running at once. Delegations beyond the limit **wait** for a slot rather than failing. Set `-1` for unlimited. Counted **per worker process**, not across a cluster, so the effective ceiling is this value multiplied by the number of workers or replicas.
|
||||
- Persistence: This environment variable is a `ConfigVar` variable.
|
||||
|
||||
:::warning `SUBAGENTS_MAX_CONCURRENT` needs a restart to change
|
||||
|
||||
The foreground limit is applied to a semaphore created on the first delegation and never resized afterwards. Changing it in the Admin Panel or the environment has **no effect until Open WebUI restarts**. `SUBAGENTS_MAX_ASYNC` is not affected and applies immediately.
|
||||
|
||||
:::
|
||||
|
||||
#### `SUBAGENTS_MAX_ASYNC`
|
||||
|
||||
- Type: `int`
|
||||
- Default: `20`
|
||||
- Description: Maximum number of background sub-agents running at once. Unlike the foreground limit, delegations over this cap **fail immediately** with an error telling the model to wait or raise the limit. Set `-1` for unlimited. Also counted per worker process.
|
||||
- Persistence: This environment variable is a `ConfigVar` variable.
|
||||
|
||||
#### `SUBAGENTS_MAX_ITERATIONS`
|
||||
|
||||
- Type: `int`
|
||||
- Default: `30`
|
||||
- Description: Maximum tool-call loops a single sub-agent may run before it is stopped. This overrides the global [`CHAT_RESPONSE_MAX_TOOL_CALL_ITERATIONS`](#chat_response_max_tool_call_iterations) for sub-agents, keeping a delegated task from looping expensively. The sub-agent reports that it hit the limit rather than failing silently.
|
||||
- Persistence: This environment variable is a `ConfigVar` variable.
|
||||
|
||||
#### `SUBAGENTS_MAX_OUTPUT`
|
||||
|
||||
- Type: `int` (characters)
|
||||
- Default: `30000`
|
||||
- Description: Maximum length of the result a sub-agent hands back to the parent chat. Longer output is truncated and marked `[output truncated]`. This caps only what is returned to the parent; the sub-agent's own chat keeps the full text.
|
||||
- Persistence: This environment variable is a `ConfigVar` variable.
|
||||
|
||||
#### `SUBAGENTS_SYSTEM_PROMPT`
|
||||
|
||||
- Type: `str`
|
||||
- Default: Empty string (falls back to the built-in sub-agent prompt)
|
||||
- Description: System prompt given to sub-agents. It is appended to the parent model's system prompt, so the sub-agent keeps the parent's instructions and adds these. Leave empty to use the built-in default.
|
||||
- Persistence: This environment variable is a `ConfigVar` variable.
|
||||
|
||||
#### `SCHEDULER_POLL_INTERVAL`
|
||||
|
||||
- Type: `int` (seconds)
|
||||
- Default: `10`
|
||||
- Description: Sets the interval in seconds between scheduler ticks. The unified scheduler handles both automation execution and calendar event alerts. Accepts `AUTOMATION_POLL_INTERVAL` as a legacy fallback.
|
||||
- Description: Sets the interval in seconds between scheduler ticks for automations and calendar event alerts. Accepts `AUTOMATION_POLL_INTERVAL` as a legacy fallback. The scheduler loop itself now ticks at the faster [`TIMER_POLL_INTERVAL`](#timer_poll_interval) so timers stay punctual, and runs automations and calendar alerts on this slower interval.
|
||||
|
||||
#### `TIMER_POLL_INTERVAL`
|
||||
|
||||
- Type: `int` (seconds)
|
||||
- Default: `1`
|
||||
- Description: How often the scheduler checks for due timers set through the `timer` builtin tool. It is deliberately much shorter than [`SCHEDULER_POLL_INTERVAL`](#scheduler_poll_interval), since a timer is expected to fire close to its stated time, while automations run on a schedule measured in minutes. Raising it reduces idle polling at the cost of timers firing late.
|
||||
|
||||
#### `CALENDAR_ALERT_LOOKAHEAD_MINUTES`
|
||||
|
||||
@@ -424,6 +485,10 @@ Treat anything in this cluster as *what the admin sees and does in the product U
|
||||
- Default: `True`
|
||||
- Description: Controls whether the admin-panel **other-users-chats** access surface is available. When disabled, admins can no longer access other users' chats in the admin panel and the corresponding endpoints reject the request. If you disable this, consider also disabling `ENABLE_ADMIN_EXPORT` (especially on SQLite), since exports include user chats and would re-open the same data on a different surface. Note that admin retains underlying database access regardless; this toggle controls the in-product surface, see the admin-posture-toggles note above.
|
||||
|
||||
**Exception for internal chats:** admins can still retrieve a chat marked internal even when this is `False`. Internal chats are the ones Open WebUI creates on a user's behalf rather than the user opening them: [sub-agent](/features/chat-conversations/chat-features/subagents) chats, [timer](/features/chat-conversations/chat-features/timers) chats and note-attached chats. This carve-out is what lets an admin retrieve one at all, because internal chats are **excluded from every listing surface**: they do not appear in chat lists, search, counts, exports, or the admin chat list. They are reachable only by id.
|
||||
|
||||
That matters for auditing rather than for privacy: a sub-agent chat holds real model work, done with the user's model and tools and counted against your quota, but it will not show up in an export or an admin listing that is meant to cover a user's activity. Do not treat those surfaces as a complete record while sub-agents or timers are in use.
|
||||
|
||||
#### `ENABLE_ADMIN_ANALYTICS`
|
||||
|
||||
- Type: `bool`
|
||||
@@ -500,7 +565,7 @@ The AnyIO default of `40` is far too low for production. When more than `THREAD_
|
||||
- Type: `bool`
|
||||
- Default: `True`
|
||||
- Description: Globally enables or disables user status functionality. When disabled, the status UI (including blinking active/away indicators and status messages) is hidden across the application, and user status API endpoints are restricted.
|
||||
- Persistence: This environment variable is a `ConfigVar` variable. It can be toggled in the **Admin Panel > Settings > General > User Status**.
|
||||
- Persistence: This environment variable is a `ConfigVar` variable. It can be toggled in the **Settings > Admin > System > General > User Status**.
|
||||
|
||||
#### `ENABLE_EASTER_EGGS`
|
||||
|
||||
@@ -1058,7 +1123,7 @@ By default, audit logging uses **blacklist mode**: all paths are logged except t
|
||||
|
||||
- Type: `bool`
|
||||
- Default: `True`
|
||||
- Description: Enables the use of OpenAI APIs.
|
||||
- Description: Enables the use of OpenAI APIs. When disabled, the model list is emptied and both `GET /openai/models` and `POST /openai/chat/completions` reject requests with `503 OpenAI API is disabled`, rather than the completions endpoint attempting the upstream call. Toggling this, or saving the OpenAI connection config, refreshes the model list immediately instead of waiting for the cache to expire.
|
||||
- Persistence: This environment variable is a `ConfigVar` variable.
|
||||
|
||||
#### `OPENAI_API_BASE_URL`
|
||||
@@ -1135,7 +1200,7 @@ when using OpenAI-compatible endpoints.
|
||||
|
||||
- Type: `bool`
|
||||
- Default: `False`
|
||||
- Description: Enables automatic context compaction. When a chat's estimated context exceeds `CONTEXT_COMPACTION_TOKEN_THRESHOLD`, older messages are summarized into a checkpoint and dropped from what is sent to the model, while recent messages are kept, so long conversations stay within the model's context window. Can also be toggled in **Admin Panel > Settings > Interface**.
|
||||
- Description: Enables automatic context compaction. When a chat's estimated context exceeds `CONTEXT_COMPACTION_TOKEN_THRESHOLD`, older messages are summarized into a checkpoint and dropped from what is sent to the model, while recent messages are kept, so long conversations stay within the model's context window. Can also be toggled in **Settings > Admin > Experience > Interface**.
|
||||
- Persistence: This environment variable is a `ConfigVar` variable.
|
||||
|
||||
#### `CONTEXT_COMPACTION_TOKEN_THRESHOLD`
|
||||
@@ -1149,7 +1214,7 @@ when using OpenAI-compatible endpoints.
|
||||
|
||||
- Type: `int`
|
||||
- Default: falls back to `CONTEXT_COMPACTION_TOKEN_THRESHOLD` when unset
|
||||
- Description: The absolute ceiling, in tokens, for any per-model context compaction threshold. A model can raise or lower its own threshold with the `compact_token_threshold` advanced parameter, but the effective value is clamped to this cap. When unset it equals `CONTEXT_COMPACTION_TOKEN_THRESHOLD`, reproducing the previous behaviour in which per-model thresholds could only be lowered. Can also be set in **Admin Panel > Settings > Interface** (**Token Cap**).
|
||||
- Description: The absolute ceiling, in tokens, for any per-model context compaction threshold. A model can raise or lower its own threshold with the `compact_token_threshold` advanced parameter, but the effective value is clamped to this cap. When unset it equals `CONTEXT_COMPACTION_TOKEN_THRESHOLD`, reproducing the previous behaviour in which per-model thresholds could only be lowered. Can also be set in **Settings > Admin > Experience > Interface** (**Token Cap**).
|
||||
- Persistence: This environment variable is a `ConfigVar` variable.
|
||||
|
||||
#### `CONTEXT_COMPACTION_PROMPT_TEMPLATE`
|
||||
@@ -1163,32 +1228,29 @@ when using OpenAI-compatible endpoints.
|
||||
|
||||
- Type: `str`
|
||||
- Description: Prompt to use when generating chat titles.
|
||||
- Default: The value of `DEFAULT_TITLE_GENERATION_PROMPT_TEMPLATE` environment variable.
|
||||
- Default: Empty string, which falls back to the built-in template shown below. (`DEFAULT_TITLE_GENERATION_PROMPT_TEMPLATE` is a built-in constant, not an environment variable, so it cannot be set.)
|
||||
|
||||
`DEFAULT_TITLE_GENERATION_PROMPT_TEMPLATE`:
|
||||
Built-in template:
|
||||
|
||||
```
|
||||
|
||||
### Task:
|
||||
Generate a concise, 3-5 word title with an emoji summarizing the chat history.
|
||||
|
||||
Generate a concise title summarizing the chat history.
|
||||
### Guidelines:
|
||||
- The title should clearly represent the main theme or subject of the conversation.
|
||||
- Use emojis that enhance understanding of the topic, but avoid quotation marks or special formatting.
|
||||
- Keep it short: 2-4 words is best.
|
||||
- Do not use emojis, quotation marks, or special formatting.
|
||||
- Write the title in the chat's primary language; default to English if multilingual.
|
||||
- Prioritize accuracy over excessive creativity; keep it clear and simple.
|
||||
|
||||
- Prioritize accuracy over creativity.
|
||||
- Your entire response must consist solely of the JSON object, without any introductory or concluding text.
|
||||
- The output must be a single, raw JSON object, without any markdown code fences or other encapsulating text.
|
||||
- Ensure no conversational text, affirmations, or explanations precede or follow the raw JSON output, as this will cause direct parsing failure.
|
||||
### Output:
|
||||
JSON format: { "title": "your concise title here" }
|
||||
|
||||
### Examples:
|
||||
- { "title": "📉 Stock Market Trends" },
|
||||
- { "title": "🍪 Perfect Chocolate Chip Recipe" },
|
||||
- { "title": "Evolution of Music Streaming" },
|
||||
- { "title": "Remote Work Productivity Tips" },
|
||||
- { "title": "Artificial Intelligence in Healthcare" },
|
||||
- { "title": "🎮 Video Game Development Insights" }
|
||||
|
||||
- { "title": "Stock Trends" },
|
||||
- { "title": "Chocolate Chip Cookies" },
|
||||
- { "title": "Music Streaming" },
|
||||
- { "title": "Remote Work" }
|
||||
### Chat History:
|
||||
<chat_history>
|
||||
{{MESSAGES:END:2}}
|
||||
@@ -1767,7 +1829,7 @@ The header name is matched case-insensitively by the ASGI layer, so pick whateve
|
||||
|
||||
- Type: `bool`
|
||||
- Default: `False`
|
||||
- Description: When enabled, caches the list of base models from connected Ollama and OpenAI-compatible endpoints in memory. This reduces the number of API calls made to external model providers when loading the model selector, improving performance particularly for deployments with many users or slow connections to model endpoints. Can also be configured from Admin Panel > Settings > Connections > "Cache Base Model List".
|
||||
- Description: When enabled, caches the list of base models from connected Ollama and OpenAI-compatible endpoints in memory. This reduces the number of API calls made to external model providers when loading the model selector, improving performance particularly for deployments with many users or slow connections to model endpoints. Can also be configured from Settings > Admin > AI > Connections > "Cache Base Model List".
|
||||
- Persistence: This environment variable is a `ConfigVar` variable.
|
||||
|
||||
**How the cache works:**
|
||||
@@ -1777,7 +1839,7 @@ The header name is matched case-insensitively by the ASGI layer, so pick whateve
|
||||
- **Cache Hit**: Subsequent requests for models return the cached list without contacting external endpoints.
|
||||
- **Cache Refresh**: The cache is refreshed when:
|
||||
- The application restarts
|
||||
- The connection settings are saved in the **Admin Panel > Settings > Connections** (clicking the **Save** button on the bottom right will trigger a refresh and update the cache with the newly fetched models)
|
||||
- The connection settings are saved in the **Settings > Admin > AI > Connections** (clicking the **Save** button on the bottom right will trigger a refresh and update the cache with the newly fetched models)
|
||||
- **No TTL**: There is no automatic time-based expiration.
|
||||
|
||||
:::tip Performance Consideration
|
||||
@@ -1957,7 +2019,7 @@ FORWARD_SESSION_INFO_HEADER_MESSAGE_ID=X-Amzn-Bedrock-AgentCore-Runtime-Custom-M
|
||||
|
||||
Beyond the fixed user and session headers above, each connection can forward **arbitrary custom headers** whose values may embed **template placeholders** that Open WebUI substitutes for each request. Unlike the variables above, this is configured **per connection, not through an environment variable**, and it works **independently of `ENABLE_FORWARD_USER_INFO_HEADERS`** (custom headers are sent even when that toggle is `false`). They are applied **last**, so a custom header takes precedence over a built-in forwarded header of the same name.
|
||||
|
||||
Set them in **Admin Panel > Settings > Connections** by editing a connection and filling the **Headers** field with a JSON object, or in the connection's `headers` object inside [`OPENAI_API_CONFIGS`](#openai_api_configs) / [`OLLAMA_API_CONFIGS`](#ollama_api_configs). For example:
|
||||
Set them in **Settings > Admin > AI > Connections** by editing a connection and filling the **Headers** field with a JSON object, or in the connection's `headers` object inside [`OPENAI_API_CONFIGS`](#openai_api_configs) / [`OLLAMA_API_CONFIGS`](#ollama_api_configs). For example:
|
||||
|
||||
```json
|
||||
{
|
||||
@@ -3264,7 +3326,7 @@ Valkey is **opt-in and not bundled**. Install the client manually (`pip install
|
||||
|
||||
- Type: `bool`
|
||||
- Default: `False`
|
||||
- Description: When enabled, PDFs are sent to the Mistral OCR API **inline as a base64 data URL** instead of being uploaded to Mistral's file store first. Useful when the separate upload step is undesirable (proxy/air-gapped setups) or fails; it trades the extra upload request for a single larger request. Also configurable as **Use Base64** in **Admin Panel → Settings → Documents**.
|
||||
- Description: When enabled, PDFs are sent to the Mistral OCR API **inline as a base64 data URL** instead of being uploaded to Mistral's file store first. Useful when the separate upload step is undesirable (proxy/air-gapped setups) or fails; it trades the extra upload request for a single larger request. Also configurable as **Use Base64** in **Settings → Admin → Tools → Documents**.
|
||||
- Persistence: This environment variable is a `ConfigVar` variable.
|
||||
|
||||
#### `EXTERNAL_DOCUMENT_LOADER_URL`
|
||||
@@ -3418,7 +3480,7 @@ DOCLING_PARAMS="{\"do_ocr\": true, \"ocr_engine\": \"tesseract\", \"ocr_lang\":
|
||||
|
||||
- Type: `dict` (JSON object)
|
||||
- Default: `{}` (engine defaults)
|
||||
- Description: Extra options passed to the **MinerU** document loader as a JSON object. Recognized keys include `enable_ocr` (default `false`), `enable_formula` (`true`), `enable_table` (`true`), `language` (`en`), and `model_version` (`pipeline`). Also configurable in **Admin Panel → Settings → Documents** when MinerU is the content-extraction engine.
|
||||
- Description: Extra options passed to the **MinerU** document loader as a JSON object. Recognized keys include `enable_ocr` (default `false`), `enable_formula` (`true`), `enable_table` (`true`), `language` (`en`), and `model_version` (`pipeline`). Also configurable in **Settings → Admin → Tools → Documents** when MinerU is the content-extraction engine.
|
||||
- Persistence: This environment variable is a `ConfigVar` variable.
|
||||
|
||||
#### `PADDLEOCR_VL_BASE_URL`
|
||||
@@ -4246,7 +4308,7 @@ Allow only specific domains: WEB_FETCH_FILTER_LIST="example.com,trusted-site.org
|
||||
- Default: `auto`
|
||||
- Options: `auto` (Random), `bing`, `brave`, `duckduckgo`, `google`, `grokipedia`, `mojeek`, `wikipedia`, `yahoo`, `yandex`.
|
||||
- Description: Specifies the backend to be used by the DDGS engine.
|
||||
- Persistence: This environment variable is a `ConfigVar` variable. It can be configured in the **Admin Panel > Settings > Web Search > DDGS Backend** when DDGS is selected as the search engine.
|
||||
- Persistence: This environment variable is a `ConfigVar` variable. It can be configured in the **Settings > Admin > Tools > Web Search > DDGS Backend** when DDGS is selected as the search engine.
|
||||
|
||||
#### `BYPASS_WEB_SEARCH_EMBEDDING_AND_RETRIEVAL`
|
||||
|
||||
@@ -4304,7 +4366,7 @@ Brave's free tier enforces a rate limit of 1 request per second. Open WebUI auto
|
||||
|
||||
- Type: `int`
|
||||
- Default: `8192`
|
||||
- Description: Maximum total tokens to retrieve per query when `WEB_SEARCH_ENGINE=brave_llm_context`. Sent to Brave's LLM Context API as `maximum_number_of_tokens`. Valid range is `1024` to `32768`. Higher values pull richer extracted passages at the cost of API quota; lower values keep responses lean. Configurable via **Admin Panel → Settings → Web Search → Context Tokens** (only shown when the `brave_llm_context` engine is selected).
|
||||
- Description: Maximum total tokens to retrieve per query when `WEB_SEARCH_ENGINE=brave_llm_context`. Sent to Brave's LLM Context API as `maximum_number_of_tokens`. Valid range is `1024` to `32768`. Higher values pull richer extracted passages at the cost of API quota; lower values keep responses lean. Configurable via **Settings → Admin → Tools → Web Search → Context Tokens** (only shown when the `brave_llm_context` engine is selected).
|
||||
- Persistence: This environment variable is a `ConfigVar` variable. Stored at config key `rag.web.search.brave_search_context_tokens`.
|
||||
|
||||
#### `KAGI_SEARCH_API_KEY`
|
||||
@@ -4373,7 +4435,7 @@ Brave's free tier enforces a rate limit of 1 request per second. Open WebUI auto
|
||||
|
||||
- Type: `str` (JSON object)
|
||||
- Default: `''` (parsed to `{}`; effective defaults are `{"url": "https://api.linkup.so/v1/search", "depth": "standard", "outputType": "sourcedAnswer"}`)
|
||||
- Description: Optional JSON object merged over the Linkup request defaults. Recognized keys include `depth` (`standard` or `deep`), `outputType` (`sourcedAnswer` or `searchResults`), and `url` (overrides the API endpoint). `q` (the query) and `maxResults` are injected automatically and cannot be overridden. Invalid JSON falls back to `{}`. Configurable via **Admin Panel → Settings → Web Search** when the `linkup` engine is selected.
|
||||
- Description: Optional JSON object merged over the Linkup request defaults. Recognized keys include `depth` (`standard` or `deep`), `outputType` (`sourcedAnswer` or `searchResults`), and `url` (overrides the API endpoint). `q` (the query) and `maxResults` are injected automatically and cannot be overridden. Invalid JSON falls back to `{}`. Configurable via **Settings → Admin → Tools → Web Search** when the `linkup` engine is selected.
|
||||
- Persistence: This environment variable is a `ConfigVar` variable. Stored at config key `rag.web.search.linkup_search_params`.
|
||||
|
||||
#### `JINA_API_KEY`
|
||||
@@ -4387,7 +4449,7 @@ Brave's free tier enforces a rate limit of 1 request per second. Open WebUI auto
|
||||
- Type: `str`
|
||||
- Default: `https://s.jina.ai/`
|
||||
- Description: Sets the Base URL for Jina Search API. Useful for specifying custom or regional endpoints (e.g., `https://eu-s-beta.jina.ai/`).
|
||||
- Persistence: This environment variable is a `ConfigVar` variable. It can be configured in the **Admin Panel > Settings > Web Search > Jina API Base URL**.
|
||||
- Persistence: This environment variable is a `ConfigVar` variable. It can be configured in the **Settings > Admin > Tools > Web Search > Jina API Base URL**.
|
||||
|
||||
#### `BING_SEARCH_V7_ENDPOINT`
|
||||
|
||||
@@ -4707,7 +4769,7 @@ Using a remote Playwright browser via `PLAYWRIGHT_WS_URL` can be beneficial for:
|
||||
- Type: `int`
|
||||
- Default: `None`
|
||||
- Description: Specifies the timeout in milliseconds for Firecrawl requests. If not set, the default Firecrawl timeout is used.
|
||||
- Persistence: This environment variable is a `ConfigVar` variable. It can be configured in the **Admin Panel > Settings > Web Search > Firecrawl Timeout**.
|
||||
- Persistence: This environment variable is a `ConfigVar` variable. It can be configured in the **Settings > Admin > Tools > Web Search > Firecrawl Timeout**.
|
||||
|
||||
#### `PLAYWRIGHT_TIMEOUT`
|
||||
|
||||
@@ -6688,6 +6750,12 @@ These settings control whether users can share workspace items **publicly**.
|
||||
- Default: `True`
|
||||
- Description: Controls whether non-admin users can share resources (knowledge bases, models, prompts, notes, skills, and tools) with **specific individual users**. When set to `False`, individual user grants are silently stripped from access grant lists; group sharing and public sharing remain unaffected. Admins always retain the ability to share with individual users regardless of this setting. Also configurable per-group in **Admin Panel → Users → Groups → Permissions → Access Grants → Allow Sharing With Users**.
|
||||
|
||||
#### `USER_PERMISSIONS_ACCESS_GRANTS_ALLOW_GROUPS`
|
||||
|
||||
- Type: `bool`
|
||||
- Default: `True`
|
||||
- Description: The group counterpart of the variable above: controls whether non-admin users can share resources with **groups**. When set to `False`, group grants are silently stripped from access grant lists on save; individual-user sharing and public sharing remain unaffected. Admins always retain the ability to share with groups. Also configurable per-group in **Admin Panel → Users → Groups → Permissions → Access Grants → Allow Sharing With Groups**.
|
||||
|
||||
### Import / Export
|
||||
|
||||
#### `USER_PERMISSIONS_WORKSPACE_MODELS_IMPORT`
|
||||
@@ -7794,7 +7862,11 @@ Open WebUI provides environment variables to customize the pip installation proc
|
||||
|
||||
- Type: `bool`
|
||||
- Default: `True`
|
||||
- Description: Master switch for Open WebUI's built-in Tools and Functions. When set to `False`, the entire Tools and Functions surface is removed: the workspace **Tools** page and admin **Functions** page are hidden, their API endpoints return empty, and every plugin execution path (filters, actions, pipe functions, built-in native tool-calling and code-interpreter detection) is skipped. This is stronger than [`SAFE_MODE`](#safe_mode): `SAFE_MODE` deactivates all Functions while the feature stays in place, whereas `ENABLE_PLUGINS=False` gates off the whole execution surface. OpenAPI and MCP tool servers configured through connections are unaffected. Surfaced to clients as the `enable_plugins` config flag.
|
||||
- Description: Turns **plugins** off entirely: the [Tools and Functions](/features/extensibility/plugin/) users write and upload, which run Python on the server. When set to `False`, the workspace **Tools** page and admin **Functions** page are hidden and plugins stop loading and running, so user tools are not offered to models and filters, actions and pipe functions are skipped. This is stronger than [`SAFE_MODE`](#safe_mode): `SAFE_MODE` deactivates all Functions while the feature stays in place, whereas `ENABLE_PLUGINS=False` removes the surface. Surfaced to clients as the `enable_plugins` config flag.
|
||||
- Not affected: things that are not plugins. The [builtin tools](/features/extensibility/plugin/tools#built-in-system-tools-nativeagentic-mode) (memory, knowledge, web search, sub-agents and the rest) are part of Open WebUI rather than uploaded code, and keep working, as do the code interpreter and any OpenAPI or MCP tool servers configured through connections; `GET /api/v1/tools/` still returns those servers. So this is not a way to stop a model using tools in general, and not an "execute no code" switch. For those, use the per-model **Builtin Tools** categories and the code-execution settings.
|
||||
- Note: the flag gates the **listing** endpoints, which return empty (`GET /api/v1/functions/`, `/functions/list`, `/functions/export`, `/tools/list`, and the local-tool half of `/tools/`). The create, update, delete and valves endpoints are **not** gated, so a plugin can still be written through the API while the execution surface is off. Treat this as a switch for whether plugins *run*, not as an authorization boundary over the plugin endpoints.
|
||||
- Also hidden while disabled: the **Functions** entry in the Admin Panel (navigating to it redirects back), the **Tools** workspace page (same), and the **Tools Access** permission and its Import/Export sub-toggles under **Users > Groups > Permissions**, since there is nothing left for them to govern.
|
||||
- Failure modes differ by surface, which is worth knowing when debugging: tools and filters simply come back empty, while installing a plugin or running an action raises an error naming `ENABLE_PLUGINS`.
|
||||
|
||||
#### `ENABLE_PIP_INSTALL_FRONTMATTER_REQUIREMENTS`
|
||||
|
||||
|
||||
@@ -133,7 +133,7 @@ You can also provide a semicolon-separated list of allowed domains. **Do not ski
|
||||
|
||||
6. **Add your url to open-webui (otherwise getting HTTPS error):**
|
||||
|
||||
- Go to your open-webui → Admin Panel → Settings → General
|
||||
- Go to your open-webui → Settings → Admin → System → General
|
||||
- In the **Webhook URL** text field, enter your URL through which you will connect to your open-webui via Nginx reverse proxy. Example: ``hello.duckdns.org`` (not essential with this one) or ``openwebui.hello.duckdns.org`` (essential with this one).
|
||||
|
||||
#### Access the WebUI
|
||||
|
||||
@@ -53,7 +53,7 @@ User settings override admin defaults. If you're having issues, check both locat
|
||||
|
||||
If you have an OpenAI API key, this is the simplest setup:
|
||||
|
||||
**In Admin Panel → Settings → Audio:**
|
||||
**In Settings → Admin → Experience → Audio:**
|
||||
- **STT Engine:** `OpenAI` | **Model:** `whisper-1`
|
||||
- **TTS Engine:** `OpenAI` | **Model:** `tts-1` | **Voice:** `alloy`
|
||||
- Enter your OpenAI API key in both sections
|
||||
@@ -75,7 +75,7 @@ environment:
|
||||
|
||||
If you prefer Mistral's audio stack:
|
||||
|
||||
**In Admin Panel → Settings → Audio:**
|
||||
**In Settings → Admin → Experience → Audio:**
|
||||
- **STT Engine:** `MistralAI` | **Model:** `voxtral-mini-latest` (or leave empty)
|
||||
- **TTS Engine:** `MistralAI` | **Model:** `mistral-tts-latest` (or leave empty) | **Voice:** choose from list
|
||||
- Enter your Mistral API key in both sections
|
||||
@@ -240,7 +240,7 @@ services:
|
||||
### TTS Voice Not Found / No Audio Output
|
||||
|
||||
**Checklist:**
|
||||
1. Verify the TTS engine is correctly configured in **Admin Panel → Settings → Audio**
|
||||
1. Verify the TTS engine is correctly configured in **Settings → Admin → Experience → Audio**
|
||||
2. Check that the voice name matches an available voice for your chosen engine
|
||||
3. For external TTS services, verify the API Base URL is accessible from the Open WebUI container
|
||||
4. Check container logs for any error messages
|
||||
@@ -356,7 +356,7 @@ If your STT or TTS engine is hosted behind a self-signed certificate or an inter
|
||||
|
||||
ElevenLabs is natively supported in Open WebUI. To configure:
|
||||
|
||||
1. Go to **Admin Panel → Settings → Audio**
|
||||
1. Go to **Settings → Admin → Experience → Audio**
|
||||
2. Select **ElevenLabs** as the TTS engine
|
||||
3. Enter your ElevenLabs API key
|
||||
4. Select the voice and model
|
||||
|
||||
@@ -60,7 +60,7 @@ WEBSOCKET_REDIS_URL=redis://redis:6379/1
|
||||
|
||||
The `WEBUI_URL` must be set correctly BEFORE using OAuth/SSO. Since it's a persistent config variable, you can only change it by:
|
||||
- Disabling persistent config temporarily with `ENABLE_PERSISTENT_CONFIG=false`
|
||||
- Changing it in Admin Panel > Settings > WebUI URL
|
||||
- Changing it in Settings > Admin > System > General > WebUI URL
|
||||
- Setting it correctly before first launch
|
||||
|
||||
**CORS Configuration Details**
|
||||
|
||||
@@ -52,10 +52,10 @@ There is no single policy that is correct for every deployment, every user, and
|
||||
|
||||
Open WebUI ships an optional **Context Compaction** feature that handles the common case for you. When a chat's estimated context grows past a token threshold, it asks a model to summarize the older messages, then continues the conversation from that summary plus the most recent messages, so a long chat keeps going without overflowing the window.
|
||||
|
||||
It is **disabled by default**. An administrator enables and tunes it in **Admin Panel > Settings > Interface**:
|
||||
It is **disabled by default**. An administrator enables and tunes it in **Settings > Admin > Experience > Interface**:
|
||||
|
||||
- **Context Compaction**: the on/off toggle ([`ENABLE_CONTEXT_COMPACTION`](/reference/env-configuration#enable_context_compaction)).
|
||||
- **Token Threshold**: the estimated context size, in tokens, above which older messages are compacted (default `80000`, [`CONTEXT_COMPACTION_TOKEN_THRESHOLD`](/reference/env-configuration#context_compaction_token_threshold)). Set it below your model's real window. An individual model can compact sooner by setting a lower **Context Compaction Threshold** (`compact_token_threshold`) in its advanced parameters; the global value stays the ceiling.
|
||||
- **Token Threshold**: the estimated context size, in tokens, above which older messages are compacted (default `80000`, [`CONTEXT_COMPACTION_TOKEN_THRESHOLD`](/reference/env-configuration#context_compaction_token_threshold)). Set it below your model's real window. This is the global default: an individual model can set its own **Context Compaction Threshold** (`compact_token_threshold`) in its advanced parameters, either lower or higher, bounded by the **Token Cap** ([`CONTEXT_COMPACTION_TOKEN_CAP`](/reference/env-configuration#context_compaction_token_cap)), which defaults to the threshold. So a model can compact later than the global default only if you raise the cap.
|
||||
- **Context Compaction Prompt**: an optional custom summarization prompt ([`CONTEXT_COMPACTION_PROMPT_TEMPLATE`](/reference/env-configuration#context_compaction_prompt_template)); leave it empty for the built-in default. It supports `{{COMPACTED_MESSAGES}}` (the messages being summarized) and `{{RECENT_MESSAGES}}` (the messages kept in context).
|
||||
|
||||
This is the summarize-and-replace strategy (option 4 below), built in. If you need a different policy (hard caps, attachment-first trimming, per-model windows), use a filter Function instead.
|
||||
@@ -67,6 +67,20 @@ This is the summarize-and-replace strategy (option 4 below), built in. If you ne
|
||||
- **The task model writes the summary.** It uses the same model selection as title and tag generation: your configured Task Model (`TASK_MODEL` / `TASK_MODEL_EXTERNAL`) if set, otherwise the chat's current model, with a fallback to the chat model when the task model is unavailable. Summary length is capped by the task model's `max_tokens` (default 1000).
|
||||
- **Your system prompt, tools, and skills are preserved.** Compaction only summarizes conversation messages. The model, workspace and folder system prompts, the available tools and their instructions, skills and any RAG, web search or memory context are all reassembled fresh on every request, after compaction runs, so they are never summarized away. The one exception is older **tool-call results** that live in the chat history: a past tool result inside the compacted block is condensed into the summary, though what the model can still call is unaffected.
|
||||
- **It fails safe.** If the summarizer returns nothing, Open WebUI falls back to a short mechanical summary (the previous summary plus truncated excerpts of the dropped messages). If compaction errors entirely, it is logged and the request proceeds with the full, uncompacted history.
|
||||
- **It splits at a user message, and can decline to split at all.** The cut is placed at a user message so a turn is never severed mid-exchange. If no suitable user message sits far enough back, for example a long conversation that is one enormous exchange rather than many turns, **compaction does not run for that request** and the full over-threshold history is sent. It is silent: there is no error, and it will try again on the next turn. So crossing the threshold does not guarantee compaction happened, and compaction is not a hard ceiling on what reaches the model. If you need a guaranteed bound, use a filter Function as below.
|
||||
- **You can read the current usage over the API.** `GET /api/v1/chats/{id}` and `POST /api/v1/chats/{id}/compact` include a `context_usage` object, so a client can show how close a chat is to compacting:
|
||||
|
||||
```json
|
||||
{
|
||||
"tokens": 41234,
|
||||
"estimated_tokens": 41234,
|
||||
"threshold": 80000,
|
||||
"percent": 52,
|
||||
"source": "estimated"
|
||||
}
|
||||
```
|
||||
|
||||
It is `null` when compaction is disabled or the chat has no messages. As `source` says, the count is **estimated**, not a tokenizer-exact figure, so treat it as a gauge rather than a billing number.
|
||||
|
||||
## The supported way: use a filter Function
|
||||
|
||||
|
||||
@@ -32,7 +32,7 @@ By default, Open WebUI automates background tasks like title generation, tagging
|
||||
**Recommendation**: Use a **very fast, small, and cheap NON-REASONING model** for these tasks. Avoid using large reasoning models (like o1, r1, or Claude) as they are too slow and expensive for simple background tasks.
|
||||
|
||||
**Configuration:**
|
||||
There are two separate settings in **Admin Panel > Settings > Interface**. The system intelligently selects which one to use based on the model you are currently chatting with:
|
||||
There are two separate settings in **Settings > Admin > Experience > Interface**. The system intelligently selects which one to use based on the model you are currently chatting with:
|
||||
* **Task Model (External)**: Used when you are chatting with an external model (e.g., OpenAI).
|
||||
* **Task Model (Local)**: Used when you are chatting with a locally hosted model (e.g., Ollama).
|
||||
|
||||
|
||||
@@ -11,7 +11,7 @@ This page covers the most common RAG problems and their solutions.
|
||||
|
||||
## Recommended Settings by Scenario
|
||||
|
||||
RAG performance depends heavily on your model setup. The defaults are conservative to work everywhere, but you will get much better results by tuning them to your specific deployment. All of these are configured in **Admin Panel > Settings > Documents**.
|
||||
RAG performance depends heavily on your model setup. The defaults are conservative to work everywhere, but you will get much better results by tuning them to your specific deployment. All of these are configured in **Settings > Admin > Tools > Documents**.
|
||||
|
||||
:::tip Agentic retrieval: enable kb_exec
|
||||
If your models use **native function calling**, set [`ENABLE_KB_EXEC=True`](/reference/env-configuration#enable_kb_exec) for a noticeably better knowledge-base experience. It gives the model a filesystem-style interface (`ls`, `tree`, `grep`, `cat`, read-by-line) over your knowledge that capable models chain more reliably than the individual search tools. It has no effect in Legacy Mode. See [Filesystem-style access](/features/workspace/knowledge#filesystem-style-access-kb_exec).
|
||||
@@ -76,7 +76,7 @@ The embedding model determines retrieval quality. The right choice depends on yo
|
||||
| **Production, API budget available** | `text-embedding-3-small` via OpenAI | Best retrieval quality per dollar |
|
||||
| **Air-gapped / self-hosted** | `nomic-embed-text` or `mxbai-embed-large` via Ollama | No external API calls needed |
|
||||
|
||||
After changing your embedding model, **reindex all existing documents** in **Admin Panel > Settings > Documents** for the new embeddings to take effect.
|
||||
After changing your embedding model, **reindex all existing documents** in **Settings > Admin > Tools > Documents** for the new embeddings to take effect.
|
||||
|
||||
---
|
||||
|
||||
@@ -199,9 +199,9 @@ After fixing the configuration, try re-embedding a document and verify no error
|
||||
Open WebUI implements various limits to ensure system stability and prevent abuse. It is important to understand how these limits apply to different upload methods:
|
||||
|
||||
* **Chat Uploads:** Subject to global file size and count limits.
|
||||
* **Max File Size:** Controlled by `RAG_FILE_MAX_SIZE` (default: Unlimited). Configurable in **Admin Panel > Settings > Documents > General > Max Upload Size**.
|
||||
* **Max File Count:** Controlled by `RAG_FILE_MAX_COUNT` (default: Unlimited). Configurable in **Admin Panel > Settings > Documents > General > Max Upload Count**.
|
||||
* **Allowed File Extensions:** Controlled by `RAG_ALLOWED_FILE_EXTENSIONS` (default: All). Configurable in **Admin Panel > Settings > Documents > General > Allowed File Extensions**.
|
||||
* **Max File Size:** Controlled by `RAG_FILE_MAX_SIZE` (default: Unlimited). Configurable in **Settings > Admin > Tools > Documents > General > Max Upload Size**.
|
||||
* **Max File Count:** Controlled by `RAG_FILE_MAX_COUNT` (default: Unlimited). Configurable in **Settings > Admin > Tools > Documents > General > Max Upload Count**.
|
||||
* **Allowed File Extensions:** Controlled by `RAG_ALLOWED_FILE_EXTENSIONS` (default: All). Configurable in **Settings > Admin > Tools > Documents > General > Allowed File Extensions**.
|
||||
* **Folder Uploads:** Subject to the `FOLDER_MAX_FILE_COUNT` [environment variable](/reference/env-configuration/#folder_max_file_count) (defaults to 100). This limit applies to the number of files directly associated with a folder.
|
||||
* **Knowledge Base Uploads:**
|
||||
* **File Limit:** Subject to the same `RAG_FILE_MAX_SIZE` limit as chats, but **not** subject to the `RAG_FILE_MAX_COUNT` limit, allowing for unlimited file uploads.
|
||||
@@ -363,7 +363,7 @@ Error generating embeddings: 429 Rate limit reached
|
||||
environment:
|
||||
RAG_EMBEDDING_CONCURRENT_REQUESTS: 5
|
||||
```
|
||||
Or configure it in the **Admin Panel > Settings > Documents > Concurrent Requests** field. The default of `0` means unlimited concurrency.
|
||||
Or configure it in the **Settings > Admin > Tools > Documents > Concurrent Requests** field. The default of `0` means unlimited concurrency.
|
||||
|
||||
2. **Reduce Batch Size**:
|
||||
Lower [`RAG_EMBEDDING_BATCH_SIZE`](/reference/env-configuration#rag_embedding_batch_size) to send fewer texts per API call.
|
||||
@@ -490,14 +490,14 @@ If you want to prevent a model from accessing **any** knowledge base in native m
|
||||
✅ **Solutions (check in order):**
|
||||
|
||||
1. **Check Global Model Settings first**:
|
||||
- Go to **Admin Panel > Settings > Models > ⚙️ (gear icon)**
|
||||
- Go to **Settings > Admin > AI > Models > ⚙️ (gear icon)**
|
||||
- Expand **Model Parameters** and check if **Function Calling** is set to `native`
|
||||
- If it is, this **overrides all models** that don't explicitly set their own `function_calling` parameter, even if you never intended for a specific model to use native mode
|
||||
- Either change the global setting to `default`, or explicitly set `function_calling` in the per-model **Advanced Params** to override the global value
|
||||
- Also check the **Model Capabilities** section: if **File Context** is disabled globally, RAG won't process files for any model that doesn't explicitly enable it
|
||||
|
||||
:::warning Global Settings Override
|
||||
The most common cause of this issue is a global `Function Calling: native` setting in **Admin Panel > Settings > Models > ⚙️ > Model Parameters**. This silently applies to **every model** that doesn't explicitly set its own `function_calling` parameter. Per-model settings in **Workspace > Models > Edit > Advanced Params** will override the global default, but only if explicitly set. A model that simply doesn't have `function_calling` configured will inherit the global value.
|
||||
The most common cause of this issue is a global `Function Calling: native` setting in **Settings > Admin > AI > Models > ⚙️ > Model Parameters**. This silently applies to **every model** that doesn't explicitly set its own `function_calling` parameter. Per-model settings in **Workspace > Models > Edit > Advanced Params** will override the global default, but only if explicitly set. A model that simply doesn't have `function_calling` configured will inherit the global value.
|
||||
:::
|
||||
|
||||
2. **Ensure Built-in Tools are enabled for the model** (if using native mode):
|
||||
|
||||
@@ -19,7 +19,7 @@ This happens because the web content fetcher doesn't use your `http_proxy`/`http
|
||||
|
||||
✅ **Solution:**
|
||||
|
||||
1. Navigate to: **Admin Panel > Settings > Web Search**
|
||||
1. Navigate to: **Settings > Admin > Tools > Web Search**
|
||||
2. Enable **Trust Proxy Environment**
|
||||
3. Save changes
|
||||
|
||||
|
||||
@@ -23,7 +23,7 @@ You **MUST** set the `WEBUI_SECRET_KEY` environment variable to a persistent val
|
||||
|
||||
### 1. Add the tool
|
||||
|
||||
Go to **Admin Panel → Settings → External Tools** and click **+** to add a new connection. Fill in the following:
|
||||
Go to **Settings → Admin → Tools → Integrations** and click **+** to add a new connection. Fill in the following:
|
||||
|
||||
| Field | Value |
|
||||
|-------|-------|
|
||||
|
||||
@@ -62,7 +62,7 @@ In the *Admin Settings*, create and save a new connection of type OpenAI API wit
|
||||
|
||||
### Step 4: Adding the Langfuse Filter Pipeline
|
||||
|
||||
Next, navigate to *Admin Settings*->*Pipelines* and add the Langfuse Filter Pipeline. Specify that Pipelines is listening on http://host.docker.internal:9099 (as configured earlier) and install the [Langfuse Filter Pipeline](https://github.com/open-webui/pipelines/blob/039f9c54f8e9f9bcbabde02c2c853e80d25c79e4/examples/filters/langfuse_v3_filter_pipeline.py) by using the *Install from Github URL* option with the following URL:
|
||||
Next, navigate to *Admin Settings*->*Pipelines* and add the Langfuse Filter Pipeline. Specify that Pipelines is listening on http://host.docker.internal:9099 (as configured earlier) and install the [Langfuse Filter Pipeline](https://github.com/open-webui/pipelines/blob/039f9c54f8e9f9bcbabde02c2c853e80d25c79e4/examples/filters/langfuse_v3_filter_pipeline.py) by using the *GitHub URL* option with the following URL:
|
||||
|
||||
```txt
|
||||
https://github.com/open-webui/pipelines/blob/main/examples/filters/langfuse_v3_filter_pipeline.py
|
||||
|
||||
Reference in New Issue
Block a user