LibreChat ou Open WebUI — lequel accepte un endpoint personnalisé avec le moins de friction

Les deux s'exécutent en auto-hébergement, parlent le protocole OpenAI et feront tous deux l'affaire. Les comparatifs qui se classent pour cette question alignent des tableaux de fonctionnalités. Celui-ci répond à la question plus précise qui vous a probablement amené ici : lequel accepte un endpoint personnalisé compatible avec OpenAI avec le moins de friction, et ce que chacun vous offre en échange.

Tout ce qui est affirmé ci-dessous provient du README de chaque projet. Il n'y a ici ni benchmark ni verdict sur le meilleur choix, car nous n'avons exécuté aucun des deux à une échelle qui permettrait de le justifier.

Origine de chacun

Le schéma est le suivant : Open WebUI a surtout investi dans le déploiement et la récupération, tandis que LibreChat a davantage investi dans les prestataires et les agents. L'importance que vous accordez à ces aspects constitue généralement un meilleur critère de départage que le nombre de fonctionnalités.

Connecter Open WebUI à une passerelle

Deux variables d'environnement, et c'est lancé :

# Open WebUI — the OpenAI-compatible connection is a base URL and a key.
docker run -d -p 3000:8080 \
  -e OPENAI_API_BASE_URL=https://api.kunavo.com/v1 \
  -e OPENAI_API_KEY=sk-kn-... \
  -v open-webui:/app/backend/data \
  --name open-webui ghcr.io/open-webui/open-webui:main

# The same two values can be set in Settings -> Connections after
# first launch, which is the faster path when you are trying it out.

Comme le sélecteur de modèles peut être alimenté depuis GET /v1/models, un endpoint qui sert plusieurs familles les place toutes dans une seule liste déroulante — les identifiants Claude et GPT apparaissent ensemble, sans seconde configuration.

Connecter LibreChat à une passerelle

LibreChat demande un bloc YAML plutôt que des variables d'environnement ; cela demande davantage de saisie, mais vous donne le contrôle du nom et des modèles :

# LibreChat — a custom endpoint is a block in librechat.yaml.
version: 1.2.1
endpoints:
  custom:
    - name: "Kunavo"
      apiKey: "${KUNAVO_API_KEY}"
      baseURL: "https://api.kunavo.com/v1"
      models:
        default: ["claude-sonnet-5", "gpt-5-6-terra", "claude-haiku-4-5"]
        fetch: true          # populate the picker from GET /v1/models
      titleConvo: true
      titleModel: "claude-haiku-4-5"
      modelDisplayLabel: "Kunavo"

La ligne titleModel mérite d'être copiée quel que soit l'endpoint : LibreChat génère le titre d'une conversation avec un appel de modèle, et le fait de le fixer au modèle le moins cher de votre liste évite que les titres soient facturés au tarif du modèle utilisé pour votre conversation.

Pourquoi placer une passerelle derrière l'un ou l'autre

Les deux clients peuvent gérer plusieurs prestataires simultanément, donc une passerelle n'est pas obligatoire. Elle modifie le nombre d'éléments que vous configurez et de factures que vous recevez : une URL de base et une clé remplacent un compte, un identifiant et une relation de facturation par famille de modèles. L'ajout ultérieur d'une famille devient l'ajout d'un identifiant de modèle dans une liste plutôt qu'une nouvelle intégration.

Kunavo fournit la surface compatible avec OpenAI utilisée par les deux clients ; l'URL de base ci-dessus est donc tout ce dont l'un ou l'autre a besoin. Les détails de configuration propres à chaque client se trouvent dans le hub des intégrations, la référence des endpoints dans chat completions, et le guide de l'API compatible avec OpenAI explique ce que signifie « compatible » et ce que cela n'inclut pas.

Questions fréquentes