Pluely v1: Ein Tauri-Overlay für Gespräche, dessen Quellcode nicht mehr offen ist
The Open Source Alternative to Cluely - A lightning-fast, privacy-first AI assistant that works seamlessly during meetings, interviews, and conversations without anyone knowing. Built with Tauri for native performance, just 10MB. Completely undetectable in video calls, screen shares, and recordings.
Auf einen Blick
- Was ist das?
- Pluely ist ein 9 bis 16 MB großes Desktop-Overlay mit den Modi Ask und Listen, das aus Bildschirmaufnahmen herausgefiltert wird. Der Haken: Seit v1 werden nur noch signierte Binärdateien ausgeliefert, obwohl das Repository unter GPL-3.0 steht.
- Für wen ist es gedacht?
- Wer ein Overlay für Live-Transkription und Screenshot-Fragen sucht und mit signierten Binärdateien ohne einsehbaren Quellcode leben kann, findet in Pluely v1 ein schlankes Werkzeug mit lokalem SQLite-Speicher und frei wählbarem Modell-Backend. Wer den Code prüfen, forken oder in einer regulierten Umgebung auditieren muss, sollte nicht adoptieren: Das Repository liefert keine Quellen für v1, und die GPL-3.0-Angabe des Repositories deckt diese Binärdateien nicht ab.
- 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 63 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 Overlay statt eines zweiten Browser-Tabs
Das Problem, das Pluely adressiert, ist eng umrissen: In einem Interview, einem Sales-Call oder einer Vorlesung kostet der Wechsel in einen Browser-Tab den Gesprächsfaden. Pluely legt stattdessen ein halbtransparentes Fenster über den Desktop, das per globalem Hotkey aus jeder Anwendung heraus aufgerufen wird und den Fokus der darunterliegenden Anwendung nicht stiehlt. Die Zielgruppe sind laut README Menschen in Live-Situationen: Interviews, Verkaufsgespräche, Standups, Vorlesungen, Live-Debugging. Der Zweck ist damit ausdrücklich nicht die nachträgliche Analyse, sondern die Antwort während des Gesprächs. Das erklärt die zwei Modi. Ask beantwortet eine einzelne Frage, wahlweise getippt, diktiert oder mit einem Screenshot als Kontext. Listen transkribiert Mikrofon und System-Audio laufend und schlägt Antworten vor, sobald jemand eine Frage stellt. Wer ein Archivwerkzeug für Meeting-Notizen sucht, ist hier falsch adressiert; das README beschreibt Sitzungen zwar als gespeicherte Meetings mit vollem Transkript, der Schwerpunkt liegt aber auf der Echtzeit-Nutzung.
Tauri, React und eine lokale SQLite-Datei
Der technische Aufbau lässt sich aus den Angaben des Repositories ableiten. Das Backend ist in Rust geschrieben und läuft über Tauri, das Frontend in React mit TypeScript, ergänzt um Tailwind CSS und shadcn-Komponenten. Dieser Stack erklärt die Größenangabe: Das README nennt Installer zwischen 9 und 16 MB und stellt das ausdrücklich den Electron-Alternativen gegenüber, die typischerweise eine mitgelieferte Chromium-Laufzeit mitschleppen. Tauri nutzt stattdessen die WebView des Betriebssystems. Der Datenfluss verläuft laut README so: Sprache geht über Mikrofon und System-Audio in die Transkription, Dokumente laufen durch eine eingebaute OCR und bleiben im Kontext für Rückfragen, Screenshots werden entweder als Region ausgewählt oder bei aktivierter Option Use image an jede Nachricht angehängt. Antworten kommen als Markdown-Stream zurück. Chats, Meetings, Transkripte und Dateien landen in einer lokalen SQLite-Datenbank; die eigenen Provider-Schlüssel bleiben laut README ebenfalls lokal. Für die Modellanbindung gibt es zwei Wege: 200+ gehostete Modelle über Pro-Pläne ohne eigene API-Keys, oder ein selbst konfiguriertes Backend über ein curl-Template beziehungsweise über vorhandene AI-CLIs wie Claude Code, Gemini CLI, Codex, Qwen Code oder Ollama.
Installation ohne Build-Schritt
Pluely wird nicht aus dem Quellcode gebaut, sondern als signierte Binärdatei verteilt. Das README verlinkt Download-Seiten für macOS, Linux und Windows und nennt die Formate: .dmg für macOS, .msi und .exe für Windows, .deb, .rpm und .AppImage für Linux. Ein Konto ist laut README für den Start nicht nötig, der Free-Plan gilt dauerhaft, Updates werden automatisch ausgeliefert. Wer ein eigenes Modell anbinden will, konfiguriert dies über ein curl-Template, also über eine Vorlage für den HTTP-Aufruf an den gewünschten Anbieter, statt über einen fest verdrahteten SDK-Client. Für die Stealth-Konfiguration verweist das README auf einen eigenen Dokumentationsabschnitt zu den Einstellungen, in dem sich das Anwendungssymbol aus Dock oder Taskleiste entfernen lässt. Eine vollständige Liste der Konfigurationsschlüssel liegt im bereitgestellten Material nicht vor; das README verweist dafür auf docs.pluely.com. Wer die Anwendung produktiv einrichten will, kommt um diese Dokumentationsseite nicht herum, weil das Repository selbst keine Konfigurationsreferenz enthält.
Der Ausschluss aus der Bildschirmaufnahme ist die eigentliche Designentscheidung
Das zentrale Versprechen ist nicht die KI, sondern die Unsichtbarkeit. Laut README wird das Overlay aus Screen-Capture ausgeschlossen, erscheint weder in Aufzeichnungen noch in Screenshots und kann zusätzlich aus Dock beziehungsweise Taskleiste verschwinden. Ein Meeting-Bot tritt dem Call nicht bei, es gibt also keinen Teilnehmer, der auffällt. Genau hier liegt die Einschränkung, die das README nicht auflöst: Der Ausschluss aus der Bildschirmaufnahme hängt von Betriebssystem- und Compositor-Mechanismen ab, nicht von der Anwendung allein. Ob er auf einem bestimmten Linux-Desktop, in einer virtualisierten Sitzung oder in einem webbasierten Aufzeichnungswerkzeug tatsächlich greift, lässt sich aus dem Repository-Material nicht beantworten. Dasselbe gilt für die Transkription des System-Audios: Sie erfordert auf den meisten Plattformen zusätzliche Berechtigungen, deren Verhalten das README nicht beschreibt. Wer Pluely wegen der Stealth-Eigenschaft auswählt, sollte diese Eigenschaft zuerst auf der eigenen Zielplattform überprüfen, bevor er sich in einem Gespräch darauf verlässt.
GPL-3.0 im Repository, geschlossene Binärdateien im Download
Das Repository trägt die Lizenzkennung GPL-3.0, der letzte Push stammt vom 14. Juli 2026, das Release app-v1.0.0 vom selben Tag. Das README erklärt zugleich, warum v1 nicht mehr als Quellcode erscheint: Der offene Code sei wiederholt neu verpackt und als Klon verkauft worden, keine Lizenz und keine Beschwerde habe das verhindert. Deshalb werden ab v1 nur noch signierte Binärdateien ausgeliefert, während das Produkt im Kern kostenlos bleibt. Diese Konstellation ist für Bewertungszwecke wichtiger als jede Funktionsliste. Die GPL-3.0-Kennzeichnung des Repositories bezieht sich auf den dort liegenden Code, nicht automatisch auf die verteilten v1-Binärdateien. Wer die Anwendung forken, den Code auditieren oder in einer Umgebung mit Nachweispflichten einsetzen will, kann sich auf diese Kennzeichnung nicht stützen. Das ist keine rechtliche Bewertung, sondern eine Beschreibung dessen, was das Material hergibt. Der Bruch zwischen Repository-Lizenz und Auslieferungsform sollte vor jeder Adoption geklärt werden, nicht danach.
Wartungslast und der Preis der geschlossenen Auslieferung
Die Release-Historie zeigt einen langsamen Rhythmus: app-v0.1.8 im November 2025, app-v0.1.9 im Januar 2026, app-v1.0.0 im Juli 2026. Zwischen den beiden letzten Versionen liegen rund sechs Monate, und v1 war laut README ein vollständiger Neuaufbau mit neuen Modi und einem Dashboard. Das ist kein Projekt, das wöchentlich nachliefert. Updates kommen automatisch, was für Anwender bequem ist und für Administratoren bedeutet, dass sie keinen Versionsstand manuell pinnen, solange sie die automatische Aktualisierung nicht abschalten. Der eigentliche Wartungsposten ist ein anderer: Wer das Projekt selbst weiterentwickeln will, kann das nicht, weil v1 keinen Quellcode mitliefert. Die verbleibende Option ist, auf der letzten offenen Version zu bleiben oder ein anderes Werkzeug zu wählen. Das ist die direkte Konsequenz der Entscheidung, gegen Klone mit geschlossenen Binärdateien vorzugehen, und sie trifft nicht die Klonverkäufer, sondern die Mitwirkenden.
Wann ein Transkriptionsdienst die bessere Wahl ist
Die naheliegende Alternative ist ein Transkriptions- und Notizdienst, der dem Meeting als eigener Teilnehmer beitritt und anschließend ein durchsuchbares Protokoll liefert. Der Unterschied liegt nicht in der Modellqualität, sondern in der Architektur: Ein solcher Dienst nimmt am Call teil, ist für alle sichtbar und speichert die Inhalte in seiner eigenen Infrastruktur. Pluely geht den umgekehrten Weg. Es tritt nicht bei, sondern rendert lokal, speichert in eine lokale SQLite-Datenbank und überlässt die Modellanbindung dem Anwender. Der Preis dafür ist, dass es keine serverseitige Nachbereitung gibt, keine Teamfreigabe und keine zentrale Aufbewahrung. Für eine Organisation, die Transkripte ohnehin zentral archivieren und auswerten will, ist der lokale Ansatz ein Nachteil, kein Datenschutzgewinn. Umgekehrt ist er für Einzelpersonen attraktiv, die keine Aufzeichnung in fremder Infrastruktur wünschen. Die Entscheidung fällt also entlang der Frage, ob das Transkript ein geteiltes Artefakt oder eine persönliche Notiz sein soll.
Redaktionelles Fazit
Wer ein Overlay für Live-Transkription und Screenshot-Fragen sucht und mit signierten Binärdateien ohne einsehbaren Quellcode leben kann, findet in Pluely v1 ein schlankes Werkzeug mit lokalem SQLite-Speicher und frei wählbarem Modell-Backend. Wer den Code prüfen, forken oder in einer regulierten Umgebung auditieren muss, sollte nicht adoptieren: Das Repository liefert keine Quellen für v1, und die GPL-3.0-Angabe des Repositories deckt diese Binärdateien nicht ab. Vor jedem Einsatz im Gespräch ist zu klären, ob der Screen-Capture-Ausschluss auf dem Zielsystem tatsächlich greift und ob die Aufnahme des System-Audios in der jeweiligen Umgebung erlaubt ist.
Community-Notizen