Imagine opening a new chat every morning and starting with: "So, I'm 31, 180 cm tall, weigh 85 kg, I'm trying to get to 75 kg, no dairy, no mushrooms, fish only as tuna, today is Tuesday so office day, no breakfast, the day starts with lunch and..."
After two weeks, you're done with that.
OpenWebUI makes it unnecessary.
What OpenWebUI is — and why it's worth knowing
OpenWebUI is a browser-based chat interface — basically like ChatGPT, but self-hosted. It runs on your PC or server, connects to local models via Ollama, and simultaneously to remote APIs like Gemini, OpenAI, or OpenRouter. One interface, all your models, full control.
Installation is a single Docker command:
docker run -d -p 3000:80 \
--add-host=host.docker.internal:host-gateway \
-v open-webui:/app/backend/data \
--name open-webui --restart always \
ghcr.io/open-webui/open-webui:mainThe interface is then available at http://localhost:3000. That's it.
But the really interesting part isn't the models OpenWebUI ships with — it's the ones you build yourself.
What a "custom model" in OpenWebUI actually means
No training, no Python, no server setup. A custom model in OpenWebUI is the combination of an existing language model (Gemini, GPT-4o, Llama — whatever you use) and your personal system prompt, plus optional knowledge bases and tools. The result shows up in the model selector like any normal LLM. Select it, type your message, done.
Every time you open it, the AI automatically has the context you'd otherwise have to retype.
A real example: calorie assistant
Here's a simplified system prompt I actually use:
About me: male, 31 years old, 85 kg, 180 cm.
Weekdays: office, no breakfast — day starts with lunch.
Friday evenings: karaoke bar (factor in the activity).
Goal: slowly towards 75 kg, moderate deficit is enough.
Don't eat: dairy, mushrooms, fish (except tuna).
Use the GetTime tool for the current day of the week.
Task: I'll tell you what I ate today.
You calculate:
- Daily energy requirement (incl. activity)
- Specific target (with weight loss goal)
- Calories so far (broken down per meal)
- Resulting deficit or surplusI've also attached a few calorie reference tables as a knowledge base.
The result: I open the model, type "150g pasta with 125g meat sauce" — and get a clean breakdown. No context copy-paste, no starting from scratch.
The prompt above was my first draft. The current version is considerably more detailed and personalised — but as a starting example it does the job.
The surprising finding while testing
What became clear: Almost every language model makes arithmetic errors when meals accumulate over the day.
They usually estimate the individual meal reasonably well. But when you enter the fourth meal in the evening and ask "what's my day total?", the lunch suddenly disappears from the sum. Or the snack from the third chat turn. More expensive models estimate better per meal — but very few manage the running daily counter cleanly.
Notable exception: Gemini 2.5 Pro. Not a single calculation error in three months.
It's not the cheapest model — currently around $2.50 per million input tokens and $10 per million output tokens. But what does a single query actually cost?
Here it's worth looking at how OpenWebUI uses that knowledge base in the first place: the calorie tables don't get pasted into every prompt in full. OpenWebUI stores them in a vector store — a database that makes text searchable by meaning — and per query sends along only the few snippets that are actually relevant: the rows for the foods you mentioned, not the whole table. (How that works under the hood deserves its own article — coming soon.)
Quick back-of-envelope: the system prompt alone is around 600 tokens. The relevant table snippets add an estimated 500 tokens. Add the day's conversation context so far — say 2,000 tokens. That's roughly 3,000 input tokens per query, plus 400 tokens output.
Calculation: 3,000 × $0.0000025 + 400 × $0.00001 ≈ just over 1 cent per query.
In practice, five queries a day adds up quickly — morning check-in, after lunch, after a snack, evening total, plus the occasional "what can I still eat?". That's realistically around $2 per month.
Two arguments for why that's worth it: first, a real nutritionist costs significantly more and doesn't check in with you daily. Second, and more valuable in the long run: you build genuine, hands-on experience with AI in everyday use. You learn how to phrase prompts, which models suit which tasks, how to build a useful knowledge base — and you personalise the system until it actually fits your life. That experience is worth more than any dollar saved.
Prompts with variables — the second useful feature
Beyond models, OpenWebUI also has reusable prompts with built-in placeholders. When you trigger one, OpenWebUI asks for those variables before sending.
Recipe example:
You know my food preferences and intolerances.
Suggest a suitable recipe I can prepare in {{ Time | number:required }} minutes —
for {{ People | number:required }} people.
{{ Extra | textarea:placeholder="Any other restrictions today? e.g. only what's in the fridge" }}Three fields appear when you call it — two of them actual number fields, because number won't accept arbitrary text and required makes them mandatory. Fill them in, send — the model already knows the baseline and only needs what changes.
What this means
AI becomes genuinely useful when it stops being generic. Custom models and prompts in OpenWebUI are the easiest path there — no programming, no external service, no new monthly subscription.
Time investment for your first solid system prompt: one to two hours. After that, it just runs.