Open WebUI on Admantium

Open WebUI: Scheduling Agents

Thu, 22 Oct 2026 00:00:00 +0000

Open WebUI provides a uniform chat interface with media uploads and persistent conversations that connect to an Ollama backend or an OpenAI API-compatible LLM provider. Recent versions also added a terminal, a Docker container in which to execute code, as well as configurable tools, skills, and memory. By building custom models, individual conversations build a persistent agent.

This is the final article of my Open WebUI investigation. It takes another turn at agent definition, detailing skill and tool definition, and showing how to invoke agents automatically via schedules and through a remote chat interface.

The technical context of this article is Open WebUI v0.9.6, published on 2026-06-01. The setup and configuration examples should also work with newer versions.

While I am fascinated by the capabilities of artificial intelligence tools and applications, crafting blog articles remains a personal skill. Every character, number, and symbol in this article was typed manually, with the exception of verbatim copies from log messages and screenshots.

Custom Tools

Definition

Tools are Python snippets defined by an admin account. They need to follow a design contract with specifically named objects and functions, and when configured for a base model, inject their definition into the system prompt so that the base model can issue tool calls.

Adding Custom Tools to Open WebUI

While there is the option to implement a custom tool following the official documentation, tools can also be imported from the Community Tool Library.

Here is an example of adding a tool that shows the current weather.

The first step is to find an appropriate tool and get its files.

On the community marketplace:

Search for the tool in the community marketplace.
Click on the Get button (an account is required).
Download the JSON file.

Alternatively, the Python file can be downloaded from the linked GitHub repository.

The second step is to define the tool in the Open WebUI instance. With an admin user account, Workspace => Tools needs to be opened. When the tool was downloaded from the community page, clicking on Import and selecting the downloaded JSON file suffices. If the Python source code file is used, then clicking on + New Tool and pasting the file content is required.

Model Configuration

As explained in my earlier articles, base models and custom models require a strict definition of their capabilities and available tools, and therefore the new weather tool needs to be added. Follow these steps:

Go to Workspace, then Models
Select an existing base model, or define a new one
The tools section lists all imported or self-defined tools; activate them for the target model

Tool Invocation

To test this new weather tool, I created a new model named assistant, based on GPT-5.4, and added the tool.

When using the model, I unfortunately encountered conversational hurdles again to get the tool applied. Only a direct mention of the tool led to success - the Python code was invoked, and its results rendered in the conversation interface.

Custom Skills

Definition

Skills are markdown declarations with detailed instructions. They are intended to specify complex steps with explicit instructions, rules, and policies, and potentially source code files that should be executed.

Skill repositories are abundant, and skills.sh provides an easy entry point. Search for skills that support GitLab interactions; I encountered git-commit and github-pr-workflow.

Here is an excerpt of the skill file.

# Source: https://github.com/github/awesome-copilot/blob/main/skills/git-commit/SKILL.md

***
name: github-pr-workflow
description: Working with GitHub Pull Requests using the gh CLI. Use for fetching PR details, review comments, CI status, and understanding the difference between PR-level comments vs inline code review comments.
***

# GitHub PR Workflow

## Key Concepts

### Comment Types

GitHub PRs have **two different types of comments**:

1. **PR-level comments** - General discussion on the PR (shown via `gh pr view --comments`)
2. **Inline code review comments** - Comments attached to specific lines of code (requires API)

**Important**: `gh pr view --comments` does NOT show inline code review comments!

## Scripts

| Script | Purpose |
|--------|---------|
| `gh-pr-info <PR> [REPO]` | **Comprehensive PR info**: summary, CI checks, and unresolved review and inline comments |

The script auto-detects the repo from the git remote, or accepts `[REPO]` as a second argument (format: `owner/repo`).

**Key features**:
- Uses GitHub's GraphQL API to reliably filter out already resolved/addressed comments.
- Excludes collapsed/hidden review threads.
- Excludes minimized comments (marked as spam/off-topic/resolved).
- Excludes dismissed reviews.
- Shows only what still needs attention.

## Common Commands
# Get complete PR info with UNRESOLVED comments only
gh-pr-info <PR> [REPO]             # ✅ Everything you need: summary, checks, reviews, unresolved comments

Adding Custom Skills

The declaration of custom skills in Open WebUI follows similar steps to those of tools. Follow these steps:

On the skill repository page, open the skill file in markdown format, and either save the file or copy its content
In Open WebUI, click on Workspace => Skills, and either Import to select the downloaded file, or + New Skill and paste the file content in the editor window
In the top-right corner, click on Access, and ensure that Public is selected in the appearing drop-down menu -see the following screenshot:

Model Configuration

The skill needs to be configured for the model too.

Go to Workspace, then Models.
Select an existing base model, or define a new one.
In the Skills section, all defined skills should appear. Activate them by selecting their respective checkbox.

Skill Invocation

After adding the new skill to a Python Engineer model, I tried to get the skill invoked. Although skills are intended to be called by the LLM when it detects a specific context or intent, I experienced the best results with direct invocation. In Open WebUI, direct keyword invocation occurs when the command starts with $.

Here is an example chat output in which the Python project from my previous article about is continued. The prompt instructed the model to systematically commit the changes.

I’ll configure the repo-local git identity, inspect the repo state, then create the planned conventional commits one by one and show each command with output.

Approved. I proceeded with repo-local git config and created the commits step by step.

Plan executed
- Set local git identity
- Inspect repo state
- Initialize git repo if needed
- Create 4 logical commits:
  - `chore: initialize repository structure`
  - `build: add Python API dependencies`
  - `feat(api): add FastAPI app with config endpoint`
  - `feat(config): add model config data`

Running a git log command in the folder shows the successful application of these commands.

commit a01ddf84128e6f09276c449d94b62da1ff9064ba (HEAD -> master)
Author: python-engineer <agent4223@python.org>
Date:   Sun Jul 5 14:21:42 2026 +0000

    feat(config): add model config data

commit 53991af08e9d57b1b89503c9ac0ddcd39e1519e0
Author: python-engineer <agent4223@python.org>
Date:   Sun Jul 5 14:21:42 2026 +0000

    feat(api): add FastAPI app with config endpoint

commit 4905c33d72afd5a95929a2313c331b36da83ca08
Author: python-engineer <agent4223@python.org>
Date:   Sun Jul 5 14:21:42 2026 +0000

    build: add Python API dependencies

commit d2ea8ce702ff159b1438949d26f83e56f2d7d55d
Author: python-engineer <agent4223@python.org>
Date:   Sun Jul 5 14:21:42 2026 +0000

    chore: initialize repository structure

Model Invocation

Models with custom tools and skills can be invoked in four different ways.

Chat Interface

The native Open WebUI chat interface is bound to the selected model. Once selected, all user messages are parsed and answered by this configured model. However, at every turn in the conversation, the model can be switched, and new messages are answered by the new model. This opens a myriad of questions surrounding conversational flow. Since capabilities and tools are configured per model, switching one could invalidate the use of skills. While the LLM could see past messages, it could not repeat the same invocation and arrive at the same result. This is further complicated by the fact that past messages can be regenerated.

Scheduled

Automations allow model calls on defined schedules. They are accessible from the user menu. Follow these steps:

Click the user icon, then click Automations
Click the + New Automation button
Provide a suitable prompt, and program the schedule with an RRULE, an iCalendar-specific format

To run a command every 5 minutes, the time modifier would be RRULE:FREQ=MINUTELY;INTERVAL=5.

Here is a screenshot showing how this invocation is defined:

Invocations of an automation appear as normal chats in the chat list. As can be seen in the following screenshot, getting the right prompt for the chosen gpt-5-nano base to perform changes without clarification questions can be tricky.

Agent Runtime

Instead of creating an Open WebUI agent via base model declaration, there is also the option to use just the chat interface and connect to an agent system. Three options are explained in the official documentation: OpenClaw, Hermes, and Open WebUI Computer, which promises uniform API-based access to operations on a computer. However, this option should be explored in a dedicated article, because the implications of which systems define skills and tools, and where the invocation happens, are not clear from these documents.

External Apps

There is no native integration to connect Open WebUI to a communication channel. But during my research, I encountered the following GitHub projects.

openwebui-telegram: This repo provides a custom Telegram bridge -it polls Telegram server endpoints for messages, and when receiving them, contacts the configured Open WebUI API endpoint for chat completions. Messages are parsed back and forth between these two APIs
open-webui/bot: An experimental project that wraps Open WebUI’s channel feature and implements a bot interface. However, there is no direct connection to a messaging service or platform
open-webui-utils: A repository that contains two Open WebUI tools for outbound message integration, one for Telegram and one for Discord

Additional projects can be found on the Open WebUI Community page when searching for messaging platforms.

Conclusion

Over the course of three years, Open WebUI incorporated several features that can turn mere model invocation into agents. Specifically, custom model definitions with prompts, configurable capabilities that produce useful tools, and built-in as well as extensible tools to execute them. Conversations become data that can be added to a knowledge base, and when used with the same base model, this provides a growing context for future conversations. Finally, the terminal added the capability to execute arbitrary code in a Docker container, creating a coding-agent experience. This article showed what tools and skills are, how to find, configure, and use them in Open WebUI. It also listed the available ways to invoke a defined model: through the chat interface, with automations triggered on defined schedules, using an external runtime, and through community projects for access from external apps. But are these features sufficient to create true agents? And how does this experience compare with other agent systems? Future articles may explore these questions.

Open WebUI: Creating Custom Agents

Mon, 12 Oct 2026 00:00:00 +0000

Open WebUI evolved from an Ollama chat interface into a full-fledged agent interface for any OpenAI API endpoint. Chat context can come from custom knowledge bases for RAG retrieval, text, images, or other chat references, as well as memory. Custom models are built on top of a base model and then configured with a custom prompt, tools, and skills. Finally, the newly added Terminal feature connects to a Docker container to run arbitrary code. With this feature set, Open WebUI promises full agent capabilities.

This article focuses on the step-by-step creation of a coding agent. You will learn which feature configurations in Open WebUI are relevant, how to set up the agent with its prompts and tools, and finally how to execute chats that result in updates to a codebase via the default chat interface and deferred cron jobs.

The technical context of this article is Open WebUI v0.9.6, published on 2026-06-01. The setup and configuration examples should also work with newer versions.

Agent Setup

Requirements

The custom coding agent should meet the following requirements:

Base model: A recent model capable of coding
Custom prompt: A senior Python full-stack engineer with a structured, rigorous work method
Tools: No special tools
Knowledge: No specialized local knowledge required
Memory: The coding session should persist; for example, stack choices should be remembered

Base Model

The agent is implemented as a custom model, accessible from the Open WebUI GUI via Workspace, then Models.

For the base model, I wanted to stay on the conservative side for this test. Specifically, I did not want to be surprised by Codex-class billing for this setup. At the time of writing, gpt-5.4-nano offered a good input and output token cost profile. All prices for OpenAI models can be derived from OpenAI API Pricing.

Prompt

For the system prompt, I used another LLM provider and a creative prompt to produce a non-standard description for the senior Python developer. Here it is:

# Senior Python Engineer — Prompt

You are a **SENIOR PYTHON ENGINEER** with **FULL-STACK** capability.

Your style combines the enigmatic clarity of a systems thinker, the discipline of a machinist, the memory of an archivist, and the rigor of empiricism-driven validation.

## Role

Design, build, debug, and improve production-grade software across backends, APIs, data flows, infrastructure boundaries, and frontend integration points.

## Expectations

- Write clean, idiomatic, maintainable Python.
- Prefer strong typing, clear abstractions, and explicit trade-offs.
- Think in systems: performance, reliability, observability, security, and developer ergonomics.
- Operate as a full-stack engineer when needed: backend first, but comfortable with frontend architecture, API contracts, and integration details.
- Default to pragmatic solutions over fashionable complexity.

## Working Style

- **Enigmatic**: find non-obvious but explainable solutions.
- **Machinist**: engineer with precision, repeatability, and mechanical discipline.
- **Archivist**: preserve context, document decisions, and keep codebases legible over time.
- **Empirical**: validate assumptions through measurement, tests, benchmarks, and evidence.

## Technical Principles

- Use Python thoughtfully: typing, async when justified, testing, profiling, and clear module boundaries.
- Design APIs and services for scale, debuggability, and failure tolerance.
- Make observability native: logs, metrics, traces, and actionable errors.
- Treat security as a design constraint, not an afterthought.
- Keep code easy to review, extend, and operate.

## Response Rules

- Give concise, technically sharp answers.
- Provide working code when implementation is requested.
- State assumptions before designing complex solutions.
- Explain trade-offs briefly and clearly.
- Avoid filler, vague advice, and unnecessary abstraction.
- Favor production-suitable patterns over tutorial-style shortcuts.

## Output Preference

Return answers as a senior engineer would: precise, grounded, structured, and directly useful.

Knowledge, Skills, and Custom Skills

To test agent invocation and gauge performance, I decided against adding additional configurations here.

Memory

Open WebUI’s default configuration has memory disabled. Each user needs to activate it explicitly. Click on the user icon, then on Settings, and then on Personalization. Flip the toggle. From then on, each interaction may store persistent facts encountered during use. This section also includes a button to manage memory, for example to list and edit entries.

Capabilities and Built-in Tools

Capabilities define allowed tool calls which, when enabled, result in an extended system prompt or additional conversation metadata. The default features are common, and the built-in tools are optional tools that can be enabled. If they are enabled, the model can issue tool calls, and Open WebUI will execute them.

The configuration for the custom model is as follows:

For most tools, the Open WebUI Docker image is bundled with the necessary libraries, so the container can run code interpretation and provide access to tasks, notes, and memory. Web search and terminal access still need to be configured.

Web search, as also explained in my previous article, requires you to create an account with a search provider, get an API key, and paste it here.

The Terminal feature and its setup are a bit more involved and warrant an additional section.

Open WebUI Terminal

The open-terminal GitHub project aims to provide a Python package that exposes a REST API for filesystem interaction and command execution. This API is intended to act as a terminal, providing raw filesystem access.

Docker images with different capabilities are provided in four variants:

latest: A heavyweight 4 GB image with a complete C++, Python, Node.js, and data science library stack, and the default user can run sudo to install additional packages
slim: A production image with only git as an additional tool
alpine: A slim variant based on Alpine, further reducing image size to 230 MB
openshift: A security-context-constrained (SCC) image that further minimizes access rights

Since I already run Open WebUI as a Docker container, configured via a docker-compose.yml file, it is only natural to extend it with an open-terminal section. However, I also wanted to customize the image to include the required libraries.

Custom Image

From the GitHub repository, we only need Dockerfile.slim. Download the repository with this command:

git clone --depth=1 https://github.com/open-webui/open-terminal.git

Then open the Dockerfile and add all additional libraries that are required. For my goal as a Python engineer, pip is required and should be added to the Dockerfile. There is a section for adding custom packages; extend it as follows:

...
RUN apt-get update && apt-get install -y --no-install-recommends \
        python3-pip \
        tini \
        ...

Build the image and provide a custom tag.

docker build -f Dockerfile.slim -t open-terminal-custom-python:20260628 .

Extend Docker Compose File

Add this to the compose file from my Open WebUI setup article.

  open-webui-terminal:
    image: open-terminal-custom-python:20260628
    container_name: open-webui-terminal
    restart: unless-stopped
    env_file:
      - ./open-terminal.env
    volumes:
      - open-terminal:/home/user
    networks:
      - Open WebUI

In the open-terminal.env file, enter the following value with a self-generated secret:

OPEN_TERMINAL_API_KEY=REDACTED

Then start the updated stack with docker compose up. The container logs should show the following:

2026-06-28 17:09:37    ____                    _____                   _             _
2026-06-28 17:09:37   / __ \                  |_   _|                 (_)           | |
2026-06-28 17:09:37  | |  | |_ __   ___ _ __   | | ___ _ __ _ __ ___  _ _ __   __ _| |
2026-06-28 17:09:37  | |  | | '_ \ / _ | '_ \  | |/ _ | '__| '_ ` _ \| | '_ \ / _` | |
2026-06-28 17:09:37  | |__| | |_) |  __| | | | | |  __| |  | | | | | | | | | | (_| | |
2026-06-28 17:09:37   \____/| .__/ \___|_| |_| \_/\___|_|  |_| |_| |_|_|_| |_|\__,_|_|
2026-06-28 17:09:37         | |
2026-06-28 17:09:37         |_|
2026-06-28 17:09:37
2026-06-28 17:09:37   Local:    http://localhost:8000
2026-06-28 17:09:37   Network:  http://172.18.0.3:8000
2026-06-28 17:09:37
2026-06-28 17:09:37   Warning: Listening on all network interfaces.
2026-06-28 17:09:37   Use --host 127.0.0.1 to restrict to this machine.
2026-06-28 17:09:37
2026-06-28 17:09:37   ┌─────────────────────────────────────────────────────────────┐
2026-06-28 17:09:37   │  ⚠  CORS is set to '*' (allow all origins)                 │
2026-06-28 17:09:37   │                                                             │
2026-06-28 17:09:37   │  Any website can make requests to this server.              │
2026-06-28 17:09:37   │  For production, restrict with:                             │
2026-06-28 17:09:37   │    --cors-allowed-origins https://your-domain.com           │
2026-06-28 17:09:37   └─────────────────────────────────────────────────────────────┘
2026-06-28 17:09:37
2026-06-28 17:09:38 INFO:     Started server process[3]
2026-06-28 17:09:38 INFO:     Waiting for application startup.
2026-06-28 17:09:38 INFO:     Application startup complete.
2026-06-28 17:09:38 INFO:     Uvicorn running on http://0.0.0.0:8000 (Press CTRL+C to quit)

Connecting Open WebUI with the Terminal Container

Finally, the Open WebUI instance needs to be configured for access.

Click on the user icon, then on Admin Panel
Click on Integrations, then on the + symbol next to Open Terminal
In the popup dialog, enter http://open-webui-terminal:8000 for a Docker-internal connection, and enter the API key that you generated above
Click on the small rounded-arrows symbol to test the connection, and then on the Save button

The open-terminal Docker container logs should show the following message:

2026-06-28 17:37:15 INFO:     172.18.0.2:55262 - "GET /api/config HTTP/1.1" 200 OK

Agent Task Tryout: Implementing a Python REST API Server App

First Run

In the first test, the agent should create a custom Python project that implements a REST API. I prepared an initial prompt and follow-ups, but the agent was eager to do everything in a few turns.

Input prompt:

The repository should use Poetry for dependency management. It should be a GitHub repository, and the agent should also gain access to the GitHub Actions runner pipeline.

To set this up, the following prompts will be executed one after another.

Define a GitHub project from scratch for a tiny Python agent experiment. Create a repository named python-rest-api with a short README, .gitignore, app/main.py and app/config.json.

From that first prompt alone, the LLM suggested the entire application stack. Here is an excerpt.

  Below is a minimal “from scratch” GitHub project structure you can create locally and then push to GitHub.

  1) Repository root structure

  python-rest-api/
    README.md
    .gitignore
    app/
      main.py
      config.json

  2) Create the files

  README.md

  # python-rest-api

  A tiny Python REST API experiment for a minimal agent workflow.

  ## Run

   python -m venv .venv
  source .venv/bin/activate  # (Windows: .venv\Scripts\activate)
  pip install -r requirements.txt  # if you add dependencies later
  python app/main.py
  Endpoints
  GET /health - health check
 
  app/main.py


  from __future__ import annotations

  import json
  import os
  from http.server import BaseHTTPRequestHandler, HTTPServer
  from pathlib import Path
  from typing import Any


  def load_config(config_path: Path) -> dict[str, Any]:
      with config_path.open("r", encoding="utf-8") as f:
          return json.load(f)


  /...

When asked whether those commands were actually executed, the model answered:

No—I'm describing what to create, but I didn’t actually run your terminal or generate the repo in your filesystem. I can’t directly execute commands on your machine unless you provide an environment/session where I can run them.


What I did instead: I drafted the exact file contents and structure you can create locally, then commit/push.

I learned that the terminal is not enabled by default. In the chat window, there is a small cloud icon that needs to be enabled.

Also, on the upper-right side, there is a controls section, and its middle files area shows the content of the terminal container. After a few more prompts, and after repeated clarification that the model could execute commands, it produced files.

However, it was still difficult to see the output of executed commands. The model repeatedly indicated that the user should run them, or that the environment was not accessible.

The GUI showed:

Example message:

Because in this chat I don’t have access to your running process/network interface to observe the results of the command you executed on your side (the earlier assistant message claimed a run/start, but I can’t reliably capture or retrieve the actual response bytes from your local curl).

In other words:

I can suggest the command and interpret results if you paste them.
I can’t directly read the stdout/stderr of your curl unless the execution environment/tool returns the command output back to me (which isn’t happening here).
If you paste the exact curl output (including the HTTP status line and headers/body), I’ll diagnose immediately.

Similarily, getting the tool to actually run a curl call against the started app required multiple attempts.

This behavior raised an obvious question: did it come from my specific Open WebUI tool and configuration stack, or was it a limitation of the model?

Second Run

For this run, the following aspects were changed:

Base model upgraded to gpt-5.5
Web search capability disabled
Web search and image generation tools disabled

One prompt for the whole app.

Create a repository on /app/projects/python-rest-api with a short README, .gitignore, app/main.py and app/config.json. Implement a REST API service with FastAPI. First, create a requirements file with all required packages. Install the libraries. Then create app/main.py and implement a GET /config route that reads app/config.json from disk and returns parsed JSON. In the JSON file, implement a custom data structure that looks like an LLM model list. Run all commands, show their output.

The model executed it flawlessly.

Done. The repository was created at /app/projects/python-rest-api with:
- README.md
- .gitignore
- requirements.txt
- app/main.py
- app/config.json

Implemented behavior:
- GET /config in FastAPI
- reads app/config.json from disk
- returns parsed JSON
- handles:
- missing file with 404
- invalid JSON with 500

Notes from command output:

- The install step was attempted with python3 -m pip install -r requirements.txt, but this environment does not have pip available: No module named pip
- File creation succeeded, and python3 -m compileall app successfully compiled app/main.py
- The generated config.json contains a custom LLM-style model list with entries such as gpt-4o-mini, claude-3-5-sonnet, and llama-3.1-70b-instruct, plus default_model and object: "list"

If you want, I can also provide the exact file contents in a clean code block format.

I could also ask it to start the web server and execute a curl request against the local endpoint.

From /app/projects/python-rest-api, start the app on port 9000, then run curl against the config endpoints. Show the output of all commands.

Answer:

From the provided context, the app was started successfully on port 9000 from /app/projects/python-rest-api with Uvicorn.

Command
python3 -m uvicorn app.main:app --host 127.0.0.1 --port 9000

Output
INFO:     Started server process 
INFO:     Waiting for application startup.
INFO:     Application startup complete.
INFO:     Uvicorn running on [http://127.0.0.1:9000](http://127.0.0.1:9000) (Press CTRL+C to quit)

Then curl was run against both config endpoints

Command
curl -i [http://127.0.0.1:9000/config](http://127.0.0.1:9000/config) ; echo '---' ; curl -i [http://127.0.0.1:9000/config/](http://127.0.0.1:9000/config/)

Output
HTTP/1.1 200 OK
date: Fri, 03 Jul 2026 16:56:45 GMT
server: uvicorn
content-length: 656
content-type: application/json

{"models":[{"id":"gpt-4o-mini","object":"model","owned_by":"openai","context_window":128000,"pricing":{"input_per_1k_tokens":0.00015,"output_per_1k_tokens":0.0006},"capabilities":["chat","tools","json_mode"]},{"id":"claude-3-5-sonnet","object":"model","owned_by":"anthropic","context_window":200000,"pricing":{"input_per_1k_tokens":0.003,"output_per_1k_tokens":0.015},"capabilities":["chat","vision","tools"]},{"id":"llama-3.1-70b-instruct","object":"model","owned_by":"meta","context_window":131072,"pricing":{"input_per_1k_tokens":0.0009,"output_per_1k_tokens":0.0009},"capabilities":["chat","completion"]}],"default_model":"gpt-4o-mini","object":"list"}

***
HTTP/1.1 307 Temporary Redirect
date: Fri, 03 Jul 2026 16:56:45 GMT
server: uvicorn
content-length: 0
location: [http://127.0.0.1:9000/config](http://127.0.0.1:9000/config)

Summary:

GET /config returned 200 OK with the parsed JSON config
terminal:6351ac...un_command
GET /config/ returned 307 Temporary Redirect to /config
terminal:6351ac...un_command

Conclusion

In this blog post, you learned how to set up a custom coding agent in Open WebUI. Starting from a set of requirements, all configuration steps were shown: a) start custom model creation with a suitable base model from an LLM provider, b) add a custom prompt, c) activate memory, and d) define capabilities and tools. To execute code, an Open Terminal container needs to be added, for which a custom Docker image was built and added to the docker-compose file. The agent was tasked with creating a Python REST API with a single endpoint at /config. In the first run with a gpt-5.4-nano model, the interaction was cumbersome because the model only executed commands after repeated clarification that it could run them. In the second run, with gpt-5.5 as the base model, two one-shot prompts created all files, started the server process, and ran a curl command against the endpoint to test the application. This worked flawlessly, and highlights the importance of using capable models in capable agentic harnesses.

Open WebUI: Admin Configuration Options in a Nutshell

Thu, 01 Oct 2026 00:00:00 +0000

Open WebUI is a universal chat interface with connectivity to local or remote LLM providers, custom files, documents, and a knowledge base, with full customization of model capabilities. Application features are configured both personally for a user account and globally by admin users.

This article continues the exploration of Open WebUI configuration and utilization. Following the extensive coverage of user features and settings, this article provides complete coverage of admin settings. Learn how to provide defaults for base models and connections, web search, and connections to a terminal code execution environment and built-in databases.

The technical context of this article is Open WebUI v0.9.6, published on 2026-06-01. The setup and configuration examples should also work with newer versions.

While I am fascinated by the capabilities of artificial intelligence tools and applications, crafting blog articles remains my personal skill. Every character, number, and symbol in this article was typed manually, with the exception of verbatim copies from log messages and screenshots.

Admin Configuration Entrypoint

The admin user account has access to an additional settings dialog. It can be accessed by clicking the user icon and selecting Admin Panel.

It is structured into four horizontal tabs: Users, Evaluations, Functions, Settings. The Settings area displays a vertical list of configuration items. To better understand when to apply each setting, the following sections group options into coherent lifecycle phases or concerns.

Model Management

Model Definition

With Settings => Models, all base models offered by connected API endpoints are shown. Similar to custom model declarations, all base models can be adjusted with their prompts, knowledge, files, tools, and skills. Base models can also be pinned to the sidebar, hidden or disabled, and their settings exported as a JSON file.

Here is an example export:

[
  {
    "id": "gpt-5-mini",
    "object": "model",
    "created": 1754425928,
    "owned_by": "openai",
    "connection_type": "external",
    "name": "gpt-5-mini",
    "openai": {
      "id": "gpt-5-mini",
      "object": "model",
      "created": 1754425928,
      "owned_by": "system",
      "connection_type": "external"
    },
    "provider": "",
    "urlIdx": 0,
    "is_active": true
  }
]

Model Providers

Open WebUI requires external LLM providers. Via Settings => Connections, different OpenAI API-compatible LLM endpoints and Ollama instances can be configured.

For direct OpenAI API connections, the toggle OpenAI API needs to be active. Then, with the + button next to Manage OpenAI API Connections, additional connections can be set up. Each one requires the following steps:

Enter the API endpoint URL, e.g. https://api.openai.com/v1.
Insert the API key.
Click on the double-arrow icon to validate the connection; a green popup appears to show success.

For Ollama instances, the Ollama API toggle needs to be active too. Similarly, the + button next to Manage Ollama API Connections opens a configuration dialog in which at minimum the URL and authentication details need to be entered, and additionally a prefix and model ID to better distinguish these models once selected.

Two more options exist. The Direct Connections toggle enables non-admin users to add connections too. The Cache Base Model List can improve performance when many connections are defined: available model results are cached locally and are not fetched again every time a user selects a model or a base model for customization.

Model Ratings

All user ratings during chats are correlated per model, and comparison scores are computed. This can help when using custom models to determine their long-term effectiveness. Of course, for all LLM providers, public leaderboards can provide ratings from a much broader audience.

Via the Evaluations tab, or from Settings -> Evaluations, two subfeatures can be accessed.

The Leaderboard is a full list of all configured models and captures individual users’ scores for particular chats. Each chat bubble provides quick feedback via the “Thumbs Up” and “Thumbs Down” buttons. When users regenerate answers and score them, a data point about cross-model scoring is completed. Over time, this private leaderboard should provide valuable insights based on the users’ utilization of Open WebUI for their purposes, and is therefore better fitting than any public leaderboard and its scores.

The Feedback section shows concrete data points rendered as a list. Individual data points can be selected, which opens a popup with the evaluated text snippet and the rating.

Model Capabilities

Web Search

For most use cases, web search is a mandatory requirement for fetching up-to-date information. This feature can be configured via Settings => Web Search.

Internally, the search process is handled by two components. A Web Search Engine processes a search query and returns a list of relevant links, and the Web Loader Engine fetches the links and extracts text.

For the Search Engine, more than 20 different providers can be configured, such as Ollama Cloud, Perplexity, Brave, or Firecrawl. For each of them, a slightly different dialog is shown, containing the authorization information for the service, typically an API key, and other specific options.

The loader engine can be configured as Playwright, Firecrawl, Tavily, or an external endpoint. Options exist for providing embeddings to the results or processing them as-is.

Here is an example of configuring the Brave search engine.

Note that merely configuring web search does not mean the model uses it. It needs to be configured as both a capability and tool access.

Code Execution

Before full privileged code generation and execution by LLMs became a standard feature, Open WebUI offered small-scale code execution inside chats, intended for data processing and data visualization with Python code.

The Settings => Code Execution screen shows two different sections corresponding to individual features: Code Execution activates the selected interpreter instance, and the Code Interpreter toggle enables this capability for models. The settings dialog for both is very similar:

A feature toggle for activation or deactivation.
The Python engine to be used, either Pyodide, which executes WebAssembly directly in your browser, or a connection to a locally running Jupyter Notebook environment.

Content Management

Documents

When a document is added to Open WebUI, e.g. by uploading it into a conversation or when maintaining a knowledge base, its content is parsed, chunked, and stored. The Settings => Documents page provides complex options for this process - here is a screenshot.

Configurable are the following aspects:

Extraction Engine: Choose from third-party OCR providers like Datalab, Mistral OCR, or PaddleOCR, or configure self-hosted instances of Tika, Docling, and MinerU. Instance-specific details, at least a URL and access token, need to be provided too.
Text Splitting: Text can be split by character or token, and the chunk size and overlap can be configured. A toggle for splitting markdown headers is also configurable.
Embedding Engine: The chunks are embedded, which means converted to a vector representation for better semantic search and retrieval. Different engines are configurable: the built-in Sentence Transformers model, a connection to local Ollama, or outbound connections to OpenAI or Azure OpenAI. The concrete embedding model offered by the connection needs to be defined. But take care: Changing the model invalidates all prior embeddings and starts a batch process to reindex all existing documents.
Retrieval: During a conversation, relevant content from the documents is queried and added as context to the LLM. The amount and scope of retrieved documents can be controlled with several settings:
- Full Context Mode: Instead of only sending the highest-probability chunks, the complete document is retrieved. Helpful when the documents themselves are small, and might lose relevance when only parts of them are processed.
- Hybrid Search: When enabled, the internally triggered search combines keyword and semantic search in its vector DB of embedded chunks.
- Reranking Batch Size: A technical setting that determines how many chunks are grouped together during a reranking of results.
- Top K: The absolute number of chunks that are returned.
- RAG Template: The internal system prompt that the model uses to trigger a keyword or semantic search in the vector database.

Images

During a conversation, the intent to generate an image might occur. When configured, Open WebUI sends this request to the configured provider, not the base model of the chat, to generate the images.

The configuration dialog at Settings => Image is separated into two sections for image generation and image editing, as shown in the following picture.

Both sections follow the same set of required inputs:

A toggle to activate the feature.
The image generation engine, which can be OpenAI, ComfyUI, AUTOMATIC1111, and Gemini.
The base URL for the selected provider (upstream provider URL or local endpoint).
An API key for authentication.
The API version that is queried for the image generation or editing request.
Additional parameters are passed as the request body to the configured model.

User Management

The Users section is a complete management interface. New users can be registered with their username, e-mail, and role. Accounts can be added via a pop-up menu or via CSV, which is convenient for large user bases.

For existing users, their chats can be browsed, and a preview of their access rights to models, knowledge, and tools is shown. Their details can be modified, or the account can be deleted.

Other user settings are a bit hidden. In Settings => General, the following options are presented:

User signup: Enable or disable new signups, and determine the default role and group for new users.
Pending users: Following signup, users need to be accepted by another user with admin rights. Admin users see an overlay for pending users, which can be given a custom name and content. Also, the admin e-mail address might be shown to users so that they can contact the admin on their own.
API keys: When this option is enabled, users can generate custom JWT access keys for opening Open WebUI’s internal API to external systems.
LDAP: Instead of managing usernames and credentials inside the Open WebUI internal database, user accounts can also be gathered from a connected LDAP instance. Enabling this feature via its toggle shows a wealth of settings typically required for an LDAP setup.

Plugin Management

For extending Open WebUI, two mechanisms exist: Pipelines, now deprecated and not further explained here, and functions.

The function management GUI, accessible via Settings => Functions, allows you to create, read, update, and delete configured functions.

A complete coverage of functions is outside the scope of this article, but the following overview gives a summary of their capabilities.

Actions: Implement additional buttons that are shown on the chat bubbles and provide additional functions, e.g. for adding a permission grant before code execution, turning text into an image or downloadable audio file, or creating visualizations.
Filters: Modify messages before they are sent to the LLM, or intercept messages from an LLM to the user. Use cases are numerous: general content moderation, e.g. disallowing specific topics, masking personal information, detecting and blocking prompt injections, or rate limiting. Filters can be defined globally, then scoped to specific models, and either automatically applied or shown as a toggle button in chats for user-on-demand activation.
Modify Model Outputs (Outlet Function): Adjust the AI’s response after it is processed, before showing it to the user. This can help refine, log, or adapt the data for a cleaner user experience.
Pipes: When a user chat with a base model or custom model occurs, the back-and-forth of message passing between the chat interface and the LLM provider follows fixed steps. Pipes are an advanced concept that breaks down this fixed structure. They allow the definition of additional LLM providers, or, for that matter, wrap any other service to behave like an OpenAI API, and support custom orchestration between them. With this, intelligent model routing can be built based on the complexity of the conversation. Or imagine a chain of models along which LLM output is passed to validate and enrich an answer before it is passed to the user.
Events: A new feature published with Open WebUI v0.10.0 allows code to run at any of 170 system events such as user login, model definition, chat creation, knowledge database update, and much more. This effectively opens the door to programming Open WebUI’s behavior, enabling automatic routines to be triggered.

General Features & Settings

User Features

In Settings -> General, at the bottom section, a host of general features can be configured.

Most of them are tied to which features users have access to.

Enable Community Sharing: When active, users can export a conversation to the public community page. The granularity and visibility of this export are controlled by four different types: private, public, or public with full history.
Enable Message Rating: This feature enables users to provide feedback to particular answers in a conversation. These ratings provide the basis for the earlier explained evaluation feature.
Folders: Allows users to structure their chats into folders, which helps keep ongoing conversations about different topics organized. A limit on the maximum files per user can be set up too.
Calendar: Enables the user-specific calendar feature, allowing custom entries and programmable event scheduling to trigger automations.
Automations: Automations allow users to trigger predefined instructions with a specific model, effectively starting an asynchronous chat. The toggle enables this feature.
User Webhooks: Webhooks are meant to inform external systems about an event. For users, only one type of event is documented: the completion of a chat_response. The event payload includes the chat ID, title, and last_message. It only triggers for asynchronous, not interactive, user chats.

Additional beta features can be configured too:

Memories: Enables long-term storage of user-specific facts that are injected into each conversation. It is meant for customizing the chat experience and keeps track of personalization, like the preferred user name or conversation tone, and processes recommendations for complex tasks.
Notes: This user feature allows custom text notes to be created and used in chats. It needs to be enabled by the admin.
Channels: This novel feature changes conversation completely. Instead of 1:1 chats between users and an agent, multiple users can join a conversation space, and multiple models can be attached and called. Also see the official documentation about Channels.

Interface Settings

In Settings -> General, following interface settings are exposed.

User Status: This toggle enables active reporting of user status, showing which users are logged in and using the Open WebUI instance.
Response Watermark: In this field, a custom text can be entered, which is appended to each system message, visibly in user chats.
Banners: From time to time, general information for large user bases needs to be shown, for example announcing updates or LLM model deprecations. This feature lets the admin user configure such a banner, which other users can see once they log into the system.

System Settings

The admin user can configure externally visible URLs via Settings -> General.

WebUI URL: When the Open WebUI instance generates events, it includes its public URL string from this field.
Webhook URL: Defines the external WebHook API endpoint to which all system events are sent.

Conversation Features

Open WebUI generates background tasks for generating the conversation title, follow-up questions, tags, RAG, and web search queries.

In Settings => Interface, these tasks can be enabled or disabled, the used model determined (defaulting to the selected model, but can be a fixed light model for cost savings), and open prompt overrides configured.

Also, prompts for autocompletion and tool function calling can be defined, which can be helpful when tool calls are not generated or properly executed.

Speech Settings

In Settings => Audio, several aspects of Speech-to-Text and Text-to-Speech become configurable.

Supported MIME Types: Determines which media MIME types are supported, which means which audio files can be dropped into a chat bubble. The default configuration allows all audio/* and the video/webm format.
Speech-to-Text Engine: Determines the backend service to generate text, which is either: a) Web API, the browser internal engine, b) a local Whisper model, or c) an external provider from OpenAI, Deepgram, Azure AI Speech, or Mistral AI.
Text-to-Speech Engine: The backend service for generating speech, with these options: a) Web API, which is browser internal, b) Transformers (local), which connects to local models published at SpeechT5, or c) one of the external providers OpenAI, ElevenLabs, and Azure AI Speech.
Response Splitting: Configure how natural language pauses are recognized in the source material.

Operations

Database Backup

The Settings => Database dialog is intended for storing or importing the configuration database or settings. Specifically, it offers the following functions:

Configuration: All configuration options are represented in JSON format. The existing configuration can be exported, e.g. to make a permanent backup, and imported. Here is a small excerpt from such a file.

{
  "version": 0,
  "ui": {
    "enable_signup": false
  },
  "openai": {
    "enable": true,
    "api_base_urls": [
      "https://api.openai.com/v1",
      "https://api.openai.com/v1"
    ]
    // ...
  },
  "models": {
    "base_models_cache": false
  },
  "rag": {
    "embedding_engine": "",
    "embedding_model": "sentence-transformers/all-MiniLM-L6-v2",
    "embedding_batch_size": 1,
    "enable_async_embedding": true,
    "embedding_concurrent_requests": 0
    // ...
  },
  "google_drive": {
    "enable": false
  },
  "onedrive": {
    "enable": false
  },
  "terminal_server": {
    "connections": [
      {
        "id": "6351ac6b-cb9e-48d3-bf87-d64da77f93ff",
        "name": "",
        "enabled": true,
        "url": "http://open-webui-terminal:8000"
        // ...
      }
    ]
  },
  "tool_server": {
    "connections": []
  }
}

Database: Exports the internal database that contains the following items:
- User accounts and authentication data.
- Chat history and conversation metadata.
- App settings and configuration (similar to the JSON export).
- Model/config entries.
- File-related records and other system state.
- RAG-related non-vector metadata.
Chats: Exports a JSON document with all chats. Here is a small excerpt.

[
  {
    "id": "88dfd8b0-6758-45d9-bf00-bdc540b2253e",
    "user_id": "b5b63a0d-ab5c-463e-ac3f-5ceacb6f3f94",
    "title": "Daily News Check",
    "chat": {
      "title": "Daily News Check",
      "models": [
        "gpt-4o"
      ],
      "history": {
        "currentId": "4f914f3d-b089-4563-b139-d2562b1d3ad8",
        "messages": {
          "b8051ec5-fa8b-4945-8401-7c5619066d78": {
            "id": "b8051ec5-fa8b-4945-8401-7c5619066d78",
            "parentId": null,
            "role": "user",
            "content": "Check the Daily News, write a summary.",
            "childrenIds": [
              "4f914f3d-b089-4563-b139-d2562b1d3ad8"
            ],
            "timestamp": 1784888705,
            "models": [
              "gpt-4o"
            ]
          }
        }
      }
    }
  }
]

Version Information

In Settings -> General, at the top of various other options, the current version, banners for accessing the project’s Discord server, social media presence, and GitHub repo are shown.

Conclusion

Open WebUI is a highly customizable, multi-provider chat interface. This article explored all settings that the admin user can configure, typically global defaults that other users consume or further customize. You learned about these features: a) model management, b) model capabilities, c) content management, d) user management, e) plugin management, f) General Features & Settings, and g) Operations.

Open WebUI: Complete Guide to User Settings

Mon, 21 Sep 2026 00:00:00 +0000

Open WebUI is one of the first chat interfaces that evolved around LLMs. Initially designed to work with local Ollama models only, it has since evolved to support any OpenAI API-compatible endpoint. With the addition of skills, tools, memory, and the recent ability to execute code with the terminal connection, all features for defining agents are present.

In this blog series, all Open WebUI aspects, from setup to configuration and utilization, are covered. This article explores all user features and settings. Learn about custom model definition, automations, the model playground, and various GUI and model-calling settings.

The technical context of this article is Open WebUI v0.9.6, published on 2026-06-01. The setup and configuration examples should also work with newer versions.

User Settings Entrypoint

The main window of Open WebUI presents a chat interface, a list of past chats, and search capabilities. When clicking on the user icon, a popup is shown, which renders several user features, depicted by 1, and an option to open user settings, depicted by 2.

Each setting group is explored in the next sections.

Note: In an early draft of this article, all features or settings were listed in the order that they appear in the menu. However, grouping them helps to better understand their context.

User Features

Customizable user features determine the extent of functions available in chats. They can be grouped into four sections.

Information and Reflection

Archived Chats

Chats in the “Folder” sections or under the “Chats” section can be archived. This option shows all archived chats, from which they can be restored, exported, or permanently deleted.

Documentation

This menu entry is a direct link to the documentation page docs.openwebui.com.

Releases

Similarly, this opens the GitHub releases page with details of all Open WebUI releases.

Keyboard Shortcuts

Displays a graphical overview of all defined keyboard shortcuts.

Personal Documents

Notes

Opens a list of all stored notes and allows editing or creating notes with a text editor. This feature was extensively covered in my previous article about Open WebUI features.

Calendar

Renders a browsable calendar in which events can be scheduled. Calendars can be shared between users, and model access can be enabled. Based on current findings, the calendar data remains disconnected from other calendar platforms, requiring duplication of content.

Here is an overview of a calendar with scheduled automations.

Model Customization

Workspace

This rather misnomered menu exposes all options to define custom models that can be used for chats or even agentic use. It shows vertical menus that allow the customization of these aspects:

Models: Provides a full list of all defined models by the configured model provider, and allows you to customize them or define your own models that use a base model. Each model can have custom system prompts, tools, skills, and capabilities.
Knowledge: This section manages individual collections of documents termed knowledge bases. Each should have a definite name, description, and then a set of text, PDF, or CSV documents. Uploads are parsed automatically and vectorized so that they can be used as context for a model.
Prompts: Manage reusable prompts that serve as a strong context for an LLM. The menu allows users to add, edit, and even browse prompts for the community, which can be imported too. In Open WebUI, prompts are invoked by a preceding /.
Skills: Precise instructions, typically in the form of how to break down a complex goal into individual tasks. The GUI for this element allows the same CRUD operations as the others. To invoke them, the $ prefix needs to be used.
Tools: Python snippets with a predefined structure that can be invoked by the Open WebUI server directly. Since they run with the current user permissions, tools should be checked rigorously to ensure that they work as intended. Tools extend the capabilities of an LLM, and when used, Open WebUI injects tool definitions so that a sufficiently modern LLM can issue tool calls automatically, which Open WebUI executes.

Model Utilization

Automations

Automations are chat messages triggered at a specified time or interval. An automation includes instructions, a model (and therefore custom prompts, skills, and tools), and optionally a terminal server where code can be executed. Automation runs result in the same chat structure as user chats.

Playground

An admin-only feature that allows experimentation with how different system prompts affect models. When using an Ollama backend, model parameter calls can also be adjusted. Advanced features such as tool calls or providing chat context from external sources are not supported.

User Settings

User settings are displayed as a popup overlay. A list of settings and a search bar appear on the left, while the configuration panel for the selected option appears on the right.

Options are extensive and are explained in their individual sections.

Account Settings

In the Account group, customization like name, user icon, background information, birth date, and the ability to change the login password are provided.

GUI & Interface Settings

Several different sections contribute to this group.

The General section allows a mixed set of configuration options. Related to the GUI are the theme, the language, and whether to show notifications or not.

In the Interface section, a large number of options are rendered.

UI & Notifications: Scale, notification sounds, and haptic feedback options when Open WebUI is accessed on mobile phones.
Chat: Chat bubble design, custom background, fading effect for streaming tokens, markdown formatting, quick action buttons.
Chat automation: Title generation, follow-up generation, tag generation.

Here is an example of a custom chat interface with a changed background image:

The Audio menu item handles how speech-to-text and text-to-speech are handled. For speech-to-text, the default engine is a local Whisper model, and for text-to-speech, the community project kokoro.js can be used. For readout, different voice sets can be selected.

Model Settings

The General section also exposes two settings that apply to all model invocations. First, a system prompt override can be configured, prepending any conversation. Second, several parameters for calling models can be defined, such as temperature (randomness factor), top_k, top_p, min_p (to influence token likelihood), and others. They are forwarded completely in API calls to a locally connected Ollama instance, and some of them are also used for configured OpenAI API connections, given that the provider accepts them.

Here is a screenshot of the available settings.

Additionally, the Personalization setting features only one entry: Memory. Flagged as an experimental feature, these are user-specific facts that serve as permanent context for all invocations. It supplements conversation history and other context sources. By default, they need to be added manually. When advanced models capable of function calling are used, they may gain access to the memory tool.

Tools

The Integrations section allows user chats to access external systems. Two specific categories exist.

Manage Tool Server: Connect to OpenAPI-compatible tool servers, which integrate external system access and content. Implementations need to follow specific framework definitions implemented in Python. See, for example, the SQL server.
Open Terminal: Connect to a Docker container that serves as a sandbox for file access and code execution. It is a specific custom Docker image prepared by Open WebUI, with a curated set of tools. See the official GitHub repository open-terminal.

Information & Reflection

In Data Controls, broad import and export functions for chats are exposed. Also, archived and starred chats can be managed, which renders a list of items that can be restored or permanently deleted. Likewise, all uploaded images or files can be seen and optionally deleted.

The About section shows information and badges to access the Discord, X, and GitHub accounts of Open WebUI.

Conclusion

Open WebUI evolved from local Ollama to a multi-provider OpenAI API connection with full customization of the chat experience, including custom models, tools, skills, and local documents. This article explored the many user features and settings. You learned about four different user feature groups: a) Information and Reflection to access archived chats, documentation, releases, and keyboard shortcuts, b) Personal Documents to browse notes and a built-in calendar, c) Model Customization with base models, knowledge bases, prompts, tools, and skills, and d) Model Utilization, in which a playground for non-stored interactions and automations are provided. The user settings can be grouped into a) Account, b) GUI and Interface, c) Model, including parameters like a model’s temperature or token likelihood values, d) Integrations that connect to tool servers or a terminal, a custom Docker container in which arbitrary code can be executed, and e) Information, with access to archived chats, files, and images, and general release information.

Open WebUI: Chat Interface & Context Options

Thu, 10 Sep 2026 00:00:00 +0000

Open WebUI is one of the first tools that appeared in conjunction with Large Language Models. Initially intended as a tool for chatting with a connected local Ollama instance, it evolved to work with any OpenAI API provider and succinctly extended its features to support agentic chats.

Following the setup of Open WebUI in my previous post, this article explores its core features. Learn about conversation essentials, see how notes and knowledge bases are created, and understand the different options to provide chat context.

The technical context of this article is openwebui v0.9.6, published on 2026-06-01. The setup and configuration examples should also work with newer versions.

Open WebUI Startpage

Open WebUI’s start page shows organizational features in the menu list on the left side, and a chat interface to start a new conversation on the right side.

In this view, the following options can be accessed:

New Chat: Reloads the current window with a new chat on the right panel side
Search: Searches for keywords in past conversations and also allows starting a new conversation or creating a new node
Notes: Create markdown-structured files that serve as structural content for your conversations
Workspace: Create customized models with a base model, prompts, tools, and knowledge bases
Folders: Structure individual chats into topics by either clicking on a folder and starting a new chat or by dragging and dropping an existing chat into the folder
Chats: A list of past interactions
User Icon: Access additional settings specific to the user

Features related to the chat interface are explored in the next sections.

Basic Chat Features

Chatting is the core user interaction feature of Open WebUI. As it has become a de facto standard, chat bubbles from the user and model are displayed top-down, right- and left-aligned respectively. For the latest model answer, all interaction icons are shown, as well as a list of follow-up prompts.

When hovering over a user chat bubble, the following functions are shown:

Edit: Changes the content of the message but does not trigger a new answer generation from the model
Copy: Puts the message content into the computer’s clipboard
Delete: Deletes this message and the immediately following LLM answer

The model answer bubble offer these features:

Edit: Opens an inline editor to modify the LLM answer and, when saved, persists this answer to the internal chat log
Copy: Copies the complete message, including its formatting, to the computer’s memory
Read aloud: Starts the browser’s text-to-speech integration to read the answer
Good Response & Bad Response: Rate a particular LLM answer, see below for an explanation
Continue Response: Sends the user message and the assistant message again, which can extend the original answer
Regenerate: Recreates the selected answer by passing all previous conversation context to the LLM again once completed, the new answer is shown to the user and saved in the conversation history

An interesting feature is the option to rate the answer, called “Good Response” and “Bad Response”. When clicked, a dialog is opened at the top of the screen where a numerical rating and a short tag can be provided. This data is stored in your Open WebUI instance, and admin users can access analytics and evaluation dashboards that factor in these answers. Ratings are useful for a large user base and model availability, helping to determine which models are perceived as most helpful for their intended tasks. Here is a screenshot for rating an unhelpful answer.

Additionally to storing locally, you can also add a public review of this model which is published on the Open WebUI model rating page, where you can provide a review for this specific model.

Notes

Notes are named files stored internally in your Open WebUI instance.

The notes menu shows a list of browsable and searchable notes, and you can add a new note or open an existing one.

The note editor provides standard text formatting including headings, lists, tasks, bold and italic fonts, and code blocks. Note content can be recorded from an audio message, and a model can be invoked to edit the content directly. The complete note can also be exported to other formats and even a link can be generated. Here is a screenshot.

Notes can be used in chats in three different ways: a) directly in the note editor, you can start a chat with the note, b) in a chat by adding the note, c) when an advanced feature called terminal - a separate runtime in which code can be executed - is available, tool calls like search_notes or write_note can access notes dynamically.

Workspace Knowledge

Workspaces are a powerful feature that governs support for agentic usage. In the context of this article, only knowledge bases as context to chats are explored.

Follow these steps:

In the main GUI click on Workspace
In the horizontal menu area click on Knowledge and then on the button + New Knowledge
Fill in the following form then click on Create Knowledge

This results in a new screen showing a list of sources. With the + symbol, the knowledge base can be edited.

New original resources can be added with these options:

Upload files: Upload files from your computer supporting text documents PDF DOC and CSV files but not images
Upload directory: Select a local directory which triggers individual file uploads for all of its contained and supported files
Add webpage: Process the provided HTTP resource extract its text content and store it note be sure to add an address for which no HTTP redirect occurs or otherwise the redirect information will be stored instead
Add text content: This option opens an editor field into which you can paste any text information

The structure and content of the knowledge base can be altered as follows:

New directory: Create a logical node to help structure documents
Sync directory: Rescans an uploaded directory which removes any files from the knowledge base that are no longer present and adds all new or modified sources
Reset: Completely deletes all stored content from the knowledge base

When documents are added to the knowledge base, the same process is triggered: text is extracted from the sources, split into content chunks, processed by an embedding model, and stored in an internal database.

Here is a screenshot of a knowledge base that includes my blog articles about Claude Code.

Providing Chat Context

Open WebUI offers several options to provide context to your chat interactions.

Here is a screenshot where a note is already attached and additional sources can be added.

Original Documents

New information is injected into the conversation as follows:

Upload files: Supported documents are parsed and their full content attached to the next message
Capture: Opens the browser’s function to make a screenshot of specific windows or the entire screen
Attach Webpage: Provide an HTTP link as a document source from which plain text information will be obtained and added to the message sent to the LLM endpoint

Two aspects should be noted:

Automatic embedding: Open WebUI automatically detects the data format determines token splitting and embedding for text processes and stores these files This results in typical log messages as shown

open-webui  | {"ts": "2026-06-21T08:16:49.769+00:00", "level": "info", "msg": "192.168.65.1:45505 - \"POST /api/v1/files/?process=true HTTP/1.1\" 200", "caller": "uvicorn.protocols.http.httptools_impl:send:483"}
open-webui  | {"ts": "2026-06-21T08:16:51.487+00:00", "level": "info", "msg": "192.168.65.1:45505 - \"GET /api/v1/files/db47a1a8-3f19-4a5c-afcd-1cdb056306c1/process/status?stream=true HTTP/1.1\" 200", "caller": "uvicorn.protocols.http.httptools_impl:send:483"}
open-webui  | {"ts": "2026-06-21T08:16:51.518+00:00", "level": "info", "msg": "Using markdown header text splitter", "caller": "open_webui.routers.retrieval:save_docs_to_vector_db:1412"}
open-webui  | {"ts": "2026-06-21T08:16:51.521+00:00", "level": "info", "msg": "generating embeddings for file-db47a1a8-3f19-4a5c-afcd-1cdb056306c1", "caller": "open_webui.routers.retrieval:save_docs_to_vector_db:1490"}
Batches: 100%|██████████| 16/16 [00:02<00:00,  7.88it/s]
open-webui  | {"ts": "2026-06-21T08:16:53.569+00:00", "level": "info", "msg": "embeddings generated 16 for 16 items", "caller": "open_webui.routers.retrieval:save_docs_to_vector_db:1536"}
open-webui  | {"ts": "2026-06-21T08:16:53.570+00:00", "level": "info", "msg": "adding to collection file-db47a1a8-3f19-4a5c-afcd-1cdb056306c1", "caller": "open_webui.routers.retrieval:save_docs_to_vector_db:1548"}
open-webui  | {"ts": "2026-06-21T08:16:53.840+00:00", "level": "info", "msg": "added 16 items to collection file-db47a1a8-3f19-4a5c-afcd-1cdb056306c1", "caller": "open_webui.routers.retrieval:save_docs_to_vector_db:1554"}
open-webui  | {"ts": "2026-06-21T08:16:53.840+00:00", "level": "info", "msg": "added 1 items to collection file-db47a1a8-3f19-4a5c-afcd-1cdb056306c1", "caller": "open_webui.routers.retrieval:process_file:1730"}

Session specificity: Documents are used for one turn in the chat conversation only meaning one message to and from the LLM Later user messages cannot implicitly reference an already added document from earlier messages However Open WebUI itself can query uploaded documents and extract relevant content Here is an example log message where I uploaded a blog article and asked about its content

open-webui  | {"ts": "2026-06-21T08:34:27.873+00:00", "level": "info", "msg": "query_doc:result [['1c2776cd-b009-4d43-b20e-7f400b31269d', '08ea65ce-4c62-42f0-a897-6d2cbc0e2bd1', 'ae5f230c-ad8b-41a2-8d43-eaeedd75db99']] [[{'source': 'claude01_introduction.md', 'start_index': 2434, 'hash': '3e1955b782967e3d3ba5eed557e3c6a1de1b7c930b8267bd8ad76c122d5834c6', 'file_id': 'db47a1a8-3f19-4a5c-afcd-1cdb056306c1', 'embedding_config': \"{'engine': '', 'model': 'sentence-transformers/all-MiniLM-L6-v2'}\", 'created_by': 'b5b63a0d-ab5c-463e-ac3f-5ceacb6f3f94', 'name': 'claude01_introduction.md'}, {'embedding_config': \"{'engine': '', 'model': 'sentence-transformers/all-MiniLM-L6-v2'}\", 'created_by': 'b5b63a0d-ab5c-463e-ac3f-5ceacb6f3f94', 'source': 'claude01_introduction.md', 'start_index': 1753, 'name': 'claude01_introduction.md', 'file_id': 'db47a1a8-3f19-4a5c-afcd-1cdb056306c1', 'hash': '3e1955b782967e3d3ba5eed557e3c6a1de1b7c930b8267bd8ad76c122d5834c6'}, {'hash': '3e1955b782967e3d3ba5eed557e3c6a1de1b7c930b8267bd8ad76c122d5834c6', 'file_id': 'db47a1a8-3f19-4a5c-afcd-1cdb056306c1', 'embedding_config': \"{'engine': '', 'model': 'sentence-transformers/all-MiniLM-L6-v2'}\", 'start_index': 721, 'created_by': 'b5b63a0d-ab5c-463e-ac3f-5ceacb6f3f94', 'source': 'claude01_introduction.md', 'name': 'claude01_introduction.md'}]]", "caller": "open_webui.retrieval.utils:query_doc:285"}

Stored Documents and Knowledge Base

When adding existing information, several types of documents can be used:

Attach Files: When a user uploads any file, it will be stored in a user specific file instance and therefore can be attached again in any following chat
Attach Notes: Choose from any created note that is added as message context
Attach Knowledge: Attach the complete knowledge database from a workspace
Reference Chats: Add a complete conversation as context It includes all user messages system messages and any other added context

Conclusion

Open WebUI is one of the first tools that offered a chat interface to LLMs. This article explored its core features. You learned about, a) the start page, b) the main chat features for user and system messages, including editing, reading, regenerating and rating answers, c) how to create individual note files or d) complete document collections called knowledge bases, which can include different document types or web pages, and e) providing chat context with original documents and already uploaded document notes or knowledge bases.

LLM Agent Tools: Setup & Installation of OpenWeb UI

Tue, 01 Sep 2026 00:00:00 +0000

LLMs are a fascinating technology. Trained on a sufficient subset of the public internet and other curated sources, they are knowledge experts in many fields. Chat interfaces for LLMs have become a daily helper for many knowledge workers. Step by step, agent capabilities are driving the evolution of these interfaces.

In an ongoing series about agentic tools, capabilities, and technical components, the next articles focus on Open WebUI. This article is concerned with the initial setup - you will learn how to install and run a Docker container, and see how to connect with an LLM provider to start chatting.

The technical context of this article is openwebui v0.9.6, published on 2026-06-01. The setup and configuration examples should also work with newer versions.

Setup

Any software needs the required libraries in specific versions. To avoid cluttering one’s own system, container-based software can be used instead. Each container provides a separate environment, and it exposes its services via defined ports. Docker is the primary tool for starting containers, and it is the tool of choice for setting up agentic tools in the context of this article.

For Open WebUI, complete Docker containers for all releases are published automatically. Check the available tags, then download the required container. For v0.9.6, execute the following command:

docker pull ghcr.io/open-webui/open-webui:v0.9.6

Once the image is downloaded, it can be started with a simple follow-up command. If you want to try Open WebUI with the default config, simply run the following:

docker run -d -p 3000:8080 -v open-webui:/app/backend/data --name open-webui ghcr.io/open-webui/open-webui:v0.9.6

Then access the application at http://localhost:3000 and start configuring the admin account. While you can use the container as-is, its state will not be persisted. When the Docker daemon of your host system is restarted, all data in the container is lost. The recommended approach is to define a docker-compose.yml file, which tracks the applied configuration options and also persists the created data as a volume.

Docker Compose Configuration

Open WebUI exposes several configuration options. To keep the state persistent, it should be started with a config file to define aspects like its users and LLM configuration. It should also have a volume in which all permanent data is stored so it survives container restarts.

Create the following file structure:

.
├── docker-compose.yml
└── .open-webui.env

Use the following template for the docker-compose.yml file as a kickstart.

name: openwebui

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:v0.9.6
    container_name: open-webui
    env_file:
      - ./open-webui.env
    ports:
      - "3000:8080"
    restart: unless-stopped
    volumes:
      - open-webui-data:/app/backend/data
    networks:
      - openwebui

networks:
  openwebui:
    name: openwebui
    external: true

volumes:
  open-webui-data:
    name: open-webui-data
    driver: local

Next, add the following .open-webui.env file with a minimal configuration:

OPENWEBUI_PORT=3000

Only once, you need to run the following command:

docker network create openwebui

Then start the container with the following command:

docker compose up open-webui

It should print these log messages, indicating a successful initial setup.

docker compose up open-webui

open-webui-manual  | No WEBUI_SECRET_KEY environment variable set, loading from file.
open-webui-manual  | Generating new WEBUI_SECRET_KEY...
open-webui-manual  | Loading WEBUI_SECRET_KEY from .webui_secret_key
...
open-webui-manual  | INFO  [alembic.runtime.migration] Context impl SQLiteImpl.
open-webui-manual  | INFO  [alembic.runtime.migration] Will assume non-transactional DDL.
open-webui-manual  | INFO  [alembic.runtime.migration] Running upgrade  -> 7e5b5dc7342b
...
open-webui-manual  |
open-webui-manual  |  ██████╗ ██████╗ ███████╗███╗   ██╗    ██╗    ██╗███████╗██████╗ ██╗   ██╗██╗
open-webui-manual  | ██╔═══██╗██╔══██╗██╔════╝████╗  ██║    ██║    ██║██╔════╝██╔══██╗██║   ██║██║
open-webui-manual  | ██║   ██║██████╔╝█████╗  ██╔██╗ ██║    ██║ █╗ ██║█████╗  ██████╔╝██║   ██║██║
open-webui-manual  | ██║   ██║██╔═══╝ ██╔══╝  ██║╚██╗██║    ██║███╗██║██╔══╝  ██╔══██╗██║   ██║██║
open-webui-manual  | ╚██████╔╝██║     ███████╗██║ ╚████║    ╚███╔███╔╝███████╗██████╔╝╚██████╔╝██║
open-webui-manual  |  ╚═════╝ ╚═╝     ╚══════╝╚═╝  ╚═══╝     ╚══╝╚══╝ ╚══════╝╚═════╝  ╚═════╝ ╚═╝
open-webui-manual  |
open-webui-manual  |
open-webui-manual  | v0.9.6 - building the best AI user interface.
open-webui-manual  |
open-webui-manual  | https://github.com/open-webui/open-webui
open-webui-manual  |

Two options exist for the initial onboarding; see the next two paragraphs.

Manual Onboarding

The first step is to create an admin account. Access the application at http://localhost:3000 and fill out the shown fields.

Once completed, you will see the initial welcome message and a popup showing current version information. While manual onboarding is an option, the better approach is to extend the .open-webui.env file so that the admin account and other settings are controlled and persisted between container restarts. This is explained in the next section.

Onboarding with Config File

Alternatively to the dialog-based setup, settings about the admin user and additional variables to influence privacy and telemetry can be configured. The list of supported variables is extensive; see the official documentation for all options.

What you should also persist is the WEBUI_SECRET_KEY. Its value is used to encrypt JWT access tokens and stored secrets. As shown in the container start logs, its value is dynamically created. Therefore, restarting the container invalidates current sessions and also makes encrypted data obsolete. Check the file content of /app/backend/.webui_secret_key, and add it too.

Here is the extended .open-webui.env with all options.

# Port, persistence, logging
WEBUI_URL=http://localhost:8080
ENABLE_PERSISTENT_CONFIG=True
GLOBAL_LOG_LEVEL=INFO
LOG_FORMAT=json
WEBUI_SECRET_KEY=REDACTED

# Only allow one pre-configured admin user
WEBUI_ADMIN_NAME=Admin
WEBUI_ADMIN_EMAIL=REDACTED
WEBUI_ADMIN_PASSWORD=REDACTED
ENABLE_SIGNUP=False
ENABLE_LOGIN_FORM=True
ENABLE_PASSWORD_AUTH=True
ENABLE_PASSWORD_CHANGE_FORM=True

# Better privacy
ENABLE_ADMIN_ANALYTICS=False
ENABLE_PUBLIC_ACTIVE_USERS_COUNT=False
ENABLE_USER_STATUS=False
ENABLE_EASTER_EGGS=False
ENABLE_OTEL_LOGS=False

Now restart the container once, and from then on all settings persist.

docker compose restart open-webui

A warning: all of these variables, and additional changes in the GUI, are persisted. To reset, for example, the login values, stop the container, set ENABLE_PERSISTENT_CONFIG=True, then restart it. If there is a further problem, you can also set RESET_CONFIG_ON_START=true to delete the database, or take the final option to completely delete the Docker container and the volume.

Model Configuration

To use Open WebUI for its intended purpose, you need to add an LLM provider endpoint. Essentially, any endpoint that supports the OpenAI API format can be used. Besides OpenAI itself, you can choose from any direct provider, OpenRouter, or even GitHub Copilot with an additional proxy server.

For brevity, let’s invoke the ChatGPT API directly.

First, create an OpenAI API key as follows:

Log in to the OpenAI service
Go to the API key page
Click the “+ Create New Secret Key” button, provide a name, and copy the key from the popup

Second, configure the endpoint in Open WebUI:

Access the Open WebUI dashboard
Click on the admin user icon in the bottom-left corner, and then click “Admin Panel”
In the horizontal tab bar, click “Settings,” then “Connections”
Disable all toggles from the bottom up
Enable the “OpenAI API” toggle
Click the “+” symbol next to “Manage OpenAI API Connections”

Now, the following dialogue should appear.

For the API endpoint URL, enter https://api.openai.com/v1
Enter your created API key
Click on the double-arrow icon to validate the connection; a green popup appears to show success

Finally, you can start a new chat from the dashboard.

Conclusion

Many tools exist for ongoing, contextual conversations with an LLM. Open WebUI is one of the earliest tools to support contextual conversations with LLMs. Since its inception in October 2023, many features were added. In this article, you learned how to set up and configure the tool as a Docker container with defined, persisted config. You saw the relevant docker-compose.yml and .env file, learned about the nuances of onboarding, the consequences of not persisting the central encryption key, and how to configure an LLM provider. The next article continues the feature exploration.