Klee : un agent macOS qui exécute ses modèles MLX en local

Le problème visé : garder les conversations sur la machine

Le README ouvre sur une promesse simple : aucune requête ne quitte le Mac. Pas de compte, pas de clé API, pas d'abonnement. Le public visé est donc étroit mais identifiable : un utilisateur de Mac Apple Silicon qui veut un agent conversationnel capable de lire et écrire des fichiers, chercher sur le web et lancer des commandes shell, sans envoyer le contenu de ces fichiers à un service distant. Le README résume la cible en une phrase : « 100% local inference -- your data stays on your Mac ». Ce n'est pas un argument marketing de plus, c'est la contrainte qui dicte tout le reste de l'architecture. Un modèle qui doit tenir dans la mémoire unifiée du Mac impose une quantification agressive, donc des variantes 4 bits hébergées sur mlx-community. Un agent local qui doit agir sur le système impose des outils natifs, donc des appels de fonctions exposés par mlx-swift-lm plutôt qu'un serveur MCP. Chaque choix du projet découle de cette contrainte initiale, et c'est ce qui le distingue d'un simple client de chat.

Comment MLX et les outils natifs s'articulent dans l'application

Klee est une application SwiftUI native d'environ 75 Mo, sans Electron, sans Docker, sans service en arrière-plan. L'inférence repose sur mlx-swift-lm, la bibliothèque MLX pour Swift, qui charge les poids quantifiés en 4 bits depuis le cache local. Le README précise que les modèles sont stockés dans ~/.klee/models/ et qu'ils persistent entre les redémarrages de l'application. Les téléchargements reprennent automatiquement s'ils sont interrompus, ce qui compte quand un fichier de 70 Go comme mlx-community/Qwen3.5-122B-A10B-4bit doit traverser une connexion instable. Les réponses arrivent en streaming, jeton par jeton, et le raisonnement du modèle s'affiche dans une carte repliable quand le modèle en produit. Le point le plus intéressant est le mécanisme d'appel d'outils. Le README indique que Klee utilise l'API ToolCall de mlx-swift-lm, sans MCP, sans Node.js, sans processus externe. Sept outils sont exposés : file_write, file_read, file_list, file_delete, web_search, web_fetch et shell_exec. Les six premiers sont des opérations de système de fichiers ou de réseau. Le septième exécute des commandes shell avec un délai d'expiration de 30 secondes. Cette limite de 30 secondes est une contrainte réelle : une compilation longue ou une commande interactive sera coupée, et rien dans le README n'indique de mécanisme de reprise ou de sortie interactive.

Installation et premiers pas : ce que dit la procédure

Klee n'est pas distribué via le Mac App Store. Le README décrit une distribution directe sous forme de fichier .dmg signé avec un Developer ID. La procédure tient en trois étapes : télécharger le .dmg depuis la page Releases, glisser Klee dans le dossier Applications, puis ouvrir l'application. Si macOS affiche un avertissement Gatekeeper, il faut passer par Réglages Système > Confidentialité et sécurité et cliquer sur « Ouvrir quand même ». C'est le comportement standard pour une application signée hors App Store, et cela signifie que la mise à jour n'est pas automatique : l'utilisateur doit revenir sur la page Releases pour chaque nouvelle version. Pour la compilation depuis les sources, le README donne trois commandes : git clone https://github.com/signerlabs/Klee.git, cd Klee, puis open Klee.xcodeproj. Il faut ensuite sélectionner le schéma Klee et lancer Cmd+R. La dépendance SPM mlx-swift-lm se résout automatiquement à la première compilation. Xcode 16 ou plus récent et macOS 15.0 ou plus récent sont requis. La recherche web est optionnelle et demande une clé API Jina AI, gratuite et sans carte bancaire. Elle s'active via le bouton de bascule dans la barre latérale, en haut à droite, puis en collant la clé dans le champ prévu. Sans cette clé, les outils web_search et web_fetch ne peuvent pas fonctionner.

Le tableau des modèles impose une contrainte matérielle dure

Le README ne cache pas la contrainte : 16 Go de RAM au minimum, Apple Silicon M1 ou plus récent, macOS 15.0. Le tableau des modèles recommande Qwen 3.5 9B, Qwen 3 8B, Gemma 3 12B ou DeepSeek R1 8B à 16 Go. À 32 Go s'ajoutent Qwen 3.5 27B et Qwen 3.5 35B en MoE. À 64 Go, Gemma 3 27B et DeepSeek R1 32B. À 96 Go et plus, Qwen 3.5 122B en MoE, environ 70 Go sur disque. Deux modèles sur neuf supportent la vision à 16 Go (Qwen 3.5 9B), et trois au total dans le tableau. Le reste ne traite pas les images. Cette matrice a une conséquence pratique : sur un Mac à 16 Go, les modèles accessibles plafonnent autour de 12 milliards de paramètres, et la marge de manœuvre pour le contexte et les autres applications est mince. Le README ne donne aucune indication sur la longueur de contexte prise en charge par modèle, ni sur la mémoire résiduelle après chargement. C'est une lacune documentaire, pas un défaut du projet, mais elle oblige à tester soi-même avant de s'engager.

Les outils natifs sont aussi la principale surface de risque

Un agent qui peut appeler file_delete et shell_exec sans confirmation explicite mérite qu'on s'y attarde. Le README ne décrit aucun mécanisme d'approbation, de bac à sable ou de journal d'audit pour ces outils. Il indique seulement que l'IA peut « read/write files, search the web, and run shell commands » et que l'utilisateur peut le lui demander naturellement. Le délai de 30 secondes sur shell_exec limite la portée d'une commande, mais pas sa nature : rm, mv ou une écriture dans un fichier de configuration restent possibles dans cette fenêtre. La documentation ne précise pas non plus si les outils sont confinés à un répertoire de travail ou s'ils peuvent atteindre l'ensemble du système de fichiers accessible à l'utilisateur. En l'absence de cette information, la prudence consiste à considérer que la portée est celle du compte utilisateur. C'est le point où Klee se distingue le moins favorablement d'un simple client de chat : la valeur ajoutée vient précisément de la capacité d'agir, et cette capacité n'est pas encadrée par une politique documentée. Un utilisateur qui veut seulement discuter avec un modèle local n'a aucune raison d'activer ces outils.

Ce que le dépôt ne dit pas : licence, maintenance et alternatives

Le README termine par une section License qui indique MIT. Les métadonnées du dépôt, telles qu'elles sont fournies, indiquent une licence inconnue. Cette divergence n'est pas anodine : sans fichier LICENSE à la racine, un utilisateur qui redistribue Klee ou l'intègre dans un produit interne ne peut pas s'appuyer sur le README seul pour établir ses droits. La première vérification avant tout usage en entreprise consiste donc à confirmer la présence effective du fichier LICENSE dans l'arborescence. Sur la maintenance, les éléments disponibles sont minces : une seule version publiée, v1.0.0 le 19 mars 2026, un dernier push le 20 mars 2026, et aucun archivage. Cela indique un projet actif à cette date, rien de plus. Aucune politique de contribution, aucun canal de signalement de vulnérabilités n'apparaît dans le matériel fourni. Pour situer Klee, la comparaison la plus directe est avec Ollama, qui sert aussi des modèles locaux mais expose une API HTTP et une CLI, et laisse le choix de l'interface à l'utilisateur. Klee fait l'inverse : l'interface graphique est le produit, et l'agent avec ses outils est intégré. Un utilisateur qui veut brancher un modèle local sur son propre script ou son éditeur n'a rien à faire de Klee. Un utilisateur qui veut une application macOS finie, avec appels d'outils et recherche web, n'a rien à assembler avec Ollama. Le coût de mise à jour de Klee est celui d'un binaire signé hors App Store : téléchargement manuel à chaque version, et re-téléchargement des modèles uniquement si le cache est vidé, puisque ~/.klee/models/ persiste.

Verdict : à qui l'outil s'adresse, et ce qu'il faut vérifier d'abord

Klee s'adresse à un utilisateur de Mac Apple Silicon avec 16 Go de RAM minimum, sous macOS 15, qui veut un agent conversationnel local capable d'agir sur ses fichiers et son shell, et qui accepte d'installer un binaire signé hors App Store. Il s'adresse aussi à un développeur Swift qui veut lire le code ou modifier l'application, puisque le projet se compile avec Xcode 16 et que la dépendance mlx-swift-lm se résout automatiquement. Il ne s'adresse pas à une machine Intel, ni à macOS 14, ni à un utilisateur qui veut exécuter des modèles non quantifiés ou de grande taille sur 16 Go. Il ne convient pas non plus à une équipe qui a besoin d'une licence clairement établie avant déploiement, tant que le fichier LICENSE n'est pas confirmé. Avant d'adopter Klee, trois vérifications concrètes : ouvrir le dépôt et confirmer la présence du fichier LICENSE à la racine, tester shell_exec sur une commande inoffensive pour observer si une confirmation est demandée, et vérifier dans ~/.klee/models/ l'espace disque consommé après le premier téléchargement. Si l'une de ces trois vérifications échoue ou reste ambiguë, le projet n'est pas prêt pour un usage au-delà du poste personnel.

Conclusion éditoriale

Klee convient à un utilisateur sur Mac Apple Silicon avec au moins 16 Go de RAM qui veut un agent local sans compte ni clé API, et à un développeur Swift prêt à ouvrir Klee.xcodeproj sous Xcode 16. Il ne convient pas à une machine Intel, à macOS 14, ni à qui veut exécuter des modèles 4 bits sans quantification, ni à qui refuse un binaire signé hors App Store. À vérifier avant toute adoption en équipe : le fichier LICENSE, la politique du dépôt sur les rapports de vulnérabilité, et le comportement réel de shell_exec sur des commandes destructrices.

Sources officielles

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