Risuai: Rollenspiel-Frontend für LLMs, das Prompt-Aufbau und Ausgabe selbst kontrolliert
Make your own story. User-friendly software for LLM roleplaying
Auf einen Blick
- Was ist das?
- Risuai ist eine TypeScript-Anwendung mit Tauri-Paket für Chat-Rollenspiel gegen viele LLM-Anbieter. Der Reiz liegt weniger im Chatfenster als in den Eingriffen in Prompt-Reihenfolge, Ausgabe-Nachbearbeitung und Speicherverwaltung. Wer das nicht braucht, fährt mit einem schlankeren Client besser.
- Für wen ist es gedacht?
- Risuai passt zu Anwendern, die Prompt-Aufbau, Ausgabe-Nachbearbeitung und Speicherverwaltung selbst steuern wollen und dafür ein größeres Interface in Kauf nehmen. Wer lediglich gelegentlich mit einem Modell plaudern möchte, sollte bei einem Web-Client bleiben, der keine Character-Cards, Lorebooks und Regex-Skripte kennt.
- Darf ich es kommerziell nutzen?
- Ja, unter Bedingungen. GPL-3.0 ist eine Copyleft-Lizenz: Wenn Sie Software weitergeben, die sie enthält, müssen Sie deren Quellcode unter derselben Lizenz veröffentlichen. Wer sie nur intern betreibt, ohne sie weiterzugeben, löst diese Pflicht nicht aus.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 6 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich TypeScript, 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 Frontend für Modell-Rollenspiel, nicht ein Modell
Risuai liefert kein Sprachmodell mit. Die Anwendung ist die Schicht zwischen dem Nutzer und einer API: Sie baut den Prompt, schickt ihn an einen Anbieter und stellt die Antwort dar. Die README beschreibt das Selbstverständnis als "cross platform AI chatting software / web application" und nennt als Zielgruppe alle, die eigene Geschichten mit einem Modell spielen wollen. Praktisch richtet sich das an Leute, die mehr Kontrolle über den Kontext wollen als ein einfaches Chatfenster bietet. Wer nur gelegentlich einen Prompt abschickt, ist hier falsch: Der Funktionsumfang verlangt Einarbeitung in Character-Cards, Lorebooks und Prompt-Reihenfolgen. Der Nutzen entsteht erst, wenn ein Modell über viele Sitzungen hinweg dieselbe Figur mit konsistentem Hintergrund spielen soll.
Prompt-Aufbau, Ausgabe-Nachbearbeitung und Speicher als drei getrennte Hebel
Die README nennt drei Mechanismen, die zusammen den eigentlichen Charakter des Projekts ausmachen. Erstens "Powerful Prompting": Die Reihenfolge der Prompt-Bestandteile lässt sich ändern, es gibt Bedingungen und Variablen, und eine Impersonate-Funktion kann Text innerhalb des Prompts platzieren. Zweitens der "Regex Script"-Punkt: Die Ausgabe des Modells wird per regulärem Ausdruck nachbearbeitet, laut README auch, um eine eigene Oberfläche zu bauen. Das ist ein Eingriff nach der Generierung, kein Fine-Tuning. Drittens die Speicherschicht: Die README nennt HypaMemoryV2/V3 als Speicherkompression und SupaMemory für Kontextverwaltung. Wie diese Verfahren intern arbeiten, geht aus dem Material nicht hervor; die Wiki ist laut README als "Work in Progress" markiert. Ein Lorebook ergänzt das, indem es Figuren Hintergrundwissen mitgibt, das nur bei Bedarf in den Kontext gelangt. Zusammen ergibt das eine Kette: Prompt zusammensetzen, Modell aufrufen, Ausgabe filtern, relevanten Speicher nachziehen.
Anbindung an Anbieter und lokale Inferenz
Die Anbieterliste in der README umfasst OpenAI, Claude, Gemini, DeepInfra, Ooba, OpenRouter und weitere. Ooba verweist auf die Text-Generation-WebUI, also auf lokal betriebene Modelle; die übrigen sind gehostete Dienste. Damit ist Risuai nicht auf einen Anbieter festgelegt, und der Wechsel zwischen einem lokalen Llama-Setup und einer gehosteten API ist eine Konfigurationsfrage, kein Umbau. Die README führt zusätzlich ein Plugin-System auf, mit dem sich laut Beschreibung eigene Funktionen und Anbieter ergänzen und weitergeben lassen. Ob ein Plugin ohne Neubau der Anwendung geladen wird, sagt das Material nicht. Ebenso bleibt offen, welche Anbieterparameter (Temperatur, maximale Ausgabelänge, Streaming) durchgereicht werden. Wer einen Anbieter mit ungewöhnlicher API anbinden will, sollte das vor der Entscheidung prüfen.
Installation über die Website, als Release oder im Container
Die README nennt drei Wege. Empfohlen wird die Website risuai.net, daneben die GitHub-Releases. Für Webhosting ist Docker vorgesehen, mit einem Einzeiler: curl -L https://raw.githubusercontent.com/kwaroran/Risuai/refs/heads/main/docker-compose.yml | docker compose -f - up -d. Danach ist die Anwendung unter http://localhost:6001 erreichbar. Wer aus dem Quellcode baut, braucht laut README Node.js 20.19 oder neuer beziehungsweise 22.12 oder neuer sowie pnpm. Der Stack besteht aus Svelte 5, TypeScript 5.9, Tauri 2.5, Vite 8 und Tailwind CSS 4. Tauri erklärt, warum es Desktop-Pakete gibt und warum die Anwendung nicht nur im Browser läuft. Wichtig für den Containerbetrieb: Die README zeigt den compose-Befehl, benennt aber kein Volume für persistente Daten. Ob Chats, Charaktere und eingebettete Assets einen Neustart des Containers überstehen, lässt sich aus dem Material nicht beantworten und sollte vor einem produktiven Einsatz in der docker-compose.yml nachgesehen werden.
Assets, Stimme und Gruppenchats als Randfunktionen mit Kosten
Die README listet weitere Bausteine: Emotionsbilder, die zur aktuellen Stimmung der Figur passend angezeigt werden, Gruppenchats mit mehreren Charakteren in einer Unterhaltung, eingebettete Bilder, Audios und Videos als Chat- oder Hintergrund-Assets, TTS zur Vertonung der Ausgabe sowie Übersetzer, die Ein- und Ausgabe automatisch übertragen. Diese Funktionen sind der Grund, warum die Anwendung mehr Ressourcen braucht als ein Textchat. Eingebettete Medien liegen im Datenbestand und müssen gesichert werden. TTS und Übersetzung erzeugen zusätzliche Aufrufe, die je nach Anbieter Geld kosten oder lokal Rechenzeit binden. Gruppenchats vervielfachen den Kontext, weil mehrere Figurenprofile gleichzeitig im Prompt stehen. Wer diese Funktionen nicht nutzt, trägt trotzdem die Komplexität der Oberfläche mit.
Grenzen: dünne Dokumentation und ein Rollenspiel-Zuschnitt
Die README verweist für Details auf die Wiki und markiert sie ausdrücklich als unfertig. Das ist die größte Einschränkung: Wer verstehen will, wie HypaMemoryV2 komprimiert, welche Variablen in Prompt-Bedingungen verfügbar sind oder wie ein Plugin aufgebaut ist, findet im Repository-Überblick keine Antwort. Man ist auf den Quellcode und die Community angewiesen. Ein zweiter Punkt ist der Zuschnitt. Risuai ist auf Figuren, Szenen und lange Kontexte ausgelegt. Für Aufgaben mit Werkzeugaufrufen, strukturierter Ausgabe oder reproduzierbaren Auswertungen bringt der Rollenspiel-Apparat keinen Vorteil; die Regex-Nachbearbeitung ist ausdrücklich als Mittel für eigene Oberflächen beschrieben, nicht als Schema-Validierung. Ein dritter Punkt betrifft die Qualität der Ergebnisse: Sie hängt vom gewählten Modell und vom Prompt ab, nicht von der Anwendung. Risuai verschiebt die Arbeit vom Modell zum Nutzer.
Alternative: SillyTavern und der Unterschied im Ansatz
Die naheliegende Alternative ist SillyTavern, ein ebenfalls quelloffenes Frontend für Rollenspiel mit Character-Cards, Lorebooks und mehreren Backends. Der Unterschied liegt weniger in der Funktionsliste als im technischen Unterbau. SillyTavern läuft als Node.js-Server mit Browser-Oberfläche; Risuai setzt auf Svelte im Frontend und Tauri für Desktop-Pakete, kann aber ebenso über Docker als Webanwendung betrieben werden. Wer eine reine Browserlösung ohne Desktop-Paket sucht, findet bei SillyTavern einen einfacheren Betrieb. Wer eine Desktop-Anwendung mit derselben Codebasis bevorzugt, findet sie bei Risuai. Bei den Speichermechanismen geht Risuai mit HypaMemory und SupaMemory eigene Wege; ob diese gegenüber den Ansätzen anderer Clients Vorteile bringen, lässt sich aus dem vorliegenden Material nicht belegen. Die Entscheidung sollte daher über Betriebsform und Datenhaltung fallen, nicht über Funktionslisten.
Pflege, Updates und Lizenz
Das Repository ist nicht archiviert, der letzte Push liegt laut Metadaten bei September 2026, die letzten Releases bei August 2026 mit den Tags v2026.8.250 und v2026.8.240 sowie einem älteren v2026.6.215 im Juli. Die Versionsnummern folgen einem Datumsschema, was auf häufige Veröffentlichungen hindeutet. Für Betreiber heißt das: Updates kommen regelmäßig, und ein Container sollte bewusst auf eine Version festgelegt werden, statt dem neuesten Tag zu folgen. Die Lizenz ist GPL-3.0. Für private Nutzung und Selbsthosting entstehen daraus keine Pflichten. Wer die Anwendung verändert und weiterverbreitet, muss den Quellcode unter derselben Lizenz zugänglich machen; das gilt auch, wenn die veränderte Fassung als Netzwerkdienst betrieben wird, sofern die Weitergabe als Verbreitung gewertet wird. Das ist eine Einschätzung, keine Rechtsberatung. Wer Risuai in ein eigenes Produkt einbetten will, sollte das vorher klären.
Redaktionelles Fazit
Risuai passt zu Anwendern, die Prompt-Aufbau, Ausgabe-Nachbearbeitung und Speicherverwaltung selbst steuern wollen und dafür ein größeres Interface in Kauf nehmen. Wer lediglich gelegentlich mit einem Modell plaudern möchte, sollte bei einem Web-Client bleiben, der keine Character-Cards, Lorebooks und Regex-Skripte kennt. Vor dem Umstieg auf eigene Daten lohnt ein Blick in die docker-compose.yml und das dort gesetzte Volume für das Datenverzeichnis, denn davon hängt ab, ob Chats und Assets einen Container-Neustart überleben. Die Lizenz ist GPL-3.0, was für die private Nutzung irrelevant ist, bei Weitergabe veränderter Fassungen aber Bedingungen an den Quellcode stellt.
Community-Notizen