# Kelivo: a Flutter LLM chat client that runs on Android, iOS, HarmonyOS and desktop

> Kelivo is an AGPL-3.0 Flutter chat client for OpenAI, Gemini, Anthropic and other providers, with MCP tool calling and a long list of search backends. It ships as an App Store build, GitHub release binaries and a separate HarmonyOS repository, and its UI is openly modelled on RikkaHub.

**Chevey339/kelivo** — A Flutter LLM Chat Client. Support Mobile & Desktop.

- Repository: https://github.com/Chevey339/kelivo
- Website: https://kelivo.psycheas.top
- Stars: 4,043 · Forks: 447
- Language: Dart
- License: AGPL-3.0
- Published: 2026-09-09 · Updated: 2026-09-09 · Language: en
- Canonical page: https://hysenlabs.com/projects/chevey339-kelivo

## What Kelivo is, and the problem it removes

Most people who use more than one LLM end up with a browser tab per provider, a separate mobile app per vendor, and no shared history between them. Kelivo's answer is a single Flutter client that talks to OpenAI, Google Gemini, Anthropic and other providers from one interface, on Android, iOS, Harmony, Windows, macOS and Linux. The README lists the supported platforms explicitly, and HarmonyOS is handled by a separate repository, kelivo-ohos, rather than in this tree.

The target user is someone who already holds API keys or provider accounts and wants a client, not a service. Kelivo does not proxy your traffic through its own backend as far as the README describes; you configure providers inside the app. That distinction matters for anyone comparing it with a hosted chat product, because it means the model choice, the key and the cost sit with you.

The feature list is broad: custom assistants, multimodal input for images, PDFs and Word documents, Markdown with code highlighting and LaTeX, TTS through system voices plus OpenAI, Gemini and ElevenLabs, MCP tool integration, prompt variables, QR code sharing of provider configurations, and chat history backup and restore. Breadth is not the same as depth, and the README does not describe how any of these are implemented.

## How the pieces fit together: Flutter shell, provider adapters, MCP tools

The repository layout tells you most of what the README does not. The top level holds android/, ios/, linux/, macos/, windows/ and web/ platform folders next to a single lib/ directory, which is the standard shape of a Flutter application rather than a plugin. There is a drift_schemas/ directory, which points at Drift as the local database layer, and a dependencies/ folder alongside pubspec.yaml. l10n.yaml plus README_ZH_CN.md match the stated English and Chinese interfaces.

So the data flow is local-first. Conversations, assistants and provider settings live in an on-device database, and the app makes outbound HTTP calls to whichever provider you configured. The README mentions custom HTTP request headers and bodies, which suggests the request layer is configurable enough to point at a self-hosted or relay endpoint, not only at the official vendor APIs.

Tool calling is where the architecture gets more interesting. Kelivo supports the Model Context Protocol and ships a built-in MCP Fetch tool. Web search is not one integration but a list: Bing, DuckDuckGo, Exa, Tavily, Zhipu, LinkUp, Brave, Metaso, SearXNG, Ollama, Jina, Perplexity, Bocha, Serper and Grok. That is a long tail of backends, and the README does not say which of them need their own API keys, which have free tiers, or how results are ranked before they reach the model.

## Installing Kelivo and sending a first message

The README does not give build-from-source instructions. It points at three distribution channels instead: the App Store listing, the GitHub releases page, and TestFlight for beta builds. The latest release in this material is v1.2.6, published on 2026-09-06, with v1.2.5 and v1.2.4 in the weeks before it. If you want a desktop build, the releases page is where the README sends you.

If you do want to build it yourself, the repository is a Flutter project, so the usual entry point is the pubspec. The README does not document the commands, so treat this as the shape of the workflow rather than a guarantee:

```bash
flutter pub get
flutter run -d macos
```

The platform folders in the repository (android, ios, macos, linux, windows) are what make those device targets available to the Flutter tool. What you should see is the chat screen shown in the README screenshots, with an empty conversation list.

Configuration comes next. The README advertises QR code sharing for provider configurations, which implies two paths: enter a provider and key by hand, or scan a code exported from another installation. A configuration shared this way carries credentials, so the transport you use to move that QR code is part of your security model, not an afterthought.

For a first real use, create a custom assistant, attach a model from a configured provider, and send a message. To exercise the parts that distinguish Kelivo from a plain chat box, enable web search or connect an MCP server and ask something that requires a tool call. The README shows a Tool Calling screenshot and a Web Search screenshot but does not walk through either setup, so expect to explore the settings screens yourself.

## Where Kelivo gets thin: storage, backup format and platform gaps

The README says chat history backup and restoration are supported, and that is the whole of it. There is no description of the backup format, whether it includes provider credentials, whether it is portable between Android and desktop, or whether it can be restored over an existing database. For a client whose value is accumulated conversation history, that is a real gap. Anyone planning to rely on Kelivo for long-lived threads should test an export and a restore before trusting it.

The same silence applies to the database. Drift schemas are versioned in the repository, which is normal for a local database that will be migrated across app updates, but the README gives no migration or rollback guidance. If a release changes the schema and something goes wrong, the documentation does not tell you what happens to existing data.

Platform support also needs reading carefully. The README marks Harmony as supported, but links to kelivo-ohos, a different repository. That means HarmonyOS users are dependent on a second project staying in step with this one, and this material does not show its release cadence. Android background generation is listed as an optional setting, which is the kind of feature that behaves differently across OEM battery managers; the README does not discuss that.

Finally, the interface design is credited to RikkaHub, and the README says the inspiration is heavy. If you have used RikkaHub, Kelivo will feel familiar rather than novel, and the two projects overlap in purpose.

## Kelivo against RikkaHub and against a chat UI you build yourself

The honest comparison is with RikkaHub, because Kelivo's own README names it as the design source. Both are Flutter LLM chat clients, so the difference is not the interface language but the surrounding feature set. Kelivo's README leans on breadth: fifteen search backends, three TTS server options besides system voices, MCP with a built-in Fetch tool, QR configuration sharing, custom fonts including on-demand Google Fonts, and an explicit HarmonyOS port. If your checklist includes a specific search provider or an MCP workflow, that list is the reason to pick Kelivo over the project it borrowed its look from.

The other alternative is not a product but a decision: build the client yourself on top of the provider SDKs. That gives you control over where conversation data lives, what the backup format is, and which platforms you support. It costs you everything in the README feature list, and the MCP and search integrations are not small pieces of work. For a team that already has a Flutter codebase and wants a chat surface, forking Kelivo under AGPL-3.0 is a third path, with the licence consequences that implies.

What none of these options give you is a server. Kelivo is a client. If your requirement is a shared, multi-user chat service with central logging, no amount of configuring providers turns this into one.

## Licence, maintenance and what an upgrade costs you

Kelivo is licensed under AGPL-3.0. The practical consequence for most readers is that if you modify it and let other people interact with it over a network, the licence's source-disclosure terms apply to your version. Distributing a modified build, for example an internal company app, carries the same obligation. Reading the LICENSE file and getting your own advice is the only responsible step here; this article is not legal advice.

The repository is not archived, and the last push was on 2026-09-09. Releases have been frequent: v1.2.4 on 2026-08-25, v1.2.5 on 2026-08-31, v1.2.6 on 2026-09-06. That cadence is the main signal about upgrade cost, because a client that ships every week will change its settings screens and its database schema at a similar rhythm. If you pin a version, expect to fall behind quickly; if you track releases, expect to re-check your provider and MCP configuration after updates.

The repository also contains AGENTS.md, CLAUDE.md and PRODUCT.md at the top level, alongside a docs/ and docx/ directory. Those files suggest the project keeps internal notes about its own direction, which is useful if you plan to contribute, and they are not described in the README. For a fork, the absence of a documented release process is the thing to assess before you depend on it.

## Conclusion

Kelivo suits people who want one chat client across phone and desktop that speaks to OpenAI, Gemini, Anthropic and a dozen search backends, and who accept the AGPL-3.0 obligations that come with shipping or modifying it. It is the wrong choice if you need a documented headless API, a server-side deployment, or a project whose README explains its data storage and backup format in detail. Before adopting it, check three things: that a release binary exists for your platform in the v1.2.6 assets, that the HarmonyOS build in the kelivo-ohos repository tracks the same version, and that your intended distribution model is compatible with AGPL-3.0.

## FAQ

### What is the Kelivo app?

Kelivo is a Flutter LLM chat client that supports mobile (Android, iOS, Harmony) and desktop (Windows, macOS, Linux). It connects to providers such as OpenAI, Google Gemini and Anthropic, and adds MCP tool calling, web search backends, custom assistants and local chat history.

### How do I install Kelivo on Windows or macOS?

The README does not give build instructions. It points to the App Store listing, the GitHub releases page for the latest version, and TestFlight for beta builds, so desktop users should look for a release asset rather than a documented build command.

### Does Kelivo support MCP and web search?

Yes. The README lists Model Context Protocol tool integration with a built-in MCP Fetch tool, and web search through Bing, DuckDuckGo, Exa, Tavily, Zhipu, LinkUp, Brave, Metaso, SearXNG, Ollama, Jina, Perplexity, Bocha, Serper and Grok.

### Is Kelivo available on HarmonyOS?

The README marks Harmony as a supported platform but links to a separate repository, kelivo-ohos, for that build. The main repository does not contain the HarmonyOS platform folder.

## Sources

- [Chevey339/kelivo on GitHub](https://github.com/Chevey339/kelivo)
- [License: AGPL-3.0](https://github.com/Chevey339/kelivo/blob/master/LICENSE)
- [Project website](https://kelivo.psycheas.top)
- [README](https://github.com/Chevey339/kelivo/blob/master/README.md)
- [Releases](https://github.com/Chevey339/kelivo/releases)

---

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