Local-first chat UI for llama.cpp models with branching conversations and file attachments

What they did

They took the llama.cpp WebUI and turned it into a friendlier desktop-style chat app. The fork keeps the llama.cpp server as the model backend but layers on a redesigned interface with DaisyUI themes, Markdown and LaTeX rendering, syntax highlighting, and responsive layouts for mobile and desktop. Conversations are stored in IndexedDB, so history stays in the browser, and users can branch a conversation by editing an earlier message while preserving the original thread. Import and export let chats move between machines. Attachments accept text, images, and PDFs, and generation parameters are exposed in settings alongside streaming responses and performance metrics. The app also works as a PWA with offline capability and ships language packs. Beyond llama.cpp, the same UI can point at LM Studio, Ollama, vLLM, or OpenAI-compatible endpoints by changing the base URL. Two deployment paths are documented: a hosted instance where users set the base URL to their local server, with a mitmproxy reverse-proxy workaround for the HTTPS-to-HTTP browser block, and a full local install where the built UI is served directly by the llama.cpp server via its --path flag. Developers build with Node 22 or newer using npm ci, npm run build, and npm start for a live dev server.

How it went

The result is a working, visually polished chat front end that runs entirely against local models, with conversation branching and attachments as the standout features. It is a community fork rather than an official release, so polish is good but the project depends on upstream llama.cpp server behavior and on users correctly configuring base URLs and certificates.

Worth knowing

The hosted-instance route hits mixed-content blocking because browsers refuse HTTP calls from HTTPS pages; the documented mitmproxy workaround requires trusting a certificate and is not beginner-friendly. The local install path assumes you already have a llama.cpp server binary and a quantized GGUF model. Conversation data lives in browser storage, so clearing site data loses history unless exported. Multi-provider support depends on each backend exposing an OpenAI-compatible API.

Wiring

The llama.cpp server is the model runtime: it loads a quantized GGUF file and exposes an HTTP API on port 8080. The UI is a static front end built with npm ci and npm run build, then either served by the llama.cpp server through its --path flag or hosted separately. In the hosted case, the UI's General settings hold a Base URL field pointing at the local server, and because browsers block HTTP requests from HTTPS pages, a mitmproxy reverse proxy on port 8443 bridges the two; users visit the proxy once to trust its certificate, then reload the UI. Conversations persist in IndexedDB, streaming uses Server-Sent Events, and the same base URL field can be repointed at Ollama, LM Studio, vLLM, or an OpenAI-compatible endpoint.

Try it yourself

Set up llama.ui against my local llama.cpp server. First, check whether a llama.cpp server binary and a GGUF model are present in this repo or on disk; if not, tell me what to download. Then build the UI with npm ci and npm run build, and give me the exact server command using --path pointing at the build output, --host 0.0.0.0, --port 8080, and --ctx-size 4096. Finally, confirm the base URL setting I should use in the UI and note any HTTPS or certificate issues I might hit if I use the hosted instance instead.