DEEIX Chat: Eine Go-Plattform für Modellrouting, Multimodal-Chat und Abrechnung
DEEIX-AI/DEEIX-Chat bietet eine praxistaugliche Open-Source-Implementierung mit stabiler Einsatzbarkeit für reale Anwendungsfälle.
Auf einen Blick
- Was ist das?
- Das Repository DEEIX-AI/DEEIX-Chat bündelt multimodalen Chat, Routenbindung auf mehrere Modelllieferanten, Dateien mit RAG, MCP-Werkzeuge, Abrechnung und Prüflisten in einer einzigen Go-Laufzeit mit statisch ausgeliefertem Next.js-Frontend.
- Für wen ist es gedacht?
- DEEIX Chat richtet sich an Teams und Unternehmen, die einen einzigen Einstiegspunkt für mehrere Modelllieferanten wie OpenAI, Anthropic und Gemini brauchen und Abrechnung sowie Prüflisten nicht aus einzelnen Bausteinen zusammensetzen wollen. Wer nur einen einzelnen Chat-Client sucht, trägt unnötige Betriebslast.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Go, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Ein Plattformumfang von Routing bis Abrechnung
DEEIX Chat beschreibt sich im README als quelloffene, installierbare KI-Plattform für Einzelpersonen, Teams und Unternehmen, die dauerhaften, stabilen und vereinheitlichten Zugriff auf mehrere Modelllieferanten brauchen. Statt vieler kleiner Werkzeuge soll das Produkt mehrere obere Anbieter hinter einem klaren Eintrittspunkt verbergen und zugleich multimodalen Chat, Modellrouting, Dateien mit RAG, MCP-Werkzeuge, Nutzungsabrechnung, Identität, Prüflisten und Betriebseinstellungen in ein Programm integrieren.
Das Featureverzeichnis des README ist nach Bereichen sortiert. Für Gespräche nennt es Streaming, Verzweigungen, Wiederholungen, Bearbeitungen, Rückmeldungen, Teilen und nachvollziehbare Metadaten der Modellausführung. Für Modelle und Routing nennt es eine Plattformmodell-Schicht mit Kanälen, echten Modellen, Routenbindungen, Prioritäten, Gewichten, Unterbrechungen bei Ausfällen und Anbieterzuordnung. Daneben stehen Protokollunterstützung für OpenAI, Anthropic, Google/Gemini, xAI, OpenRouter und OpenAI-kompatible Anbieter über Text, Bilder und Werkzeuge hinweg.
Architektur: Eine Go-Laufzeit mit statischem Next.js-Frontend
Die Bauplan-Tabelle im README teilt das System in Schichten mit festen Technologien. Das Frontend läuft auf Next.js 16 und React 19 mit TypeScript, Tailwind CSS, Shadcn/UI, Streamdown, KaTeX, Mermaid, Recharts und Motion. Die Backend-Laufzeit ist Go 1.26 mit Gin, Gorm, Swagger, OpenTelemetry und Zap. Daten und Zwischenspeicher nutzen PostgreSQL mit pgvector, SQLite mit sqlite-vec, Redis oder einen Speicher im Hauptspeicher, Dateien landen im lokalen Dateisystem oder in S3-kompatiblem Objektspeicher.
Das Herzstück ist der Ablauf mit einer einzelnen Laufzeit: Das Frontend wird zu statischen Dateien gebaut und vom Go-Dienst mitgeliefert, während APIs, Berechtigung, Modellrouting, Dateien, Abrechnung und Prüfliste im selben Backend-Prozess laufen. Schwere Dokumentverarbeitung und Texterkennung sind laut README optionale Dienste, damit die Grundinstallation leicht bleibt. Die Liste für diese Zusatzdienste reicht von Apache Tika und Docling über RapidOCR und Tesseract OCR bis zu Paddle OCR, Cloud-Adaptern und MinerU.
Innenleben: cmd/internal/cli bis infra
Das README beschreibt die inneren Grenzen des Backends in Pfadform. Der Einstiegspunkt liegt in cmd/internal/cli, internal/app baut die Anwendung zusammen, transport/http besitzt die HTTP-Grenze, die Schicht application koordiniert Anwendungsfälle und Vorgänge, domain trägt die geschäftliche Bedeutung, und infra enthält die Umsetzungen für Datenbank, Zwischenspeicher, Speicher und äußere Protokolle.
Auch die Datenhaltung folgt dieser Ordnung. Die Datenschicht nutzt Tabellen mit Domänen-Vorwort, während Finanzunterlagen, Prüflisten, Systemereignisse und schnell wachsende Vektordaten als getrennte Quellen der Wahrheit geführt werden. Wer das System in sein eigenes Team integrieren will, findet in dieser Beschreibung eine brauchbare Karte, an der sich eigene Erweiterungen einpassen lassen, etwa ein neuer Protokolladapter in infra oder ein zusätzlicher Anwendungsfall in application.
Dateien, Abruf und Gedächtnis für den Gesprächskontext
Der Bereich Dateien und Abruf umfasst laut README das Hochladen und Vorschauen von Dateien, das Herausziehen von Text, Texterkennung, Speicherguthaben, Einspeisung des vollen Zusammenhangs, Zerteilung, Einbettungen und sinngemäße Suche. Ziel ist, dass der Inhalt von Dokumenten von selbst in den Gesprächszusammenhang rückt, ohne dass Nutzer Texte von Hand hineinkopieren.
Für den Kontext-Umfang listet das README Nachrichtenfenster, Zeichenbudgets, Zusammenfassung durch Verdichtung, Gesprächsgedächtnis, dauerhaftes Gedächtnis und Nachweise aus der sinngemäßen Suche, mit dem ausdrücklichen Ziel kontrollierter Kosten bei dauerhaften Gesprächen. Das Werkzeugumfeld ergänzt MCP-Server und anbieter eigene offizielle Werkzeuge mit Auffinden, Freischalten, Auswahl durch den Nutzer, Ausführungsgrenzen, Darstellung der Ergebnisse und Nachverfolgbarkeit der Werkzeugaufrufe.
Abrechnung mit Stripe Checkout, EPay und Nutzungslisten
Ein selten anzutreffender Baustein in einem Chat-Framework ist eine vollständige Abrechnungsschicht. Das README nennt Modellpreise, Werkzeugpreise pro Aufruf, Abonnements, Aufladungen, Guthaben, Nutzungslisten, Abrechnungsschnappschüsse, Stripe Checkout, EPay und Bestätigung über Webhooks. Damit ist der Weg von einer Modellaufruf-Rechnung bis zur Geldbewegung im Produkt vorgesehen, nicht erst durch eine externe Buchhaltung.
Für den Betrieb innerhalb eines Unternehmens ist diese Schicht nicht zwingend nötig, doch sie erklärt einen Teil der Architektur: Finanzunterlagen und Prüflisten sind laut Architekturabschnitt von den übrigen Daten getrennt. Wer die Abrechnung nicht braucht, kann die zugehörigen Bereiche bei der Einführung einfach außer Acht lassen; für den Weiterverkauf von Modellzugriffen an interne Abteilungen oder Kunden ist sie dagegen bereits vorgebaut.
Identität und Sicherheit von TOTP bis SSO
Der Bereich Identität listet lokale Konten, Sitzungsverwaltung, HttpOnly-Erneuerungscookies, 2FA/TOTP, vertrauenswürdige Geräte, SSO/OIDC/OAuth, Kontaktbestätigung und verschlüsselte sensible Daten auf. Für den Betriebsmodus hält das README fest, dass die Produktion unsichere Standardschlüssel, schwache Verschlüsselungsschlüssel, CORS mit Platzhalter und öffentliche URLs ohne HTTPS zurückweist, und dass Erneuerungsmarken sowie wiederherstellungsartige Geheimnisse als Hashes gespeichert werden.
Für Verwaltung und Nachvollziehung nennt das README eine zentrale Verwaltung von Nutzern, Rollen, Anbietern, Modellen, Routen, Preisen, Abonnements, Guthaben, Nutzungslisten, Prüflisten, Anmeldeereignissen und Systemereignissen. Diese Gegenstände liegen im gleichen Verwaltungsbereich wie die Modellkonfiguration, was die Prüfung von Zugriffen auf Modellkanäle innerhalb eines Programms möglich macht.
Erste Schritte mit config.example.yaml und pnpm dev
Für die örtliche Entwicklung beschreibt das README drei Schritte. Zuerst kopiert man die Konfiguration mit cp config.example.yaml config.yaml und passt database.postgres.dsn, database.redis.* und öffentliche URLs in config.yaml an die eigene Umgebung an. Danach folgen pnpm install und cp frontend/.env.example frontend/.env.local. Der Start geschieht mit pnpm dev, wobei pnpm dev:web oder pnpm dev:api nur einen der beiden Arbeitsbereiche starten. Das Frontend verwendet NEXT_PUBLIC_API_BASE_URL für API-Anfragen.
Das README weist ausdrücklich darauf hin, dass die Standardkonfiguration eine örtliche PostgreSQL- und Redis-Verbindung erwartet und die örtliche Entwicklung für das Bearbeiten des Quellcodes gedacht ist. Wer nur eine Ausprobierung mit wenigen Abhängigkeiten sucht, wird stattdessen auf die leichte Docker-Installation verwiesen. Verweise auf Anleitungen, Telegram-Gruppe und X-Konto führen zur Projektseite deeix.com und deren Schnellstartdokumentation.
Fazit: Junges Projekt mit umfassendem Funktionsanspruch
Die Zahlen des Repositories zeichnen ein junges, schnell bewegtes Bild. DEEIX-AI/DEEIX-Chat verweist laut Metadaten auf 1384 Sterne, 204 Forks und nur 5 offene Issues, der Standardzweig ist dev. Die Versionsgeschichte zeigt v0.4.0 vom 28. August 2026, v0.3.6 vom 20. August 2026 und v0.3.5 vom 13. August 2026, also Veröffentlichungen im Wochentakt. Die Lizenz ist Apache-2.0, was Einbettung in eigene Produkte ohne Rückführungspflicht erlaubt.
Der Funktionsanspruch ist breiter als bei gewöhnlichen Chat-Frontends: Routing über mehrere Lieferanten, Abrechnung, Identität und Prüflisten sind vorgebaut, während Docker, Docker Compose, SQLite oder PostgreSQL die Einstiegswege bilden. Beachten sollte man das Alter des Projekts und die Tatsache, dass Leistungswerte oder Betriebsversprechen über die Beschreibung hinaus im README nicht belegt sind. Wer es ernsthaft prüfen will, fährt am besten einen Probelauf mit Docker Compose, schaltet einen Modellkanal über die Verwaltungsoberfläche frei, verbindet ein Testdokument mit sinngemäßer Suche und vergleicht die Abrechnungseinträge auf der Nutzungsliste mit den tatsächlich erfolgten Aufrufen.
Redaktionelles Fazit
DEEIX Chat richtet sich an Teams und Unternehmen, die einen einzigen Einstiegspunkt für mehrere Modelllieferanten wie OpenAI, Anthropic und Gemini brauchen und Abrechnung sowie Prüflisten nicht aus einzelnen Bausteinen zusammensetzen wollen. Wer nur einen einzelnen Chat-Client sucht, trägt unnötige Betriebslast. Vor dem Einsatz lohnt der Schnellstart über config.example.yaml und pnpm dev sowie ein Blick auf die Abrechnungs- und Sicherheitsfunktionen in der eigenen Konfiguration.
Community-Notizen