my-neuro: ein Live2D-Desktop-Begleiter mit lokalem LLM, GPT-SoVITS und MemOS

Ein Workbench-Projekt, kein fertiges Produkt

Die README beschreibt my-neuro als Arbeitsfläche, nicht als Anwendung. Der Satz, das Projekt sei eher ein Werkzeugkasten, mit dem man Schritt für Schritt eine Figur zusammenbaut, steht dort wörtlich. Daraus folgt der Adressatenkreis: Menschen, die einen Live2D-Avatar mit eigener Stimme, eigener Persönlichkeit und eigenem Gedächtnis betreiben wollen und dafür mehrere Teilsysteme selbst zusammensetzen. Wer eine fertige Desktop-App mit Assistenten-Installation sucht, ist hier falsch. Das Repository liefert JavaScript als primäre Sprache, dazu Python-Anteile, die aus dem TTS- und LLM-Stack stammen. Der Funktionsumfang ist in der README als Checkliste organisiert, und diese Liste ist ehrlich genug, die offenen Punkte mit unmarkierten Kästchen zu führen: echte Emotionen, ein menschenähnlicheres Interaktionsdesign, der Anschluss ausländischer Streaming-Plattformen. Der Autor schreibt selbst, dass rund 30 Prozent der geplanten Funktionen umgesetzt seien. Das ist eine Selbsteinschätzung aus der README, keine unabhängige Messung, aber sie ist die belastbarste Aussage über den Reifegrad, die das Material hergibt.

Wie die Teile zusammengesteckt sind

Aus der README und der Liste referenzierter Fremdprojekte lässt sich der Datenfluss grob rekonstruieren, und mehr als eine grobe Rekonstruktion ist mit diesem Material nicht möglich. Ein Sprach- oder Texteingang erreicht das LLM, das entweder lokal läuft oder über eine API eines geschlossenen Anbieters angebunden ist. Die Antwort wird an ein TTS-System übergeben, standardmäßig GPT-SoVITS, das die Stimme erzeugt. Parallel dazu läuft die Untertitelausgabe, und die README nennt ausdrücklich den Fall, dass Untertitel auf Chinesisch erscheinen, während die Audiodatei in einer Fremdsprache gesprochen wird. Ein Live2D-Modell übernimmt Mimik und Bewegung, gesteuert aus dem Dialoginhalt. Das Gedächtnis kommt aus MemOS, einem separaten Projekt von MemTensor. Für Werkzeugaufrufe ist MCP vorgesehen, und für Webaktionen wird microsoft/playwright-mcp referenziert. Die Minecraft-Anbindung stammt aus mindcraft-bots/mindcraft. Das ist eine Komposition aus mindestens fünf externen Projekten mit unterschiedlichen Sprachen und Abhängigkeiten. Wer das betreibt, betreibt faktisch einen kleinen Verbund, nicht ein Programm. Genau hier liegt das zentrale Risiko, und die README geht darauf nicht ein.

Installation führt über eine externe Website

Das Repository enthält keine Installationsanleitung im engeren Sinn. Es verweist für den Deployment-Ablauf auf mynewbot.com/tutorials und bietet zusätzlich ein Integrationspaket über einen Baidu-Pan-Link an, das für Einsteiger gedacht ist und nach dem Entpacken sofort laufen soll. Ein Hinweis in der README ist dabei konkret und praktisch relevant: Der Dateipfad darf keine chinesischen Zeichen, Leerzeichen oder Klammern enthalten. Wer das Paket in ein Verzeichnis wie Programme (x86) entpackt, provoziert Fehler, die schwer zu diagnostizieren sind, weil sie an ganz anderer Stelle auftauchen. Für vollständig lokale Inferenz verweist die README auf den Ordner LLM-studio, der Anleitungen zum lokalen Betrieb und zum Finetuning enthält. Konkrete Kommandos, Umgebungsvariablen oder Konfigurationsschlüssel nennt die README nicht. Es gibt keine Beispieldatei, keinen Aufruf, keinen Port, keine Modellpfadvariable. Das ist die größte Schwäche des Materials: Ein Leser erfährt, dass es geht, aber nicht wie. Die Release-Bezeichnungen exe3.0 und v6.7.2 deuten auf ein Windows-Installationspaket hin, doch die README bestätigt das nicht explizit.

Ein Sekunde Latenz als Behauptung, nicht als Messung

Die README führt als erreichtes Ziel eine Dialoglatenz unter einer Sekunde bei vollständig lokaler Inferenz. Das ist eine Projektangabe ohne Messmethodik. Es fehlt jede Information darüber, auf welcher Hardware, mit welchem Modell in welcher Größe und mit welcher Eingabelänge dieser Wert gilt. Wer einen Begleiter bauen will, bei dem Unterbrechungen per Stimme oder Tastatur funktionieren, für den ist die Latenz der kritische Pfad, denn eine Unterbrechung wirkt nur, wenn die Pipeline schnell genug abbricht. Die README nennt die Unterbrechungsfunktion als umgesetzt, liefert aber kein Abbruchkriterium. Für eine Bewertung bleibt daher nur, den Wert als Zielgröße zu behandeln und selbst zu messen. Dasselbe gilt für die visuelle Erkennung: Die README schreibt, das Modell entscheide über die Spracheingabe, wann die Bilderkennung aktiviert wird. Das ist ein interessanter Entwurf, weil er Rechenlast spart, aber es macht die Bildverarbeitung vom Sprachverständnis abhängig. Ein falsch verstandener Satz bedeutet dann, dass gar nicht hingesehen wird.

Die Checkliste als ehrliche Grenzziehung

Interessanter als die erledigten Punkte sind die offenen. Emotionale Zustände, die über eine Sitzung hinaus bestehen, sind nicht umgesetzt. Die README nennt als Ziel, dass die Figur eigene Stimmungen über Tage hinweg entwickelt, dass sie auf eine Bemerkung lange beleidigt bleibt oder sich über ein Wort lange freut. Genau dieser Punkt steht auf der Liste als geplant, und der Autor nennt ihn selbst als nächsten Entwicklungsschwerpunkt. Der aktuelle Stand ist demnach eine Figur mit Langzeitgedächtnis für Fakten und Vorlieben, aber ohne eigenen Zustand. Wer Erinnerungsvermögen mit Emotionalität verwechselt, wird enttäuscht. Ein zweiter offener Punkt ist der Anschluss ausländischer Live-Streaming-Plattformen. Bilibili ist umgesetzt, alles andere nicht. Für Streamer außerhalb des chinesischen Marktes ist das ein Ausschlusskriterium, sofern sie nicht selbst eine Anbindung schreiben. Die Liste der Modellwünsche, etwa Bildschirmfarbwechsel nach Stimmung oder freies Bewegen über den Desktop, ist ausdrücklich als unentschieden markiert und sollte nicht als Roadmap gelesen werden.

Wo my-neuro das falsche Werkzeug ist

Der Fall, in dem dieses Projekt schadet, ist der Produktiveinsatz ohne Bereitschaft zur Fehlersuche. Die Abhängigkeit von mindestens fünf Fremdprojekten bedeutet, dass ein Update in einem davon die eigene Installation brechen kann, ohne dass my-neuro selbst sich ändert. Ein zweiter Fall: Wer rechtliche Sicherheit über die Herkunft der trainierten Stimme braucht. Die README nennt Voice-Cloning und TTS-Training als Funktionen und verweist auf GPT-SoVITS. Ob eine geklonte Stimme verwendet werden darf, hängt von den Rechten an der Ausgangsaufnahme ab, und dazu sagt das Repository nichts. Ein dritter Fall: Wer eine dokumentierte API für eigene Integrationen sucht. MCP ist vorhanden, aber die README beschreibt keinen Vertrag, keine Tool-Signaturen, keine Fehlerbehandlung. Wer my-neuro als Backend für eine eigene Anwendung einplanen will, plant gegen eine undokumentierte Schnittstelle. Und wer eine Figur ohne laufenden Desktop braucht, etwa als Serverdienst, findet hier keine Angabe, ob das überhaupt vorgesehen ist.

Was andere anders machen

Der naheliegende Vergleich ist ein reiner VTuber-Stack aus Live2D-Modell, einem Streaming-Werkzeug und einem separat betriebenen TTS. Dort ist der Avatar eine Darstellungsschicht, und das Sprachmodell läuft daneben, ohne Zugriff auf das Modell. Bei my-neuro ist die Kopplung umgekehrt gedacht: Das LLM steuert Mimik, Bewegung, Soundeffekte und Werkzeugaufrufe, der Avatar ist Ausgabe des Modells. Der zweite Unterschied betrifft das Gedächtnis. Ein typischer Chatbot-Aufbau hält Kontext nur im laufenden Fenster. my-neuro bindet mit MemOS ein eigenes Gedächtnissystem ein, das Informationen über Sitzungen hinweg vorhält. Der dritte Unterschied ist die Werkzeugschicht über MCP, die dem Modell erlaubt, Aktionen auszuführen statt nur zu antworten, etwa Software zu starten oder über playwright-mcp im Web zu handeln. Das ist ein anderer Anspruch als ein Chatfenster mit schöner Grafik. Es ist aber auch der Grund, warum die Fehlerfläche größer ist: Ein Modell, das Aktionen ausführen darf, kann falsche Aktionen ausführen, und die README behandelt diese Frage nicht.

Wartung, Lizenz und der Blick vor dem Start

Das Repository steht unter MIT. Diese Lizenz deckt den Code im Repository ab. Sie deckt nicht die Gewichte von GPT-SoVITS, nicht MemOS, nicht mindcraft, nicht playwright-mcp und nicht die Live2D-Modelle ab, die Nutzer einbinden. Jede dieser Komponenten bringt eigene Bedingungen mit, und wer my-neuro weitergibt oder kommerziell betreibt, muss diese Bedingungen getrennt prüfen. Das ist keine Rechtsberatung, sondern der Hinweis, dass die Lizenzangabe oben im Repository nicht der einzige relevante Text ist. Zum Wartungsaufwand: Die Release-Historie zeigt v6.7.1 am 7. September 2026 und v6.7.2 zwei Tage später, dazu ein Installationspaket exe3.0. Diese Taktung bedeutet, dass Fehlerkorrekturen schnell kommen, aber auch, dass eine gepinnte Version sinnvoll ist, wenn die Installation einmal läuft. Ein Upgrade-Pfad ist in der README nicht beschrieben, ebenso wenig eine Migrationsanleitung für das Gedächtnis. Wer MemOS-Daten über ein Upgrade hinweg behalten will, muss das vorher klären, nicht danach.

Redaktionelles Fazit

Wer einen Live2D-Avatar mit eigener Stimme, lokalem LLM und Bilibili-Streaming-Anbindung sucht und bereit ist, die verstreute Dokumentation auf mynewbot.com/tutorials sowie die Foren- und QQ-Kanäle selbst zu durchsuchen, findet hier eine MIT-lizenzierte Basis, die genau diese Kombination abdeckt. Wer eine reproduzierbare Installation mit versionierten Konfigurationsdateien, dokumentierten API-Verträgen und ohne chinesischsprachige Oberfläche braucht, sollte zuerst prüfen, ob der Release exe3.0 auf dem Zielsystem überhaupt startet und ob die Modellpfade ohne Leerzeichen und Sonderzeichen auskommen. Vor jedem produktiven Einsatz ist zu klären, unter welcher Lizenz die GPT-SoVITS-Gewichte, die Live2D-Modelle und die MemOS-Komponenten jeweils stehen, denn die MIT-Lizenz des Repositories deckt diese Fremdartefakte nicht ab.

Offizielle Quellen

1. Issues
2. License: MIT
3. morettt/my-neuro on GitHub
4. README
5. Releases