TL;DR: Every recent llama-server binary ships a full SvelteKit chat interface, served automatically at http://127.0.0.1:8080 — no Docker, no pip install, no separate frontend to maintain. It handles file and PDF attachments, image input for vision models, branching chat history, and JSON-schema output. For a solo self-hoster it replaces Open WebUI outright; for multi-user or RAG setups, it doesn’t try to.

	llama.cpp built-in WebUI	Open WebUI	Ollama 0.32 agent
Best for	Solo dev already running llama-server	Teams, RAG, multi-user	Terminal-first quick chat
Install	None — bundled in the binary	Docker container + updates	None (bundled with Ollama)
The catch	No accounts, no server-side history, no RAG	Heaviest to run and maintain	Web search routes through ollama.com

Honest take: If you’re one person on one machine and you already run llama.cpp, stop maintaining an Open WebUI container just to get a chat window. The built-in UI is genuinely good now.

For most of llama.cpp’s life, the answer to “how do I get a ChatGPT-style interface for this?” was “install something else” — Open WebUI in Docker, a Gradio wrapper, or switching to LM Studio entirely. That quietly stopped being true. The project replaced its old barebones test page with a modern SvelteKit application, merged in PR #14839 and now compiled directly into the llama-server binary. The maintainers documented it in Discussion #16938, and tech press spent late 2025 and 2026 writing “I ditched Ollama for llama.cpp’s WebUI” posts.

This guide covers what the built-in UI actually does, the exact commands to run it, the security caveat that matters on a home network, and an honest comparison against Open WebUI and Ollama’s own interactive agent.

What the built-in WebUI is

The WebUI is a standalone SvelteKit project inside the llama.cpp repo that gets compiled and embedded into the C++ server at build time. When llama-server starts, it serves the interface at the root endpoint of the same host and port as the API. There is no second process, no Node runtime on your machine, and no version skew between frontend and backend — the UI you get is the one built for exactly your server version.

That architecture is the whole pitch. Open WebUI is a Python application with its own database, its own auth system, and its own update cadence. The llama.cpp UI is a static bundle your inference server already carries. If you download the prebuilt release binaries or build from source with default flags, it’s there.

Setup: one command

If you already run llama-server, you already run the WebUI. A typical launch:

llama-server -m ./models/qwen3.6-35b-a3b-Q4_K_M.gguf \
  --jinja -c 16384 \
  --host 127.0.0.1 --port 8080

Or pull a model straight from Hugging Face:

llama-server -hf ggml-org/gpt-oss-20b-GGUF --jinja -c 0

Open http://127.0.0.1:8080 in a browser. The chat interface loads at the root URL; the OpenAI-compatible API endpoints (/v1/chat/completions and friends) live on the same port, so tools like Continue.dev can share the server with your browser tab.

Flags worth knowing:

• --jinja — enables the model’s chat template. Use it; without a proper template, instruct models behave strangely in chat.
• -c <n> — context size. -c 0 uses the model’s maximum. The UI won’t warn you about a tiny context the way it won’t warn you in the API either.
• -np N (--parallel) — number of server slots, which the UI uses for parallel conversations. Pair with --kv-unified to share the KV-cache budget across slots instead of hard-splitting it.
• --no-webui — disables the interface entirely if you want an API-only server.

Feature walkthrough

The feature set is deeper than “test page.” Verified against the official guide in Discussion #16938:

Attachments and documents. Drag in text files or PDFs from disk or clipboard. PDFs can be ingested as extracted raw text, or — when you’re running a vision model with a --mmproj projector — as page images, which preserves tables and layout that text extraction mangles.

Vision input. With a multimodal model loaded, you can paste images directly into the conversation.

Chat history with branching. Conversations persist across restarts, stored in your browser’s IndexedDB — not on the server. You can edit or regenerate any message and the UI keeps the alternate branches, plus export and import chats as files. The browser-local storage is a privacy win (nothing written server-side) and a portability loss (history doesn’t follow you to another machine).

Parallel conversations. With --parallel set above 1, multiple chats can generate simultaneously instead of queuing.

Sampling controls. Temperature, top-k, top-p and friends are adjustable per-conversation in the UI, overriding server defaults.

Structured output and rendering. You can enforce a JSON schema on responses, and the UI renders math notation and can preview HTML/JavaScript the model writes.

Recent server builds have gone further — there are experimental --tools, --agent, and MCP-server flags that turn the server into an agentic loop with external tools. The README marks these “do not enable in untrusted environments,” and that warning deserves respect: treat them as a preview, not a daily driver.

The security caveat

The default bind is 127.0.0.1, which is correct and safe: only your machine can reach it. The moment you bind --host 0.0.0.0 to reach the UI from a laptop or phone on your LAN, understand what you’ve exposed: the WebUI has no login system. Anyone who can reach the port can chat with your model and hit the full API.

Mitigations, in increasing order of effort:

1. --api-key <key> — the server accepts one or more comma-separated keys and rejects unauthenticated API calls. This is the minimum for any non-localhost bind.
2. A reverse proxy (nginx or Caddy) in front of port 8080 with basic auth and TLS — the right answer for anything reachable beyond your desk.
3. Don’t expose it at all: SSH port-forwarding (ssh -L 8080:localhost:8080 user@server) gives you remote access with zero new attack surface.

This is the same class of mistake that left thousands of Ollama instances exposed on the open internet. Default binds exist for a reason.

Versus Open WebUI: who still needs the container?

For a single user, the built-in UI removes Open WebUI’s reason to exist: you skip Docker, image pulls, breaking updates, and a second service to babysit. But Open WebUI keeps clear wins the built-in UI doesn’t attempt:

• Multi-user with accounts and permissions — the built-in UI has no concept of users.
• Built-in RAG — document collections, embeddings, and retrieval pipelines. The llama.cpp UI attaches files per-conversation; it does not index a knowledge base.
• Multi-backend management — Open WebUI can front several Ollama and OpenAI-compatible endpoints at once and switch models per chat. llama-server serves what it loaded.
• Server-side history — your chats follow your account, not your browser profile.

If any of those four is a requirement, keep Open WebUI. If none is, the container is pure overhead.

Versus Ollama 0.32’s interactive agent, the split is interface-shaped: Ollama’s agent lives in the terminal and phones ollama.com for web search, while llama-ui is browser-based, attachment-capable, and fully local. They also sit on different runtimes — if you’re weighing those, start with our Ollama vs LM Studio vs llama.cpp comparison. And llama-server runs on remarkably modest hardware — see the ik_llama.cpp CPU-inference review for how far a GPU-less box can go, or runaihome.com for picking local AI hardware that fits your models.

When NOT to use it

• You need shared access for family or a team — no accounts means no boundaries.
• Your workflow is RAG-heavy — per-chat attachments don’t replace an indexed document store.
• You want one UI over many backends and models simultaneously.
• You depend on browser-independent chat history synced across devices.

FAQ

Do I need to install or build the WebUI separately? No. It’s compiled into the llama-server binary — prebuilt releases include it, and source builds embed it by default. If llama-server starts, the UI is live at the server’s root URL unless you passed --no-webui.

Where is my chat history stored? In your browser’s IndexedDB, on your machine — the server keeps nothing. Clearing site data deletes it, and a different browser or device starts empty. Use the UI’s chat export if you want portable backups.

Can I still use the OpenAI-compatible API while the WebUI is enabled? Yes. The UI and the API share one port: the interface is served at /, the API at /v1/.... Editors like Continue.dev, scripts, and the browser tab can all talk to the same running server.

Sources

• guide: using llama-ui — the new WebUI of llama.cpp (Discussion #16938)
• llama.cpp server README (tools/server)
• llama.cpp SvelteKit WebUI PR #14839
• llama.cpp Official WebUI is Finally Here — Communeify

What self-hosting actually costs

Real cost breakdowns for self-hosted AI: hardware floors, power, maintenance hours, and the honest comparison against paying for it. No spam, unsubscribe anytime.

Email address Subscribe