Building your own chat app for nothing

The gap the API leaves

An API key gives you models and no product. A free, open-source front-end fills that gap, and the result is a chat application you control: your system prompt, your model choice, your conversation history stored where you decide.

Four are worth knowing, all free and open source:

• Open WebUI: the most complete. Runs in a browser, supports multiple providers and local models at once, has document upload with retrieval, web search and multi-user accounts. Installed with one Docker command.
• LibreChat: similar scope, strong on multi-provider setups, plugins and organisational use.
• Chatbox: a simple desktop application. Install it, paste a key, use it. The easiest starting point by a distance.
• Jan: a desktop app built around running models locally, which also accepts remote keys.

What you gain

Every model in one window. Switch between providers mid-conversation. This is the fastest way to build the two-tool habit, because a second opinion is one dropdown away rather than another tab and another login.

Your own system prompt. Set it once (how you want to be addressed, what you do, spelling conventions, how long answers should be) and it applies everywhere, on every model, without a company’s instructions competing with yours.

Conversations that are yours. Stored in a database on your machine or your server. Exportable, searchable, backed up by you, not deleted when a subscription lapses.

Cost visibility. Most of these show token counts and running spend per conversation. Seeing the number after each message changes how you use the tool within a week.

A local model beside a frontier one. The same window, one dropdown apart. Confidential material goes to the local one; everything else goes wherever is best. Nothing about this arrangement requires you to think about it after setup.

What you give up

Be honest about this, because these tools are often oversold.

• Polish. Voice modes, mobile apps and slick document handling lag well behind the commercial products.
• The built-in extras. Web search, code execution and file retrieval exist in some of these, and they are more work to set up and less reliable than the versions inside a paid product.
• Support. When something breaks, you are reading issues on a code-hosting site.
• Maintenance. Updates are yours to apply. A front-end left unpatched for a year on a public server is a genuine security problem.

Getting one running

The lowest-effort path is Chatbox: download, install, paste a key, done in five minutes. The most capable is Open WebUI, which needs Docker:

docker run -d -p 3000:8080 \
  -v open-webui:/app/backend/data \
  --name open-webui ghcr.io/open-webui/open-webui:main

Then open localhost:3000, create the first account, and add your provider keys in settings. On the same machine it will also find a local model served by Ollama without further configuration.

The setting worth changing on day one

Most front-ends send the entire conversation with every message, which is correct for coherence and expensive for long chats. Nearly all of them have a setting (often called context window, message limit or history depth) that caps how many previous turns get resent.

Set it to something like the last ten messages. You will barely notice the difference in quality, and on a long working conversation it can cut the cost by most of it. This is the single highest-value configuration change in any of these applications, and it is off by default in all of them.

Two cautions worth stating

Do not expose it to the internet carelessly. These tools are designed to be run on your own machine or behind a login. A copy on a public address with your API key inside is a bill waiting to happen and, if it holds documents, a data leak.

Check what any front-end sends. Most of these are honest and their code is public, which is the point of choosing open ones. Applications from app stores that offer the same convenience are frequently not: some route your requests through their own servers, where your text and sometimes your key can be read. If the app cannot explain where your request goes, assume it goes through them.

That last point generalises past this lesson. A front-end sits between you and the model and sees everything. Choosing one whose code you or somebody else can read is not paranoia: it is the only way that question gets answered at all.