Oriveo Community Edition

Jedes Modell, eine App.

Open-Source-KI-Chat mit deinem eigenen Key, für iOS, Android und das Web, dazu ein nativer macOS-Client in Entwicklung. Kein Konto, kein Abo und kein Dienst von uns auf dem Weg der Chat-Anfrage.

Oriveo holen: oriveoai.com  ·  App Store  ·  Google Play  ·  Web-App

_{Die Store-Builds sind Oriveo, die kommerzielle Edition. Dieses Repository ist die Community Edition, aus dem Quelltext gebaut.}

Aus dem Quelltext bauen  ·  Architektur  ·  Editionen  ·  FAQ  ·  Mitwirken

English · العربية · Deutsch · Español · Français · हिन्दी · Indonesia · 日本語 · 한국어 · Português · Русский · ไทย · Türkçe · Tiếng Việt · 简体中文 · 繁體中文

Oriveo Community Edition ist ein quelloffener (open-source) Mehrmodell-KI-Chat-Client (multi-model AI chat client), der mit deinem eigenen Key arbeitet (bring-your-own-key, BYOK), für iOS, Android und das Web; ein nativer macOS-Client ist in Entwicklung. Er ist eine local-first Alternative zu einem gehosteten ChatGPT- oder Claude-Abo, für Leute, die einen Modellanbieter lieber direkt bezahlen als ein Abo für das, was davor sitzt. Du hinterlegst API-Keys, die dir ohnehin schon gehören, der Client spricht damit mit dem Anbieter, und den Web-Client kannst du selbst hosten (self-host) – kein Oriveo-Konto, und nichts, was etwas an uns zurückmeldet.

Er spricht 15 Modellanbieter nativ – OpenAI, Anthropic, Google Gemini, OpenRouter, DeepSeek, Grok, Mistral, Groq, Together AI, Fireworks AI, MiniMax, Z.ai, Qwen, Kimi (Moonshot) und SiliconFlow – dazu jeden OpenAI-, Anthropic- oder Gemini-kompatiblen Endpunkt, auf den du ihn zeigen lässt, auch llama.cpp, Ollama, LM Studio oder vLLM auf deinem eigenen Rechner. Ein LLM-Client (LLM client), ein Satz Unterhaltungen, egal welches Modell antwortet.

Niemand soll das Modell, für das du bezahlst, messen, protokollieren oder mit einem Aufschlag belegen können.

• Deine Keys, deine Rechnung. Du zahlst den Listenpreis des Anbieters. Nichts wird aufgeschlagen, gemessen oder weiterverkauft.
• Standardmäßig lokal. Unterhaltungen, Notizen, Ordner, Fähigkeiten und Anhänge liegen auf dem Gerät. Exportiere sie jederzeit in eine Datei; es gibt keine Kopie in der Cloud, deren Zugang du verlieren könntest.
• Ein Verhalten, drei Clients. Wie ein Request für einen bestimmten Anbieter, einen Transport und eine Funktion aussieht, steht einmal in shared/, und alle drei Clients prüfen gegen dieselben JSON-Fixtures. Eine Eigenheit, die in diesen Daten steckt, wird einmal behoben; eine, die in einem Parser steckt, fällt drei Test-Suites gleichzeitig auf.
• Das Einzige, was er abruft. Ein öffentlicher, nur lesender Modellkatalog, damit ein heute veröffentlichtes Modell ohne App-Update funktioniert – ohne Key, ohne von uns angehängte Kennung und auf einen eigenen Host richtbar.

• Chat – Streaming, Reasoning-Blöcke, Quellenangaben, Anhänge (Bilder und Video, PDF, Office (docx, xlsx, pptx), OpenDocument, EPUB, RTF, HTML und jede reine Text- oder Quelldatei), Auswahl zitieren, Wiederholen, Neu generieren, nach einer abgebrochenen Antwort fortsetzen
• Anbieter – 15 eingebaut, jeder mit deinem eigenen Key; Modell und Generierungsparameter pro Anbieter überschreibbar, dazu die Wahl eines regionalen Endpunkts, wo der Anbieter einen anbietet
• Relay-Dienst (Relay) – jeder OpenAI-, Anthropic- oder Gemini-kompatible Endpunkt, dazu die native API von llama.cpp, auch einer in deinem LAN
• Lokale Modellserver – llama.cpp, Ollama, LM Studio, vLLM, Open WebUI; iOS und Android finden sie im lokalen Netz per mDNS, wo die Engine sich ankündigt, sonst durch Abklopfen der üblichen Ports
• Anmeldung per Abo – nutze ein ChatGPT- oder Grok-Abo, das du schon hast, statt eines API-Keys, über den Device-Authorization-Flow des jeweiligen Anbieters
• Fähigkeiten – wiederverwendbare System-Prompts mit eigenem Modell, eigener Reasoning-Einstellung und eigenen Referenzdokumenten
• MCP-Tools – füge einen Remote-MCP-Server über seine Adresse hinzu, melde dich im Browser oder mit einem Access-Token an und lass das Modell dessen Tools im Chat aufrufen; jedes Tool läuft von selbst, fragt erst nach oder bleibt aus – so, wie du es einstellst
• Notizen und Ordner – eine Antwort als Notiz sichern, Unterhaltungen ordnen, in beidem suchen
• Mit anderem Modell prüfen – eine Antwort einem zweiten Modell zur Prüfung geben und beide zusammen behalten
• Gedächtnis – ein paar Fakten über dich, einmal aufgeschrieben und in jede neue Unterhaltung mitgenommen
• Kosten – Ausgaben pro Nachricht und pro Anbieter, auf dem Gerät berechnet aus dem, was jede Antwort tatsächlich gemeldet hat, inklusive der Stufen für Cache-Lesen und Cache-Schreiben
• Bildgenerierung – wo der Anbieter sie unterstützt
• Backup – alles in eine Datei exportieren; die Anbieter-Keys darin werden, wenn du sie mitnehmen willst, mit einem Passwort deiner Wahl verschlüsselt
• 16 Oberflächensprachen, inklusive vollständigem Rechts-nach-links-Layout für Arabisch

Dieses Repository ist die Oriveo Community Edition, lizenziert unter AGPL-3.0-or-later. Die Apps im App Store, bei Google Play und die gehostete Web-App sind Oriveo – ein separates proprietäres Produkt, das eine Kontoschicht hinzufügt.

Builds der Community Edition verwenden das Identifier-Präfix ai.oriveo.community, sodass einer auf demselben Gerät neben einem Store-Build stehen kann, ohne dass sich beide einen Keychain oder irgendwelche lokalen Daten teilen. Was diese Edition annimmt und was nicht, steht in COMMUNITY.md.

Oriveo, das vollständige Produkt: iPhone und iPad · Android · Web · oriveoai.com

Jeden Anbieter unten erreichst du mit einem Key, den du dir selbst anlegst. Zwei von ihnen erreichst du statt mit einem Key auch, indem du dich mit einem Abo anmeldest, das du schon hast: OpenAI mit einem ChatGPT-Abo und Grok.

Drei native Clients, eine Definition davon, wie man mit einem Modellanbieter spricht.

flowchart LR
    shared["shared/<br/>Request-Rezepte · Kontrakte · Fixtures"]

    subgraph clients ["Drei native Clients"]
        direction TB
        ios["iOS · SwiftUI"]
        android["Android · Compose"]
        web["Web · Next.js"]
    end

    route["Next.js Route Handler<br/>auf dem Server, der die App ausliefert"]

    subgraph upstream ["Mit deinen eigenen Zugangsdaten erreicht"]
        official["15 Modellanbieter"]
        relay["Beliebiges kompatibles Relay"]
        local["Ein Server bei dir"]
    end

    catalog[("Öffentlicher Modellkatalog<br/>nur lesend · ohne Key")]

    shared -.->|"von jedem Client geprüft"| clients
    catalog -.->|"Fähigkeiten und Preise"| clients
    ios & android ==>|"direkt vom Gerät"| upstream
    web ==> route ==> upstream
    web -.->|"CORS-taugliche Endpunkte und Relays im LAN"| upstream

Jeder Client hat seine eigene UI, seinen eigenen Speicher und seine eigene Navigation und trifft die gemeinsamen Kontrakte an genau einer Nahtstelle: der Schicht, die dieses Modell, diese Funktion in einen HTTP-Request verwandelt.

Die eine Asymmetrie, die man kennen sollte, ist der Web-Client. Die meisten Anbieter-APIs senden keine CORS-Header, ein Browser kann sie also nicht direkt aufrufen. Diese Requests laufen über einen Next.js Route Handler auf dem Rechner, der die App ausliefert – deinem eigenen, wenn du sie lokal betreibst. Die wenigen Endpunkte, die einen Browser doch zulassen (Kimis China-Endpunkt und die Guthaben-Endpunkte von OpenRouter, SiliconFlow, DeepSeek und Kimi), und Relays in deinem eigenen Netz werden direkt aufgerufen. Der iOS- und der Android-Client haben diese Einschränkung nicht und gehen immer direkt zum Anbieter.

Die Architektur der einzelnen Clients:

Fertige Binaries gibt es hier nicht – kein APK, keine .ipa. Die Community Edition ist Quelltext, den du selbst baust. Am schnellsten kommst du über den Web-Client zu einer laufenden App.

cd web
npm install
npm run dev:app        # http://localhost:3001

cd android
./gradlew :app:assembleDebug

• Anbieter-Keys landen im iOS Keychain und unter Android in EncryptedSharedPreferences, unter einem Schlüssel, der im Android Keystore liegt. Ein Browser hat dafür keine Entsprechung, also liegen sie im Web unverschlüsselt in IndexedDB – so wie bei Browser-BYOK-Clients allgemein üblich. Für die stärkste Garantie nimm den iOS- oder Android-Client.
• Unterhaltungen, Notizen, Ordner, Fähigkeiten und Anhänge liegen auf dem Gerät. Nichts wird irgendwohin hochgeladen.
• Kein Konto, und keine Analytics. Es gibt nichts, wo man sich anmelden müsste, und nichts zählt mit, was du tust. Das Web-Bundle enthält Sentry für Fehlerberichte. Es bleibt stumm, bis du NEXT_PUBLIC_SENTRY_DSN auf ein eigenes Projekt setzt, und wenn du das tust, ist es so konfiguriert, dass es neben Stacktraces auch Session Replays aufzeichnet. Der iOS- und der Android-Client enthalten überhaupt kein Reporting-SDK.
• Auf iOS und Android gehen Chat-Requests direkt vom Gerät zum Anbieter. Im Web laufen die meisten über den Next.js-Server, der die App ausliefert, weil die meisten Anbieter-APIs einen direkten Browser-Aufruf nicht zulassen. Dieser Server speichert weder Keys noch Nachrichten, und wenn du die App lokal betreibst, ist er dein eigener Rechner.
• Zwei Requests, die die App von sich aus macht: ein nur lesender Modellkatalog, gelesen in zwei Aufrufen. Der eine deckt ab, wie jedes Modell angesprochen werden will, der andere die Fakten zu einzelnen Modellen, den iOS erst nach einer Anmeldung per Abo liest. Zusammen sorgen sie dafür, dass ein heute veröffentlichtes Modell ohne neuen Build funktioniert. Keiner von beiden trägt einen Key, eine Unterhaltung oder eine von uns angehängte Kennung. Der Host sieht den Standard-User-Agent der Plattform, und das Einzige, was der Client zurückschickt, ist das ETag des Katalogs selbst, als If-None-Match. Den Web-Client (NEXT_PUBLIC_BACKEND_URL) und den Android-Build (-PORIVEO_METADATA_BASE_URL) kannst du auf einen eigenen Host richten; auf iOS ist dieses Override nur eine Bequemlichkeit für Debug-Builds.

ios/           iOS-Client (SwiftUI)
android/       Android-Client (Jetpack Compose)
web/           Web-Client (Next.js)
macos/         macOS-Client – in Entwicklung, kommt in den nächsten Monaten
shared/        Client-übergreifende Kontrakte, aufgezeichnete Fixtures, Swift-Wire-Kernel
readme_i18n/   Diese READMEs in fünfzehn weiteren Sprachen
docs/assets/   Bilder, die die READMEs verwenden
llms.txt       Ein maschinenlesbarer Index dieser Dokumentation
.github/       Vorlagen für Issues und Pull Requests

Fehlermeldungen und Pull Requests sind willkommen. CONTRIBUTING.md beschreibt, wie man jeden Client baut und wie ein guter Pull Request aussieht. COMMUNITY.md beschreibt, wofür diese Edition da ist und welche wenigen Arten von Änderung nicht angenommen werden, egal wie gut sie geschrieben sind.

Ein Sicherheitsproblem gefunden? Bitte mach dafür kein öffentliches Issue auf – SECURITY.md erklärt, wie du es privat meldest und was dieses Projekt als Schwachstelle behandelt und was nicht. Von allen Beteiligten wird erwartet, dass sie sich an den Verhaltenskodex halten.

AGPL-3.0-or-later. Beiträge werden unter derselben Lizenz angenommen.

Anbieternamen und -logos gehören ihren jeweiligen Eigentümern und erscheinen hier nur, um die Dienste zu benennen, auf die dieser Client gerichtet werden kann. Sie sind von der Lizenz dieses Repositorys nicht gedeckt, und dass sie hier auftauchen, ist von niemandem eine Empfehlung. Die Fonts und Bibliotheken, die die Clients mitbringen, und die Bedingungen, unter denen sie stehen, sind in THIRD-PARTY-NOTICES.md aufgeführt.