LibreChat vs Open WebUI — which takes a custom endpoint with less friction

Both run self-hosted, both speak the OpenAI protocol, and both will do the job. The comparisons that rank for this question line up feature tables. This one answers the narrower question you probably arrived with: which of them takes a custom OpenAI-compatible endpoint with less friction, and what each one gives you in exchange.

Everything asserted below comes from each project's own README. There is no benchmark here and no verdict about which is better, because we have not run either at a scale that would justify one.

Where each one came from

The pattern is that Open WebUI has invested most in the deployment and retrieval side, and LibreChat in the provider and agent side. Which of those you care about is usually a better tie-breaker than a feature count.

Pointing Open WebUI at a gateway

Two environment variables, and it is running:

# 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.

Because the model picker can be populated from GET /v1/models, an endpoint that serves several families puts all of them in one dropdown — the Claude, GPT and Gemini ids appear together with no second configuration.

Pointing LibreChat at a gateway

LibreChat wants a YAML block rather than environment variables, which is more to write and buys you naming and model control:

# 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-4-6", "gpt-5-4", "gemini-2-5-flash"]
        fetch: true          # populate the picker from GET /v1/models
      titleConvo: true
      titleModel: "claude-haiku-4-5"
      modelDisplayLabel: "Kunavo"

The titleModel line is the one worth copying regardless of endpoint: LibreChat generates a conversation title with a model call, and pinning that to the cheapest model in your list stops the titles being billed at the rate of whatever you happen to be chatting with.

Why put a gateway behind either

Both clients can hold several providers at once, so a gateway is not required. What it changes is how many things you configure and how many bills you get: one base URL and one key in place of an account, a credential and a billing relationship per model family. Adding a family afterwards becomes a model id in a list rather than a new integration.

Kunavo serves the OpenAI-compatible surface both clients speak, so the base URL above is all either needs. Setup detail per client is on the integrations hub, the endpoint reference is at chat completions, and the OpenAI-compatible API guide covers what “compatible” does and does not include.

FAQ