Open WebUI pricing: what the software costs and what the tokens cost

Open WebUI publishes no price list at all: openwebui.com/pricing and openwebui.com/enterprise both return 404, and the chat interface is free to self-host with no seat cap and no request cap. What an enterprise license gates is removing the Open WebUI branding and enterprise-only add-ons such as Terminals, not the number of people who use it. The numbers a buyer actually needs are the three the project does not bill you for — the machine, the model tokens, and the settings inside Open WebUI that quietly send tokens you did not type. All three are below, with sources and check dates.

Three wrong prices circulate for this query, so clear them first. $60 per seat per year is real and official, but it is the Supporter tier of Open WebUI Computer — the cptr package, a separate product from the same team under a different license, whose own free tier reads "$0 forever". A yearly enterprise figure attributed to Open WebUI in search results comes from a third-party hosting vendor and appears on no official page, so it is not repeated here. And a $19-per-month "Pro" plan belongs to openwebui.net — a lookalike domain that is not openwebui.com, and whose app is branded "NextChat" in its own copy (checked September 21, 2026). It is named here so you recognise it, and deliberately not linked.

What the software costs, and what the license actually gates

The project homepage sells the install, not a plan: "pip install open-webui / One command. 60 seconds. No account required." The repository is live and unarchived, and its most recent commit on main is dated September 4, 2026. The current release is v0.11.3, whose files were published to PyPI on August 31, 2026. Note one official disagreement: the homepage blog card still headlines v0.11.1 from August 25. That is a blog post, not a version banner; GitHub Releases is the release truth.

The license needs the same care. GitHub reports it as NOASSERTION / "Other", while third-party write-ups often still call it BSD-3. Both are half right. The LICENSE file is BSD-3 text plus a fourth clause, introduced at v0.6.6, that prohibits altering, removing, obscuring or replacing Open WebUI branding, except where "the total number of end users … does not exceed fifty (50) within any rolling thirty (30) day period", where you have written permission, or where you hold an enterprise license. The project's license page puts it plainly: "Branding requirements only apply to larger deployments (50+ users, aggregate)", and "anyone can still fork from v0.6.5 with zero restrictions". So: not an OSI-approved license today, and not a use cap either — the threshold gates rebranding, not running it.

What the enterprise license grants, in the project's own words, is "White-labeling, rebranding, modifications to original branding, or enterprise-exclusive offerings like Terminals". Terminals is documented as the orchestration layer for Open Terminal: it provisions a separate workspace — files, processes, package environment, resource limits and network boundary — per user, and is the one named example of a feature the license gates rather than the branding. Managed "Open WebUI hosting" from third-party vendors is a separate matter again: it is a server bill on someone else's infrastructure. No verified figure for any managed host was obtained for this page — the one vendor plan page checked renders price placeholders rather than numbers to a plain fetch — so none is quoted.

Two different questions hide inside "Open WebUI API cost"

The query is genuinely ambiguous, and the two halves have different answers.

Outbound calls are the ones that cost money. Open WebUI ships no model of its own, so every token is billed by whatever endpoint you configured. Open WebUI's own API costs nothing: at released tag v0.11.3, backend/open_webui/main.py serves GET /api/models (L874), POST /api/chat/completions (L1085) and — newer, and easy to miss — an Anthropic-shaped POST /api/v1/messages (L1976) with POST /api/v1/messages/count_tokens beside it (L1907). You authenticate to those with an Open WebUI key of your own rather than with your provider's key. Open WebUI charges nothing for them, because they are a front door: every request still lands on the upstream you configured and is billed there. Pointing your own scripts at Open WebUI instead of at the provider changes the routing, not the bill.

The billable calls you did not type

This is the part a rate comparison misses. Read at tag v0.11.3 in backend/open_webui/config.py, four background generators are on by default and one is off.

How many extra tokens that is in practice was not measured for this page, and any percentage claiming otherwise would be invented. What is checkable is the shape: the flags are on, the task model is unset, so the naming and tagging traffic bills at whatever chat model that conversation is already using until you name a cheap id in TASK_MODEL_EXTERNAL. Open WebUI's own FAQ says the same thing — "By default, these tasks use the same model you're chatting with" — and recommends the same fix. Two defaults go the other way and are worth knowing before you budget: web search is off (ENABLE_WEB_SEARCH, L1155) and image generation is off (ENABLE_IMAGE_GENERATION, L1336), while the code interpreter is on (L422).

Four subsystems, four endpoint slots — and a default worth reading twice

Chat compatibility does not carry over to the rest of the product. Retrieval embeddings, speech-to-text, text-to-speech and image generation each have their own base-URL and key pair, and each one's fallback is the singular OPENAI_API_BASE_URL. Here is the part that surprises people: at tag v0.11.3, after the connection list has been built, line 365 of config.py reassigns OPENAI_API_BASE_URL = 'https://api.openai.com/v1' unconditionally. Every subsystem default evaluated later — RAG_OPENAI_API_BASE_URL (L1092), IMAGES_OPENAI_API_BASE_URL (L1490), AUDIO_STT_OPENAI_API_BASE_URL (L1565), AUDIO_TTS_OPENAI_API_BASE_URL (L1606) — therefore resolves to OpenAI's endpoint no matter which variable you set for chat. This is the module-level default read from source; these values seed a persisted configuration that the admin UI can then override, and the behaviour was not reproduced in a running instance for this page. Issue #22084 describes the same symptom; it was opened March 1, 2026 and is now closed as completed, so treat the source reading above as the v0.11.3 module-level default rather than as an open bug.

The good news is that all four of those slots cost nothing in API spend on the default settings.

Kunavo does not serve embeddings, does not serve speech-to-text and does not serve text-to-speech.

That boundary decides which of those slots you can point at a gateway at all: RAG_OPENAI_API_BASE_URL, AUDIO_STT_OPENAI_API_BASE_URL and AUDIO_TTS_OPENAI_API_BASE_URL are not slots to aim here. Leave the retrieval step on its local default — that is both the shipped setting and the free one — or send it to a provider that does sell that step. The only line of your retrieval bill that reaches a chat provider is the retrieved text itself, which arrives as ordinary input tokens inside the next prompt. RAG implementation covers how chunk size and top-k turn into that input count.

# The chat connection. This is the only slot the setup guides cover.
OPENAI_API_BASE_URL=https://api.kunavo.com/v1
OPENAI_API_KEY=sk-kn-...

# Titles, tags and retrieval queries run on the CHAT model unless you say
# otherwise. TASK_MODEL_EXTERNAL defaults to empty (config.py L2195).
TASK_MODEL_EXTERNAL=gpt-5-6-luna

# Leave the document-embedding step alone: empty means local, and local
# means no API spend at all (config.py L996 and L1002).
RAG_EMBEDDING_ENGINE=
RAG_EMBEDDING_MODEL=sentence-transformers/all-MiniLM-L6-v2

A worked estimate for one day of chat

This is illustrative token arithmetic, not a measured cost and not a bill ceiling. Assume one person's working day in the chat window: 40 assistant turns, each sending 6,000 uncached input tokens (the visible thread plus any retrieved chunks) and returning 700 output tokens — 240,000 input and 28,000 output in total. Assume 8 new chats that day, and that Open WebUI's default title, tag and retrieval-query generators fire three extra calls per chat at 2,000 input and 40 output each. That per-call size is an assumption; it was not measured. Rates are live Kunavo catalog prices per million tokens.

Read the last column rather than the chat column. Under these assumptions the background traffic is about 12% of a Claude Sonnet 5 day — $0.106 of $0.866 — spent on naming and tagging chats. Setting TASK_MODEL_EXTERNAL to GPT-5.6 Luna instead brings that slice to $0.004 and the day to $0.764, with no change to what anyone actually reads. That single setting moves more of this bill than switching providers at the same tier would.

Scale by your own head count and days before treating it as a budget, and note what the arithmetic excludes: prompt caching, image or video generation, and any tool the code interpreter calls. Kunavo's catalog amount is a billing floor rather than a cap — when the upstream reports its charge, the bill is the greater of catalog cost and upstream cost times the applicable markup. The minimum Kunavo top-up is $10 in prepaid credit, which is a funding minimum, not a subscription or a per-seat fee. See billing details, and usage for the per-request ledger. Open WebUI reports its own view too: the v0.11.3 README describes admin dashboards that "track message volume, token consumption, and cost across users and models". That feature was not exercised for this page, and two meters counting the same traffic will not agree token for token, so reconcile against whichever side you are actually funding.

Which route wins, and when

One protocol detail decides the setup more than the vendor choice does. Open WebUI is explicitly protocol-oriented — it implements the OpenAI Chat Completions protocol and declines to add provider-specific APIs to the core — so the thing to hand it is an OpenAI-shaped /v1 root, even for Claude models. Its own Anthropic page configures https://api.anthropic.com/v1 as an OpenAI connection and relays Anthropic's warning that the compatibility layer is meant for testing rather than production. There is also a per-connection API Type toggle for Open Responses, which the documentation labels experimental and warns "may not work as expected with all providers". Kunavo serves a Responses-shaped route, but that combination was not runtime tested for this page, so treat the chat-completions path as the known-good one and the toggle as something to try on a spare connection.

Comparing the front end itself rather than the provider? LibreChat vs Open WebUI and AnythingLLM vs Open WebUI cover that choice, and best LLM gateway compares the gateway layer on rate and funding terms rather than on integration depth.

Set it up, then check the first day's charge

The connection lives at Settings → Admin → Connections → "Manage OpenAI API Connections" → "Add Connection", with a URL and an API Key field; the same thing can be done with the two environment variables above at container start. Keep the /v1 on the URL — Open WebUI appends the route itself, and the source strips a trailing slash.

One failure mode is worth knowing in advance, because it looks like a dead integration and is not. Open WebUI's own documentation states that saving a connection does not test it, that the Verify button calls the provider's /models endpoint, and that if that call fails "this does not mean the provider is incompatible: chat completions will still work" — you type the model ids into the per-connection Model IDs allowlist instead. Filling that allowlist is worth doing regardless: on a catalog with image, video and music models, an empty filter puts models a chat window cannot call into the picker.

Kunavo publishes a setup guide for this client. That is a published configuration reference, not a compatibility test — Open WebUI has not been runtime tested here against Kunavo's endpoint, and everything above was read from Open WebUI's released source and its own documentation. Keep a working route available while you try it, run one bounded day, then read what your account actually recorded. Start at the Open WebUI integration guide, and create a Kunavo account when you are ready to fund a key.

FAQ

Open WebUI pages, repository, commit history and package checked September 19 and re-checked September 21, 2026; the 404s on openwebui.com/pricing and openwebui.com/enterprise were fetched directly, and every configuration default cited was read at released tag v0.11.3 rather than at main. Not checked: managed-hosting prices, any enterprise dollar figure, the token overhead of the default background tasks, Open WebUI's own usage dashboards, and any end-to-end run of Open WebUI against Kunavo. Kunavo token rates come from the live catalog, and every dollar example here is illustrative token arithmetic.