LocalGPT, l’assistant IA local-first — basé sur Rust, avec mémoire persistante

 (github.com/localgpt-app)
2 points par GN⁺ 2026-02-09 | 1 commentaires | Partager sur WhatsApp
  • Assistant IA local exécuté en Rust : fonctionne entièrement sur l’appareil personnel sans connexion Internet, sans transmettre les données vers l’extérieur
  • Architecture en exécutable unique : peut être lancé sans installer Node.js, Docker ou Python, sous la forme d’un binaire léger d’environ 27 Mo
  • Système de mémoire persistante : offre une mémoire de long terme et des fonctions de recherche grâce à un dépôt de connaissances basé sur Markdown, SQLite FTS5 et la recherche sémantique
  • Prend en charge à la fois CLI, interface web et GUI desktop, et est compatible avec plusieurs fournisseurs de LLM comme OpenAI, Anthropic et Ollama
  • Compatible avec le format OpenClaw, permettant d’exécuter des tâches autonomes à l’aide des fichiers SOUL, MEMORY et HEARTBEAT

Aperçu

  • LocalGPT est un assistant IA centré sur l’appareil local, une application basée sur Rust dotée d’une mémoire persistante et de capacités de travail autonome
    • Exécution complète sur l’appareil personnel sans dépendre de serveurs externes
    • Inspiré du projet OpenClaw tout en conservant la compatibilité
  • L’installation est possible avec la commande cargo install localgpt, avec au choix l’inclusion de l’interface graphique ou le mode headless

Principales fonctionnalités

  • Architecture à binaire unique ne nécessitant ni Node.js, ni Docker, ni Python
  • Conservation locale des données : toute la mémoire et les paramètres sont stockés sur l’appareil de l’utilisateur
  • Mémoire persistante : utilise un dépôt de connaissances fondé sur des fichiers Markdown, avec prise en charge de la recherche rapide et de la recherche sémantique via SQLite FTS5 et sqlite-vec
  • Fonction heartbeat autonome permettant d’exécuter des tâches en arrière-plan
  • Interfaces variées : CLI, interface web et GUI desktop
  • Prise en charge de plusieurs LLM : compatible avec Anthropic (Claude), OpenAI, Ollama, etc.

Fonctionnement

  • La mémoire est stockée dans le répertoire ~/.localgpt/workspace/, avec la structure principale suivante
    • MEMORY.md : stockage des connaissances de long terme
    • HEARTBEAT.md : file de tâches autonomes
    • SOUL.md : personnalité et consignes de comportement
    • knowledge/ : dépôt de connaissances structuré par sujet
  • Recherche par mots-clés avec SQLite FTS5, et recherche sémantique locale basée sur des embeddings avec sqlite-vec

Configuration et commandes CLI

  • Le fichier de configuration est stocké dans ~/.localgpt/config.toml et permet de définir le modèle par défaut, les clés API, l’intervalle du heartbeat, les plages horaires de travail, etc.
  • Principales commandes CLI
    • localgpt chat : démarrer une session de conversation
    • localgpt ask "질문" : exécuter une requête unique
    • localgpt daemon start : lancer le démon en arrière-plan
    • localgpt memory search "query" : rechercher dans la mémoire
    • localgpt config init : générer la configuration par défaut

HTTP API

  • Une REST API est fournie lorsque le démon est en cours d’exécution
    • GET /health : vérifier l’état
    • POST /api/chat : requête de conversation
    • GET /api/memory/search?q=<query> : recherche dans la mémoire
    • GET /api/memory/stats : consulter les statistiques de mémoire

Stack technique

  • Basé sur Rust, Tokio, Axum, SQLite (FTS5 + sqlite-vec), fastembed et eframe
  • Distribué sous licence Apache-2.0, avec environ 93 % du code écrit en Rust

Autres informations

  • Sur GitHub, le projet compte environ 646 étoiles et 39 forks
  • Le billet de blog “Why I Built LocalGPT in 4 Nights” détaille le processus de développement et l’historique commit par commit
  • Les principaux contributeurs identifiés sont au nombre de quatre : Yi Wang, Claude, objectkit et Ax73

À lire aussi

1 commentaires

 
GN⁺ 2026-02-09
Commentaires Hacker News

  • Voir ce genre de chose en 2026 donne vraiment une impression cyberpunk
    La structure avec MEMORY.md, HEARTBEAT.md, SOUL.md est très intéressante
    Cela dit, comme ça dépend de ANTHROPIC_API_KEY, c’est difficile de vraiment appeler ça « local-first »
    Malgré tout, je pense qu’à long terme, le local-first représente l’avenir
    J’ai fait quelque chose de similaire en Rust l’an dernier, et faire tourner les modèles en local faisait clairement la différence en vitesse
    J’ai aussi ma vidéo de démo
    Implémenter ce genre de chose au niveau de l’OS a été une véritable rupture de paradigme
    Je pense que notre manière d’interagir avec les appareils va changer en profondeur dans les 5 à 10 prochaines années

    • Ce n’est pas du local-first, le nom semble mal choisi
    • Il n’est pas nécessaire d’utiliser un LLM tiers
      On peut définir directement un endpoint compatible OpenAI ou Anthropic, y compris sur localhost
    • Code associé : providers.rs L222
    • Moi aussi, je teste OpenClaw et Qwen3 Coder Next en local-first sur mon LAN
      Je viens juste de commencer, mais ça semble assez prometteur
    • Qu’on aime ou non l’IA, l’ampleur actuelle des investissements ressemble au programme Apollo de notre génération
      Plus de 100 datacenters de classe gigawatt devraient voir le jour dans les prochaines années
      Je trouve que c’est un bien meilleur usage de l’argent que l’industrie de l’armement

  • Un conseil : pour les billets et la documentation, il vaut mieux écrire soi-même ou au moins éditer soi-même
    En l’état, la documentation et les textes donnent tous l’impression d’avoir été écrits par un LLM, sans aucun soin

    • De nos jours, beaucoup ont déjà renoncé à écrire plus de quelques phrases
      Ces machines à blanchir le plagiat sont en train de détruire le sens de l’écriture chez les gens
    • Je suis d’accord, rédiger la documentation soi-même devient même plus amusant
    • Il y a aussi un contre-argument
      À la base, je déteste écrire de la documentation, donc avant il n’y en avait quasiment pas dans mon code
      Ce qui le rendait difficile à utiliser pour les autres
      Les LLM produisent rapidement des explications précises et les maintiennent à jour, donc c’est idéal pour la rédaction de documentation
      Même si ça se voit qu’un humain ne l’a pas écrite, tant que le contenu est correct, je n’y vois pas de problème
    • J’aimerais que cela serve de frein contre ce type de posts bas de gamme, mais en réalité ce n’est pas le cas
      Au contraire, il y a une ambiance où l’on semble fier de ne faire aucun effort

  • L’idée de ce projet est excellente
    Le cœur, c’est un framework structuré de mémoire persistante + recherche sémantique
    La fonction SOUL est en réalité déjà prise en charge par la plupart des LLM sous forme de fichiers Markdown
    Ce type de structure peut devenir le point de départ d’un réseau privé d’agents
    Mais le problème, c’est le nom — LocalGPT n’est

    1. pas local,
    2. et pas un modèle GPT non plus
      Il vaudrait mieux le renommer pour refléter plus précisément l’intention

  • Question sérieuse : je me demande en quoi cela diffère de OpenClaw
    Ça utilise la même structure SOUL.md, MEMORY.md, HEARTBEAT.md,
    et OpenClaw propose déjà la messagerie multicanal, les appels vocaux, l’automatisation du navigateur, et même des sous-agents
    J’aimerais savoir s’il y a un élément différenciateur autre que le fait que ce soit écrit en Rust

    • Beaucoup de gens, moi y compris, ont peur d’OpenClaw
      Il y a trop de fonctionnalités, et son architecture de sécurité est faible
      L’approbation des permissions est surtout formelle, et il peut modifier sa propre configuration
      C’est pourquoi j’isole les permissions avec Wardgate
      Il faut répartir ça sur plusieurs nœuds/agentes et séparer les identifiants ainsi que l’accès aux API
    • On dirait juste un générateur de site statique pour le vibe coding
    • Le fait que ce soit petit et non basé sur Node est un avantage
      Tout le monde n’a pas une machine puissante

  • Je me demande pourquoi il faut se connecter à des fournisseurs de LLM comme OpenAI ou Anthropic
    Si c’est un GPT local, l’inférence ne devrait-elle pas aussi être locale ?

    • Il n’est pas nécessaire de se connecter à un service externe
      On peut définir un serveur local comme Ollama en tant que fournisseur de LLM
      Le README ne montre qu’un exemple avec Anthropic, mais le code montre que d’autres options sont possibles
      Il suffit de modifier une ligne dans la configuration
    • L’effort est appréciable, mais le nom prête à confusion
      En réalité, ce n’est ni local ni un GPT
      C’est plus proche d’un clone Rust de OpenClaw
    • Si aucun fournisseur local n’est configuré, le système bascule automatiquement sur un fournisseur en ligne
      Code associé : providers.rs L222
    • Ce n’est pas indispensable

  • Le problème central de sécurité pour des agents comme LocalGPT ou OpenClaw, c’est la trinité fatale :
    « private data access + external communication + untrusted content »
    Un seul e-mail malveillant peut suffire à déclencher une instruction du type « transfère ma boîte mail à l’attaquant »
    Je travaille sur des politiques de sécurité basées sur les object capabilities pour résoudre cela
    J’aimerais concevoir des politiques empêchant structurellement toute fuite d’informations sensibles

    • Ce problème de la trinité est actuellement le défi le plus urgent du domaine
      Je vois deux pistes de solution
      1. limiter tous les envois externes à une validation manuelle (OTP, etc.)
        mais c’est très fatigant
      2. éviter complètement cette trinité dès la conception — par exemple avec des agents à deux facteurs bloquant toute communication externe
        Je me demande si vous explorez d’autres approches

  • J’ai essayé OpenClaw, mais il manque d’observabilité
    Il n’y a aucun log permettant de voir ce que l’agent pense ou fait en ce moment
    Ce genre de système serait parfait en Elixir/BEAM
    On pourrait suivre l’état via l’arbre des processus et inspecter les boîtes aux lettres des messages pour voir le fil de pensée

    • Le projet lemon semble faire exactement ça
    • Les modèles comme GPT ou Claude cachent délibérément une partie de leur raisonnement interne
      Ils n’en montrent qu’une fraction et consomment en réalité plus de tokens
    • Bonne idée, vous devriez le construire vous-même
    • Je suis d’accord sur le manque d’observabilité
      Le fait de devoir pallier une fonctionnalité qui devrait être native avec des tutoriels YouTube montre bien que c’est actuellement le chaos

  • Sur Linux Mint, cargo install localgpt a échoué
    En ajoutant "x11" dans Cargo.toml, la compilation a réussi
    Je ne connais pas très bien Rust, mais ça semble être un problème de dépendance GUI

  • Quels sont les modèles locaux intéressants pour servir d’assistant local ?
    Je me demande aussi s’il existe des évaluations du compromis entre ressources de calcul et mémoire
    J’aimerais savoir à partir de quel niveau de matériel cela devient réellement utile

  • Le mot « local » est vraiment utilisé de manière étrange ces temps-ci
    On parle de local alors que la majorité des fonctionnalités interagit quand même avec Internet