Stories by Sebastian on Medium

LiteLLM: Model and Key Management

Sebastian — Thu, 12 Nov 2026 07:01:02 GMT

LiteLLM is a versatile LLM proxy server. It provides developers with a single service that accepts OpenAI and Anthropic API requests and forwards them to the configured models. It supports rolling budgets and cost tracking to prevent unrestricted token consumption. It also provides observability into external LLM usage.

Following the deployment options and local setup described in the previous article, this article focuses on model and key management. It provides a concise overview of the API routes and organizes the available request parameters into logical groups. Specifically, it covers model definitions, health checks, and key configuration.

The technical context of this article is litellm v1.94.1, published on 2026-07-31. Setup and configuration examples should work with newer versions too.

The background material for this article stems from the official LiteLLM documentation, specifically the pages Model Management, Health Checks, and Virtual Keys.

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.

This article originally appeared at my blog admantium.com.

Model Management

One of the fundamental configuration items that any LiteLLM proxy administrator deals with is the model provider. For any upstream model, a configuration item can be added that encapsulates its access, parameters, routing rules, and much more.

API Structure and Properties

The API provides routes for managing individual models or access groups, which are sets of models. API operations can be divided into the following categories:

Create

POST /model/new
POST /access_group/new

Read

GET /{v1/}/models
GET /{v1/}models
GET /{v1/|/v2/}model/info
GET /model_group/info
GET /access_group/list
GET /access_group/{access_group}/info

Update

POST /model/update
PATCH /model/{model_id}/update
PUT /access_group/{access_group}/update

Lifecycle

POST /model/block
POST /model/unblock

Delete

POST /model/delete
DELETE /access_group/{access_group}/delete

Another set of API routes is concerned with the internal model hub feature, such as GET /public/model_hub. The API documentation lists these routes as part of model management. They are omitted here to stay focused on provider model activation.

The parameters for model creation are both slim and expansive. They are slim because only model_name, model_info, and litellm_params are required. They are expansive because litellm_params lists more than 100 different parameters that are provider-specific, provider-agnostic, or internal to LiteLLM; no distinction is made in the official Swagger documentation. Here is an attempt to group them semantically:

Provider authentication: Essential parameters such as the API base, API version, credentials, and region information (api_base, api_version, api_key)
LiteLLM credentials: Instead of defining the LLM provider credentials verbosely, an ID for an existing stored credential can be provided (litellm_credential_name, litellm_trace_id)
Price information / Tokens: Input, output, and cache-hit prices per token or per 100,000 tokens (input_cost_per_token, output_cost_per_token, cache_read_input_token_cost)
Price information /Multimodal models: Pricing information for working with images, audio, and video (input_cost_per_image, input_cost_per_image)
Proxy: Controls whether other proxies are involved in cascading provider API resolution and which authentication method to use (use_litellm_proxy, use_xai_oauth)
API throughput: Controls internal file-size limits, whether to allow pass-through when making external requests, and which type of external API to use (max_file_size_mb, use_in_pass_through, use_chat_completions_api)
Embeddings: Configures the logical vector shape and which vector store to use when writing to or reading from vector stores (output_vector_size, vector_store_id, milvus_text_field)
Routing / Auto: An interesting concept involving a policy-like declaration of how model requests reach their intended or reflected provider (auto_router_config_path, auto_router_default_model, auto_router_embedding_model)
Routing / Complexity: Rule sets that determine a weighted assumption about request content to drive routing (complexity_router_config, complexity_router_default_model)
Routing / Adaptive: Dynamic routing based on live data about costs, performance, or the measured quality of answers (adaptive_router_config, adaptive_router_default_model, quality_router_config)
Routing / Operational controls: Provides absolute token-based limits, API retries, and more (tpm, rpm, max_retries)
Metadata: Documents additional fields such as descriptions, labels, and model classifications, which can be used as placeholder values in other configuration options (model_info, tags, tag_regex)

Model Definition Example

Model declaration follows two patterns: at startup, models are present in configuration files; at runtime, they are added through the GUI or by invoking specific API endpoints.

For the first option, the canonical litellm-config.yml file can be extended. Here is an example that declares (at the time of writing novel) GPT 5.6 models:

model_list:
  - model_name: gpt-5.6-luna
    litellm_params:
      model: openai/gpt-5.6-luna
      api_key: os.environ/OPENAI_API_KEY
  - model_name: gpt-5.6-terra
    litellm_params:
      model: openai/gpt-5.6-terra
      api_key: os.environ/OPENAI_API_KEY
  - model_name: gpt-5.6-sol
    litellm_params:
      model: openai/gpt-5.6-sol
      api_key: os.environ/OPENAI_API_KEY

Adding a model through the API can be done with this command:

curl -X POST "http://0.0.0.0:4000/model/new" \
    -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
    -H "Content-Type: application/json" \
    -d '{
      "model_name": "gpt-5-pro",
      "litellm_params": {
        "model": "openai/gpt-5-pro",
        "api_key": "os.environ/OPENAI_API_KEY"
      }
    }'

And the response:

{
  "model_id": "b8f3dedc-ed78-4531-a805-dc54ba4aff7e",
  "model_name": "gpt-5-pro",
  "litellm_params": {
    "model": "o2K565rjul8ofeW5pKuHD1vQpi2lxBuHXiRV-vsD5TeDlxN7bkvnyNGf7IubKSlQ9oWhgnYCvHE=",
    "api_key": "xTxk2kljn1JiEjxeu8xhfhFOnEQ_9b7GJE2Yz4Xa-Nn0G9I3C5wXsZnfH67zYugWjq6qGN91BTQnJXdnuJ77qgo=",
    "use_xai_oauth": false,
    "use_litellm_proxy": false,
    "use_in_pass_through": false,
    "merge_reasoning_content_in_choices": false
  },
  "model_info": {
    "id": "b8f3dedc-ed78-4531-a805-dc54ba4aff7e",
    "db_model": false
  },
  "blocked": false,
  "created_at": "2026-08-01T12:32:10.585000Z",
  "created_by": "default_user_id",
  "updated_at": "2026-08-01T12:32:10.585000Z",
  "updated_by": "default_user_id"
}

The origin of models is shown in the GUI. Models from a configuration file display a closed-lock symbol. They are effectively immutable: the GUI does not allow edits, and API calls return an error code indicating that no changes are accepted.

Model Health Checks

External providers offer LLMs through their managed infrastructure. Even the original providers, OpenAI and Anthropic, can sometimes experience service degradations or outright downtime.

With LiteLLM, health checks for specific models can be configured. Applications and tools connected to LiteLLM will only be served healthy endpoints. For handling unavailable models, model aliases can be configured, but they must be explicitly requested by the application, or a fallback policy can be defined and applied.

To apply health checks and view their results graphically, open the Models + Endpoints section through the dashboard, then select Health Status from the horizontal menu.

The alternative API call is as follows:

curl "http://0.0.0.0:4000/health?model=gpt-5.6-luna" \
    --header "Authorization: Bearer $LITELLM_MASTER_KEY"

{
  "healthy_endpoints": [
    {
      "custom_llm_provider": "openai",
      "use_in_pass_through": false,
      "use_litellm_proxy": false,
      "use_xai_oauth": false,
      "merge_reasoning_content_in_choices": false,
      "model": "gpt-5.6-luna",
      "max_tokens": 16,
      "cache": {
        "no-cache": true
      },
      "x-ratelimit-remaining-requests": "499",
      "x-ratelimit-remaining-tokens": "199994",
      "model_id": "e4a50849-1dae-47fd-8759-a71f175b11dd"
    }
  ],
  "unhealthy_endpoints": [],
  "healthy_count": 1,
  "unhealthy_count": 0
}

Health checks are applied whenever a model is requested. As a large model catalog could create a substantial number of health checks, this behavior can be turned off so that only explicit checks through the API endpoint trigger a status update. The following snippet needs to be placed in the configuration file:

general_settings:
  background_health_checks: false

Key Management

With a catalog of defined and configured models, LiteLLM virtual keys govern and control access to its proxy API routes and, therefore, to external connections.

API Structure and Properties

For managing keys, the following API routes are essential:

Create

POST /key/generate
POST /key/service-account/generate

Read

GET /key/info
GET /key/list
GET /key/aliases

Update

POST /key/update
POST /key/bulk_update
POST /team/key/bulk_update

Lifecycle

POST /key/regenerate
POST /key/{key}/regenerate
POST /key/{key}/reset_spend
POST /key/block
POST /key/unblock
POST /key/health

Delete

POST /key/delete

Keys are fundamental. The complete set of API parameters for keys encompasses more than 50 fields, divided into the following aspects:

It is important to bear in mind that key ownership defined through roles in LiteLLM grants permissions only for CRUD operations on the key itself. The encoded key’s access to models, routes, and budgets remains unchanged, so any person or system with the key credential can use it to access the proxy’s API routes.

Identity: Keys are alphanumeric character sequences. Their creation results in a random value with a defined pattern, but a value can also be explicitly set (key, key_alias)
Ownership: Keys can belong to users, teams, or organizations, or they can be defined as service accounts (user_id, team_id, organization_id)
Model management: The available models for a specific key default interestingly to all models, but they can be restricted by defining model names or key aliases; in the case of group ownership, these restrictions are also inherited (models, aliases)
Access management: Provides total or restricted access to LiteLLM API routes (llm_api, management, read_only), or can construct sets of explicitly named paths (allowed_routes)
Usage restrictions: Limits key applicability through required request parameters (enforced_params, prompts), or can temporarily disable a key altogether (block)
Budget management: Defines absolute or rolling periods of available budgets when using associated models (max_budget, budget_duration, budget_fallbacks)
Rate limits: Defines throughput barriers that consistent usage cannot violate (rpm_limit, tpm_limit, max_parallel_requests)
Guardrails: Safeguards input, output, and tool-call content (guardrails, policies)
Information and status: Sets additional identifiable information for keys (metadata, tags), or controls whether key creation leads to notifications (send_invite_email)
Lifecycle: Defines automatic key rotation (auto_rotate, rotation_interval)

Key Generation Example

Keys can be added through the GUI and the API. Management through the API should be preferred: not only is the full set of options available, but the specificity of inputs can also be persisted in version control systems, allowing for controlled and audited changes.

Key creation through the GUI was covered in my previous article getting started with LiteLLM.

Through the API, new keys are created through the /key/generate and /key/service-account routes. Here is an introductory call that includes all the attributes covered so far:

> curl -X POST "http://0.0.0.0:4000/key/generate" \
    --header "Authorization: Bearer $LITELLM_MASTER_KEY" \
    --header "Content-Type: application/json" \
    --data-raw '{
      "key_alias": "sys-ops-default-key",
      "team_id": "sys-ops",
      "models": ["gpt-5.6-luna"],
      "aliases": {"mistral": "local-llms"}
    }'{
  "key_alias": "sys-ops-default-key",
  "duration": null,
  "models": [
    "gpt-5.6-luna"
  ],
  "spend": 0.0,
  "max_budget": null,
  # ...
  "team_id": "sys-ops",
  # ...
  "aliases": {
    "mistral": "local-llms"
  },
  # ...
  "key_name": "sk-...hJCg",
  "key_type": "default",
  "expires": null,
  # ...
  "token_id": "c9996271b8f97687bdc78c91d1ab6e91b95317aad5b922b49943fd0fbec49d17",
  "organization_id": null,
  "project_id": null,
  "litellm_budget_table": null,
  "token": "c9996271b8f97687bdc78c91d1ab6e91b95317aad5b922b49943fd0fbec49d17",
  "created_by": "default_user_id",
  "updated_by": "default_user_id",
  "created_at": "2026-08-04T17:46:52.040000Z",
  "updated_at": "2026-08-04T17:46:52.040000Z"
}

Conclusion

An LLM proxy is essential for transparently managing a large group of models for a substantial user base. It helps connect different providers, translate and transform requests from applications to provider APIs, keep costs within monetary and token budgets, and provide observability into LLM usage. This article showed two essential concepts of the LiteLLM proxy: model and API key management. For each, a concise summary of lifecycle-based API routes, request parameter groups, and concrete invocation examples was provided.

LiteLLM: Getting Started with LLM Proxies

Sebastian — Mon, 02 Nov 2026 07:01:02 GMT

When running multiple applications that interact with LLM provider endpoints, management of keys, token consumption and cost spending, operational aspects like failover and semantic routing, or observability topics like availability, latency, and traces become important. Especially customer-facing apps that expose chat functionality need tight guards to prevent misuse and runaway costs. These aspects are the domain of LLM proxies, dedicated projects that sit between applications and LLM endpoints.

LiteLLM is a sophisticated LLM proxy, available as open-source software for self-hosting, as well as production-grade deployments on infrastructure or even fully managed cloud solutions. This article starts a new blog series and explores the rich feature set of LiteLLM. This first article discusses features, deployment options, and a step-by-step manual for local setup as Docker containers.

The technical context of this article is litellm v1.94.1, published on 2026-07-31. Setup and configuration examples should work with newer versions too.

This article originally appeared at my blog admantium.com.

LiteLLM Feature Set at a Glance

The LiteLLM proxy provides the following feature set, grouped into different stages of handling AI tools.

API key management: Provide virtual API keys to persons, teams, or applications, and set fixed token or cost budgets.
Cost tracking: Actively monitor token consumption and accumulated costs.
Guardrails: Filter both incoming and generated messages for inappropriate topics or language.
Fallback and retry: Detect upstream provider outages and switch to other available models to keep systems operational.
Caching: Add semantic caches to frequent requests, saving both costs and round-trip time for a better user experience.
OpenTelemetry traces: Requests and responses are separated into GenAI OTEL spans, allowing precise control over how LLM usage, e.g. by an agent app, is internally structured into thinking loops, tool calls, RAG searches, and answer synthesis.
Observability: With traces, also identify latency within the LLM call stack, e.g. by figuring out slow tool calls or a massive context window due to bloated RAG results.
Enterprise features: Provide company-wide single sign-on logic, audit logs, and multi-tenant governance by setting up multiple organizations and teams for managed keys. IP restriction and deeper multi-tenant governance are positioned as enterprise features.

Installation Options

LiteLLM is geared towards enterprise usage, and as such, multiple installation options in terms of cloud environments and multiple components for load balancing requests and long-term storage of operational data are supported.

The essential components in each stack are these:

LiteLLM microservices: To enhance scalability and improve redundancy, functional aspects of LiteLLM can be broken down into different services
Gateway: Central component to which applications connect
Backend: Process and storage engine; provides a REST API and frontend APIs for management
Frontend: The management GUI of LiteLLM
LiteLLM proxy: A single service that combines the functions of the gateway, backend, and configuration GUI
PostgreSQL: Stores keys, teams, users, and configuration items

When hosted in cloud environments, these specific components are added:

Load balancer
AWS: Application Load Balancer (ALB) or Network Load Balancer (NLB)
GCP: GKE Ingress (managed Kubernetes)
Azure: Application Load Balancer (ALB)
Redis: Saves router state and provides global caching

The deployment mechanisms are:

Helm chart: Deploy to managed Kubernetes clusters in AWS (Elastic Kubernetes Service), GCP (Google Kubernetes Engine), or Azure (Azure Kubernetes Service)
Terraform: Deploy to AWS and GCP by using dedicated Terraform providers
Docker: For on-premises and local installations

For more information about cloud-based production deployments, see the official LiteLLM Deployment Guidelines.

Local Setup

LiteLLM can be installed natively, via the LiteLLM CLI that comes packaged with an SDK, or as a Docker container. For local setup, the last option is preferable: The complete application stack, all dependencies, and binaries are versioned inside the container, and essential configurations will be mounted via volumes. You only keep relevant stateful information and can provide safe updates via version pinning.

The LiteLLM Quickstart Guidelines outline all steps in detail. Here is a step-by-step manual, which provide the most recent application versions, and the start for using configuration files effectivly.

Docker Compose file
Download the official Docker Compose file from the LiteLLM GitHub repository
Open the file and change the image tags with the following up-to-date version pinning:

image: litellm/litellm:v1.94.1
  image: postgres:18.4-trixie
  image: prom/prometheus:v3.13.1

LiteLLM environment variables
Create a .env file
Generate two random passwords for LiteLLM by running LC_ALL=C tr -dc 'A-Za-z0-9' < /dev/urandom | head -c 20; echo
Open the .env file and add these passwords

LITELLM_MASTER_KEY="sk-REDACTED"
LITELLM_SALT_KEY="REDACTED"

Configuration files
Create the local directory config/
Create config/litellm.yml and paste and edit the following content:

general_settings:
    master_key: sk-REDACTED # same key as above
    database_url: "postgresql://llmproxy:dbpassword9090@db:5432/litellm"

Configuration files
Create config/prometheus.yml and add these lines:

global:
    scrape_interval: 15s
    evaluation_interval: 15s

scrape_configs:
    - job_name: "litellm"
      static_configs:
        - targets: ["litellm:4000"]

Docker Compose file changes
Edit the container volume mounts to reflect the configuration file locations:

litellm:
    volumes:
      - ./config/litellm.yml:/app/litellm-config.yml
    command:
      - "--config=/app/litellm-config.yml"

# ... 

  prometheus:
    volumes:
      - prometheus_data:/prometheus
      - ./config/prometheus.yml:/etc/prometheus/prometheus.yml

Edit the Postgres volume target path, required in postgres:18.4:

db:
    volumes:
      - postgres_litellm:/var/lib/postgresql

Start the Docker Compose stack
Run docker compose up, and be patient while all the images are completely loaded:

> docker compose up

# log messages
  [+] Running 15/19
  ✔ prometheus Pulled                                                       1.9s
  ✔ litellm Pulled                                                          2.5s
  ✔ db Pulled                                                               4.2s
  ⠦ open-webui 15 layers [⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⠀⡀⣿⣿⡀] 35.33MB/1.315GB Pulling          8.6s
  ...

During startup, the litellm container needs to set up its database, which can also take some time to complete

litellm-1     | 2026-07-31 16:54:12,717 - litellm_proxy_extras - INFO - Running prisma migrate deploy
  litellm-1     | 2026-07-31 16:54:12,718 - litellm_proxy_extras - INFO - Using custom Prisma CLI at /opt/prisma/binaries/node_modules/.bin/prisma
  litellm_db    | 2026-07-31 16:54:16.529 UTC  LOG:  could not receive data from client: Connection reset by peer
  litellm-1     | 2026-07-31 16:54:16,645 - litellm_proxy_extras - INFO - prisma migrate deploy stdout: Prisma schema loaded from schema.prisma
  litellm-1     | Datasource "client": PostgreSQL database "litellm", schema "public" at "db:5432"
  litellm-1     |
  litellm-1     | 140 migrations found in prisma/migrations
  litellm-1     |
  litellm-1     | Applying migration `20250326162113_baseline`
  litellm-1     | Applying migration `20250326171002_add_daily_user_table`
  litellm-1     | Applying migration `20250327180120_add_api_requests_to_daily_user_table`

...

  litellm-1     | 2026-07-31 16:54:21,890 - litellm_proxy_extras - INFO - ✅ Migration diff applied successfully
  litellm-1     | 2026-07-31 16:54:21,891 - litellm_proxy_extras - INFO - ✅ Post-migration sanity check completed
  litellm-1     | INFO:     Started server process [1]
  litellm-1     | INFO:     Waiting for application startup.
  litellm-1     | LiteLLM Proxy: Using default (v1) migration resolver. If your deployment has seen schema thrashing during rolling deploys, try --use_v2_migration_resolver (safer: avoids the diff-and-force recovery that caused the thrash).
  litellm-1     |
  litellm-1     |    ██╗     ██╗████████╗███████╗██╗     ██╗     ███╗   ███╗
  litellm-1     |    ██║     ██║╚══██╔══╝╔════╝██║     ██║     ████╗ ████║
  litellm-1     |    ██║     ██║   ██║   █████╗  ██║     ██║     ██╔████╔██║
  litellm-1     |    ██║     ██║   ██║   ██╔══╝  ██║     ██║     ██║╚██╔╝██║
  litellm-1     |    ███████╗██║   ██║   ███████╗███████╗███████╗██║ ╚═╝ ██║
  litellm-1     |    ╚══════╝╚═╝   ╚═╝   ╚══════╝╚══════╝╚══════╝╚═╝     ╚═╝
  litellm-1     |

Then, open http://localhost:4000/ui/ and see the dashboard:

Model and Virtual API Key Definition

To start using LiteLLM as a proxy, an LLM provider needs to be configured, and then a virtual API key added that the client applications, or any tool working with an OpenAPI endpoint for this matter, uses.

Model Setup

LiteLLM provides many built-in providers, including direct access to OpenAI, Anthropic, cloud providers like Azure AI, Google Vertex AI, and AWS Bedrock, as well as Mistral, Cohere, and OpenRouter. See the full list at LiteLLM providers.

For demonstration purposes, a direct connection to OpenAI will be configured.

On the dashboard, in the left menu, click on Model + Endpoint
In the vertical tab list, click on Add Model, and the same-named dialogue appears
Fill out the details as follows:
Provider: OpenAI
LiteLLM Model Name(s): Put in the models of you choice, e.g. the moste recent gpt-5.6-luna, gpt-5.6-terra and gpt-5.6-sol
Mode: Chat - /chat/completions
OpenAI API key: sk-21113tfa … no, just kidding, use your own key

Click on Test Connection, and when the success message appears, click on Save Model.

API Key

Virtual API keys are a strong feature of LiteLLM, allowing the provision to individual developers or groups.

Follow these steps for key generation:

On the dashboard, in the left menu, click on Model + Endpoint > Virtual Keys.
Click on the + Create New Key button
In the resulting dialog, fill out these details:
Owned By: You
Key Name: Provide a custom name, e.g. openai-api-key
Models: leave empty
Key Type: stick with “AI APIs” (so that it can use only the model APIs)
Under Additional Options, several interesting features are provided, but outside the scope of this article

Testing

To use the API key, you can either issue a curl statement to the local endpoint …

curl http://localhost:4000/v1/chat/completions \
  -H 'Authorization: Bearer sk-REDACTED' \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "gpt-5.6-luna",
    "messages": [{"role": "user", "content": "Say hello in five words."}]
  }'

… or acces the LiteLLM dashboard and cick on Playground in the vertical menu. Enter the virtual key, select the model, and start chatting.

Conclusion

The proliferation of LLM providers creates both opportunity and overhead. When an increasing array of tools and applications access LLMs unrestrained, excessive token usage and cost explosion is just a matter of time. LLM proxies provide essential key management and budget management options, reducing operational risks tremendously.

In this introductory article, you learned about LiteLLM. Specifically: a) its feature set, b) the production setup options that support the major cloud providers and deployment options via Kubernetes or Terraform, c) a full guide to local setup using Docker containers, and d) the configuration of an LLM provider, an API key, and testing the LiteLLM proxy access through curl or via the buildin playground.

Open WebUI: Scheduling Agents

Sebastian — Thu, 22 Oct 2026 06:31:01 GMT

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.

This article originally appeared at my blog admantium.com.

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  [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  [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 
Date:   Sun Jul 5 14:21:42 2026 +0000
feat(config): add model config data

commit 53991af08e9d57b1b89503c9ac0ddcd39e1519e0
Author: python-engineer 
Date:   Sun Jul 5 14:21:42 2026 +0000
feat(api): add FastAPI app with config endpoint

commit 4905c33d72afd5a95929a2313c331b36da83ca08
Author: python-engineer 
Date:   Sun Jul 5 14:21:42 2026 +0000
build: add Python API dependencies

commit d2ea8ce702ff159b1438949d26f83e56f2d7d55d
Author: python-engineer 
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

Sebastian — Mon, 12 Oct 2026 06:31:01 GMT

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.

This article originally appeared at my blog admantium.com.

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

Sebastian — Thu, 01 Oct 2026 05:19:54 GMT

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.

This article originally appeared at my blog admantium.com.

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

Sebastian — Mon, 21 Sep 2026 15:52:54 GMT

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.

This article originally appeared at my blog admantium.com.

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

Sebastian — Thu, 10 Sep 2026 05:41:02 GMT

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.

This article originally appeared at my blog admantium.com.

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

Sebastian — Mon, 31 Aug 2026 04:26:32 GMT

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.

This article originally appeared at my blog admantium.com.

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.

Complete OpenClaw Installation Guide with Telegram Communication Channel

Sebastian — Thu, 20 Aug 2026 05:11:57 GMT

In 2026, agentic AI tools and frameworks generated much interest from technical and non-technical users alike. On the forefront of all of these tools is OpenClaw, the most popular open-source project that catapulted agents into mainstream usage.

This article covers the complete installation steps and setup. You will learn how to install OpenClaw on your local computer, set up Telegram as the communication channel, and perform essential security hardening.

The technical context of this article is OpenClaw v2026.6.11 released 2026-06-30. All provided information and command examples should be valid with newer versions too, barring an update of the CLI commands' syntax. However, configuration details differ between OpenClaw versions, and therefore, you should check the most recent documentation guidelines as well.

While I’m 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 verbose copies from log messages and screenshots.

This article originally appeared at my blog admantium.com.

Prerequisites

To install and run OpenClaw, you need a computer with either Linux or Windows, and the NodeJS library installed. This opens the option to use a spare laptop or computer, a dedicated VPS like several other installation guides explain, or even just a local Raspberry Pi. The only crucial requirements are available CPU and RAM: 2GB RAM and 2 CPUs are the minimal requirements, and 4GB RAM and 4 vCPUs are sufficient for an installation that produces a medium or high system load.

PlatformMinimumRecommendedNotesRaspberry PiRaspberry Pi 3+Raspberry Pi 4+32-bit OS supportedLinux x64Ubuntu 20.04+Ubuntu 22.04+Debian/Ubuntu derivativesCloud VPS2GB RAM, 2 vCPU4GB RAM, 4 vCPUAWS EC2, DigitalOcean, etc.

As for the software, only NodeJS is strictly required. If you want to use Docker for the hosting environment, you need to ensure that a proper version is installed as well.

LibrariesMinimumRecommendedNodeJSv22.19v24Dockerv20.10+v24.0+

Installation

OpenClaw can be installed in three ways: As a Docker container that includes all dependencies, as a bash script that checks and installs missing dependencies, or just by adding the NPM packages.

In a freshly installed, current Linux distribution, adding the NPM package is sufficient. Simply run the following command.

npm i -g openclaw@2026.6.11

Installation can take up to several minutes. Once completed, a unified OpenClaw process starts which creates both a gateway process and the dashboard.

An essential command with which to verify the installation, and to identify any issues, is openclaw doctor. Run it once to ensure the installation succeeded, but stop before making any configuration.

openclaw doctor


🦞 OpenClaw 2026.6.11 (4dcc39c) - Making 'I'll automate that later' happen now.

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
██░▄▄▄░██░▄▄░██░▄▄▄██░▀██░██░▄▄▀██░████░▄▄▀██░███░██
██░███░██░▀▀░██░▄▄▄██░█░█░██░█████░████░▀▀░██░█░█░██
██░▀▀▀░██░█████░▀▀▀██░██▄░██░▀▀▄██░▀▀░█░██░██▄▀▄▀▄██
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
                  🦞 OPENCLAW 🦞

┌  OpenClaw doctor
│
◇  Startup optimization ─────────────────────────────────────────────────────────────────────╮
│                                                                                            │
│  - NODE_COMPILE_CACHE is not set; repeated CLI runs can be slower on small hosts (Pi/VM).  │
│  - OPENCLAW_NO_RESPAWN is not set to 1; set it to avoid extra startup overhead from        │
│    self-respawn.                                                                           │
│  - Suggested env for low-power hosts:                                                      │
│    export NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache                               │
│    mkdir -p /var/tmp/openclaw-compile-cache                                                │
│    export OPENCLAW_NO_RESPAWN=1                                                            │
│                                                                                            │
├────────────────────────────────────────────────────────────────────────────────────────────╯
│
◇  Gateway ──────────────────────────────────────────────────────────╮
│                                                                    │
│  gateway.mode is unset; gateway start will be blocked.             │
│  Fix: run openclaw configure and set Gateway mode (local/remote).  │
│  Or set directly: openclaw config set gateway.mode local           │
│  Missing config: run openclaw setup first.                         │
│                                                                    │
├────────────────────────────────────────────────────────────────────╯
│
◇  Gateway auth ──────────────────────────────────────────────────────────────────────╮
│                                                                                     │
│  Gateway auth is off or missing a token. Token auth is now the recommended default  │
│  (including loopback).                                                              │
│                                                                                     │
├─────────────────────────────────────────────────────────────────────────────────────╯
│
■  Generate and configure a gateway token now?
...

Setup

The configuration complexity of OpenClaw seems daunting, but all available options are streamlined during the initial onboarding process. I recommend starting the installation with the interactive onboarding wizard, and tweaking individual settings after this initial setup.

Start the process with the following command:

openclaw onboard --install-daemon

🦞 OpenClaw 2026.6.11 (4dcc39c) - I've read more man pages than any human should-so you don't have to.

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
██░▄▄▄░██░▄▄░██░▄▄▄██░▀██░██░▄▄▀██░████░▄▄▀██░███░██
██░███░██░▀▀░██░▄▄▄██░█░█░██░█████░████░▀▀░██░█░█░██
██░▀▀▀░██░█████░▀▀▀██░██▄░██░▀▀▄██░▀▀░█░██░██▄▀▄▀▄██
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
                  🦞 OPENCLAW 🦞

┌  OpenClaw setup

This ongoing setup dialog will guide you through different installation phases. The following list divides the setup decisions, and shows the corresponding dialog prompt printed in the terminal.

Security Warning

◆  I understand this is personal-by-default and shared/multi-user use requires lock-down. Continue?
│  ● Yes / ○ No

A disclaimer about the project’s nature, mentioning risks and concerns, and listing guidelines for a safe initial configuration. You need to answer with Yes in order to continue.

2. Setup Mode

◆  Setup mode
│  ● QuickStart (Configure details later via openclaw configure.)
│  ○ Manual

The Manual setup mode is intended for configuring OpenClaw on a public internet host, detailing network stack configurations including URL and port. Continue with the preselected QuickStart for an instance that runs locally.

3. Model Configuration

◆  Model/auth provider
│  ● Alibaba Cloud Model Studio (Coding Plan API key (CN / Global))
│  ○ Anthropic
│  ○ BytePlus
│  ○ Chutes

OpenClaw needs at least one LLM provider for processing inputs. The list is quite extensive, enabling free selection from more than 30 providers. It includes well-known options such as OpenAI, Anthropic, DeepSeek, or Minimax, API gateways like LiteLLM, and multi-provider aggregators like OpenRouter.

4. Channel Configuration

Select channel (QuickStart)
│  ● Telegram (Bot API) (recommended · newcomer-friendly)
│  ○ WhatsApp (QR link)
│  ○ Discord (Bot API)

An OpenClaw installation exposes a dashboard with many features, one being a chat interface. However, the true appeal of OpenClaw is its compatibility with different communication channels: messengers like WhatsApp and Signal, collaboration tools like Slack and Discord, and integrations with ecosystems like Mattermost or Nextcloud.

5. Search provider

Search provider
│  ○ Brave Search
│  ● DuckDuckGo Search (experimental) (Free web search fallback with no API key required · key-free)
│  ○ Exa Search

OpenClaw agents frequently perform web searches to fetch accurate and up-to-date information. Technically, search results should be provided in a non-HTML format, for example JSON. This structure can be obtained from search providers, which require a dedicated, paid account. The alternative is to use a headless Brave browser, which works, but can run into bot-detection challenges.

6. Skills

Skills status ─────────────╮
│                             │
│  Eligible: 3                │
│  Missing requirements: 40   │
│  Unsupported on this OS: 7  │
│  Blocked by allowlist: 0    │
│                             │
├─────────────────────────────╯
│
◆  Configure skills now? (recommended)
│  ● Yes / ○ No
│
Install missing skill dependencies
│  ◻ Skip for now (Continue without installing dependencies)
│  ◻ 🔐 1password
│  ◻ 📰 blogwatcher
│  ◻ 🫐 blucli
│  ◻ 📸 camsnap
│  ◻ 🧩 clawhub
│  ◻ 🛌 eightctl

Skills extend the capabilities of your OpenClaw agents. Much of the perceived user value stems from sophisticated skill definitions that are included and activated by default. This includes interfacing natively with apps installed on the computer, accessing internet services from Google, BlueSky, or Obsidian, and much more. And of course, you can further extend the skills once the initial setup is completed.

7. Hooks

Hooks ──────────────────────────────────────────────────────────────────╮
│                                                                          │
│  Hooks let you automate actions when agent commands are issued.          │
│  Example: Save session context to memory when you issue /new or /reset.  │
│                                                                          │
│  Learn more: https://docs.openclaw.ai/automation/hooks                   │
│                                                                          │
├──────────────────────────────────────────────────────────────────────────╯
│
◆  Enable hooks?
│  ◻ Skip for now
│  ◻ 🚀 boot-md
│  ◻ 📎 bootstrap-extra-files
│  ◻ 📝 command-logger
│  ◻ 💾 session-memory

When using an OpenClaw agent, the invocation traverses typical lifecycle phases from initialization, tool access, execution, and answer generation. During these phases, hooks can be executed, with the goal of extending or tweaking the default behavior. A common option is to activate an additional prompt during initialization, which can be achieved with the boot-md hook.

8. Technical Setup

◇  Systemd ───────────────────────────────────────────────────────────────────────────────╮
│                                                                                         │
│  Systemd user services are unavailable. Skipping lingering checks and service install.  │
│                                                                                         │
├─────────────────────────────────────────────────────────────────────────────────────────╯


...

◇  Gateway service ─────────────────────────────────────────────────────────────────────╮
│                                                                                       │
│  Systemd user services are unavailable; skipping service install. Use your container  │
│  supervisor or `docker compose up -d`.                                                │
│                                                                                       │
├───────────────────────────────────────────────────────────────────────────────────────╯
│

...

◇  Control UI ───────────────────────────────────────────────────────────────────────────────╮
│                                                                                            │
│  Web UI:                                                         │
│  Web UI (with token):                                                                     │
│          │
│  Gateway WS: ws://127.0.0.1:18789                                                         │
│  Gateway: not detected (gateway closed (1006 abnormal closure (no close frame)): no close │
│  reason)                                                                                  │
│  Docs:                                           │
│                                                                                            │
├────────────────────────────────────────────────────────────────────────────────────────────╯

...

◇  Security ──────────────────────────────────────────────────────╮
│                                                                 │
│  Running agents on your computer is risky - harden your setup:  │
│                              │
│                                                                 │
├─────────────────────────────────────────────────────────────────╯

...

└  Onboarding complete. Use the dashboard link above to control OpenClaw.

In this non-interactive phase, the OpenClaw installation sets up a systemd service, starts it, performs a health check, prints access information, and other data.

This concludes the onboarding, and you can now access the OpenClaw dashboard. To see the required dashboard URL, run the command openclaw dashboard --no-open; it prints a URL string with the required token embedding.

Telegram Integration Setup

One of OpenClaw’s strengths is its capability to be accessible from many different channels. Integration with the Telegram messenger provides an always-enabled connection for communication with your OpenClaw instance and for receiving messages that result from asynchronous tasks, for example cron jobs.

Telegram setup follows these steps.

Create a New Telegram Bot

A bot is a system user configured in Telegram, with a unique ID. It can be created through the Telegram chat interface itself. Follow these steps:

Open a message to @BotFather
Enter the /newbot command.
Provide a bot name, which is the unique ID with which to access the bot. You can use acronyms and cryptic letter/number combinations to prevent accidental access from other Telegram users.
Configure the Bot Username, which is the account name to which you refer in OpenClaw. Use mnemonics or generic names to identify the bot, such as “Researcher”.

When the bot is configured, a 46-character bot token is printed in Telegram. This access token needs to be configured in the OpenClaw instance to enable access. You can manually edit the openclaw.json configuration file, or use openclaw onboard again and only change the channel configuration. The CLI dialogue is as follows:

Telegram bot token ────────────────────────────────────╮
│                                                         │
│  1) Open Telegram and chat with @BotFather              │
│  2) Run /newbot (or /mybots)                            │
│  3) Copy the token (looks like 123456:ABC...)           │
│  Tip: you can also set TELEGRAM_BOT_TOKEN in your env.  │
│  Docs:               │
│  Website:                          │
│                                                         │
├─────────────────────────────────────────────────────────╯
│
◇  How do you want to provide this Telegram bot token?
│  Enter Telegram bot token
│
◆  Enter Telegram bot token

The final step is to allow the OpenClaw instance to communicate with the bot. This process, called pairing, is started by sending a new message to the bot via Telegram. This will create a short, 5-character access token. And this token needs to be confirmed in your OpenClaw instance.

On your instance, run the following commands, and insert this token.

openclaw pairing list telegram
openclaw pairing approve telegram $TOKEN

Now you can send a message to your bot and your instance should answer. If not, please check the troubleshooting hints in the next section.

Telegram Troubleshooting

A typical error case is that the bot is not answering at all. In my personal experience, this often can be boiled down to a typo in the bot token. You can check this by sending the token to a Telegram status API endpoint. In the following example, replace "${TOKEN}" with the 46-character token.

curl -s "https://api.telegram.org/bot${TOKEN}/getMe"

If the token is not correct, you will receive a JSON document with the following content.

{
  "ok": false,
  "error_code": 401,
  "description": "Unauthorized"
}

… while a correct token creates this:

{
  "ok": true,
  "result": {
    "id": "REDACTED",
    "is_bot": true,
    "first_name": "claw",
    "username": "REDACTED",
    "can_join_groups": true,
    "can_read_all_group_messages": false,
    "supports_inline_queries": false,
    "can_connect_to_business": false,
    "has_main_web_app": false,
    "has_topics_enabled": false,
    "allows_users_to_create_topics": false
  }
}

When the bot token is correct, but the error persists, a network error in the Telegram-to-OpenClaw instance communication is likely. Run the following command:

openclaw channels status --probe

Gateway reachable.
- Telegram default: enabled, configured, running, mode:polling, bot:@REDACTED, token:config, works

If this shows a specific error message, access the OpenClaw documentation for further information, and hopefully your access problem can be resolved.

Conclusion and Next Steps

OpenClaw is an agentic tool which provides both full access to a computer and abundant skills to interface with external systems. It is the premier tool that catapulted the capabilities of LLM agents to the public. In this article, you learned how to install OpenClaw from scratch. Installation is simple; a mere NPM package on a current Linux distribution is sufficient. Onboarding is an interactive dialogue, which guides you through model, channel, search provider, skills, and hooks. Telegram channel configuration involves bot creation, bot token configuration, and pairing. With the installation completed, you can start exploring the many use cases that OpenClaw offers.

From Large Language Models to AI Agent Systems

Sebastian — Mon, 10 Aug 2026 04:59:40 GMT

In 2024, the first capable Large Language Models emerged. Self-hosted Ollama with local model inference was one pattern, and using commercial vendors and models like OpenAI’s GPT or Anthropic’s Sonnet models. Several open-source projects started to create AI assistants, targeting working autonomously on tasks ranging from research to productivity and coding.

In my blog article series about LLMs, I wrote Universal Personal Assistant with LLMs as the last entry in December 2024. I had the goal to investigate agent systems like AutoGen, CrewAI, and AgentZero. But using these frameworks showed severe limitations: Tool calls did not function reliably, and a human operator needed to constantly shepherd the LLM invocation to stay on track. I did not write a single article following this experience.

In 2026, the AI agent paradigm is a technical reality, and it keeps evolving rapidly. Commercial products include agent-like capabilities in their products, from the universal ChatGPT, to knowledge organisation with Notion and web search with Perplexity. Open-source frameworks likewise evolved: Chat interfaces with session persistence like OpenWebUI, personal agent frameworks like OpenClaw and Hermes, and several coding tools like Droid, Kilo, and Pi.

Agents are here now. They autonomously read and compose e-mails, conduct research and write comprehensive overviews, and program web applications and apps.

In this ongoing blog series, agent applications and their capabilities will be the focus. Two goals are prevalent. First, to explore and categorize the (agentic) features of commercial products and open-source projects. Second, how to set up agentic tools and surrounding infrastructure like LLM proxies and observability tools.

This introductory blog post provides an overview of application types and concrete commercial and open-source tools.

This article originally appeared at my blog admantium.com

Commercial Tools

The space of commercial tools is enormous. While AI becomes embedded into many types of products, agentic capabilities are the focus in the following groups.

Research

Gathering information from several webpages, reading several texts, comparing and summarizing — this is a premier task for AI apps.

Perplexity AI: Perplexity is an AI-powered search engine with different capabilities: Standard fast web search, and deep research for parallel fetching and comparison of several sources. You can select which model to use, enter text and voice, and instruct it to narrow down sources. Search processes and text generation happen fast, providing accurate results quickly, and always linking the relevant sources for verifying factual claims.
Google AI Search/AI Overview: Google also extended its search capabilities with conversational AI. When used, information is synthesized from various sources, providing a quick overview of topics of interest. Follow-up questions can narrow down the results. AI Overview is offered as an installable app for mobile phones only, which provides integration with a phone’s native capabilities, including its camera for pictures or videos.

Knowledge Management

Knowledge management is concerned with organizing lists, notes, and texts into a coherent, structured format. Keeping this structure with editors requires structural integrity and strict rules to follow, while using a tool is dependent on the provider’s system, making exports difficult.

Notion AI: Notion pages are structured documents accessible from the web or via dedicated app. Adding agents to these pages allows extended search capabilities via connectors, e.g. to external databases, or content improvements like summarization or text rewriting. Since agents can also query the complete workspace, context-aware suggestions can be produced, e.g. to reduce redundancy in notes. The specific strength of Notion is that agent invocation stays inside the workspace itself; no separate search or chat interface is required.
Google NotebookLM: A Gemini-powered research assistant that performs retrieval-augmented generation over uploaded sources such as Docs, PDFs, Slides, and URLs, generating grounded summaries and explanations. It is especially useful when the source set is known in advance and the goal is to stay within those materials. A distinctive feature is source-grounded output that avoids drifting beyond the uploaded corpus.
Perplexity Spaces: The Spaces feature is designed as a long-running, continuous session in which you can add sources, configure LLM invocation instructions, attach custom files and other data sources, and then start discussions structured as threads. Additionally, spaces can be shared with other people, allowing collaborative work on dedicated knowledge areas.

Productivity

Personal productivity is a very attractive area for agent applications. Organizing disjoint data sources, from task lists to calendars, from e-mails to note-taking apps, can be tedious if not structured rigorously. Agent apps provide organization and processes in spite of structural differences.

Google Workspace with Gemini: Google apps remain at the frontier of productivity, already providing a tight integration between emails, documents, sheets, and task lists. Their Gemini model can be opened in any workspace app, providing immediate support by AI models. Alternatively, a Gemini chat can be used standalone, with full access to all information, making it seamless to e.g. let an e-mail be composed about the contents of several documents. Also, you can use this feature to generate texts and add them to documents.
ChatGPT Agent Mode: ChatGPT is the premier interface for invoking LLMs in long, session-based conversations. The agent mode extends this capability, allowing a combined tool array for multi-step workflows, with tasks like web research, file editing, code execution, and connection to various third-party apps. Tasks can even be scheduled regularly, providing timed workflows.
Slack AI: Slack is a standard communication tool, used in small businesses and enterprises alike. Integration of AI takes several forms. For channels, summaries can be generated. Inside a huddle, meeting notes can be summarized. And the canvas feature allows collaborative text editing.

Content Generation

While text generation and image generation are core capabilities in all aforementioned application areas, specialized domains require specific formats or need to follow rules.

Jasper Agents: A complete platform for brand-specific content generation, including landing pages, blogs, and whole campaigns. It structures content generation into strict phases, and uses specialized agents for each step, with fixed guardrails and quality controls. It is also designed for collaborative work, allowing whole teams to structure and refine the workflow processes.
Ema: The Enterprise Machine Assistant promises AI employees that can fill roles from customer support, sales, research, and HR. Workflow engines invoke agents autonomously, and allow connecting to various data sources, ensuring governance and system connectivity.
Sight AI: An autonomous content-generation platform for researching, writing, and publishing SEO-optimized articles. Specialized agents partake in each workflow phase, and learn from their work. Published page rankings are monitored, their impact measured, and important findings stored in a knowledge graph that serves as a continuously evolving knowledge base for improving all publication aspects.

Sales and Support

These agents are tuned for CRM workflows, customer engagement, and service automation.

Agentforce: Salesforce’s all-in-one solution for conversational agents that support all CRM processes. They can be employed as customer-facing chatbots, in back-office environments for customer support, and even for reaching out to resellers. All agents are highly customizable by the human team that invokes them.
Kore.ai: Kore offers pre-made AI apps for banking, healthcare, retail, and HR, as well as a complex agentic platform with which to implement and add agents for any business processes. Their focus on and experience with enterprise customers results in well-integrated solutions, orchestrating multimodal workflows that include voice, chat, documents, and system access. A special feature is enterprise-grade virtual assistant deployment across many business functions.
Sierra: Sierra provides brand-specific AI support agents for customer services across voice, webpage, and app channels. It handles both FAQ-style information access, and can also handle operational service flows, e.g. triggering returns or handling subscriptions. Their advertised strength is brand awareness, ensuring a coherent customer experience.

Workflow Automation

These agents orchestrate multi-step workflows and actions across apps and systems.

Zapier Agents: Zapier has been at the forefront of automation for more than a decade. With their rich experience of inter-system connectivity, it is no surprise that adding agents provides a seamless experience. Many templates are available, resulting in seamless invocation of agents to summarize content or work autonomously. This allows for productive business automation, spawning agents to fulfil customer requests, file invoices, and more.
Beam AI: Agentic process-automation platform whose agents interpret requests, make routing decisions, and automate workflows in support, sales operations, and HR. A standout feature is decision-making inside process flows, not just form-based task triggering.

Low-Code/Visual Coding

While dedicated coding agents output complex source code, the entry level into custom applications are visual editors, allowing non-technical users to implement complex logic.

Lovable: AI-powered platform for creating full-stack web apps from natural-language prompts. It is especially helpful for fast prototyping and MVP creation. Users can start with a generic prompt, and then quickly refine generated results with follow-ups. Since its inception, capabilities like third-party system integrations were added, allowing the generated code to access these systems immediately.
Bubble: A similar visual app builder with a focus on structured design workflows. Upon the initial prompts, design choices are presented, e.g. a set of features, or the structure of a webpage. The visual editor allows configuring these aspects, and then continuing with the prompt, or rewinding to an earlier version. It also rapidly expanded its capabilities with a third-party API connector, and opened a marketplace for plugins that can be integrated into its GUI.
Retool: Low-code platform for internal tools that uses AI to generate applications from prompts while keeping visual editing, data bindings, and enterprise controls in place. It is particularly strong when apps must connect to business data, run securely, and evolve over time.

General-Purpose Assistant

These are broad assistants that handle many task types via chat, tools, and multimodal inputs.

ChatGPT: General assistant for writing, coding, and research, with browsing and agent capabilities for multi-step tasks. It is flexible enough to act as both a conversational helper and a goal-directed autonomous agent with decision-making capabilities.
Gemini: General assistant for search, reasoning, and productivity tasks, with multimodal support and strong workspace integration. It works well when users need one assistant across documents, mail, search, and visual inputs.
Meta AI: The AI Assistant from Meta, accessible as a standalone web application, and also integrated into WhatsApp, Instagram, and Facebook. It allows seamless follow-up questions inside these apps, accessing user messages for rich, grounded context.

Open-Source Projects

An agent is a persistent, task-oriented process that has access to tools for editing files, connecting to external systems, and even shell commands in its environment. It also has a memory system, deriving context from several sessions/conversations, which also evolves the agent’s capabilities so as not to repeat mistakes.

Converging with the appearance of the first Large Language Models, early frameworks that provide single agents were developed. The evolution to multi-agent invocation is rather new, which required experience with agent memory consistency and fixed workflow handovers between the different processes.

Single-Agent Frameworks

LangChain: Modular framework in which strict workflows with agent invocation are designed. Agents have access to their own memory, vector stores for RAG, and other data sources. The framework even features its own domain-specific language for composing complex workflows as functions with streaming support.
AgentZero: A general-purpose personal assistant framework with persistent memory and tool-enabled execution. It uses its host system for tool execution, so tasks can incorporate commands, code, and file operations.
AutoGen: Open-source framework for building AI agents and facilitating cooperation among multiple agents to solve tasks. It adds conversation programming and finite state machine patterns for controlling agent communication. AgentEval is integrated for task-oriented evaluation and iterative self-improvement. Has been declared in maintenance mode as of September 2025.
Parlant: An agent harness for reliable customer-facing AI. Agent behavior is modeled as explicit rules and conditions, then selectively injects only the relevant guidelines into the prompt at runtime. This results in fine-grained, predictable control over a single agent.

Multi-Agent Frameworks

CrewAI: Multi-agent orchestration framework centered on crews, agents, and tasks. The template method separates agents and tasks into YAML files, making projects easier to read and reuse. It also adds built-in tools, planning support, and training-oriented workflows.
OpenClaw: The most famous open-source agent runtime that generated awareness for technical and non-technical users alike. It provides three strong pillars: First, support for more than 20 LLM providers, including OpenAI, Anthropic, the generic OpenRouter, and more. Second, tight integration into the Google and Apple ecosystems, connecting apps from mail to note-taking. Third, a multitude of channels to simplify communication with agents, including popular messaging platforms like WhatsApp and Telegram, and platforms like Slack and Discord. It is also known for fast-moving features, not always with system stability and backwards compatibility.
Hermes Agent: A framework for self-improving agents with persistent memory and autonomous skill creation, using searchable past interactions and skill documents to adapt workflows across chat platforms. It is the number one contender to OpenClaw, valued for its stability and strict permission system to keep agents from harming their system.
OpenFang: A fast-moving open-source agent operating system built in Rust, positioned as a more kernel-level, background-process style alternative to chat-first agents. It emphasizes autonomous execution, skill templates, and a command registry, geared toward reliable scheduling and long-running tasks. It is shipped as a single, production-oriented binary, reducing resource overhead significantly compared to frameworks based on interpreted programming languages.
ZeroClaw: A compact, fully autonomous AI assistant infrastructure, emphasizing simplified practical deployments and channel connectivity. Its support for LLM providers and channels rivals that of OpenClaw, and its roots in Rust provide operational benefits, with a special focus on permissions to execute tools. An interesting feature is its hardware support to access communication protocols like I2C or serial interfaces, making it viable to be deployed on Raspberry Pi or ESP32 platforms.

Conclusion

In 2026, AI agents perform autonomous tasks in areas like productivity, research, content generation, and coding. This blog article gave a concise overview of both commercial tools and open-source projects in these realms. In the commercial space, the breadth from research to knowledge management, and from low-code to workflow automation, shows how much traction agents are developing. And the open-source projects show the steady progress from single-agent frameworks, requiring manual Python code with LLM invocations, to Telegram-controlled multi-agent environments with full access to the computer they run on.