# cherry-studio: one Electron codebase shipped as two editions, with a rewards program still dated to Q3 2025

> A TypeScript desktop client for many LLM providers, with assistants generated by a build script, Sentry reporting gated on user consent, and a CHERRY_EDITION flag that decides which product and which cloud origin you get. The contributor incentive on the page describes a window that has already closed.

**CherryHQ/cherry-studio** — Cherry Studio is a multi-provider LLM desktop client for Windows, macOS and Linux combining smart chat, autonomous agents and 300+ built-in assistants.

- Repository: https://github.com/CherryHQ/cherry-studio
- Website: https://cherryai.com
- Stars: 52,245 · Forks: 5,025
- Language: TypeScript
- License: AGPL-3.0
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/cherryhq-cherry-studio

## CHERRY_EDITION picks the product, the builder config, and the cloud origin

There is no single build command in this repository. Every platform script is paired with a cn variant, and the switch is one environment variable threaded through dotenv:

```
pnpm run typecheck && dotenv -v CHERRY_EDITION=global -- electron-vite build && pnpm run build:utility-process
```

The cn equivalents set CHERRY_EDITION=cn and point electron-builder at a different config file, electron-builder.cn.config.cjs, instead of electron-builder.yml. The origin is switchable as well, and the development template says why in a comment: it points at a local Cherry Cloud backend, and without the override the edition's production origin is used.

```
MAIN_VITE_CHERRY_CLOUD_API_ORIGIN=http://127.0.0.1:8084
```

The consequence is that a build target is not just an operating system and an architecture. You are choosing a product edition and a backend origin at the same time. What the page cannot tell you is what the two editions differ in beyond the builder config and origin, so treat the edition names as build inputs and not as a documented feature matrix.

## The 300+ assistants are generated by a script that has its own check mode

The feature list advertises more than 300 pre-configured assistants alongside custom assistant creation and multi-model simultaneous conversations, and the assistant catalogue is not hand maintained data. There is a script for it, and there is a second command that only checks:

```
tsx scripts/generate-cherry-assistant-knowledge --check
```

That pairing is the interesting part. The generator runs as part of the build story, so the assistant knowledge is derived output, and the check mode exists so a mismatch between the generated content and the source of truth fails loudly instead of shipping. If you fork this project, the first thing to run is the check, because a catalogue that is out of step with its source will not announce itself. The package manifest also wires a wider verification set: `pnpm lint && pnpm docs:check && pnpm test`, plus vitest bench projects split across aiCore, main, renderer, and shared, and two Playwright configs, one of them named for regression.

## The rewards program names a tracking period that closed in September 2025

The Developer Co-creation Program is the part of the page that has not aged well. The inaugural tracking period is given as Q3 2025, July through September, with rewards for that cycle distributed on October 1st. The threshold is stated as more than 30 meaningful commits to any of the project's open source repositories on GitHub. What you get for clearing it is a $70 USD credit or reimbursement for a Cursor subscription, unlimited API calls for the DeepSeek and Qwen models, and occasional perks that include API access to models like Claude, Gemini, and OpenAI.

The consequence is straightforward for anyone weighing a contribution today. The only terms on the page describe a cycle that has already finished, and no second tracking period is named, so there is no stated basis for what a current contribution earns. Read the page as a record of one past cycle rather than as an offer, and check GitHub Discussions for anything newer before you plan around it.

## The root manifest is private, so there is no package to pin

The manifest is named CherryStudio, its version reads 2.1.3, and that number matches the v2.1.3 release tag dated 2026-09-24, with v2.1.2 on 2026-09-21 and v2.1.0 on 2026-09-18 behind it. It is also marked private, and its entry point is the built main process at ./out/main/main.js. The consequence is that you cannot depend on this project the way you depend on a library: there is no published artifact to add to a lockfile, and the version field is a build input rather than something a package manager resolves. What you consume is a desktop build, and the update path for it is the app's own updater, with a dev-app-update.yml at the repository root and electron-builder producing the platform packages. The rest of the tree is organised for that reality, with separate TypeScript configurations for the end to end suite, the node side, and the web renderer, plus a pnpm workspace file and a patches directory.

## Sentry reporting is disabled in development and needs consent in production

The development environment file is unusually candid about telemetry, and its comments state the policy rather than leaving you to infer it. Sentry uses a built-in public DSN. Development reporting is disabled. Production uploads require user consent. Source map upload is opt-in, release workflows turn it on, and it needs credentials you supply yourself, with SENTRY_AUTH_TOKEN, SENTRY_ORG, and SENTRY_PROJECT all commented out and unset by default. The consequence is one for organisations running a fork. Because the DSN is built in, your build reports into a project you do not control unless you switch on source map upload and point the variables at your own organisation, and if you would rather have no telemetry at all, the consent gate is something the application enforces on the user's behalf, not something you can strip out of a build flag. Two other entries in the same file are worth knowing: NODE_OPTIONS is preset to --max-old-space-size=8000, and CS_DEV_PROFILE_ROOT isolates the Cherry home, userData, and logs into one directory during development.

## Mobile and HarmonyOS are roadmap items, not artefacts you can download

The application as described is a desktop client on Windows, Mac, and Linux, and the build scripts visible in the manifest target Linux and the electron-vite pipeline, one script building both x64 and arm64 in a single electron-builder call. Everything else is on the roadmap, and the roadmap is specific about stage. Platform support lists a HarmonyOS edition for PC, an Android app marked phase 1, an iOS app marked phase 1, multi window support, window pinning, and Intel AI PC support for Core Ultra. Knowledge management lists notes and collections, a dynamic canvas, OCR, and text to speech, and advanced features list a plugin system and ASR, with an MCP marketplace and deep research under core features. The consequence is that anyone looking for a phone or tablet build from this repository will not find one, and phase 1 labels are an early stage signal rather than a delivery date. The same applies to the plugin system, which is planned but not yet the mechanism for extending the app today.

## Theming is delegated to a gallery and four community repositories

Appearance is treated as somebody else's problem in a deliberate way. The page links a theme gallery at cherrycss.com and then four separate community themes: an Aero theme, a PaperMaterial theme, a Claude dynamic style, and a Maple Neon theme, each in its own repository, with an explicit invitation to open pull requests for more themes. The shipped client adds its own light and dark themes and a transparent window option, so the baseline is covered and everything beyond that is community work. The consequence for a user is that a visual change you want may be a pull request against a third party repository rather than a setting, and a theme is a separate maintenance stream that moves on its own schedule. The same split shows up in the project structure, where a v2-refactor-temp directory sits at the top level next to migrations/, and where a design document and multiple agent instruction files are checked in.

## Conclusion

cherry-studio suits someone who wants a single desktop client holding several provider keys, local models through Ollama or LM Studio, and a large catalogue of pre-configured assistants, and who is willing to read a documentation site rather than infer behaviour from the repository. It does not suit a team that needs a pinned dependency, an owned error reporting project, or a defined contributor incentive, because the manifest is private, the Sentry DSN is built in, and the stated rewards period ended in September 2025. Before adopting, check which edition you are getting, and where your API keys and conversation data live on disk.

## FAQ

### What is Cherry Studio?

It is a desktop client that supports multiple LLM providers, available on Windows, Mac, and Linux, published under the AGPL-3.0 licence. It lists major cloud services such as OpenAI, Gemini, and Anthropic, web services such as Claude, Perplexity, and Poe, and local models through Ollama and LM Studio, along with more than 300 pre-configured assistants.

### how to install cherry studio

The page prints no install command. It points to the official site at cherry-ai.com, documentation at docs.cherry-ai.com, and a development guide at docs/contrib/development.md, and the application is described as ready to use with no environment setup required.

### is cherry studio open source

Yes, under the AGPL-3.0 licence. The repository ships a CODE_OF_CONDUCT.md, CONTRIBUTING.md, SECURITY.md, and PRIVACY.md, and contributions follow a branching strategy documented at docs/contrib/branching-strategy.md with a fork, branch, push, and pull request workflow.

### how to use mcp in cherry studio

MCP appears among the practical tools as an MCP (Model Context Protocol) Server, and an MCP Marketplace for that ecosystem is on the roadmap rather than shipped. The page does not describe how to add or configure a server, so that part is left to the documentation.

### Is Cherry Studio safe?

The page makes no safety claim of its own. It does state that Sentry error reporting is disabled in development, that production uploads require user consent, and that source map upload is opt in, and the development template shows that you supply your own API key, base URL, and model name.

## Sources

- [Official documentation](https://cherryai.com)
- [Official README](https://github.com/CherryHQ/cherry-studio#readme)
- [Project repository](https://github.com/CherryHQ/cherry-studio)
- [Release notes](https://github.com/CherryHQ/cherry-studio/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cherryhq-cherry-studio