AingDesk: lokale Modelle, Wissensbasis und MCP-Client in einer Electron-Oberfläche

Welche Lücke AingDesk schließt

Wer ein lokales Sprachmodell über Ollama laufen lässt, hat schnell ein Terminal, aber selten eine Oberfläche, in der sich Chats, Dokumente und Werkzeuge gemeinsam verwalten lassen. AingDesk setzt genau dort an. Das Projekt beschreibt sich selbst als AI-Assistent mit Unterstützung für Wissensbasen, Modell-APIs, Freigabe, Websuche und Agenten. Die Zielgruppe lässt sich aus dem README ableiten: Anfänger, für die laut Produkthighlights der Einstieg in die KI einfach bleiben soll, und Nutzer, die lokale Modelle neben Cloud-Anbietern betreiben wollen. Wer ausschließlich eine Programmbibliothek für eigene Anwendungen sucht, ist hier falsch. AingDesk ist eine fertige Anwendung mit grafischer Oberfläche, keine Bibliothek zum Einbetten.

Aufbau: Electron-Client und Server-Variante

Das Repository ist in TypeScript geschrieben und trägt die Themen electron, nodejs, ollama, deepseek, llm und localai. Daraus ergibt sich ein zweigeteiltes Auslieferungsmodell. Für macOS und Windows gibt es herunterladbare Client-Versionen, die über die offizielle Website, über CNB oder über die GitHub-Releases bezogen werden. Daneben existiert eine Server-Variante, die sich per Docker betreiben lässt und laut README auch für server-seitige Bereitstellung gedacht ist. Der Serverbetrieb bindet Port 7071 und legt Daten über mehrere Volumes ab: /data, /uploads, /logs, /aingdesk/bin und /sys_data. Diese Trennung ist für den Betrieb wichtig, weil Modell-Binärdateien, hochgeladene Dokumente und Protokolle in unterschiedlichen Verzeichnissen landen und entsprechend unterschiedlich gesichert werden müssen. Ein einzelnes Backup des Projektordners reicht nicht aus, um eine Instanz vollständig wiederherzustellen.

Installation: Docker, Compose und der Build aus dem Quelltext

Der schnellste Weg führt über Docker. Das README gibt diesen Befehl an: docker run -d mit dem Namen node, den fünf genannten Volumes, der Portzuordnung -p 7071:7071, dem Arbeitsverzeichnis -w /aingdesk und dem Image aingdesk/aingdesk. Wer lieber Compose nutzt, legt ein Verzeichnis aingdesk an, wechselt hinein, lädt die Datei docker-compose.yml über den CNB-Raw-Link herunter und startet mit docker compose up -d oder docker-compose up -d. Für einen eigenen Build sind die Schritte im README ebenfalls dokumentiert: Repository klonen, in das Verzeichnis wechseln, dann cd frontend, yarn, zurück ins Wurzelverzeichnis, erneut yarn und schließlich yarn dev. Eine Besonderheit steht ausdrücklich im Text: macOS-Nutzer sollen die Abhängigkeit @rollup/rollup-win32-x64-msvc in der package.json entfernen. Das ist ein Hinweis darauf, dass die Abhängigkeitsliste plattformspezifische Rollup-Pakete enthält und der Build auf macOS sonst nicht sauber durchläuft.

Wissensbasis, Agenten und MCP-Client

Die Kernfunktionen listet das README in einer Reihenfolge, die auch die Arbeitsweise beschreibt. Zuerst die Einrichtung lokaler Modelle und gängiger Modell-APIs, dann die lokale Wissensbasis, danach die Erstellung intelligenter Agenten. Anschließend folgen die Online-Freigabe, damit andere die Instanz nutzen können, die Websuche und der MCP-Client. Die Wissensbasis ist ausdrücklich als lokal bezeichnet, was bedeutet, dass die Dokumente auf der eigenen Maschine oder dem eigenen Server verbleiben. Der MCP-Client ist der interessanteste Baustein, weil er AingDesk an externe Werkzeugserver anbindet und damit über reine Textgenerierung hinausgeht. Die Freigabe-Funktion ist dagegen der Punkt, an dem eine lokale Installation plötzlich erreichbar wird. Wer diese Funktion aktiviert, sollte wissen, welche Daten über die Wissensbasis hinaus sichtbar werden. Das README beschreibt die Freigabe nur als Funktion, nicht mit den zugehörigen Zugriffsregeln. Diese Details muss man in der Dokumentation unter docs.aingdesk.com nachschlagen.

Wo das README dünn bleibt

Die größte Schwäche liegt nicht im Funktionsumfang, sondern in der Dokumentation im Repository. Es gibt keine Beschreibung der Datenhaltung für die Wissensbasis, keine Angaben zu Embedding-Modellen, keine Größenangaben für den Arbeitsspeicher und keinen Hinweis darauf, wie sich mehrere Nutzer auf einer Server-Instanz voneinander abgrenzen. Auch die Freigabe-Funktion bleibt undefiniert: unklar ist, ob sie einen öffentlichen Link erzeugt, eine Anmeldung erfordert oder auf das lokale Netzwerk beschränkt ist. Die gleichzeitige Unterhaltung mit mehreren Modellen in einer Sitzung ist im README als kommend markiert, also nicht als verfügbar. Wer diese Funktion einplant, plant gegen eine Ankündigung, nicht gegen ein Merkmal. Die Versionshistorie zeigt drei Releases zwischen April und Mai 2025, wobei v1.2.2 und v1.2.3 nur zwei Tage auseinanderliegen. Das deutet auf eine schnelle Fehlerkorrektur nach einer Veröffentlichung hin, was bei jungen Projekten üblich ist, aber auch bedeutet, dass Zwischenversionen sorgfältig geprüft werden sollten.

Alternative: Open WebUI und der Unterschied im Ansatz

Die naheliegende Alternative ist Open WebUI, das ebenfalls eine grafische Oberfläche für lokale Modelle bereitstellt und sich primär als Webanwendung über einer OpenAI-kompatiblen Schnittstelle versteht. Der Unterschied liegt im Auslieferungsweg. Open WebUI wird typischerweise als Serverdienst betrieben und im Browser genutzt. AingDesk liefert zusätzlich einen Desktop-Client für macOS und Windows, der ohne eigenen Server auskommt, und integriert den MCP-Client direkt in die Anwendung. Wer ohnehin einen zentralen Dienst für ein Team betreibt, findet bei Open WebUI ein Modell, das stärker auf Mehrbenutzerbetrieb ausgerichtet ist. Wer dagegen auf einem einzelnen Rechner arbeiten und lokale Modelle mit einer Wissensbasis verbinden will, kommt mit AingDesk schneller zu einer lauffähigen Umgebung, weil die Einrichtung lokaler Modelle im README als Ein-Klick-Vorgang beschrieben wird. Ein Vergleich der Qualität der Wissensbasis ist anhand des Materials nicht möglich, weil AingDesk keine Angaben zu Chunking oder Retrieval macht.

Lizenz, Wartung und Upgrade-Aufwand

AingDesk steht unter der MIT-Lizenz. Das erlaubt kommerzielle Nutzung, Veränderung und Weitergabe, solange der Urheberrechtshinweis und der Lizenztext erhalten bleiben. Wer die Anwendung in ein Produkt einbettet, sollte dennoch prüfen, ob die eingebundenen Modelle und externen Dienste eigenen Bedingungen unterliegen, denn die MIT-Lizenz des Projekts deckt nicht die Modelle ab, die man darüber anspricht. Das ist keine Rechtsberatung, sondern ein Hinweis auf die Prüfpflicht. Beim Upgrade-Aufwand fällt die Kombination aus Desktop-Client und Server-Variante ins Gewicht. Ein Upgrade betrifft beide Auslieferungswege getrennt, und beim Serverbetrieb sind die Volumes /data, /uploads und /sys_data zu sichern, bevor ein neues Image gestartet wird. Ob es Migrationsschritte zwischen Datenbankversionen gibt, geht aus dem README nicht hervor. Die Versionssprünge v1.2.2 auf v1.2.3 innerhalb von zwei Tagen legen nahe, dass man Releases nicht ungeprüft einspielt. Wer AingDesk produktiv betreibt, sollte die Versionsnummer festhalten und vor dem Wechsel die Release Notes der Zielversion lesen.

Redaktionelles Fazit

Wer Ollama oder eine OpenAI-kompatible API bereits betreibt und dafür eine grafische Oberfläche mit Wissensbasis und MCP-Client sucht, findet in AingDesk eine MIT-lizenzierte Option für macOS, Windows oder einen eigenen Server. Wer Betriebsgarantien, dokumentierte Upgrade-Pfade oder eine breite Community für Fehlerfälle braucht, sollte vorher die Release Notes und die Dokumentation unter docs.aingdesk.com prüfen und mit den Volumes /data, /uploads und /sys_data ein eigenes Backup-Konzept aufsetzen. Vor jedem Produktiveinsatz ist zu klären, ob die im README als kommend angekündigte Funktion für parallele Modellgespräche in der eigenen Version bereits enthalten ist.

Offizielle Quellen

1. aingdesk/AingDesk on GitHub
2. License: MIT
3. Project website
4. README
5. Releases