Beyond Claude & GPT

This blog post is also available in English

TL;DR

Bei ernsthafter KI-Nutzung zählen neben der Modellqualität zunehmend Kosten, Datenschutz und Verfügbarkeit, und genau hier schwächeln proprietäre US-Modelle.
Open-Weights-Modelle bieten EU Data Residency, Zero Data Retention und Anbieterunabhängigkeit: dasselbe Modell gibt es bei vielen Providern, ein Wechsel ändert sein Verhalten nicht.
Unser Setup deckt Chat und Expertenmodelle (OpenWebUI) sowie Coding-Agenten und Produktintegration (LiteLLM als Proxy und Router) ab, mit KI-Inferenz von EU-Providern.
So lassen sich Anbieter transparent wechseln, ohne dass Agenten oder Anwendungen etwas davon merken: günstiger, unabhängiger und eine echte Ergänzung zu Claude und GPT.

Dieser Blogpost ist Teil einer Reihe.

Teil 1: KI-Features für Jira Data Center – ohne Atlassian Cloud
Teil 2: Nebu: Self-made Souveränität
Teil 3: OpenProject: Eine Alternative zu Jira?
Teil 4: Beyond Claude & GPT (dieser Blogpost)

Inspiriert vom Digital Independence Day, der zu Rezepten für digitale Souveränität aufruft, teilen wir hier regelmäßig eigene Lösungsansätze zu Themen, die unsere Kunden bewegen – ab sofort jeden ersten Sonntag im Monat.

Ich gebe zu: Es gibt sie bei uns – die Fraktion, die gerne das Größte, Schnellste und Beste benutzt. Der Bereich KI ist da keine Ausnahme. Aber das ist auch gut so, denn genau mit diesem Antrieb bleiben wir am Puls der Zeit und wissen in unseren Projekten immer, was gerade technisch möglich ist.

KI ist dabei ein sehr breites Feld. Damit wir nicht nur über das neueste Modell reden, sondern über konkrete Einsatzmuster, lässt sich unsere KI-Nutzung im Wesentlichen (bisher) in drei Kategorien einteilen:

Chat zur Informationsrecherche bzw. Nutzung von selbst erstellten «Fachexperten»
Agentic Software Engineering
Nutzung als integraler Bestandteil eines Produkts

Für alle diese Bereiche liefern uns (u. a.) die bekannten US-Anbieter bequeme, komfortable Tools - von ChatGPT über Claude Code bis zu den jeweiligen API-Plattformen. Nachdem die Nutzung von KI in letzter Zeit aber auch «erwachsener» geworden ist, steht nicht mehr nur im Vordergrund, das größte, schnellste und beste Modell zu nutzen, sondern auch praktische, rechtliche und wirtschaftliche Aspekte zu betrachten:

Wie entwickeln sich die Kosten unserer KI-Nutzung?
Wo werden meine Daten verarbeitet, und wer hat im Zweifel Zugriff darauf?
Bin ich in der Lage, ohne großen Aufwand auf einen anderen Anbieter zu wechseln, sollte mein genutztes Modell nicht mehr verfügbar sein?

Allein wenn wir nur Anthropic und OpenAI betrachten, ergeben sich für einen Nutzer schon vier verschiedene Accounts, wenn alle Services genutzt werden sollen, denn sowohl Anthropic als auch OpenAI bieten jeweils sowohl ein Subscription-Angebot (claude.ai und chatgpt.com) als auch ein API-Angebot (Claude Platform und OpenAI Platform). In der Subscription sind Chat und Agentic Coding in Kontingenten enthalten, aber auch hier können selbstverständlich zum Brechen der Limits weitere Münzen eingeworfen werden. Das API-Angebot wird immer im Pay-per-use pro Token abgerechnet. Um da den Gesamtüberblick zu behalten, ist schon ein wenig Aufwand nötig. Wer auf den API-Plattformen außerdem keine Notifications oder Limits setzt, wird sich wundern, wie schnell die Rechnung dort steigen kann.

Die Frage nach dem Datenschutz kann für Standard-Subskriptionen und den typischen Projektgebrauch aktuell von keinem dieser beiden Anbieter befriedigend beantwortet werden, denn beide bieten eine rein auf die EU beschränkte Datenverarbeitung nur auf Anfrage oder gar nicht an. In keinem Fall wird Zero Data Retention geboten - also das restlose Löschen von Prompt- und Antwortdaten unmittelbar nach Auslieferung der Antwort. Begründet wird dies mit Pflichten zur Abuse-Detection. Damit werden Prompts der Nutzer teils bis zu 30 Tage gespeichert. Immerhin verpflichten sich beide Anbieter, bei bezahlter Nutzung ihrer Dienste die Nutzerdaten nicht für das Training ihrer Modelle zu verwenden. Im Bereich von Open-Weights-Modellen sind EU Data Residency, Zero Data Retention und Verzicht auf das Training von Modellen Selbstverständlichkeiten. Es gibt genügend entsprechende Anbieter in der EU ohne Wurzeln zurück in die USA.

Warum möchte ich überhaupt mein Modell wechseln? Nun, zum einen gibt es woanders vielleicht ein besseres oder günstigeres Modell. Vielleicht wurde mir aber auch das bisher verwendete Modell abgestellt. Prominentes Beispiel sind die mittlerweile aufgehobenen Exportbeschränkungen der US-Regierung für Fable- und Mythos-Modelle von Anthropic. Aber auch GPT-5.6 muss sich aktuell erst einer Prüfung unterziehen, bevor es allgemein verfügbar gemacht werden darf. Über die wahren Hintergründe dieser Beschränkungen und Verzögerungen wird viel spekuliert, woran wir uns hier nicht beteiligen wollen. Es zeigt aber, dass die Verfügbarkeit nicht garantiert ist. Diese Situation ist in (mindestens) zweierlei Hinsicht problematisch:

Wenn proprietäre US-Modelle einer Beschränkung unterliegen, betrifft dies alle Anbieter dieser Modelle. Nicht nur Anthropic selbst darf sie nicht anbieten, auch Provider wie AWS Bedrock dürfen sie nicht anbieten. Die Modelle sind also faktisch nicht nutzbar. Open-Weights-Modelle sind hier immun. Einmal veröffentlicht, können die Weights von jedem heruntergeladen und das Modell betrieben werden.
Ein Wechsel weg von den proprietären Frontier-Modellen zu einem alternativen Modell mag technisch nur eine API-Umstellung sein, kann fachlich aber die Ergebnisse der KI-Anwendung stark beeinflussen, sodass auch mühsam erstellte Prompts komplett angepasst werden müssen, um auf ähnliche Ergebnisse zu kommen. Bei Open-Weights-Modellen gibt es viele Anbieter für die gleichen Modelle. Wenn ich Probleme mit einem Anbieter habe, wechsle ich zu einem anderen - das Modell und sein Verhalten bleiben aber die gleichen.

Um all diese Punkte im Griff zu behalten, möchten wir euch hier ein System aus quelloffener Software und Open-Weights-Modellen vorstellen, welches die drei Kategorien und die erwähnten Aspekte adressiert.

Das Tooling

Die erste Überlegung ist herauszufinden, was wir selbst «betreiben» wollen und was wir von existierenden Providern nutzen wollen. Wo der Betrieb eines Servers mit entsprechender Software für den Chat und API-Zugang noch recht einfach machbar ist, geht die Überlegung bei der KI-Inferenz schon weiter ins Detail. Offene Modelle gibt es in sämtlichen Größen von «läuft auf meinem Rechner» bis «braucht mehr als 4 GPUs». Wenn wir nun annehmen, dass wir gerne moderne, große Open-Weights-Modelle nutzen wollen, die mit GPT und Opus konkurrieren können, landen wir zum Datum des Erscheinens dieses Artikels (05.07.2026) unweigerlich bei GLM-5.2 und Kimi K2.7. Mit 744B und 1T Parametern ist die notwendige Hardware beträchtlich. Das empfohlene Setup für GLM-5.2 mit fp8-Quantisierung ist 8x Nvidia H200, und da reden wir über den grundlegenden Betrieb und noch nicht über die Anzahl der parallelen Benutzer.

Der aktuell bei uns im Betrieb befindliche Sweetspot ist:

Zentrale Zugänge zu Chat und API selbst hosten
KI-Inferenz von EU-Providern beziehen

Die drei Hauptanwendungsbereiche decken wir dabei mit folgenden Tools ab:

Chat, Recherche und Expertenmodelle -> OpenWebUI
Coding Agents -> LiteLLM
Produktintegration -> LiteLLM

In unserem konkreten Fall sieht der Überblick über das Gesamtsystem so aus:

Architecture diagram: Browser to OpenWebUI and LiteLLM Proxy/Router, routing to AI providers (StackIt, Mistral, TensorX, Scaleway, Novita). — Eine Übersicht über die verwendeten Systeme und Komponenten

Sofern das System nicht nur für die eigene, private Verwendung gedacht ist und auch personenbezogene Daten anderer Personen verarbeitet werden, so ist es wichtig, auf AVVs (Auftragsverarbeitungsverträge) mit allen datenverarbeitenden Parteien zu achten. Im Wesentlichen also dem Hosting-Provider für OpenWebUI und LiteLLM und den KI-Inferenz-Providern.

Auch beim Betrieb sollte man die laufende Pflege nicht unterschätzen: Modelle werden aktualisiert, Provider ändern Preise oder schränken Angebote ein, und VirtualKeys samt Budget-Limits wollen regelmäßig überprüft werden. Der Mehraufwand hält sich in Grenzen, aber er ist nicht null.

OpenWebUI für Chat und Expertenmodelle

OpenWebUI bietet ein komfortables Web-Interface ähnlich denen von ChatGPT oder Claude. Nur, dass eben im Hintergrund offene KI-Modelle von verschiedensten Anbietern verwendet werden können, sei es selbst gehostet oder per API eines Providers. Neben dem simplen Chat bietet OpenWebUI eine ganze Reihe an Funktionalitäten, die es erlauben, weiteres Wissen einzubeziehen.

Notizen erlauben es, Text oder Sprache festzuhalten und in Chat-Anfragen zu durchsuchen
Wissen erlaubt es, Daten in eine Vektordatenbank einzulesen und auf diese per RAG zuzugreifen
MCP erlaubt es, auf eine Vielzahl verfügbarer Informationsquellen per MCP zuzugreifen

Mit diesen Funktionalitäten kann ich mir also eine Wissenszentrale aufbauen, sei es projektspezifisch oder firmenweit.

Beispielsweise erlaubt es das Wissen-Feature, einen Experten für ein bestimmtes Thema zu bauen. Wir haben das bei uns exemplarisch mit dem Terraform-Provider von StackIt probiert. Die Dokumentation dafür ist frei verfügbar als Sammlung von Markdown-Dateien und kann als «Wissen» in OpenWebUI eingelesen werden. Erstellen wir nun ein neues Modell in OpenWebUI, so können wir ein Grundmodell wie GLM-5.2 mit Wissen aus OpenWebUI verknüpfen. Dieses neue Modell nennen wir beispielsweise «StackIt Terraform Expert». Zusammen mit einem passenden System-Prompt für das neue Modell können wir nun Fragen zur Erstellung von Terraform-Code für StackIt stellen.

Ein anderes Szenario ist der Zugriff auf firmeninterne Informationen. Per MCP können Modelle in OpenWebUI an Quellen wie OpenCode, Jira und Confluence angeschlossen werden. Die allseits beliebte Frage, wo denn das aktuelle Folien-Template liegt – und noch so viel mehr – kann die KI somit ebenfalls beantworten.

Für OpenWebUI gibt es im Übrigen auch gute mobile Apps, die das eigene KI-System unterwegs bequem nutzbar machen. Gute Erfahrungen habe ich dabei z. B. mit der iOS-App Conduit gemacht.

Technische Details

Auch wenn das Token-Volumen über OpenWebUI verschwindend gering im Vergleich zur Verwendung von Coding Agents ist, wollen wir auch diesen Verbrauch gerne tracken. Daher legen wir in LiteLLM einen eigenen VirtualKey an, mit dem wir OpenWebUI über LiteLLM mit KI-Modellen versorgen. Das bietet uns außerdem die Möglichkeit, für OpenWebUI transparent den Anbieter eines KI-Modells zu wechseln.

LiteLLM für Coding Agents und Produktintegration

Überall, wo KI über eine API angesprochen werden muss, kommt LiteLLM als Proxy und Router ins Spiel. Die Konsolidierung aller KI-API-Aufrufe über LiteLLM bietet uns folgende Vorteile:

Zentrales Kosten- und Nutzungstracking
Transparentes Auswechseln des Anbieters eines Modells
Individuelle, projekt- oder anwendungsspezifische Budgets
Ein und dieselbe BaseURL, egal welches Modell ich nutzen möchte

Tatsächlich bietet LiteLLM noch eine ganze Menge mehr an Features, aber das sind erst mal die wichtigsten in diesem Kontext.

Model list table showing IDs, providers, credentials, costs (In/Out), and action toggles for multiple LLMs. — Liste der in LiteLLM eingepflegten Modelle

Die Einrichtung innerhalb LiteLLM beginnt damit, die gewünschten Modelle und Provider-Credentials anzulegen. Wenn der Provider LiteLLM schon bekannt ist, wie z. B. bei Novita, dann werden viele Informationen zum Modell automatisch ausgefüllt. Das betrifft vor allem die Preise für Input- und Output-Tokens und Cache-Reads. Provider können aber auch angelegt werden, sodass dann die Preisinformationen manuell an den Modellen gepflegt werden müssen.

Um die gerade eingerichteten Modelle über LiteLLM nutzen zu können, werden in LiteLLM VirtualKeys (API-Keys) benötigt. Diese können einem Nutzer oder auch einem Nutzer im Kontext eines Teams zugeordnet sein. Das ist sinnvoll, wenn die KI-Nutzung pro Projekt andere Budget-Limits haben soll.

Bar chart “Top Public Model Names”: eu.glm-52 leads (~$43), then eu.deepseek-v4-pro, eu.mistral-medium-3.5, eu.kimi-k27-code, us.qwen-37-max. — Chart mit den meistgenutzten Modellen nach Kosten

Bar chart titled “Daily Spend” (2026-06-29 to 2026-07-03), peaking at ~$24 and dipping to ~$5 on 2026-07-01. — Chart mit Kosten pro Tag

Aus den verbrauchten Token und den Preisinformationen erstellt LiteLLM dann diverse Charts, in denen Kosten und Nutzung aus vielen verschiedenen Blickwinkeln sortiert dargestellt werden, zum Beispiel:

Kosten pro VirtualKey
Kosten pro Modell
Kosten pro Tag
Kosten pro Team

Interessant zu erwähnen ist an dieser Stelle auch, dass Anthropic- und OpenAI-Modelle «durch» LiteLLM genutzt werden können. Das funktioniert auch für Benutzer, die eine Subscription haben. LiteLLM bietet hierfür zwei Funktionen, «Forward client headers to LLM API» und «Forward LLM provider auth headers», die dafür sorgen, dass separate Header, die von den Coding Agents für den Login bei Anthropic und OpenAI genutzt werden, durchgeschliffen werden.

KI-Inferenz per API-Provider

Bei der Recherche und dem Testen diverser Inferenz-API-Provider hat sich das Bild in den letzten Monaten stark verändert. Waren es Anfang dieses Jahres noch hauptsächlich US-Provider wie z. B. Novita, die zeitnah aktuelle Open-Weights-Modelle im Programm hatten, so gibt es mittlerweile mehrere Provider aus der EU ohne US-Wurzeln, die auch mit wenig Verzögerung aktuelle Modelle im Repertoire haben. Gute Anlaufstellen sind da z. B.:

TensorX aus Irland
Scaleway aus Frankreich

Sogar innerhalb Deutschlands gibt es mit StackIt und IONOS Provider für KI-Inferenz-APIs, allerdings waren bei unseren letzten Tests dort leider nur kleinere oder veraltete Modelle verfügbar.

Nutzung

Für die Nutzung gibt es hier noch ein paar praktische Hinweise zur Anbindung von Coding Agents und Anwendungen an LiteLLM. Außerdem schauen wir uns an, wie in OpenWebUI ein Expertenmodell erstellt werden kann.

Verwendung von Coding Agents mit LiteLLM

Hier gibt es einige Beispiele, wie Coding Agents mit LiteLLM verbunden werden können. Die Modell-ID ist dabei immer so zu wählen, wie sie in LiteLLM definiert wurde (vgl. Screenshot oben).

Claude Code

Claude Code wird in ~/.claude/settings.json konfiguriert. Der Inhalt sollte in etwa so aussehen:

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://url.zu.litellm.tld",
    "ANTHROPIC_AUTH_TOKEN": "${LITELLM_VIRTUAL_KEY}",
    "ANTHROPIC_MODEL": "eu.mistral-medium-3.5",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "eu.deepseek-v4-flash",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "eu.mistral-medium-3.5",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "eu.glm-52",
    "CLAUDE_CODE_ATTRIBUTION_HEADER": "0"
  }
}

Soll eine Anthropic- bzw. claude.ai-Subscription durch LiteLLM genutzt werden, sehen die Einstellungen so aus:

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://url.zu.litellm.tld",
    "ANTHROPIC_CUSTOM_HEADERS": "x-litellm-api-key: Bearer ${LITELLM_VIRTUAL_KEY}"
  }
}

Pi Coding Agent

Für Pi müssen zwei Dateien angepasst werden:

.pi/agent/models.json:

{
  "providers": {
    "ai-gateway": {
      "api": "openai-completions",
      "apiKey": "ai-gateway",
      "baseUrl": "https://url.zu.litellm.tld/v1",
      "models": [
        {
          "_launch": true,
          "contextWindow": 262144,
          "id": "eu.mistral-medium-3.5",
          "input": ["text", "image"],
          "reasoning": true
        },
        {
          "_launch": true,
          "contextWindow": 1048576,
          "id": "eu.deepseek-v4-pro",
          "input": ["text", "image"],
          "reasoning": true
        }
      ]
    }
  }
}

.pi/agent/auth.json:

{
  "ai-gateway": {
    "type": "api_key",
    "key": "dein-litellm-virtualkey"
  }
}

OpenCode

Auch in OpenCode müssen wir zwei Dateien anpassen, eine für die verfügbaren Modelle und die BaseURL und eine für den API-Key.

~/.config/opencode/opencode.json:

{
  "provider": {
    "ai-gateway": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "AI-Gateway",
      "options": {
        "baseURL": "https://url.zu.litellm.tld/v1"
      },
      "models": {
        "eu.mistral-medium-3.5": {},
        "eu.deepseek-v4-pro": {},
        "eu.deepseek-v4-flash": {}
      }
    }
  }
}

~/.local/share/opencode/auth.json:

{
  "ai-gateway": {
    "type": "api",
    "key": "dein-litellm-virtualkey"
  }
}

Nutzung von LiteLLM in Anwendungen

LiteLLM stellt sowohl eine OpenAI-kompatible API als auch eine Anthropic-Messages-kompatible API zur Verfügung. Es können daher die existierenden Libraries verwendet werden, wenn die BaseURL und der API-Key angepasst werden.

Ein schnelles Ausprobieren geht z. B. mit curl:

OpenAI-kompatibel

curl -X POST https://url.zu.litellm.tld/v1/chat/completions \
-H "Authorization: Bearer YOUR_LITELLM_VIRTUALKEY" \
-H "Content-Type: application/json" \
-d '{
        "model": "eu.mistral-medium-3.5",
        "messages": [
        {
            "role": "user",
            "content": "Why is the sky blue?"
        }
        ]
    }'

Anthropic-Messages-kompatibel

curl -X POST https://url.zu.litellm.tld/v1/messages \
-H "Authorization: Bearer YOUR_LITELLM_VIRTUALKEY" \
-H "Content-Type: application/json" \
-d '{
        "model": "eu.mistral-medium-3.5",
        "max_tokens": 1024,
        "messages": [
        {
            "role": "user",
            "content": "Why is the sky blue?"
        }
        ]
    }'

In beiden Fällen werden die Anfragen von LiteLLM an den angeschlossenen Provider für das hier exemplarisch gewählte Modell eu.mistral-medium-3.5 weitergeleitet.

Anbindung von OpenWebUI an LiteLLM

Damit auch unsere Chat-, Recherche- und Expertenmodell-Lösung OpenWebUI unsere über LiteLLM zur Verfügung gestellten KI-Modelle benutzen kann, müssen wir unseren LiteLLM-Server als «Verbindung» hinzufügen. Das geht unter

"Admin-Einstellungen" -> "Einstellungen" -> "Verbindungen"

Dialog “Verbindung hinzufügen” showing external URL https://url.zu.litellm.tld/v1, Bearer auth, API type “Chat Completions”. — Hinzufügen einer Verbindung von OpenWebUI zu LiteLLM

Dafür verwenden wir die URL unseres LiteLLM-Servers gefolgt von /v1 und einen zuvor in LiteLLM dafür erstellten VirtualKey.

“Einstellungen” > “Modelle” list filtered by “ai-g”, showing AI gateway models with “ÖFFENTLICH”/“PRIVAT” tags and toggles. — Liste der von LiteLLM zur Verfügung gestellten Modelle

Unter "Admin-Einstellungen" -> "Einstellungen" -> "Modelle" bekommen wir nun unsere Modelle angezeigt und können sie in OpenWebUI verwenden.

Expertenmodelle in OpenWebUI

Wie schon eingangs beschrieben, bietet OpenWebUI über RAG oder MCP die Möglichkeit, externes Wissen zu benutzen. Wir schauen uns das hier einmal Schritt für Schritt exemplarisch am schon erwähnten «StackIt Terraform Expert» an und nutzen dafür Wissensspeicher bzw. RAG.

Es ist ebenso möglich, einen solchen Experten per OpenAPI oder MCP an eine Wissensquelle anzuschließen.

Schritt 1: Wissen besorgen

Als Erstes brauchen wir die Wissensbasis. Der StackIt Terraform Provider wird in einem offenen GitHub-Repository gepflegt. Darin enthalten ist auch die Dokumentation in Markdown-Dateien. Wir holen uns also zunächst das Repository:

git clone https://github.com/stackitcloud/terraform-provider-stackit.git

Nun liegt die Doku im Verzeichnis ./terraform-provider-stackit/docs.

Schritt 2: «Wissen» in OpenWebUI erstellen

Form titled “Wissensspeicher erstellen” with “StackIt Terraform Expert” and private access settings. — Wissensspeicher erstellen

Über «Arbeitsbereich» -> «Wissen» wird ein neuer Wissensspeicher erstellt und passend benannt und beschrieben.

Screenshot of “StackIt Terraform Expert” collection: “Kein Inhalt gefunden” with open add menu (e.g., “Dateien hochladen”, “Neues Verzeichnis”). — Wissen hinzufügen

Nach dem Erstellen öffnen wir diesen Wissensspeicher nun und laden über «Ordner hochladen» den docs-Ordner aus dem Repository hoch.

Der Wissensspeicher kann nun einem Modell als Basiswissen mitgegeben oder in jedem Chat per #StackIt Terraform Expert eingebunden werden.

Schritt 3: Modell erstellen und mit Wissen verknüpfen

Wir erstellen nun ein Modell, das das zuvor erstellte Wissen automatisch nutzt.

Erstellen eines Expertenmodells

Dazu geben wir folgende Informationen an:

Modellname
Basismodell (z. B. eu.mistral-medium-3.5)
System-Prompt
(optional) Standard-Prompt-Vorschläge
Wissensspeicher

Das Modell ist nun einsatzbereit und nutzt das zuvor hochgeladene Wissen automatisch. Technisch wird hierfür RAG verwendet, dessen Nutzung unter «Admin-Einstellungen» -> «Einstellungen» -> «Dokumente» auch im Detail getunt werden kann.

Schritt 4: Der erste Test

Wir testen nun unseren gerade erstellten Experten:

Screenshot of “StackIt Terraform Experte” explaining how to create S3-compatible object storage in StackIt with Terraform. — Testlauf mit dem gerade erstellten Expertenmodell

An query_knowledge_files und view_knowledge_files sieht man, dass OpenWebUI die entsprechenden Tools nutzt, um im bestehenden Wissen nach Antworten zu suchen. Wir können uns mit unserem Expertenmodell also über das zur Verfügung gestellte Wissen unterhalten. Zusätzlich lassen sich die einzelnen Tool-Aufrufe aufklappen, sodass direkt erkennbar ist, welche Teile des Wissens für die Antwort herangezogen wurden.

An dieser Stelle angekommen, haben wir ein eigenes KI-System auf die Beine gestellt, das zentrale Elemente unter eigener Kontrolle hält und KI-Inferenz über APIs verschiedener Provider anbindet. Es lohnt sich dabei auf jeden Fall, noch tiefer in LiteLLM und OpenWebUI hineinzuschauen, denn die hier vorgestellten Features stellen nur die Oberfläche der Möglichkeiten dar. OpenWebUI erlaubt beispielsweise das Sammeln und Teilen von Skills, LiteLLM bietet darüber hinaus die Möglichkeit, Agenten und MCP-Server einzubinden – um nur ein paar Punkte zu nennen.