LibreChat vs open-webui: agents and provider switching against RAG and platform breadth
LibreChat is a TypeScript, MIT-licensed chat front end that leans on agents, MCP tools and multi-provider switching; open-webui is a Python platform that leans on built-in RAG, plugins and enterprise administration. They overlap in chat and diverge everywhere else, so the choice is mostly about which side of the stack you care about.
At a glance
| Project | danny-avila/LibreChat | open-webui/open-webui |
|---|---|---|
| Licence | MITPermissive: commercial use allowed | Custom licenceCustom licence: read the LICENSE file |
| Maintenance | Commits in the last dayLast push September 29, 2026 | Commits in the last six monthsLast push September 25, 2026 |
| Language | TypeScript | Python |
| GitHub stars | 45,122 | 153,167 |
| Read more | Our analysisGitHub | Our analysisGitHub |
Which one to choose
Choose LibreChat if you want permissive MIT licensing, a single chat UI that switches between OpenAI, Anthropic, Gemini, Bedrock, Vertex and local Ollama endpoints, and you intend to build agents with MCP tools, code execution and human-in-the-loop approval flows.
Choose open-webui if you need local-first RAG with a choice of vector databases, granular RBAC and user groups, LDAP or SSO provisioning, and a broader workspace of notes, channels, calendars and automations, and you accept its custom licence and larger upgrade surface.
Two projects, two centres of gravity
The clearest difference is what each project treats as the centre of the product. LibreChat is a chat interface first: the README describes a ChatGPT-style UI that connects to dozens of providers and then layers agents, tools and multi-user management on top. open-webui describes itself as a self-hosted AI platform designed to operate entirely offline, with Ollama and OpenAI-compatible APIs as runners and a built-in inference engine for RAG. That wording is not marketing noise; it predicts where each project spends its complexity budget.
LibreChat's v0.8.8-rc1 release notes concentrate on agent control: interrupting or steering an agent mid-run, queuing follow-up messages, human-in-the-loop agents that pause for input or tool approval, a unified agent builder, subagents, and experimental agent plugins. open-webui's README concentrates on breadth: notes, channels, persistent memory, calendars, automations, voice and video calls, image generation, multi-model conversations, usage analytics, and nine vector databases. A team that mainly wants to talk to models and let them call tools will find more of what it needs in the first list. A team that wants a workspace around the model will find more in the second.
The languages reinforce this. LibreChat is TypeScript, which suits teams already running Node services and who want the chat layer to sit alongside their existing stack. open-webui is Python, which suits teams whose RAG pipelines, embedding jobs and data tooling are already Python. Neither is a better language in the abstract; the practical question is which runtime your team can patch at 2am.
Provider switching versus local-first retrieval
LibreChat's README lists Anthropic, AWS Bedrock, OpenAI, Azure OpenAI, Google, Vertex AI and the OpenAI Responses API, plus custom endpoints for any OpenAI-compatible API without a proxy, and local or remote providers including Ollama, Groq, Cohere, Mistral, Apple MLX, koboldcpp, together.ai, OpenRouter, Helicone, Perplexity, ShuttleAI, Deepseek and Qwen. The design intent is that a user picks a model per conversation and the front end does not care which vendor answers.
open-webui also connects to any OpenAI-compatible API and local Ollama models, and the README names LMStudio, GroqCloud, Mistral, OpenRouter and vLLM as examples. The difference is what happens after the model answers. open-webui ships local RAG backed by nine vector databases (ChromaDB, PGVector, Qdrant, Milvus, Elasticsearch, OpenSearch, Pinecone, S3Vector and Oracle 23ai), multiple content extraction engines including Tika, Docling, Document Intelligence, Mistral OCR and PaddleOCR-vl, hybrid search combining BM25 with vector search, reranking, and full-context mode. It also offers web search through a long list of providers, from SearXNG and Brave to Tavily, Perplexity and Firecrawl, injected directly into the conversation.
LibreChat's README does not document a comparable built-in retrieval stack. Its file handling is tied to the code interpreter and to agent tools such as file search, and the release notes mention artifact workflows and document templates rather than a vector database matrix. If retrieval over your own documents is the core requirement, open-webui documents that path in detail and LibreChat does not. If per-conversation provider choice is the core requirement, both support it, but LibreChat's README enumerates a wider set of first-class providers.
Getting each one running
LibreChat's README shows one-click deployment buttons for Railway, Zeabur and Sealos, and links to documentation for configuration. The configuration surface is large because providers, agents, tools and authentication are all configurable, and the earlier analysis notes that the v0.8.8-rc1 release is explicitly experimental. A reader should treat the release candidate as a preview: the release notes mark human-in-the-loop agents, stateful code interpreter sessions and agent plugins as experimental, which means the features most likely to attract a new adopter are also the ones most likely to change.
open-webui documents installation through pip, uv, Docker and Kubernetes using kubectl, kustomize or helm, with :ollama and :cuda tagged container images. It also points to an enterprise plan with custom theming, SLA support and long-term support versions, which tells you the project expects organisations to run it for a long time and to need a supported upgrade path. The cost of that breadth is a larger set of moving parts: a database choice between SQLite with optional encryption and PostgreSQL, file storage on local disk, S3, Google Cloud Storage or Azure Blob Storage, and a vector database choice among nine options. Each of those is a decision you must make before the first user logs in.
Neither README documents rollback for a failed upgrade. LibreChat's README does not document rollback, and open-webui's README does not document rollback either. If an upgrade goes wrong, the recovery path is whatever your own backup and deployment tooling provides, not something either project promises.
Operations, scaling and the upgrade burden
The release notes for LibreChat v0.8.8-rc1 include several items aimed at operators: Redis delta batching, configurable HTTP timeouts, Amazon DocumentDB 5.0+ support, low-noise Redis and browser observability, agent stream circuit breakers, and a rolling-upgrade-safe generation protocol. That last item is notable because it implies the project has thought about upgrades that happen while traffic is live. The same notes mention delegating config sections, encrypting registered secrets, SSRF checks for speech, OCR and web tools, and generating unique temporary credentials when secrets are blank. These are the concerns of a deployment that other people depend on.
open-webui's operational story is expressed as choices rather than mechanisms. You choose the database, the storage backend and the vector database, and the README says administrators define detailed roles, groups and permissions. It also documents usage analytics and model evaluation with an arena, A/B testing and ELO-based leaderboards, which is useful when you are deciding which model to standardise on. What the README does not describe is how upgrades are sequenced or how data migrations between vector databases are handled. The earlier analysis warns that the project's scope raises questions about complexity and upgrade burden, and that adopting it means accepting frequent upgrades and a large feature surface.
A fair summary: LibreChat's notes describe reliability work on the streaming and agent path, while open-webui's README describes configurability across storage and retrieval. If your risk is long-running agent sessions failing mid-stream, LibreChat documents more mitigation. If your risk is picking a storage backend you cannot migrate away from, open-webui gives you more options but leaves the migration itself to you.
Where each one falls short
LibreChat is weaker on retrieval. Its README does not present an equivalent to open-webui's vector database support, hybrid search or extraction engine list. A team whose primary use case is asking questions across a document corpus will be assembling that capability from agent tools and external services rather than enabling a documented feature.
open-webui is weaker on licensing clarity. Its licence is listed as Other, a custom licence GitHub cannot classify, and the README does not restate the terms. LibreChat is MIT, which most organisations can clear quickly. The earlier analysis for open-webui explicitly says to verify the exact licence terms before deploying, and that advice stands: an unclassified licence is not necessarily restrictive, but it is not the same as MIT either.
Each is also weaker where the other is strong on focus. LibreChat's configuration surface and feature set are large, and the earlier analysis warns against adopting it if you want a minimal, single-provider chat client. open-webui's README lists notes, channels, calendars, automations, voice calls, image generation and persistent memory; the earlier analysis warns against adopting it if you require a minimal, single-purpose chat UI or if your team cannot handle frequent upgrades. A reader who wants something small should look past both of these projects, not choose between them.
One more asymmetry: LibreChat's headline release is a release candidate, so its most interesting features are the least settled. open-webui's most recent listed release, v0.11.1, is a stable version, but the README's breadth means the surface you must test after each upgrade is wider.
Licence and maintenance implications
Both repositories were last pushed on 2026-09-14, and neither is archived, so both are under current development. The maintenance question is not whether someone is committing; it is what you inherit when you adopt.
LibreChat's MIT licence means you can fork, modify and redistribute with minimal legal review. That matters if you plan to embed the chat layer in a product or ship a modified build to customers. The trade-off is that the project's own release notes mark several of its headline features as experimental, so the freedom to fork comes with a responsibility to track upstream changes yourself.
open-webui's custom licence means the terms have to be read rather than assumed. The README does not summarise them, and the earlier analysis says to verify the exact terms. The project also advertises an enterprise plan with SLA support and long-term support versions, which suggests that organisations wanting a guaranteed support relationship are expected to pay for it rather than rely on the community. That is a legitimate model, but it changes the calculation for a company that assumed open-webui was freely supportable in the same way as an MIT project.
On cadence: open-webui's listed releases run v0.10.2 in July, v0.11.0 in late July and v0.11.1 in late August 2026. LibreChat's listed releases are v0.8.7-rc1 in mid June, v0.8.7 in late June and v0.8.8-rc1 in mid August 2026. Both projects ship often enough that pinning versions and reading changelogs before upgrading is a practical necessity rather than a precaution.
Choosing for concrete scenarios
A two-person startup that wants one self-hosted chat window with a model picker, MIT licensing and no legal review: LibreChat. The README's custom endpoint support and long provider list cover the switching requirement, and the MIT licence keeps the paperwork short.
A ten-person team building an internal assistant that queries a document library and must respect per-group access: open-webui. The README documents RBAC and user groups, nine vector databases, hybrid search with reranking, and multiple extraction engines. LibreChat's README does not document an equivalent retrieval stack, so that work would fall to you.
An organisation that must authenticate against LDAP or Active Directory and provision users automatically: open-webui. Its README names LDAP/AD integration, SSO via trusted headers and OAuth providers, and SCIM 2.0 provisioning. LibreChat's README describes secure multi-user auth but does not enumerate those enterprise protocols in the excerpt available.
A developer who wants an agent that pauses for tool approval, accepts mid-run steering and can delegate to subagents: LibreChat, with the caveat that these are release-candidate features. The v0.8.8-rc1 notes describe exactly this behaviour. open-webui's README describes models and agents with custom instructions, tools and knowledge, and plugins including Tools and Skills, but not the same interrupt-and-resume control loop.
A team that wants a workspace with shared channels, a calendar, scheduled prompts and voice calls alongside chat: open-webui. Those features are listed in its README and have no counterpart in LibreChat's README.
The two are not strictly competitors. A deployment could use open-webui as the retrieval and workspace layer for a broad user base while a smaller group runs LibreChat for agent-heavy work, accepting two systems to operate. Most readers, though, will pick one, and the deciding question is whether their hard requirement is agent control and provider breadth or retrieval and administration.
Bottom line
Pick LibreChat when MIT licensing, per-conversation provider switching and agent control are the requirements, and accept that its most advanced features are release-candidate and that retrieval is not a documented strength. Pick open-webui when local-first RAG, RBAC, enterprise authentication and a broader workspace are the requirements, and accept a custom licence plus a larger upgrade surface. Before committing, verify four things: the exact terms of open-webui's licence file, whether the vector database and storage backend you intend to use are supported by the release you will run, which LibreChat v0.8.8-rc1 features you depend on and whether they are marked experimental, and your own rollback procedure, because neither README documents one.