# Oriveo Community Edition: one BYOK chat client for 15 providers and three platforms

> Oriveo is a bring-your-own-key AI chat client for iOS, Android and the web, with a Swift core shared across all three, keys you hold yourself, and no Oriveo service in the request path. It is AGPL-3.0, and the store builds are a separate commercial edition.

**oriveo/oriveo** — Open-source, bring-your-own-key (BYOK) multi-model AI chat client for iOS, Android and the web. One LLM client for OpenAI, Anthropic, Google Gemini, OpenRouter, DeepSeek and ten more providers, plus any OpenAI-, Anthropic- or Gemini-compatible endpoint — Ollama, LM Studio, llama.cpp, vLLM. Local-first, self-hostable, no account. AGPL-3.0.

- Repository: https://github.com/oriveo/oriveo
- Website: https://oriveoai.com
- Stars: 546 · Forks: 16
- Language: Swift
- License: AGPL-3.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/oriveo-oriveo

## The point is that no Oriveo service sits in the chat path

Oriveo Community Edition is an open-source, bring-your-own-key multi-model AI chat client for iOS, Android and the web, with a native macOS client in development. The framing in the README is that it is a local-first alternative to a hosted ChatGPT or Claude plan, for people who would rather pay a model provider directly than pay a subscription to whatever sits in front of it. You supply API keys you already own, the client talks to the provider with them, the web client is yours to self-host, and there is no Oriveo account and nothing reporting back. The stated reason the project exists is blunt: nobody should be able to meter, log or mark up the model you are paying for. The concrete guarantees that follow are three. Your keys and your bill, where you pay the provider's list price and nothing is marked up, metered or resold. Local by default, with conversations, notes, folders, skills and attachments living on the device, exportable to a file at any time, with no cloud copy to lose access to. And no account, where nothing reports back to us. One network call is explicitly acknowledged rather than hidden, a public read-only model catalog, so that a model released today works without an app update, with no key and no identifier attached, and the catalog can be pointed at a host of your own.

## Fifteen native providers plus any endpoint that speaks one of three protocols

The provider coverage is the concrete feature and it splits into two categories. Fifteen are native: OpenAI, Anthropic, Google Gemini, OpenRouter, DeepSeek, Grok, Mistral, Groq, Together AI, Fireworks AI, MiniMax, Z.ai, Qwen, Kimi from Moonshot and SiliconFlow. Then there is the relay category, any OpenAI-, Anthropic- or Gemini-compatible endpoint you point it at, which the README names as llama.cpp, Ollama, LM Studio and vLLM running on your own machine. The summary line is that you get one LLM client, one set of conversations, and whichever model answers. That is the actual product decision here, because a hosted chat product that supports many models usually hides that choice behind its own model routing and its own pricing table. The local model server support is the most specific part of the list, with llama.cpp, Ollama, LM Studio, vLLM and Open WebUI all named, and a discovery mechanism described, with iOS and Android finding them on the local network by mDNS where the engine advertises itself and otherwise by probing usual ports. Per-provider model and generation-parameter overrides are supported, along with a choice of regional endpoint where the provider offers one.

## The shared/ spec is the contract all three clients assert against

The architecture claim is the one that separates this from three separate apps that happen to share a name. The README states that how a request is shaped for a given provider, transport and capability is written down once in shared/, and that all three clients assert against the same JSON fixtures. The stated consequence is that a quirk living in that data is fixed once, while a quirk living in a parser is caught by three suites at the same time. This is the kind of design that only works if the spec is genuinely the source of truth rather than documentation that drifts, and the repository layout backs the claim up. There is a shared/ directory at the root as well as ios/, android/, web/ and macos/, plus a docs/ directory and a readme_i18n/ tree holding the localised READMEs, which cover Arabic, German, Spanish, French, Hindi, Indonesian, Japanese, Korean, Portuguese from Brazil, Russian, Thai, Turkish, Vietnamese and both Simplified and Traditional Chinese, and the client list is described as 16 languages with full right-to-left layout for Arabic. There is also an llms.txt file at the root, which is the machine-readable summary format intended for language models.

## Subscription sign-in and MCP tools sit alongside plain API keys

Two features extend the model beyond a key and a prompt. The first is subscription sign-in, which lets you use a ChatGPT or Grok subscription you already hold instead of an API key, over each provider's own device-authorization flow. That is a meaningful difference for someone who pays for a consumer plan and does not want a second bill for API usage, and it works through the provider's own authorisation rather than any credential sharing. The second is MCP tools, where the README describes adding a remote MCP server by its address and signing in through the browser or with a token. Skills are a third piece: reusable system prompts with their own model, reasoning setting and reference documents, which is the pattern people building agent workflows usually reach for and is rarely a first-class concept in a chat client. The feature list also covers the practical surface of a chat app in detail, including streaming, reasoning blocks, citations, attachments across a long list of formats, quote-a-selection, retry, regenerate, and continuing after an interrupted answer.

## The store builds are a different product from this repository

This is the single most important thing to understand before you install anything, and the README puts it in a sub-heading directly under the download links. The store builds are Oriveo, the commercial edition, and this repository is Oriveo Community Edition, built from source. The distinction is not cosmetic. The repository is the AGPL-3.0-or-later source, and the app you download from the App Store or Google Play is the commercially licensed build. The licence itself is stated at the top of the README with a badge for AGPL-3.0-or-later, and the repository root carries both a LICENSE file and a THIRD-PARTY-NOTICES.md file alongside SECURITY.md, CODE_OF_CONDUCT.md, COMMUNITY.md and CONTRIBUTING.md. For an organisation that intends to ship its own build of a BYOK chat client, the AGPL terms are the deciding factor, since they reach the network use of a modified version. The platform requirements are stated as badges: iOS 18 and later, Android 8 and later, the web client built with Next.js, and the macOS client marked as in development rather than shipped. The native client is Swift, which is the primary language for the repository.

## Building from source is the documented path here, and the docs are in docs/

Because this repository is the community edition built from source, the documentation is the thing to read before you start, and the README points at a get started section alongside the architecture section, the editions section and an FAQ. The repository does not present a single copy and paste build recipe in the part of the documentation available here, and the guidance it does give is to follow the get started section of the documentation rather than to clone and run a single command. The per-platform READMEs are the place to look, since the badges themselves link to ios/README.md, android/README.md, web/README.md and macos/README.md, which is a strong hint that build instructions differ per client. The macOS one is the one to read with the most care, since that client is still in development and the badge labels it as such rather than as available. The releases are tracked separately from the store edition, with the latest release links pointing at the GitHub releases page rather than the app stores, and the listed versions are v1.1.0 on 2026-09-23 and v1.0.0 on 2026-09-06, with the last push to the repository on 2026-10-19.

## Conclusion

Oriveo Community Edition suits a developer who already pays model providers directly and wants one chat client across a phone, a tablet and the browser, with conversations and attachments kept on the device and no vendor in the request path. It is the wrong choice if you want a hosted chat product with support behind it, since the store builds are the commercial edition rather than this repository, and it is the wrong choice if you cannot ship an AGPL-3.0 licensed application. Verify first which client you are actually running, since the community edition and the store edition differ, that the provider you want is either one of the 15 native integrations or speaks a compatible protocol, and that the shared/ spec you depend on is the one your client asserts against.

## FAQ

### What is Oriveo Community Edition?

It is an open-source, bring-your-own-key multi-model AI chat client for iOS, Android and the web, with a native macOS client in development. It is a local-first alternative to a hosted chat subscription, with no account and no Oriveo service in the chat request path.

### Which model providers does Oriveo support?

Fifteen are native, including OpenAI, Anthropic, Google Gemini, OpenRouter, DeepSeek, Grok, Mistral, Groq, Together AI, Fireworks AI, MiniMax, Z.ai, Qwen, Kimi and SiliconFlow. Any endpoint that speaks an OpenAI-, Anthropic- or Gemini-compatible protocol also works, which covers llama.cpp, Ollama, LM Studio and vLLM.

### Is the app on the App Store the same as this repository?

No. The README states that the store builds are Oriveo, the commercial edition, while this repository is Oriveo Community Edition built from source, under AGPL-3.0-or-later.

### How does Oriveo keep the three clients consistent?

How a request is shaped for a given provider, transport and capability is written down once in the shared/ directory, and all three clients assert against the same JSON fixtures, so a behaviour change is made in one place and checked by three suites.

## Sources

- [License: AGPL-3.0](https://github.com/oriveo/oriveo/blob/main/LICENSE)
- [oriveo/oriveo on GitHub](https://github.com/oriveo/oriveo)
- [Project website](https://oriveoai.com)
- [README](https://github.com/oriveo/oriveo/blob/main/README.md)
- [Releases](https://github.com/oriveo/oriveo/releases)

---

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