Klee: lokale LLM-Chat-App für macOS mit MLX und nativen Tools

Lokale Inferenz als Produktentscheidung, nicht als Feature

Klee richtet sich an Nutzer, die einen Chat mit einem großen Sprachmodell wollen, ohne dafür ein Konto anzulegen, einen API-Schlüssel zu verwalten oder Prompts an einen fremden Server zu schicken. Die README formuliert das Ziel direkt: keine Cloud, kein Konto, kein Abonnement. Der praktische Nutzen liegt weniger im Datenschutzversprechen als in der Wegfallentscheidung. Es gibt keinen Tarif, kein Rate Limit und keine Abrechnung pro Token. Dafür gibt es auch keinen Support-Vertrag und keine Verfügbarkeitsgarantie. Die Zielgruppe ist enger, als die Feature-Liste vermuten lässt: Apple Silicon ist Pflicht, macOS 15.0 oder neuer ebenfalls, und 16 GB RAM sind das Minimum. Auf einem M1 mit 8 GB startet die App nach den Systemanforderungen gar nicht erst sinnvoll. Wer bereits eine lokale Inferenzpipeline mit llama.cpp oder Ollama betreibt, findet hier keine neue Engine, sondern eine andere Verpackung: eine native SwiftUI-Oberfläche, die den Modelldownload und die Tool-Aufrufe übernimmt.

MLX, mlx-swift-lm und die ToolCall-API als tragende Schichten

Die Inferenz läuft über MLX, Apples Framework für Array-Operationen auf der Unified Memory Architecture. Klee bindet es über die SPM-Abhängigkeit mlx-swift-lm ein, die laut README beim ersten Build automatisch aufgelöst wird. Die Modelle stammen aus der mlx-community auf HuggingFace und liegen als 4-Bit-Quantisierungen vor. Das ist eine bewusste Festlegung: keine FP16-Varianten, keine 8-Bit-Zwischenstufen, keine eigenen Quantisierungen. Die Tool-Anbindung erfolgt über die ToolCall-API von mlx-swift-lm. Die README stellt ausdrücklich klar, dass dafür kein MCP, kein Node.js und keine externen Prozesse nötig sind. Das unterscheidet Klee von Assistenten, die Tools über einen separaten Server oder ein JSON-RPC-Protokoll anbinden. Der Datenfluss ist entsprechend kurz: Der Nutzer tippt, das Modell entscheidet über einen ToolCall, die App führt ihn nativ in Swift aus, das Ergebnis geht zurück in den Kontext. Websuche und Web-Fetch laufen dagegen nicht lokal, sondern über die Jina-API. Das ist die einzige Stelle, an der Daten das Gerät verlassen, und sie ist optional. Wer die Websuche nicht aktiviert, bleibt vollständig offline.

Installation ohne App Store, mit Gatekeeper-Hürde

Klee wird als signierte DMG-Datei über die GitHub-Releases verteilt, nicht über den Mac App Store. Der Ablauf ist kurz: DMG herunterladen, Klee in den Programme-Ordner ziehen, öffnen. Beim ersten Start kann macOS eine Gatekeeper-Warnung zeigen. Die README nennt den Ausweg: Systemeinstellungen, Datenschutz & Sicherheit, dann Schaltfläche Öffnen trotzdem. Das ist ein Reibungspunkt, den App-Store-Nutzer nicht kennen, und er wiederholt sich bei jedem Update, solange die App nicht notarisiert ist. Aus dem Quellcode bauen geht ebenfalls, erfordert aber Xcode 16 oder neuer und macOS 15.0 oder neuer. Die Befehle aus der README sind schlicht: git clone https://github.com/signerlabs/Klee.git, dann cd Klee, dann open Klee.xcodeproj. Anschließend das Schema Klee wählen und mit Cmd+R starten. Die SPM-Abhängigkeit mlx-swift-lm wird beim ersten Build aufgelöst. Für die Websuche ist ein separater Schritt nötig: ein kostenloser API-Schlüssel von jina.ai, dann in der Seitenleiste den Schalter Web Search aktivieren und den Schlüssel einfügen. Modelle landen in ~/.klee/models/ und bleiben über Neustarts hinweg erhalten.

Modellauswahl ist an den Arbeitsspeicher gekoppelt

Die README gibt eine Tabelle vor, die Modellgröße, Mindest-RAM, Vision-Fähigkeit und HuggingFace-ID verbindet. Das ist hilfreicher als eine reine Feature-Liste, weil es die Auswahl einschränkt. Auf 16 GB laufen Qwen 3.5 9B (rund 6 GB), Qwen 3 8B (rund 4,3 GB), Gemma 3 12B (rund 8 GB) und DeepSeek R1 8B (rund 4,6 GB). Auf 32 GB kommen Qwen 3.5 27B (rund 16 GB) und Qwen 3.5 35B als MoE-Variante (rund 20 GB) hinzu. 64 GB erschließen Gemma 3 27B und DeepSeek R1 32B, 96 GB oder mehr erst Qwen 3.5 122B mit rund 70 GB. Wer unter 16 GB bleibt, hat keine empfohlene Option. Die Vision-Unterstützung ist nicht flächendeckend: Sie gilt laut Tabelle für Qwen 3.5 9B, Qwen 3.5 27B, Qwen 3.5 35B und Qwen 3.5 122B, nicht für die Gemma- oder DeepSeek-Modelle. Die RAM-Angaben sind Empfehlungen, keine Messwerte. Ob ein 27B-Modell mit 16 GB tatsächlich noch läuft, lässt sich aus der README nicht ableiten. Der Modelldownload ist als Ein-Klick-Vorgang beschrieben und setzt unterbrochene Downloads automatisch fort.

Sieben Tools, ein Timeout und viel Dateisystemzugriff

Klee stellt sieben native Tools bereit: file_write, file_read, file_list, file_delete, web_search, web_fetch und shell_exec. Die ersten vier arbeiten direkt auf dem Dateisystem, ohne Sandbox-Hinweis in der README. shell_exec führt Shell-Befehle mit einem Timeout von 30 Sekunden aus. Diese Kombination ist mächtig und riskant zugleich. Ein Modell, das Dateien überschreiben oder löschen kann, benötigt keine besondere Feindseligkeit, um Schaden anzurichten. Ein fehlgeleiteter ToolCall genügt. Die README beschreibt keine Bestätigungsabfrage vor schreibenden oder löschenden Operationen, keine Pfadbeschränkung auf ein Arbeitsverzeichnis und keine Protokollierung. Wer Klee produktiv einsetzt, sollte das vorher klären. Die Websuche hängt an einem externen Dienst: Ohne Jina-API-Schlüssel bleiben web_search und web_fetch funktionslos. Der Schlüssel liegt laut README in der Seitenleiste, nicht in einer Konfigurationsdatei. Die Inline-Thinking-Karte zeigt den Reasoning-Prozess des Modells in einem einklappbaren Bereich. Das ist vor allem bei DeepSeek-R1-Modellen nützlich, deren Ausgabe sonst schwer nachvollziehbar ist.

Wo Klee die falsche Wahl ist

Die Plattformbindung ist absolut. Klee läuft nur auf Apple Silicon unter macOS 15.0 oder neuer. Ein Linux-Rechner, ein Windows-PC oder ein Intel-Mac scheiden aus. Auch innerhalb der Apple-Welt gibt es eine harte Untergrenze: 16 GB RAM. Wer ein MacBook Air mit 8 GB besitzt, findet in der Modelltabelle keine Zeile. Die Modellvielfalt ist eng. Alle Einträge stammen aus der mlx-community und sind 4-Bit-quantisiert. Wer eine bestimmte Modellfamilie wie Mistral, Llama oder Phi bevorzugt, findet sie nicht in der Liste. Wer eine andere Quantisierungsstufe braucht, um Qualität gegen Speicher zu tauschen, hat keine Option. Die Tool-Ausführung ist nicht abgesichert, wie oben beschrieben. Und die Lizenzangabe ist widersprüchlich: Die README nennt MIT, die Metadaten des Repositorys führen kein Lizenzfeld. Vor einem kommerziellen Einsatz sollte die LICENSE-Datei im Repository geprüft werden, nicht die README-Zeile. Schließlich ist die Websuche an einen Drittanbieter gebunden. Wer vollständige Offline-Fähigkeit benötigt, muss sie deaktivieren und auf web_search und web_fetch verzichten.

llama.cpp-basierte Oberflächen als Alternative

Der naheliegende Vergleich ist eine Oberfläche auf Basis von llama.cpp, etwa Jan oder LM Studio. Der Unterschied liegt weniger in der Inferenzgeschwindigkeit, die von der Hardware abhängt, als in der Architektur. llama.cpp ist plattformübergreifend und läuft auf x86, ARM und verschiedenen GPUs. Klee setzt dagegen auf MLX, das ausschließlich auf Apple Silicon läuft und die Unified Memory Architecture direkt nutzt. llama.cpp-basierte Oberflächen bieten in der Regel einen breiteren Modellkatalog mit mehreren Quantisierungsstufen und Formaten wie GGUF. Klee beschränkt sich auf 4-Bit-MLX-Modelle aus einer Quelle. Dafür ist Klee nativ in Swift und SwiftUI geschrieben, bringt rund 75 MB auf die Waage und benötigt weder Electron noch Docker noch Hintergrunddienste. Eine llama.cpp-Oberfläche mit ähnlichem Funktionsumfang bringt häufig eine Electron-Laufzeit oder einen Python-Server mit. Die Tool-Anbindung unterscheidet sich ebenfalls: Klee nutzt die ToolCall-API von mlx-swift-lm direkt im Prozess, während viele Alternativen Tools über MCP-Server oder externe Skripte anbinden. Wer MCP bereits produktiv nutzt, verliert durch einen Wechsel zu Klee diese Anbindung. Wer umgekehrt keinen Node.js-Prozess neben dem Chat betreiben will, gewinnt.

Wartung, Updates und Lizenzlage

Klee wird als signierte App außerhalb des App Store verteilt. Updates erfolgen daher manuell über die GitHub-Releases, sofern die App keine eigene Update-Prüfung mitbringt, was die README nicht erwähnt. Jedes Update durchläuft denselben Gatekeeper-Ablauf. Modelle liegen in ~/.klee/models/ und überleben App-Neustarts, belegen aber dauerhaft Speicherplatz: Die Spanne reicht von rund 4,3 GB für Qwen 3 8B bis rund 70 GB für Qwen 3.5 122B. Wer mehrere Modelle parallel vorhält, sollte das einplanen. Die Lizenzfrage ist der wichtigste offene Punkt. Die README nennt MIT, die Repository-Metadaten führen kein Lizenzfeld. Das ist keine Kleinigkeit, denn MIT erlaubt kommerzielle Nutzung und Weiterverbreitung, während eine fehlende Lizenz rechtlich bedeutet, dass alle Rechte vorbehalten sind. Bis eine LICENSE-Datei im Repository liegt, ist die Angabe in der README eine Behauptung, keine belegte Tatsache. Die Modellgewichte selbst stehen unter eigenen Lizenzen, die von der MIT-Angabe der App nicht berührt werden. Wer Klee kommerziell einsetzen will, muss beide Ebenen getrennt prüfen.

Redaktionelles Fazit

Klee ist für Entwickler und technisch versierte Nutzer auf Apple Silicon mit mindestens 16 GB RAM sinnvoll, die lokale Inferenz ohne Cloud-Zwang und mit Datei- und Shell-Zugriff wollen. Wer Windows oder Linux nutzt, unter 16 GB RAM arbeitet oder einen breiten Modellkatalog mit vielen Quantisierungen braucht, sollte zu llama.cpp-basierten Oberflächen greifen. Vor dem Einsatz zu prüfen: ob die gewünschte Modell-ID in der Tabelle steht, ob die Jina-API für Websuche vorhanden ist, und ob die MIT-Lizenzangabe im Repository tatsächlich als LICENSE-Datei vorliegt, denn die Metadaten des Repositorys führen kein Lizenzfeld.

Offizielle Quellen

1. Issues
2. Project website
3. README
4. Releases
5. signerlabs/Klee on GitHub