What is the difference between an open-source chatbot and an open-source LLM?

An open-source LLM is the language model itself: the weights and architecture that produce responses. An open-source chatbot is a full application, including the chat interface, conversation history, tool connections, and user management, that uses one or more LLMs as its backend. You can use an open-source chatbot with either open-source or commercial LLMs.

Can I run an open-source chatbot on a standard laptop?

Smaller models, such as 7B parameter models, can run on a modern laptop with 16 GB of RAM, especially on Apple Silicon machines with unified memory. Larger models require more RAM or a GPU with sufficient VRAM. Ollama lists system requirements for each model it supports. Start with a small model and test it before assuming a larger one will work on your hardware.

Are open-source chatbots free to use?

The software itself is free, but running a model has costs. Local models use your hardware and electricity. Self-hosted servers need infrastructure. If the chatbot is configured to call a commercial API like OpenAI, those API calls have costs based on usage. The "free" part is the software license, not necessarily the total cost of running it.

Can multiple people on a team use the same self-hosted chatbot?

Tools like Open WebUI and LibreChat support multi-user deployments. You host the application on a server, and team members access it through their browsers. Each user can have separate conversations and settings. The setup requires more work than a single-user install, but it is a supported use case for those tools.

How do I keep my project context when switching between open-source models?

Save the important decisions, task status, and next steps in a place that exists outside the chatbot, such as fenbs. When you switch to a new model, the project record is still there. Ask the new model to read the context before it starts work rather than starting from an empty conversation.

Open-Source Chatbots: Choose an Assistant for Work

Open-source chatbots let you run or self-host an AI assistant with more control over your data and model choice. Here is how the main options compare and how to keep shared project context across them.

September 30, 2026Updated October 21, 20267 min read

An open-source chatbot is a conversational AI application whose code is publicly available, meaning you can run it on your own hardware, inspect what it does with your data, and swap the underlying model for a newer one as they are released. Tools like fenbs work alongside these chatbots by keeping shared project context, rules, and task status in one place that any connected AI can read, so switching from one model to another does not mean starting the conversation from scratch.

What to look for in an open-source chatbot

The most useful criteria when choosing depend on why you want an open-source option in the first place. If the reason is data privacy, check where the model runs and whether any queries leave your network. If the reason is model flexibility, check how easily you can swap or update the underlying model. If the reason is team use, check whether the tool has multi-user support and access controls.

Model source: does it run a local model (no data leaves your machine) or call an external API?
Setup complexity: can a non-developer install and run it, or does it require Docker, Python environment setup, or GPU hardware?
Tool and function support: can the chatbot use outside tools, search the web, or call APIs?
MCP support: can it connect to external services using the Model Context Protocol?
Multi-user access: does it support separate accounts, shared sessions, or team workspaces?
Maintenance: is the project actively maintained, and are security patches released promptly?

Open-source chatbot options compared
Tool	Best fit	Setup	MCP support	Notes
Ollama	Running local models on Mac, Linux, or Windows	Low: single installer	Via third-party bridges	Pulls and runs models locally; no web interface by default; pairs with Open WebUI.
Open WebUI	Browser-based frontend for Ollama and OpenAI-compatible APIs	Moderate: Docker or pip	Via extensions	Adds multi-user support, conversation history, and model switching over a local or remote API.
LibreChat	Teams wanting a self-hosted ChatGPT-style interface	Moderate to high: Docker Compose	In development	Supports multiple AI providers simultaneously; includes memory and plugin support; active community.
Jan	Desktop app for local model use without Docker	Low: installer	Partial	Single-user desktop app; good for individuals who want a GUI without server setup.
fenbs	Keeping project context, rules and tasks across any AI tool you switch to	Hosted: no installation	Native MCP server	Not a chatbot itself; keeps the work record that any connected assistant reads. Use it alongside an open-source chatbot when you need shared context.

Locally-run models with Ollama

Ollama is the most straightforward way to run a large language model on your own machine. You install it with a single command, then pull a model by name, such as ollama pull llama3.2 or ollama pull mistral. It handles model storage and serving without Docker. Queries never leave your machine, which makes it a good starting point for anyone who wants a local AI for sensitive notes or code review.

Ollama does not ship a chat interface. You interact with it via the command line or connect it to a frontend like Open WebUI. It also does not have built-in tool support or MCP connectivity, but several community bridges exist that add those capabilities. Check the Ollama documentation and community for current options.

Self-hosted options with a web interface

Open WebUI pairs with Ollama or any OpenAI-compatible API endpoint to give you a browser-based chat interface. It adds conversation history, multi-user accounts, and model switching. Deploy it with Docker, point it at a local Ollama instance or an API key, and your team has a shared chat interface that keeps data on your server.

LibreChat is a more feature-complete option for teams. It supports multiple AI providers at once, including local models, OpenAI, Anthropic, and others, and users can switch between them in a single interface. It includes a plugin system, memory support, and conversation branching. The setup is more involved, typically requiring Docker Compose and some environment variable configuration, but it is well documented.

MCP support and tool connections

MCP, the Model Context Protocol, is a standard that lets an AI app connect to an outside tool, sign in, and get a list of actions it can take. Support for MCP in open-source chatbots varies. Some frontends are adding native MCP support; others require a bridge or plugin. If MCP connectivity is important to you, check the project's GitHub issues and release notes for the current status before committing to a setup.

fenbs connects over MCP at https://fenbs.ai/api/mcp with a browser sign-in. If your open-source chatbot supports MCP, you can connect it to fenbs so it reads your project context, rules, and Where we left off before each session. Check Integrations for the current list of supported AI apps. If your chatbot is not on that list, fenbs does not currently connect to it natively.

How fenbs helps

Keep project context for any model you switch to

fenbs stores your team's projects, tasks, Decisions and rules, lessons, and Where we left off outside any one AI app. When you try a new model or move between an open-source assistant and a commercial one, the context travels with you rather than staying behind in the old tool's chat history. Connect through Integrations to set it up.

Create a free account

Free for one person · No credit card · Works with Claude, ChatGPT, Cursor and more

Maintenance and community health

Check how recently a project was updated before you build on it. An open-source chatbot that is not actively maintained may have unpatched security issues, may not support the latest models, or may have an incompatible dependency in a year's time. Look at the GitHub commit history, the number of open issues, and whether pull requests are reviewed and merged. A healthy project is not necessarily the largest one; a smaller project with an active maintainer and quick responses to security reports is better than a popular one that has gone quiet.

Pay attention to how a project handles breaking changes in its dependencies. Model APIs change, and a chatbot frontend that worked well last month may behave differently after an upstream update if the project has not kept pace. Pin dependencies for production use, and run a smoke test when any dependency updates.

For the underlying models, see open-source LLMs for a look at the models themselves, separate from the chatbot frontends and interfaces built around them.

Keeping project decisions across tool switches

A team evaluating open-source chatbots will often try two or three before settling on one. During that period, the project decisions and requirements need to survive switching tools. Keeping them inside the chatbot under evaluation means they stay inside the tool you may abandon. The same problem applies when a new team member joins and needs to understand why the team chose a particular configuration.

A record outside the chatbot, covering why each tool was chosen, what rules were agreed on, and what the current tasks are, is more durable than the chat history of the evaluation itself. See open-source project management for keeping a project board alongside this work.

When to use a commercial assistant instead

Open-source chatbots are a good fit when data privacy is a hard requirement, when you need to run on hardware you control, or when you want to tune or replace the model without a vendor relationship. They are less convenient when you need phone apps, reliable uptime guarantees, or a product team handling updates. For most individual users, a commercial assistant is faster to start with. Open-source options become more compelling when your organization has specific data residency or compliance requirements, or when a team wants a shared, customizable tool without per-seat licensing costs.

When evaluating open-source chatbots alongside commercial options such as ChatGPT or Claude, see AI chatbot for business for a broader view of the decision criteria.

How to do this with fenbs

Create a free account and add a project for the work you plan to do with your open-source chatbot.
Write the rules and decisions your team has agreed on as Decisions and rules in that project. These appear first in the AI context when a connected assistant reads the project.
Add tasks for current work items so any assistant can see what is in progress and where each piece stands.
If your open-source chatbot supports MCP, connect it to fenbs from Integrations. Check that page for the current list of supported apps and setup guides.
Before switching from one model to another, ask the current assistant to save progress: what was completed, what is still running, and the next step for each open task.