Open WebUI mit einem Custom OpenAI-kompatiblen Endpoint verbinden.

Kurzantwort: eine Connection in Admin Settings.

Öffne als Admin die Admin Settings, gehe zu Connections und klicke unter dem Abschnitt OpenAI API auf Add Connection. Zwei Felder zählen: die URL, gesetzt auf https://api.apisrouter.com/v1, und der API-Key. Speichern, und Open WebUI fragt die /v1/models-Liste des Endpoints ab, um den Model-Selector zu befüllen; prüfe mit der Check-Funktion der Connection, dann wähle in einem neuen Chat eine beliebige Catalog-ID. Auf diesem Weg hinzugefügte Connections gelten für den gesamten Workspace: Jeder Nutzer deiner Open-WebUI-Instanz sieht die Modelle, vorbehaltlich der von dir konfigurierten Model-Access-Kontrollen. Dieselben Werte können stattdessen zur Deploy-Zeit als Umgebungsvariablen ausgeliefert werden, OPENAI_API_BASE_URL und OPENAI_API_KEY, was der sauberere Weg ist, wenn die Instanz per Compose-Datei statt per Klick eingerichtet wird.

URL:      https://api.apisrouter.com/v1
API Key:  sk-YOUR-APISROUTER-KEY

Save → models auto-populate from /v1/models
(optional) Model IDs allowlist to curate the selector

Wie Open WebUI OpenAI-Connections nutzt.

Open WebUI (rund 145K GitHub-Stars) ist das Standard-Self-Hosted-KI-Chat-Frontend: ein vollwertiger Web-Client mit Nutzern und Berechtigungen, RAG und Knowledge Collections, Tool-Calling und Modell-Verwaltung, klassischerweise mit Ollama für lokale Modelle gepaart, aber genauso zu Hause im Gespräch mit entfernten APIs. Sein Connection-Modell ist additiv. Der Ollama-Abschnitt deckt lokale Runtimes ab; der Abschnitt OpenAI API deckt jeden Endpoint ab, der den Standard-Chat-Completions-Dialekt spricht, und du kannst mehrere Connections nebeneinander hinzufügen. Jede Connection trägt ihre Modell-Liste zum gemeinsamen Selector bei, jede hat ihren eigenen Key, und jede kann ausgeschaltet werden, ohne ihre Konfiguration zu löschen. Anfragen tragen die Modell-ID als reinen String zu welcher Connection auch immer sie bedient. Dieses Design bedeutet, dass eine Gateway-Connection nichts verdrängt: Deine lokalen Modelle laufen weiter kostenlos pro Token über Ollama, während claude-sonnet-4-6, gpt-5.5, gemini-3.5-flash und deepseek-v4-pro zu Selector-Einträgen für die Konversationen werden, die Frontier-Qualität brauchen. Ein Key deckt alle ab, und die Nutzung bleibt admin-seitig lesbar, weil Cloud-Traffic genau eine Stelle verlässt.

Deploy-Time-Setup: Umgebungsvariablen.

Für Docker-Compose- und Kubernetes-Deployments kann die Connection Teil des Manifests sein. OPENAI_API_BASE_URL nimmt den Endpoint, OPENAI_API_KEY den Key; die Instanz startet mit der bereits vorhandenen Connection. Mehrere Endpoints werden über die Plural-Formen unterstützt (OPENAI_API_BASE_URLS und OPENAI_API_KEYS mit semikolon-getrennten Werten), falls du mehr als eine entfernte Quelle betreibst. Zwei operative Hinweise. Erstens: Über die UI gesetzte Werte werden in Open WebUIs Datenbank persistiert und haben nach dem ersten Start Vorrang vor Umgebungs-Defaults, ein dokumentiertes Verhalten, das Operatoren regelmäßig überrascht, wenn sie das Env ändern und nichts passiert; passe bestehende Connections in Admin Settings an, oder setze ENABLE_PERSISTENT_CONFIG=false, wenn die Umgebung maßgeblich bleiben soll. Zweitens: Ist die Modell-Liste des Endpoints groß, nutze die Model-IDs-Allowlist der Connection, um zu kuratieren, was deine Nutzer sehen; ein Vier-Einträge-Selector wird genutzt, ein Zweihundert-Einträge-Selector wird nur weggescrollt. Versionshinweis: Menü-Formulierungen haben sich über das schnelle Release-Tempo des Projekts verschoben (Settings vs. Admin Settings, Abschnittsnamen innerhalb von Connections), also such auf älteren Builds nach dem Paar OpenAI API Base URL und Key, wo auch immer Connections leben.

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    environment:
      - OPENAI_API_BASE_URL=https://api.apisrouter.com/v1
      - OPENAI_API_KEY=sk-YOUR-APISROUTER-KEY
    ports:
      - "3000:8080"

Modellauswahl für einen Multi-User-Workspace.

Da jedes Cloud-Modell über einen Key abrechnet, ist A/B-Testing eine Selector-Wahl. Lass dieselbe Team-Workload zwei Wochen auseinander auf zwei Kandidaten-Defaults laufen und lass die Nutzungsansicht pro Modell in der APIsRouter-Konsole entscheiden, pro Modell und pro Tag, statt anhand von Benchmarks zu raten.

• Die Wahl des Default-Modells leistet in einer geteilten Instanz die meiste Arbeit. claude-haiku-4-5-20251001 oder gemini-3.5-flash als Workspace-Standard hält die Kosten pro Konversation bei gelegentlicher Nutzung flach.
• claude-sonnet-4-6 und gpt-5.5 gehören für Entwürfe, Analysen und Code-Fragen in den Selector; Nutzer steigen hoch, wenn die Aufgabe es verdient.
• RAG-Pipelines vervielfachen Input-Token: Jede Antwort trägt abgerufene Chunks. deepseek-v4-pro lohnt einen Test als RAG-Arbeitspferd, wo Long-Context-Handling pro ausgegebenem Token das entscheidende Merkmal ist.
• Halte wirklich private Inhalte auf lokalen Modellen über Ollama und leite alles andere über das Gateway; der Selector führt beide Spuren ehrlich.
• Nutze die Model-IDs-Allowlist als Policy: Was nicht im Selector steht, kann dich im Nutzungslog nicht überraschen.

Nutzungsbasiert · unter offiziellem Preis

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

Fehlerbilder speziell für Open WebUI.

Dass nach dem Hinzufügen der Connection keine Modelle erscheinen, ist die häufigste Meldung. Die Ursachen in Reihenfolge: der Key ist gegen /v1/models fehlgeschlagen (mit der Verify-Funktion der Connection prüfen), der URL fehlt das /v1-Suffix, oder der Connection-Schalter ist aus. Open WebUI baut den Selector aus dem, was die Liste zurückgibt, also bedeutet ein leerer Selector, dass der Listing-Call fehlgeschlagen ist oder nichts zurückgab. Umgebungsänderungen, die ignoriert wirken, sind die oben beschriebene Persistent-Config-Regel: Nach dem ersten Start gewinnt die Datenbank über die Umgebung bei Einstellungen, die die UI verwaltet. Bearbeite die Connection in Admin Settings, oder deaktiviere Persistent Config explizit. Ein Modell, das gelistet wird, aber im Chat Fehler wirft, ist meist eine ID, die die Liste zeigt, dein Key aber nicht nutzen kann, oder ein Tippfehler durch manuelles Bearbeiten der Model-IDs-Allowlist; vergleiche mit der rohen /v1/models-Ausgabe. Und halte die Spuren beim Debuggen auseinander: Ollama-Connection-Probleme und OpenAI-Connection-Probleme sehen vom Chat-Fenster aus identisch aus. Die Connections-Seite zeigt, zu welcher Spur ein Modell gehört; teste die fehlerhafte Spur direkt, bevor du annimmst, die ganze Instanz sei down.

Wer Open WebUI über ein Gateway leitet.

• Teams, die ein Chat-Frontend für alle selbst hosten und Frontier-Modelle verfügbar machen wollen, ohne einzelnen Nutzern Vendor-Keys auszustellen.
• Ollama-Nutzer, die lokale Modelle für private Arbeit behalten, aber Claude- und GPT-Qualität im selben Selector für die Konversationen wollen, die es brauchen.
• Admins, die die Cloud-Rechnung lesbar brauchen: eine Connection, ein Key und ein Nutzungslog pro Modell statt Belege von vier Vendoren.
• Operatoren in Regionen, wo manche Vendor-Anmeldungen mühsam sind; Zugang auf Guthabenbasis ohne Kartenpflicht entfernt die Abhängigkeit pro Provider.
• Homelab-Betreiber, die Open WebUI für den Haushalt betreiben, wo ein einzelnes Prepaid-Guthaben leichter zu überblicken ist als jedes Abo.

Endpoint prüfen und den ersten Chat debuggen.

Beweise den Endpoint zuerst vom Server aus, besonders bei containerisierten Deployments, wo das Netzwerk des Containers nicht das deines Laptops ist. Eine Modell-Liste und eine Chat-Completion vom Host aus bestätigen die Gateway-Hälfte, bevor Open WebUI ins Bild kommt. Füge dann die Connection hinzu und beobachte, wie sich der Selector füllt. Authentifizierungsfehler sind das Key-Feld; ein leerer Selector ist der Listing-Call; ein verdoppelter Pfad (/v1/v1/...) in Server-Logs bedeutet, dass das URL-Feld bereits ein /v1 trug und etwas ein weiteres anhängte, also lies die URL exakt so, wie sie gespeichert wurde. Sobald Chats laufen, zeigt die APIsRouter-Konsole Modell, Token-Zahlen und Ausgaben pro Anfrage. Für eine Multi-User-Instanz ist das die entscheidende Zahl: welche Modelle deine Nutzer tatsächlich wählen und was eine Woche des Workspace wirklich kostet, pro Modell, pro Tag, auf einer Seite.

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $APISROUTER_API_KEY" | head -50

curl -s https://api.apisrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $APISROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-haiku-4-5-20251001",
       "messages":[{"role":"user","content":"ping"}]}'

Häufige Fragen