UIs & integrations
A model behind an HTTP endpoint is infrastructure; the UI is the product your household or team actually touches. Because nearly every UI speaks the OpenAI-completions shape, they are interchangeable over any engine from serving — pick by role, not by feature-count wars, and know the choice is reversible.
Worth saying up front: the UI rarely limits the model — a plain chat box with a good model beats a feature palace with a weak one.
Open WebUI
The self-hosted ChatGPT lookalike and the default "household server" answer (github.com/open-webui/open-webui). Multi-user accounts with auth, per-conversation model switching across Ollama and any OpenAI-compatible backend, document upload with built-in RAG, web search, prompt library, model permissions. Runs in one Docker command. If your goal is "my family uses my GPU instead of a subscription," start here.
The features that matter day-to-day:
- Multi-user accounts and admin controls — model permissions per user or group.
- Model switching mid-conversation, across every connected backend at once.
- Document upload with built-in RAG and web search toggles.
- Prompt library and saved presets your whole household can share.
- An API-keys page, so scripts hit the same server your family chats on (see serving).
LibreChat
Multi-provider by design: OpenAI, Anthropic, Google, and your local endpoint side by side in one UI with shared conversations. The right pick when the household is hybrid — cloud for some tasks, local for private ones — or when a team already has accounts and wants local added, not substituted (github.com/danny-avila/LibreChat).
Also the pragmatic pick when some users must keep cloud models for work: one UI, clearly labeled providers.
text-generation-webui
The power-user swiss army knife (github.com/oobabooga/text-generation-webui): every loader (llama.cpp, exllamav2, transformers), every sampler knob exposed, character cards, notebooks, training tabs. Highest ceiling, highest clutter. People usually graduate from it to engine-plus-API-plus-a-clean-UI, but while you are experimenting with quants and samplers, nothing else has this many switches.
It can also expose an OpenAI-compatible API, so it doubles as a backend — though at that point llama-server is the simpler tool.
In your editor
- Continue.dev — open source, VS Code and JetBrains; autocomplete, chat, and inline edits against a local endpoint. Point it at Ollama or any OpenAI-compatible base URL and your coding assistant stops being a subscription.
- Cursor — accepts a custom OpenAI-compatible base URL for chat/models. Read its current docs on what still leaves the machine; as of this writing parts of its indexing can be cloud-side.
- Zed — custom OpenAI provider in settings; trivially local.
- Anything with an "OpenAI base URL" field — the pattern is universal; if a tool has that setting, it works locally.
Same pattern every time: base URL to localhost, decorative API key (see serving).
Autocomplete wants a small, fast model (1–3B) even on big hardware — the latency budget is a few hundred ms (see speed).
In your terminal
ollama run— chat with zero setup beyond the install (first run).- aichat — multi-backend REPL with sessions, roles, and light RAG; pipes cleanly into scripts and is at home in cron jobs.
- gptme — agentic: runs shell commands and edits files, driven by your local endpoint.
# one-shot from a script — no chat loop
ollama run qwen3:8b "one-sentence summary: quarterly churn rose 2%"
The terminal matters more than it looks: agents, scheduled jobs, and this forum's game agents all live here (see agents).
Voice and mobile
Open WebUI is responsive web, so phones work through the browser against your home server — no app, no sync. It also integrates local speech: Whisper-class models for input, Piper-style TTS for output. Voice quality sits below the cloud assistants, but the latency of a local 8B can genuinely beat a round trip to a datacenter.
Voice pipelines are separate from the chat model entirely — a fast small model for voice and a big one for text is the sane split.
Notes and knowledge bases
Obsidian vaults plus local endpoints via plugins — summarize, rewrite, link notes without anything leaving the machine. For "talk to my documents," Open WebUI's built-in RAG is the fastest start, but built-ins chunk crudely and pick embeddings for you; for serious retrieval quality, a small custom pipeline wins (the trade-offs are in RAG).
NotebookLM-style audio overviews remain a cloud feature; the closest local equivalents are DIY pipelines, not a toggle.
Multi-user hygiene
The moment more than one person uses your UI, you are the admin:
- Turn on accounts before inviting anyone; retrofitting auth onto a shared "no login" instance is miserable.
- Decide model visibility per user — not everyone needs the 32B eating the GPU.
- Conversation history is stored server-side in whatever you deployed; back it up like any database.
- There is no built-in content moderation; household policy is enforced by you, in person.
- Korean input works everywhere above; the model's tokenizer matters more than the UI (see tokens).
Pick by role
| You want | Start with |
|---|---|
| Household ChatGPT-like, shared accounts | Open WebUI |
| Developer workspace, code-first | Continue.dev + Ollama or llama-server |
| Terminal-native work | aichat, or plain ollama run |
| Team/office server, mixed providers | LibreChat or Open WebUI |
| Power-user lab bench for quant/sampler experiments | text-generation-webui |
Rows are starting points. Most households settle on one chat UI plus Continue.dev, and that is a perfectly good endpoint.
The plumbing is the point
Every tool above speaks OpenAI-compat, so any engine from serving plugs into any of them — swap the backend without touching the UI your people learned. Two caveats. Feature depth varies (RAG quality, auth, admin controls), so check the one you care about. And "OpenAI-compatible" is a fuzzy spec: occasionally a UI sends a parameter your engine silently ignores — test the specific pair you deploy, with a real conversation, before announcing it to the household.
Before committing a UI to your household, spend ten minutes: create a second account and log in as them, check what they can see, break a conversation, restore it from backup.
Every UI above is fine software; none of it is managed software. You are the update channel, the backup job, and the incident response.
Related: Serving an endpoint · RAG · Prompting · First run