Cherry Studio: an Electron desktop client for many LLM providers at once

What Cherry Studio solves for people juggling several model providers

The README describes Cherry Studio as a desktop client supporting multiple LLM providers, available on Windows, Mac and Linux. That sentence is the whole pitch, and it is narrower than the tagline suggests. The problem it addresses is provider fragmentation. If you use OpenAI for one task, Anthropic for another, and a local model through Ollama or LM Studio for a third, you normally keep three browser tabs, three API key stores and three conversation histories. Cherry Studio puts those behind one interface and one topic list.

The second feature is the assistant library. The README claims 300+ pre-configured AI Assistants, plus custom assistant creation and multi-model simultaneous conversations. A pre-configured assistant here is a saved prompt plus a model binding, so the practical benefit is that you stop retyping the same system message. The third is document handling: text, images, Office files and PDFs, with WebDAV for file management and backup.

The audience is a single person at a desk. The README lists HarmonyOS, Android and iOS under Platform Support in the roadmap, which means those builds are planned, not shipped. If you want a chat client on your phone today, this is the wrong project, and the search traffic around "cherry studio apk" and "cherry studio ios" is asking for something the README does not yet offer.

Electron, a renderer, and MCP servers as the extension point

The repository layout makes the architecture plain. There is an electron.vite.config.ts, an electron-builder.yml, a src/ tree, a packages/ workspace, and a pnpm-workspace.yaml. package.json sets "main": "./out/main/main.js", which is the Electron main process entry point after a build. So Cherry Studio is an Electron application with a main process and a renderer, not a web app you can host.

That split matters for what the app can reach. The main process owns the operating system surface: file access for document ingestion, the WebDAV client for backup, and whatever network calls the providers need. The renderer draws the conversations and the Markdown, Mermaid and code highlighting the README lists. The build scripts confirm two editions: "build" sets CHERRY_EDITION=global and "build:cn" sets CHERRY_EDITION=cn, with a separate electron-builder.cn.config.cjs for the cn targets. There is also a build:utility-process step in both, so a third process type exists alongside main and renderer.

The extension mechanism is MCP. The README lists MCP (Model Context Protocol) Server under practical tools, and the roadmap lists an MCP Marketplace as future work. This is the part worth understanding before you commit: MCP servers give the model access to tools outside the chat window, and the README does not document a sandbox or a permission model for them. Treat every MCP server you add as code you chose to run.

Installing Cherry Studio on Ubuntu and wiring up a first model

The README says the app is ready to use with no environment setup required and points to the releases page and the official site for downloads. The .env.example file in the repository is for building from source, not for running the app, but it documents the variables a build expects. If you want to compile it yourself, the workspace uses pnpm.

pnpm install
pnpm run build
pnpm run build:linux:x64

The first command installs the workspace dependencies, the second typechecks and runs the electron-vite build with CHERRY_EDITION=global, and the third packages a Linux x64 artifact through electron-builder. The build script sets NODE_OPTIONS=--max-old-space-size=8000 in .env.example, so a machine with limited memory will struggle here. There are separate scripts for arm64 and for the cn edition, for example build:linux:arm64 and build:linux:cn.

For a first real use, the more common path is the packaged installer from the releases page rather than a local build. After launching, you add a provider and paste its API key, then pick a model. The .env.example shows the shape of the configuration the project expects for a build-time default provider:

API_KEY="sk-xxx"
BASE_URL="https://api.siliconflow.cn/v1/"
MODEL="Qwen/Qwen3-235B-A22B-Instruct-2507"

Those three keys name a SiliconFlow endpoint and a Qwen model. In the running app the equivalent step is the provider settings screen, where you supply the base URL and key for whichever service you use. Once a provider responds, pick one of the bundled assistants or create your own, and the first conversation will render with Markdown and code highlighting. If you are adding a local model instead, the README names Ollama and LM Studio as supported.

Where Cherry Studio is the wrong tool

The clearest limitation is the one the README states as a feature: it is a desktop client. There is no server mode, no container image in the top-level repository entries, and no documented way to run it headless on a shared machine. A team that wants a single internal chat endpoint with centralized keys and audit logs cannot get that from this repository. WebDAV backup moves your data between your own devices, which is not the same as a multi-user deployment.

The second limitation is the platform gap. HarmonyOS, Android and iOS all appear under Platform Support in the roadmap, which is a statement of intent. Anyone who needs a phone client now should read that list as a list of things that do not exist yet.

The third is the assistant count. 300+ pre-configured assistants is a large number, and the README gives no detail on how they are curated, how often they are revised, or what model each one assumes. A saved prompt is only as good as the prompt, and a large library makes it harder to tell which entries are maintained and which are filler. The repository does include a build:builtin-knowledge script and a generate-cherry-assistant-knowledge generator with a --check mode, which suggests the built-in assistant knowledge is generated rather than hand-written, but the README does not describe the review process behind it.

Finally, MCP servers are an attack surface. The README lists MCP Server support with no mention of isolation, allowlists or per-server permissions. That is a design gap, not a bug, and it should shape how freely you add third-party servers.

How Cherry Studio differs from a browser-based client like Chatbox

The obvious comparison is Chatbox, another multi-provider chat client, and the difference is mostly in where the code runs and what it can touch. Cherry Studio is Electron with a main process, which is what lets it read local files for document ingestion, write to a WebDAV target, and spawn MCP servers. A browser-based client is bounded by the browser sandbox and by whatever the page's origin allows.

That extra reach cuts both ways. Reading your local PDFs and Office documents is useful. It also means the app has filesystem access that a web client does not, and the security properties of the two are not comparable. If your threat model is "I do not want a desktop binary touching my disk," a web client wins on that axis alone.

The second difference is the extension model. Cherry Studio's roadmap centers on MCP: an MCP Marketplace, a plugin system, and a Selection Assistant. Chatbox's feature set is not described in this repository, so a fair comparison on extensibility is not possible from what the repository documents. What can be said is that Cherry Studio has committed publicly to MCP as its integration path, and that choice determines which third-party tools you can plug in.

Licence, maintenance and what an upgrade costs you

Cherry Studio is licensed AGPL-3.0. The repository also carries a commercial licence badge and a sponsor link in the README, which is the common dual-licensing pattern: the AGPL governs the open source distribution, and a separate commercial licence exists for cases the AGPL does not suit. The AGPL's network clause is the part that matters for anyone embedding this code in a service. If you fork Cherry Studio and expose a modified version over a network, the AGPL's source-availability obligation is the question to put to a lawyer. Nothing here is legal advice, and the repository's LICENSE file is the authority.

Maintenance looks current. The last push was on 2026-08-28, and the most recent releases are v2.0.10 on 2026-08-28, v2.0.9 on 2026-08-24 and v2.0.8 on 2026-08-19. The cadence is roughly weekly across those three. The repository is not archived. package.json declares version 2.0.14 while the newest listed release is v2.0.10, which is normal for a main branch that runs ahead of tagged releases.

Upgrade cost depends on how you installed it. If you use the packaged installer, upgrading is replacing the application, and your conversations and provider keys live in the app's user data directory. The .env.example mentions CS_DEV_USER_DATA_SUFFIX for running multiple dev instances side by side, which tells you the user data directory is the unit you would need to back up. If you build from source, an upgrade means pulling main and re-running the build chain, and the typecheck step in pnpm run build will surface any breakage before you package anything. There is no documented migration path between major versions in the README, so read the release notes for a version before you jump to it.

Editorial conclusion

Adopt Cherry Studio if you want one desktop window for cloud and local models, and you accept the AGPL-3.0 and Electron trade-offs. Skip it if you need a headless server, a mobile client today, or a self-hosted web deployment. Before installing, check the releases page for the current version and the exact asset for your platform, then read PRIVACY.md and SECURITY.md in the repository before you paste in API keys for a provider account you care about.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes