Tarification d’Open WebUI : coût du logiciel et coût des tokens

Open WebUI ne publie aucune liste de prix : openwebui.com/pricing et openwebui.com/enterprise renvoient tous deux 404, et l’interface de discussion est gratuite à auto-héberger, sans plafond de sièges ni plafond de requêtes. Ce qu’une licence d’entreprise contrôle, c’est la suppression de la marque Open WebUI et l’accès à des modules complémentaires réservés aux entreprises tels que Terminals, et non le nombre de personnes qui l’utilisent. Les chiffres dont un acheteur a réellement besoin sont les trois éléments que le projet ne vous facture pas — la machine, les tokens du modèle et les paramètres d’Open WebUI qui envoient discrètement des tokens que vous n’avez pas saisis. Les trois sont détaillés ci-dessous, avec leurs sources et dates de vérification.

Trois prix erronés circulent pour cette requête ; il faut donc les clarifier d’abord. 60 $ par siège et par an est le prix réel et officiel, mais il s’agit du niveau Supporter de Open WebUI Computer — le package cptr, un produit distinct de la même équipe sous une licence différente, dont le propre niveau gratuit affiche « 0 $ pour toujours ». Un montant annuel pour entreprise attribué à Open WebUI dans les résultats de recherche provient d’un hébergeur tiers et n’apparaît sur aucune page officielle ; il n’est donc pas repris ici. Et un forfait « Pro » à 19 $ par mois appartient à openwebui.net — un domaine similaire qui n’est pas openwebui.com, et dont l’application est appelée « NextChat » dans ses propres textes (vérifié le 21 septembre 2026). Il est mentionné ici pour que vous puissiez le reconnaître, et volontairement non lié.

Ce que coûte le logiciel et ce que la licence encadre réellement

La page d’accueil du projet vend l’installation, pas un forfait : « pip install open-webui / Une commande. 60 secondes. Aucun compte requis. » Le dépôt est actif et non archivé, et son commit le plus récent sur main date du 4 septembre 2026. La version actuelle est v0.11.3, dont les fichiers ont été publiés sur PyPI le 31 août 2026. À noter, toutefois, un désaccord officiel : la carte de blog de la page d’accueil affiche encore v0.11.1 du 25 août. Il s’agit d’un article de blog, pas d’une bannière de version ; GitHub Releases fait foi pour les versions.

La licence exige la même prudence. GitHub la signale comme NOASSERTION / « Other », tandis que les articles tiers continuent souvent de la qualifier de BSD-3. Les deux affirmations sont partiellement exactes. Le fichier LICENSE contient le texte BSD-3 ainsi qu’une quatrième clause, introduite dans v0.6.6, qui interdit de modifier, supprimer, masquer ou remplacer la marque Open WebUI, sauf lorsque « le nombre total d’utilisateurs finaux … ne dépasse pas cinquante (50) sur toute période glissante de trente (30) jours », lorsque vous disposez d’une autorisation écrite ou lorsque vous détenez une licence Enterprise. La page de licence du projet l’exprime clairement : « Les exigences relatives à la marque s’appliquent uniquement aux déploiements plus importants (50 utilisateurs ou plus, au total) », et « chacun peut toujours créer un fork à partir de v0.6.5 sans aucune restriction ». Conclusion : il ne s’agit pas aujourd’hui d’une licence approuvée par l’OSI, mais ce n’est pas non plus une limite d’utilisation ; le seuil encadre le changement de marque, pas l’exécution du logiciel.

Ce que la licence Enterprise accorde, selon les propres termes du projet, c’est « le marquage blanc, le changement de marque, les modifications de la marque originale ou les offres exclusives aux entreprises telles que Terminals ». Terminals est documenté comme la couche d’orchestration d’Open Terminal : elle provisionne un espace de travail distinct — fichiers, processus, environnement de packages, limites de ressources et frontière réseau — pour chaque utilisateur, et constitue l’exemple nommé d’une fonctionnalité que la licence encadre, au-delà de la marque. L’« hébergement Open WebUI » géré par des fournisseurs tiers est encore autre chose : il s’agit d’une facture de serveur sur l’infrastructure de quelqu’un d’autre. Aucun montant vérifié pour un hébergeur géré n’a été obtenu pour cette page — l’unique page tarifaire vérifiée d’un fournisseur affiche des espaces réservés au prix plutôt que des chiffres lors d’une récupération simple — ; aucun montant n’est donc cité.

Deux questions différentes se cachent derrière « coût de l’API Open WebUI »

La requête est réellement ambiguë, et ses deux volets ont des réponses différentes.

Ce sont les appels sortants qui coûtent de l’argent. Open WebUI ne fournit aucun modèle qui lui soit propre ; chaque token est donc facturé par le point de terminaison que vous avez configuré. L’API propre d’Open WebUI ne coûte rien : dans la balise publiée v0.11.3, backend/open_webui/main.py sert GET /api/models (L874), POST /api/chat/completions (L1085) et — plus récent et facile à manquer — un POST /api/v1/messages de forme Anthropic (L1976), avec POST /api/v1/messages/count_tokens juste à côté (L1907). Vous vous authentifiez auprès de ces points de terminaison avec votre propre clé Open WebUI, et non avec la clé de votre fournisseur. Open WebUI ne les facture pas, car ce sont une porte d’entrée : chaque requête aboutit toujours chez le fournisseur amont que vous avez configuré et y est facturée. Faire pointer vos propres scripts vers Open WebUI plutôt que vers le fournisseur modifie le routage, pas la facture.

Les appels facturables que vous n’avez pas saisis

C’est la partie qu’une comparaison des tarifs omet. Dans la balise v0.11.3 de backend/open_webui/config.py, quatre générateurs d’arrière-plan sont activés par défaut et un est désactivé.

Le nombre de tokens supplémentaires en pratique n’a pas été mesuré pour cette page, et tout pourcentage affirmant le contraire serait inventé. Ce qui peut être vérifié, c’est la structure : les indicateurs sont activés, le modèle de tâche n’est pas défini, donc le trafic de nommage et d’attribution de tags est facturé au modèle de conversation déjà utilisé par cette conversation, jusqu’à ce que vous indiquiez un identifiant peu coûteux dans TASK_MODEL_EXTERNAL. La FAQ propre d’Open WebUI dit la même chose — « Par défaut, ces tâches utilisent le même modèle que celui avec lequel vous conversez » — et recommande le même correctif. Deux paramètres par défaut vont dans l’autre sens et méritent d’être connus avant d’établir votre budget : la recherche Web est désactivée (ENABLE_WEB_SEARCH, L1155) et la génération d’images est désactivée (ENABLE_IMAGE_GENERATION, L1336), tandis que l’interpréteur de code est activé (L422).

Quatre sous-systèmes, quatre emplacements de point de terminaison — et une valeur par défaut à lire deux fois

La compatibilité de conversation ne s’étend pas au reste du produit. Les embeddings de récupération, la conversion parole-texte, la synthèse vocale et la génération d’images ont chacun leur propre paire URL de base-clé, et le repli de chacun est l’unique OPENAI_API_BASE_URL. Voici la partie surprenante : dans la balise v0.11.3, après la création de la liste des connexions, la ligne 365 de config.py réaffecte OPENAI_API_BASE_URL = 'https://api.openai.com/v1' inconditionnellement. Toutes les valeurs par défaut des sous-systèmes évaluées ensuite — RAG_OPENAI_API_BASE_URL (L1092), IMAGES_OPENAI_API_BASE_URL (L1490), AUDIO_STT_OPENAI_API_BASE_URL (L1565), AUDIO_TTS_OPENAI_API_BASE_URL (L1606) — se résolvent donc vers le point de terminaison OpenAI, quelle que soit la variable que vous définissez pour la conversation. Il s’agit de la valeur par défaut au niveau du module, lue dans le code source ; ces valeurs initialisent une configuration persistante que l’interface d’administration peut ensuite remplacer, et ce comportement n’a pas été reproduit dans une instance en fonctionnement pour cette page. Le problème n° 22084 décrit le même symptôme ; il a été ouvert le 1er mars 2026 et est désormais fermé comme terminé. Considérez donc la lecture du code ci-dessus comme la valeur par défaut au niveau du module dans v0.11.3, et non comme un bug ouvert.

La bonne nouvelle est que ces quatre emplacements ne génèrent aucune dépense d’API avec les paramètres par défaut.

Kunavo ne fournit pas d’embeddings, ne fournit pas de conversion parole-texte et ne fournit pas de synthèse vocale.

Cette limite détermine vers quelle passerelle vous pouvez réellement pointer ces emplacements : RAG_OPENAI_API_BASE_URL, AUDIO_STT_OPENAI_API_BASE_URL et AUDIO_TTS_OPENAI_API_BASE_URL ne sont pas des emplacements à orienter ici. Laissez l’étape de récupération utiliser sa valeur locale par défaut — c’est à la fois le paramètre fourni et l’option gratuite — ou envoyez-la à un fournisseur qui propose cette étape. La seule partie de votre facture de récupération qui atteint un fournisseur de modèles conversationnels est le texte récupéré lui-même, qui arrive comme des tokens d’entrée ordinaires dans l’invite suivante. L’implémentation RAG explique comment la taille des segments et top-k se transforment en ce nombre de tokens d’entrée.

# The chat connection. This is the only slot the setup guides cover.
OPENAI_API_BASE_URL=https://api.kunavo.com/v1
OPENAI_API_KEY=sk-kn-...

# Titles, tags and retrieval queries run on the CHAT model unless you say
# otherwise. TASK_MODEL_EXTERNAL defaults to empty (config.py L2195).
TASK_MODEL_EXTERNAL=claude-haiku-4-5

# Leave the document-embedding step alone: empty means local, and local
# means no API spend at all (config.py L996 and L1002).
RAG_EMBEDDING_ENGINE=
RAG_EMBEDDING_MODEL=sentence-transformers/all-MiniLM-L6-v2

Estimation détaillée pour une journée de conversation

Il s’agit d’un calcul illustratif de tokens, pas d’un coût mesuré ni d’un plafond de facturation. Supposons la journée de travail d’une personne dans la fenêtre de conversation : 40 tours de l’assistant, chacun envoyant 6 000 tokens d’entrée non mis en cache (le fil visible ainsi que les segments récupérés) et renvoyant 700 tokens de sortie — soit au total 240 000 tokens d’entrée et 28 000 tokens de sortie. Supposons également 8 nouvelles conversations ce jour-là, et que les générateurs par défaut de titre, de tags et de requête de récupération d’Open WebUI effectuent trois appels supplémentaires par conversation, avec 2 000 tokens d’entrée et 40 tokens de sortie chacun. Cette taille par appel est une hypothèse ; elle n’a pas été mesurée. Les tarifs sont les prix actuels du catalogue Kunavo par million de tokens.

Lisez la dernière colonne plutôt que la colonne de conversation. Selon ces hypothèses, le trafic d’arrière-plan représente environ 12 % d’une journée Claude Sonnet 5 — $0.074 sur $0.606 — dépensés pour nommer et attribuer des tags aux conversations. Remplacer TASK_MODEL_EXTERNAL par Claude Haiku 4.5 ramène cette part à $0.037 et le total de la journée à $0.569, sans modifier ce que quiconque lit réellement. Ce seul paramètre déplace davantage cette facture qu’un changement de fournisseur au même niveau tarifaire.

Multipliez par votre propre nombre d’utilisateurs et de jours avant de considérer ce montant comme un budget, et notez ce que le calcul exclut : la mise en cache des invites, la génération d’images ou de vidéos, ainsi que tout outil appelé par l’interpréteur de code. Le montant du catalogue Kunavo constitue un plancher de facturation, et non un plafond : lorsque le fournisseur amont signale son coût, la facture est le montant le plus élevé entre le coût du catalogue et le coût amont multiplié par la majoration applicable. Le rechargement minimum Kunavo est de $10 de crédit prépayé, ce qui constitue un minimum de financement, et non un abonnement ni des frais par siège. Consultez les détails de facturation ainsi que l’utilisation pour le registre par requête. Open WebUI fournit également sa propre vue : le README v0.11.3 décrit des tableaux de bord d’administration qui « suivent le volume de messages, la consommation de tokens et le coût par utilisateur et par modèle ». Cette fonctionnalité n’a pas été utilisée pour cette page, et deux compteurs mesurant le même trafic ne correspondront pas token par token ; rapprochez donc les chiffres du côté que vous financez réellement.

Quelle route choisir, et quand

Un détail de protocole détermine davantage la configuration que le choix du fournisseur. Open WebUI est explicitement orienté protocole — il implémente le protocole OpenAI Chat Completions et refuse d’ajouter des API propres aux fournisseurs au cœur du produit — ; il faut donc lui fournir une racine /v1 au format OpenAI, même pour les modèles Claude. Sa propre page Anthropic configure https://api.anthropic.com/v1 comme une connexion OpenAI et relaie l’avertissement d’Anthropic selon lequel la couche de compatibilité est destinée aux tests plutôt qu’à la production. Il existe également un sélecteur API Type par connexion pour Open Responses, que la documentation qualifie d’expérimental et dont elle avertit qu’il « peut ne pas fonctionner comme prévu avec tous les fournisseurs ». Kunavo fournit une route au format Responses, mais cette combinaison n’a pas été testée en conditions réelles pour cette page ; considérez donc le chemin chat-completions comme celui dont le fonctionnement est établi, et le sélecteur comme une option à essayer sur une connexion de test.

Vous comparez l’interface elle-même plutôt que le fournisseur ? LibreChat vs Open WebUI et AnythingLLM vs Open WebUI couvrent ce choix, tandis que meilleure passerelle LLM compare la couche de passerelle selon les tarifs et les conditions de financement plutôt que selon la profondeur de l’intégration.

Configurez-la, puis vérifiez la facturation du premier jour

La connexion se trouve dans Settings → Admin → Connections → « Manage OpenAI API Connections » → « Add Connection », avec un champ URL et un champ API Key ; la même opération peut être effectuée au démarrage du conteneur avec les deux variables d’environnement ci-dessus. Conservez le /v1 dans l’URL — Open WebUI ajoute lui-même la route, et le code source supprime la barre oblique finale.

Un mode d’échec mérite d’être connu à l’avance, car il ressemble à une intégration inactive alors que ce n’est pas le cas. La documentation propre d’Open WebUI précise que l’enregistrement d’une connexion ne la teste pas, que le bouton Verify appelle le point de terminaison /models du fournisseur, et que si cet appel échoue, « cela ne signifie pas que le fournisseur est incompatible : les chat completions continueront de fonctionner » — vous saisissez plutôt les identifiants de modèle dans la liste blanche Model IDs de la connexion. Il vaut dans tous les cas la peine de remplir cette liste blanche : dans un catalogue comprenant des modèles d’image, de vidéo et de musique, un filtre vide place dans le sélecteur des modèles qu’une fenêtre de conversation ne peut pas appeler.

Kunavo publie un guide de configuration pour ce client. Il s’agit d’une référence de configuration publiée, et non d’un test de compatibilité — Open WebUI n’a pas été testé en conditions réelles ici avec le point de terminaison Kunavo, et tout ce qui précède provient du code source publié d’Open WebUI et de sa propre documentation. Conservez une route fonctionnelle pendant vos essais, effectuez une journée limitée, puis consultez ce que votre compte a réellement enregistré. Commencez par le guide d’intégration Open WebUI, puis créez un compte Kunavo lorsque vous serez prêt à créditer une clé.

Questions fréquentes

Les pages Open WebUI, le dépôt, l’historique des commits et le package ont été vérifiés le 19 septembre, puis vérifiés de nouveau le 21 septembre 2026 ; les réponses 404 à openwebui.com/pricing et openwebui.com/enterprise ont été récupérées directement, et chaque valeur de configuration par défaut citée a été lue à la version publiée portant le tag v0.11.3 plutôt que dans main. Non vérifiés : les prix de l’hébergement géré, tout montant en dollars pour Enterprise, le surcoût en tokens des tâches d’arrière-plan par défaut, les tableaux de bord d’utilisation propres à Open WebUI et toute exécution de bout en bout d’Open WebUI avec Kunavo. Les tarifs des tokens Kunavo proviennent du catalogue actuel, et chaque exemple en dollars présenté ici est un calcul illustratif de tokens.