PyGPT: Desktop-Assistent mit elf Betriebsmodi und eigenem API-Schlüssel

Welches Problem PyGPT löst und für wen es gedacht ist

Die README beschreibt PyGPT als all-in-one Desktop-KI-Assistenten, der Modelle von OpenAI, Google Gemini, Anthropic Claude, xAI Grok, Perplexity, DeepSeek sowie Modelle über HuggingFace, LlamaIndex, OpenAI-kompatible APIs und lokale Ollama-Installationen zusammenführt. Das Problem ist damit nicht ein fehlendes Modell, sondern die Zersplitterung: Wer heute mehrere Anbieter nutzt, wechselt zwischen Browser-Tabs, Abos und Kontextverlust. PyGPT setzt dagegen auf eine lokale Anwendung, die den Verlauf, die Dateien und die Konfiguration auf dem Rechner hält und nur die Modellaufrufe nach außen gibt. Die Anwendung nutzt den eigenen API-Schlüssel des Nutzers, wie die README mehrfach betont. Für lokale Modelle über Ollama sind laut README keine externen Zugangsdaten nötig.

Die Zielgruppe ist entsprechend breit, aber nicht beliebig. Genannt werden ausdrücklich Funktionen für Menschen mit Behinderungen: anpassbare Tastenkürzel, Sprachsteuerung und die Übersetzung von Bildschirmaktionen in Audio über Sprachsynthese. Das ist ein konkretes Merkmal, kein Marketingzusatz. Daneben richtet sich das Projekt an Nutzer, die RAG über eigene Dateien wollen, ohne eine eigene Pipeline zu bauen, und an Entwickler, die Agenten, Plugins und MCP-Server ausprobieren möchten. Wer nur gelegentlich einen Chat braucht, findet in einem Browser-Client weniger Installationsaufwand.

Elf Modi, ein gemeinsamer Kontextspeicher

Die README listet elf Betriebsmodi: Chat, Chat with Files, Realtime mit Audio, Research über Perplexity, Completion, Bild- und Videogenerierung, Experts, Computer use, Agents v2 (beta), Agents und Autonomous Mode. Das ist die eigentliche Struktur des Programms. Jeder Modus ist eine andere Art, den Kontext an ein Modell zu übergeben: Im Completion-Modus wird ein Prompt einmalig beantwortet, im Chat-Modus läuft eine Sitzung mit Verlauf, im Research-Modus übernimmt Perplexity die Websuche, und im Modus Chat with Files wandern die Dokumente durch LlamaIndex.

Bemerkenswert ist, dass alle Modi auf denselben Speicher für Konversationen zugreifen. Die README nennt kurzfristigen und langfristigen Speicher sowie die Möglichkeit, zu früheren Kontexten zurückzuspringen. Dazu kommen Kalender, Tagesnotizen und eine Suche in Kontexten nach Datum. Das ist mehr als eine Chat-Historie: Der Verlauf wird als zusätzlicher Kontext an das Modell gegeben, sofern der Nutzer das im Modus vorsieht. Die Kehrseite liegt auf der Hand. Je nach Modell und aktivierter Kontextlänge wächst der Tokenverbrauch, und die README erwähnt eine eingebaute Tokenverbrauchsberechnung, aber keine automatische Kürzung nach Budget. Wer lange Sitzungen führt, sollte die Kontextgrenzen im Blick behalten.

RAG über LlamaIndex: Dateien, Vektordatenbanken, Einbettungen

Für Chat with Files nutzt PyGPT LlamaIndex. Die README nennt als unterstützte Datentypen txt, pdf, csv, html, md, docx, json, epub, xlsx, xml, Webseiten, Google, GitHub, Video, Audio und Bilder. Dazu kommen integrierte Vektordatenbanken und eine automatisierte Einbettung von Dateien und Daten. Der Ablauf ist damit klassisches RAG: Dokumente werden geladen, in Abschnitte zerlegt, eingebettet und in einer Vektordatenbank abgelegt. Bei einer Frage sucht die Anwendung ähnliche Abschnitte und übergibt sie zusammen mit dem Prompt an das Modell.

Die praktische Konsequenz: Die Qualität der Antworten hängt an der Einbettung und der Zerlegung, nicht am Chat-Modell allein. Die README beschreibt keine Konfiguration für Chunk-Größe oder Überlappung. Wer große PDF-Sammlungen verarbeitet, muss daher selbst beobachten, ob die abgerufenen Abschnitte zur Frage passen. Ein zweiter Punkt ist der Speicherort: Die Vektordatenbank liegt lokal, was für vertrauliche Dokumente spricht, aber auch bedeutet, dass die Einbettung je nach gewähltem Anbieter weiterhin einen externen Aufruf darstellt. Die README sagt dazu nichts Ausdrückliches, und genau diese Frage sollte man vor dem Einsatz mit sensiblen Daten klären.

Installation: Binärpaket, PyPi oder Quellcode

Die README nennt mehrere Wege. Für Linux und Windows 10/11 gibt es kompilierte 64-Bit-Versionen, die über die Download-Seite pygpt.net bezogen werden. Zusätzlich existieren Pakete im Snap Store, im Microsoft Store, als AppImage über die GitHub-Releases und auf PyPi unter dem Namen pygpt-net. Für Mac gibt es laut README kein Binärpaket, dort muss PyGPT aus PyPi oder aus dem Quellcode laufen.

Aus dem Quellcode ist der Ablauf der übliche: Repository klonen, dann die Abhängigkeiten aus der Datei requirements.txt installieren, anschließend die Anwendung starten. Die README gibt in dem vorliegenden Ausschnitt keine vollständigen Shell-Befehle an, sondern verweist auf die Dokumentation unter pygpt.readthedocs.io. Anforderungen, die sich belegen lassen: Python in der Spanne >=3.10 und <3.14, und ein Rechner mit Linux, Windows 10, Windows 11 oder Mac. Nach dem Start müssen API-Schlüssel in der Anwendung hinterlegt werden. Die README nennt OpenAI, Google, Anthropic, xAI, Perplexity, Mistral und OpenRouter als Anbieter, für die je nach Modell ein Konto und ein gültiger Schlüssel nötig sind. Lokale Modelle über Ollama brauchen keine externen Zugangsdaten. Wer den Quellcode-Weg wählt, sollte die Python-Version exakt in der genannten Spanne halten, da das Projekt keine andere angibt.

Werkzeuge, Plugins und MCP: die Angriffsfläche des Assistenten

PyGPT beschränkt sich nicht auf Textausgabe. Die README beschreibt Plugins wie Files I/O, Code Interpreter, Web Search, Google, Facebook, X/Twitter, Slack, Telegram, GitHub und MCP. Hinzu kommt ein eingebautes Python/OS-Werkzeug mit Echtzeit-Ausführung von Python und IPython, die Ausführung von System- und eigenen Befehlen sowie ein Crontab und Task-Scheduler. Der Assistent kann damit Dateien lesen und schreiben, Prozesse starten und externe APIs aufrufen.

Das ist die mächtigste und zugleich riskanteste Eigenschaft. Ein Modell, das Systembefehle ausführen darf, ist nur so sicher wie die Anweisungen, die es erhält. Die README beschreibt keine Sandbox, keine Rechtebeschränkung und keine Bestätigungsschicht für Befehle. Wer Plugins wie Files I/O oder Code Interpreter aktiviert, gibt dem Modell Zugriff auf den eigenen Rechner, und Prompt-Injection aus einer geladenen Webseite oder einem Dokument ist ein realistischer Pfad dorthin. Der MCP-Support erweitert diese Fläche um externe Server, deren Verhalten nicht im Repository liegt. Für den produktiven Einsatz heißt das: Plugins einzeln aktivieren, nicht pauschal, und den Crontab nur mit Aufgaben bestücken, deren Wirkung man kennt.

Agenten v2 im Beta-Status und der Knoten-Editor

Die README führt Agents v2 als Beta und beschreibt es als orchestrierten Multi-Agenten-Modus mit einem sichtbaren Orchestrator und dynamisch verwalteten Worker-Agenten. Daneben stehen die älteren Modi Agents und Autonomous Mode sowie ein knotenbasierter Agents Builder. Das ist ein anderer Ansatz als bei einem einfachen Chat: Der Orchestrator zerlegt eine Aufgabe, verteilt sie an Unteragenten und führt Ergebnisse zusammen. Der Nutzer sieht laut README den Orchestrator und die verwalteten Worker.

Der Beta-Hinweis ist ernst zu nehmen. Beta bedeutet in der Praxis, dass sich Schnittstellen, Konfiguration und Verhalten zwischen Releases ändern können, und die Release-Kadenz im Repository ist hoch: v2.8.10, v2.8.12 und v2.8.13 liegen innerhalb weniger Tage. Wer Agenten in einen wiederkehrenden Ablauf einbaut, sollte die Konfiguration versionieren und nach jedem Update erneut prüfen. Für Aufgaben mit klarem, kurzem Ablauf ist der einfache Chat-Modus die robustere Wahl. Der Agents Builder hilft, Abläufe visuell zu skizzieren, ersetzt aber keine Fehlerbehandlung: Die README nennt keine Wiederholungsversuche oder Abbruchbedingungen für fehlgeschlagene Werkzeugaufrufe.

Lizenz, Wartung und die Frage nach dem Betrieb

Die Lizenzangabe im Repository lautet NOASSERTION. Das bedeutet, dass die automatische Erkennung keine eindeutige Standardlizenz zuordnen konnte. Die README bezeichnet das Projekt als free und open source und verweist auf den Quellcode auf GitHub, nennt aber im vorliegenden Ausschnitt keinen Lizenznamen. Wer PyGPT kommerziell einsetzen, weitergeben oder in ein eigenes Produkt einbetten will, muss die Lizenzdatei im Repository selbst lesen. Eine Aussage über erlaubte oder verbotene Nutzung lässt sich daraus hier nicht ableiten, und rechtliche Beratung ersetzt das ohnehin nicht.

Der Wartungsaufwand ist ein zweiter Kostenpunkt. Die Releases folgen dicht aufeinander, und die Anwendung hängt an einer großen Zahl von Abhängigkeiten: LlamaIndex, Vektordatenbanken, mehrere SDKs für Sprache, Bild und Video sowie MCP. Jedes Update eines Anbieters kann eine Anpassung nötig machen. Dazu kommen die laufenden API-Kosten, die vollständig beim Nutzer liegen, weil PyGPT eigene Schlüssel verwendet. Für lokale Modelle über Ollama entfallen diese Kosten, dafür steigen die Anforderungen an die eigene Hardware. Wer den Quellcode-Weg geht, sollte die Abhängigkeiten pinnen und die Python-Version innerhalb der dokumentierten Spanne halten.

Wann PyGPT das falsche Werkzeug ist

PyGPT ist eine Desktop-Anwendung mit grafischer Oberfläche. Wer einen Dienst für mehrere Nutzer, eine zentrale Verwaltung von Schlüsseln oder eine API für eigene Anwendungen braucht, wird hier nicht fündig. Die README beschreibt keine Serverbereitstellung, keine Mandantentrennung und keine Rollenverwaltung. Auch für reproduzierbare Auswertungen ist der Aufbau ungünstig: Die Konfiguration liegt in der Anwendung, und die README nennt keine Möglichkeit, einen Lauf mit festen Parametern zu exportieren.

Eine reale Alternative mit anderem Ansatz sind Bibliotheken wie LlamaIndex selbst oder LangChain. Dort baut man die Pipeline im Code: Dokumentenlader, Splitter, Vektorspeicher und Abfragekette sind explizite Objekte, versionierbar und testbar. PyGPT verpackt dieselbe Art von Pipeline in eine Oberfläche und nimmt dem Nutzer die Verdrahtung ab, gibt ihm dafür aber weniger Kontrolle über Chunking, Abrufstrategie und Fehlerbehandlung. Für einen einzelnen Anwender, der mit eigenen Dateien arbeiten will, ist der fertige Client der kürzere Weg. Für ein Team, das dieselbe Auswertung wiederholt und nachvollziehbar ausführen muss, ist der Code-Weg der bessere. Eine dritte Möglichkeit sind reine Chat-Clients ohne Werkzeugausführung. Sie sind harmloser, können aber weder Dateien einbetten noch Befehle ausführen, und genau diese Fähigkeiten sind der Grund, warum man PyGPT überhaupt in Betracht zieht.

Redaktionelles Fazit

PyGPT passt zu Anwendern, die einen lokalen Desktop-Client mit vielen Providern, RAG über eigene Dateien und optional lokalen Ollama-Modellen wollen und bereit sind, API-Schlüssel selbst zu verwalten. Wer eine gehostete Lösung ohne Betriebsaufwand, eine stabile Agenten-API für die Produktion oder eine klar benannte Lizenz für kommerzielle Weitergabe braucht, sollte zuerst die Lizenzangabe im Repository klären und die Agenten v2 im Beta-Status gegen die eigene Aufgabe testen. Vor dem produktiven Einsatz ist die Datei requirements.txt gegen die dokumentierte Python-Spanne >=3.10, <3.14 zu prüfen, da das Projekt ausdrücklich nur diesen Bereich nennt.

Offizielle Quellen

1. Issues
2. Project website
3. README
4. Releases
5. szczyglis-dev/py-gpt on GitHub