AIaWs Abschied: Was NitroRCr/AIaW leistet und warum es zu Nya AI migriert

Ein Client, der Workspaces statt Chats organisiert

Die meisten Chat-Oberflächen für LLMs sammeln Unterhaltungen in einer einzigen Liste. AIaWs Modell ist anders: Workspaces trennen Gespräche nach Themen, lassen sich in Ordner gruppieren und verschachteln, und innerhalb eines Workspace oder global existieren mehrere Assistenten. Dazu kommen Prompt-Variablen, mit denen sich wiederkehrende Textbausteine aus Prompts herausziehen und als Workspace-Variablen wiederverwenden lassen. Das ist ein Bedienkonzept für Menschen, die mehrere LLMs parallel für unterschiedliche Aufgaben nutzen, nicht für Gelegenheitsfragen. Die Zielgruppe ergibt sich aus den unterstützten Plattformen: Windows, Linux, macOS, Android und Web als PWA, dazu mehrere Anbieter wie OpenAI, Anthropic, Google, DeepSeek, xAI und Azure. Wer Anbieter wechselt, ohne die Oberfläche zu wechseln, ist der Adressat.

Local first, dann Cloud: der Datenfluss

Laut README liegen die Daten zuerst lokal, offline lesbar und ohne Ladeverzögerung. Erst nach einem Login kommt die Cloud-Synchronisation für geräteübergreifende Nutzung hinzu. Zusätzlich beschreibt das Projekt Multi-Window-Kollaboration: mehrere Tabs im selben Browser synchronisieren ihre Daten reaktiv. Das ist ein konkretes Versprechen über den Speicherort, aber das README sagt nichts über Konfliktauflösung, wenn zwei Geräte offline dieselbe Unterhaltung ändern. Wer diesen Punkt als Auswahlkriterium hat, muss die Dokumentation unter docs.aiaw.app konsultieren, nicht das README. Die Architektur ist als Vue-Anwendung mit Quasar aufgebaut, was sich an den Build-Befehlen ablesen lässt. TypeScript ist die primäre Sprache des Repositories.

MCP, Plugins und der Unterschied zu reinem Tool-Calling

AIaWs Plugin-System geht über Tool-Aufrufe hinaus, so formuliert es das README. Eingebaute Plugins decken Rechner, Dokument- und Videoparsing sowie Bildgenerierung ab; weitere kommen aus einem Marktplatz. Gradio-Anwendungen lassen sich als Plugin konfigurieren, und eine Teilmenge der LobeChat-Plugins soll kompatibel sein. Für MCP unterstützt der Client Tools, Prompts und Resources über STDIO- und HTTP-Verbindungen, MCP-Server können aus dem Marktplatz oder manuell hinzugefügt werden. Das ist mehr Protokollabdeckung, als viele Clients bieten, die nur Tools implementieren. Für die Websuche setzt AIaW auf SearXNG und beschreibt die Suche als sofort nutzbar, mit gleichzeitigem Suchen und Crawlen von URLs. Wer eine eigene SearXNG-Instanz betreibt, kann das Verhalten damit kontrollieren; wer keine hat, hängt an der Voreinstellung.

Selbst hosten mit pnpm und quasar

Die Einrichtung folgt dem üblichen Quasar-Ablauf. Abhängigkeiten installieren mit pnpm i. Entwicklung mit Hot-Code-Reloading über quasar dev. Linting über pnpm lint. Für die Produktion entweder quasar build für eine SPA oder quasar build -m pwa für die Progressive Web App. Ein Hinweis für alle, die die PWA-Variante wählen: Der Build-Schalter -m pwa ist nicht optional, die SPA-Variante liefert kein Service-Worker-Verhalten. Eine ausführliche Self-Hosting-Anleitung verlinkt das README unter docs.aiaw.app/self-host/. Dort, nicht im Repository-README, sind Umgebungsvariablen und Serverkonfiguration zu erwarten. Wer AIaWs Docker-Topic im Repository sieht und daraus einen fertigen Container ableiten will, findet im vorliegenden Material keinen docker run-Befehl und keine Compose-Datei. Das ist eine Lücke zwischen Topic-Liste und dokumentiertem Einstieg.

Der Nachfolger ist keine Option, sondern die Vorgabe

Das Repository trägt einen Warnhinweis, der nicht zu übersehen ist: Das Projekt ist abgekündigt und wurde durch Nya AI ersetzt, eine vollständige Neuentwicklung mit neuem Technologie-Stack. Der Text spricht von den meisten Funktionen und einer konsistenten Erfahrung, dazu neuen Funktionen und Optimierungen. Diese Formulierung ist bewusst unscharf. Wer MCP-Server, Gradio-Plugins oder Prompt-Variablen produktiv nutzt, kann aus dem README nicht ableiten, ob jeder dieser Bausteine in Nya AI existiert. Die letzte Veröffentlichung, v1.8.12 vom Mai 2026, trägt den Titel der Version ohne Zusatz; die vorherige, v1.8.10, ist mit 'Migrating to Nya AI' überschrieben. Diese Abfolge zeigt, wohin die Arbeit fließt. Ein Fork wäre möglich, aber die Lizenz ändert nichts daran, dass die Upstream-Entwicklung endet.

Wo AIaWs Ansatz an Grenzen stößt

Die lokale Datenhaltung ist der Kern des Versprechens und zugleich seine Einschränkung. Ohne Login bleibt der Bestand an ein Gerät und einen Browser gebunden. Wer Teamfreigaben oder zentrale Verwaltung von Assistenten über eine Organisation hinweg braucht, ist hier falsch: Nichts im README deutet auf Rollen, Rechte oder geteilte Workspaces hin. Ebenso wenig gibt es Belege für eine Server-seitige Protokollierung von Modellaufrufen, wie sie in regulierten Umgebungen verlangt wird. Ein weiterer Punkt betrifft die Plugin-Kompatibilität: Die Formulierung, dass einige LobeChat-Plugins kompatibel seien, sagt nichts über die anderen. Wer seine Toolchain auf ein bestimmtes Plugin stützt, sollte vor der Migration prüfen, ob es in Nya AI unterstützt wird. Und schließlich: Das Projekt ist abgekündigt. Neue Fehlerberichte werden, so legt es der Warnhinweis nahe, in die Neuentwicklung fließen, nicht in dieses Repository.

Was andere Clients anders machen

Vergleicht man AIaWs Modell mit einem reinen Web-Frontend für einen OpenAI-kompatiblen Endpunkt, etwa dem im README verlinkten New API, wird der Unterschied sofort sichtbar. New API sitzt auf der Serverseite und verteilt Modellzugriffe im OpenAI-Format; es speichert keine Konversationen lokal im Browser und kennt keine Workspaces. AIaWs Stärke liegt genau auf der anderen Seite: die lokale, offlinefähige Oberfläche mit Plugin- und MCP-Schicht. Wer nur einen einheitlichen Endpunkt für mehrere Modelle braucht, ist mit New API allein bedient und braucht AIaWs gar nicht. Wer dagegen eine Desktop- und Mobiloberfläche mit Anbieterwechsel, Anhängen, Artifacts und Websuche sucht, findet in AIaWs ein Paket, das diese Teile verbindet. Die Entscheidung hängt also nicht an der Funktionsliste, sondern an der Frage, ob die Daten lokal bleiben sollen.

Lizenz, Wartung und der Weg nach vorn

AIaW steht unter BSD-3-Clause, einer permissiven Lizenz. Sie erlaubt Weitergabe und Änderung, verlangt aber die Beibehaltung des Urheberrechtshinweises und schließt Gewährleistung aus. Für Forks bedeutet das: Der Code darf weiterleben, die Marke und die Projektpflege nicht automatisch. Das Repository ist nicht archiviert, letzter Push und letzte Veröffentlichung fallen auf denselben Tag im Mai 2026. Ob das ein letzter Wartungsstand oder der Beginn einer Übergangsphase ist, lässt sich aus dem Material nicht beantworten. Faktisch ist die Weiterentwicklung an Nya AI gebunden. Wer heute plant, sollte die Migrationsseite unter docs.aiaw.app/migration/ öffnen, die dort genannten Schritte mit der eigenen Installation abgleichen und erst dann entscheiden, ob ein Verbleib auf v1.8.12 vertretbar ist. Ein Fork ist nur dann sinnvoll, wenn eine konkrete Funktion fehlt, die Nya AI nicht anbietet, und wenn jemand die Wartung übernimmt.

Redaktionelles Fazit

Für bestehende Installationen ist AIaWs Ende besiegelt: Das README nennt das Projekt deprecated und verweist auf die Migrationsanleitung unter docs.aiaw.app/migration/. Wer heute neu einsteigt, sollte direkt Nya AI prüfen. Vor jeder Übernahme ist zu klären, ob die eigene Konfiguration (MCP-Server, Plugins, Workspace-Variablen) in Nya AI überhaupt existiert, denn das README verspricht nur 'most of the features', nicht alle.

Offizielle Quellen

1. License: BSD-3-Clause
2. NitroRCr/AIaW on GitHub
3. Project website
4. README
5. Releases