Cherry Studio: a desktop client for cloud and local AI models

Connecting models and built-in services

Cherry Studio is an Electron application whose entry point is ./out/main/main.js, built with electron-vite and packaged with electron-builder for Windows, macOS and Linux. You can connect cloud providers such as OpenAI, Anthropic and Gemini, add any custom service that speaks a compatible API, or point it at local models through Ollama and LM Studio. One conversation can hold answers from several models side by side, which is the main reason to keep multiple providers configured at once.

The consequence is that cost and capability sit with whoever you connect. The project states it plainly: model and tool availability depends on your provider, operating system and configuration, and some features need API credentials, downloaded models, extra dependencies or system permissions. The privacy policy also describes built-in model services that do not require a user-supplied API key; their availability and providers can change. Check the available services and their terms in your version.

Agents carry their own workspace, model and tool permissions

The v2 line centres on agents. Each agent gets its own instructions, its own workspace, its own model and its own set of tool permissions. Inside those limits an agent can work with files, run commands, and drive browser and computer automation tools. Capabilities extend through Skills and through MCP (Model Context Protocol) servers, and agents can run scheduled tasks or be wired to messaging platforms through a feature called Channels.

Because an agent can run commands and operate a browser, the permission settings per agent are the part to get right before anything else. Giving a general purpose agent a broad workspace and command access means a model you do not control is acting on your files. Scheduled tasks make this sharper: a misconfigured agent keeps running on its timer whether or not you are watching the window.

Local storage and model requests

Local knowledge bases are built from files, folders and web pages, then attached to conversations or agents. Document handling covers PDF, Office files, images and plain text, with OCR and document processing options. Markdown notes and a file library hold attachments and generated files. Conversation history is stored locally by default, and backups can use local storage or WebDAV. Requests sent to a cloud model are processed by that provider; the privacy policy says built-in services relay request content through Cherry Studio.

That design has a cost. There is no built-in sync service named for the desktop app, so moving to a second machine means setting up WebDAV or copying backups yourself. Shared knowledge bases and centralized model management appear only in the separate Enterprise Edition, which also adds employee access controls and private deployment. A team that wants everyone pointed at one curated knowledge base will not get that from the open source build.

Error reporting and privacy settings

Error reporting goes through Sentry. The repository's .env.example describes Sentry configuration, including a built-in public DSN and consent for production uploads. The privacy policy separately describes operational information and error reports as collected by default and points to privacy toggles; check the behavior and settings in the version you use. Source map upload is opt-in and is switched on by release workflows that hold SENTRY_AUTH_TOKEN, SENTRY_ORG and SENTRY_PROJECT credentials. A PRIVACY.md file sits at the repository root alongside SECURITY.md.

The same file shows a development detail worth knowing if you build from source: MAIN_VITE_CHERRY_CLOUD_API_ORIGIN points at http://127.0.0.1:8084 for a local Cherry Cloud backend, and without that override the edition's production origin is used. So a source build talks to a production Cherry Cloud origin unless you change it, and you should read PRIVACY.md for what that origin receives.

Global and CN editions come from one codebase

The build scripts in package.json split the app into two editions. The default build sets CHERRY_EDITION=global, while build:cn sets CHERRY_EDITION=cn and packages with a separate electron-builder.cn.config.cjs file. Linux targets exist for x64 and arm64, both together and separately, for each edition. Every build runs a typecheck first and then builds a utility process as a separate step.

For most users this only matters when picking a download, but it matters to anyone packaging the app themselves: the two editions are separate builds with separate builder configs, not a runtime toggle. Running several development copies side by side is handled with profile variables in .env.example:

#CS_DEV_PROFILE_ROOT=
#CS_DEV_USER_DATA_SUFFIX=

The first isolates Cherry home, userData and logs under an absolute root. The second appends a unique suffix and is ignored when the first is set.

Themes written for v1 break on the v2 interface

Appearance is open to change: light and dark themes, layouts and custom CSS. A community has grown around this, with a Theme Gallery at cherrycss.com and themes such as Aero, PaperMaterial, a Claude dynamic style and Maple Neon hosted in separate repositories.

The catch is the version jump. Themes written for v1 need adaptation for the v2 interface, and the project asks you to check each theme's supported Cherry Studio version before installing. Custom CSS targets the app's markup, so a theme that has not been updated can leave parts of the window unstyled or unreadable. If you depend on a heavily themed setup, pin to a release you have checked rather than taking every update.

Releases land days apart

The project is not idle. The last push to the main branch was on 2 November 2026, and three releases shipped within a week: v2.1.8 on 26 October, v2.1.9 on 30 October and v2.1.10 on 31 October 2026. package.json carries version 2.1.10. A nightly channel exists alongside stable releases.

This pace is good for fixes and bad for anyone who needs a stable surface, such as theme authors or people scripting against the API Gateway, which lets other applications use the models you have configured in Cherry Studio. Contributors branch from main, must sign and sign off their commits, and open pull requests against main using the repository template. A Branching Strategy document under docs/dev/contrib sets the release conventions.

AGPL-3.0 with a separate commercial track

The desktop source is licensed under AGPL-3.0, and the README carries a separate commercial license badge next to the license badge. The Enterprise Edition is sold through enterprise.cherryai.com, with purchasing, pricing and demos handled at [email protected]. No price for the desktop app itself appears in the README.

The mobile app for iOS and Android lives in its own repository, CherryHQ/cherry-studio-app, so mobile issues and builds are not tracked here. Searching this repository for an APK will not help; the mobile download sits at cherryai.com/mobile. The same split applies to the website and user documentation, which live in CherryHQ/cherry-studio-website.

Editorial conclusion

Cherry Studio brings several model providers, agents, MCP servers and knowledge bases into one desktop client. Its privacy policy describes both user-configured providers and built-in model services; availability depends on the service and configuration. Review the provider's data policies and agent permissions, and check privacy settings and theme compatibility before relying on the app.

Frequently asked questions

Official sources

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