Stell dir vor, du öffnest jeden Morgen einen neuen Chat und fängst an: "Also, ich bin 31, 180 cm, wiege 85 kg, ich versuche auf 75 kg zu kommen, ich esse keine Milchprodukte, keine Pilze, Fisch nur als Thunfisch, heute ist Dienstag also Bürotag, kein Frühstück, der Tag beginnt mit dem Mittagessen und..."
Nach zwei Wochen hat man das satt.
OpenWebUI macht das überflüssig.
Was OpenWebUI ist — und warum es sich lohnt
OpenWebUI ist eine browserbasierte Chat-Oberfläche — im Prinzip wie ChatGPT, aber du hostest sie selbst. Sie läuft auf deinem PC oder Server, verbindet sich mit lokalen Modellen via Ollama und gleichzeitig mit Remote-APIs wie Gemini, OpenAI oder OpenRouter. Eine Oberfläche, alle Modelle, volle Kontrolle.
Installiert ist es mit einem einzigen Docker-Befehl:
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:mainDanach ist die Oberfläche unter http://localhost:3000 erreichbar. Das war's.
Aber das eigentlich Interessante sind nicht die Modelle, die OpenWebUI mitbringt — sondern die, die du dir selbst baust.
Was ein "eigenes Modell" in OpenWebUI bedeutet
Kein Training, kein Python, kein Server-Setup. Ein eigenes Modell in OpenWebUI ist die Kombination aus einem bestehenden Sprachmodell (Gemini, GPT-4o, Llama — was auch immer du nutzt) und deinem persönlichen System-Prompt, plus optionaler Wissensdatenbank und Werkzeugen. Das Ergebnis erscheint in der Modellauswahl wie ein normales LLM. Auswählen, tippen, fertig.
Bei jedem Aufruf holt sich die KI automatisch den Kontext, den du sonst mühsam eintippen würdest.
Ein echtes Beispiel: Kalorien-Assistent
Hier ein vereinfachter System-Prompt, den ich tatsächlich im Einsatz habe:
Zu mir: männlich, 31 Jahre, 85 kg, 180 cm.
Wochentags Büro, kein Frühstück — Tag beginnt mit Mittagessen.
Freitags abends: Karaoke-Bar (Aktivität einrechnen).
Ziel: langsam Richtung 75 kg, moderate Reduktion reicht.
Nicht essen: Milchprodukte, Pilze, Fisch (außer Thunfisch).
Nutze das Werkzeug GetTime für den aktuellen Wochentag.
Aufgabe: Ich nenne, was ich heute gegessen habe.
Du berechnest:
- Tagesbedarf (inkl. Aktivität)
- spezifischer Bedarf (mit Abnahmeziel)
- Kalorienzufuhr bisher (aufgeschlüsselt pro Mahlzeit)
- resultierendes Defizit oder ÜberschussDazu habe ich ein paar Kalorientabellen als Wissensdatenbank angehängt.
Das Ergebnis: Ich öffne das Modell, schreibe "150g Nudeln mit 125g Hackfleischsoße" — und bekomme eine saubere Bilanz. Kein Erklärungs-Copy-Paste, kein Neustart.
Der obige Prompt war übrigens mein erster Entwurf. Mittlerweile ist er deutlich detaillierter und personalisierter — als Einstieg und Beispiel reicht er aber allemal.
Die überraschende Erkenntnis beim Testen
Was dabei aufgefallen ist: Nahezu alle Sprachmodelle verrechnen sich, wenn Mahlzeiten über den Tag akkumuliert werden.
Die einzelne Mahlzeit schätzen sie meist vernünftig. Aber wenn man abends die vierte Eingabe macht und "Tagesbilanz?" fragt, fehlt plötzlich das Mittagessen in der Summe. Oder der Snack aus dem dritten Turn. Teure Modelle schätzen die einzelne Mahlzeit besser — den laufenden Tageszähler bringen trotzdem die wenigsten sauber durch.
Rühmliche Ausnahme: Gemini 2.5 Pro. Seit drei Monaten kein einziger Rechenfehler.
Das ist nicht das günstigste Modell — derzeit rund 2,50 $ pro Million Input-Token und 10 $ pro Million Output-Token. Was kostet aber eine einzelne Anfrage tatsächlich?
Hier lohnt ein Blick darauf, wie OpenWebUI die Wissensdatenbank überhaupt nutzt: Die Kalorientabellen wandern nicht komplett in jeden Prompt. OpenWebUI legt sie in einem Vektorstore ab — einer Datenbank, die Texte nach Bedeutung durchsuchbar macht — und schickt pro Anfrage nur die paar Ausschnitte mit, die gerade passen: die Zeilen zu den genannten Lebensmitteln, nicht die ganze Tabelle. (Wie das im Detail funktioniert, ist einen eigenen Artikel wert — kommt noch.)
Kurze Überschlagsrechnung: Der System-Prompt allein sind etwa 600 Token. Die passenden Tabellen-Ausschnitte kommen auf geschätzte 500 Token. Dazu der bisherige Tagesverlauf im Kontext — sagen wir 2.000 Token. Macht rund 3.000 Input-Token pro Anfrage, plus 400 Token Ausgabe.
Rechnung: 3.000 × 0,0000025 $ + 400 × 0,00001 $ ≈ gut 1 Cent pro Anfrage.
Im Alltag kommen schnell fünf Anfragen pro Tag zusammen — morgens, nach dem Mittag, nach dem Snack, abends die Bilanz, zwischendurch "was kann ich noch essen?". Macht realistisch rund 2 $ im Monat.
Zwei Argumente dafür: Erstens, ein echter Ernährungsberater kostet ein Vielfaches davon — und sieht dich nicht täglich. Zweitens, und das ist der langfristig wertvollere Teil: Du sammelst echte, tiefgreifende Erfahrung im alltäglichen Umgang mit KI. Du lernst, wie du Prompts formulierst, welche Modelle für welche Aufgaben taugen, wie du eine Wissensdatenbank sinnvoll aufbaust — und du personalisierst das System so weit, dass es wirklich zu dir passt. Diese Erfahrung ist mehr wert als jeder gesparte Dollar.
Prompts mit Variablen — die zweite nützliche Funktion
Neben Modellen gibt es in OpenWebUI auch wiederverwendbare Prompts mit eingebauten Platzhaltern. Beim Aufruf fragt OpenWebUI diese Variablen ab, bevor es die Anfrage abschickt.
Beispiel Kochrezept:
Du kennst meine Lebensmittelvorlieben und Unverträglichkeiten.
Schlage mir ein passendes Rezept vor, das ich in {{ Zeit | number:required }} Minuten
zubereiten kann — für {{ Personen | number:required }} Personen.
{{ Extra | textarea:placeholder="Weitere Einschränkungen heute? z.B. nur Sachen aus dem Kühlschrank" }}Beim Aufruf erscheinen drei Felder — zwei davon echte Zahlenfelder, weil number keine beliebige Texteingabe zulässt und required sie zur Pflicht macht. Ausfüllen, abschicken — das Modell kennt die Grundbedingungen bereits und braucht nur noch, was sich ändert.
Was das bedeutet
KI wird dann wirklich nützlich, wenn sie aufhört, generisch zu sein. Eigene Modelle und Prompts in OpenWebUI sind der einfachste Weg dorthin — ohne Programmierung, ohne externen Dienst, ohne monatliches Abo auf einer neuen Plattform.
Der Aufwand für den ersten brauchbaren System-Prompt: ein bis zwei Stunden. Danach läuft es.