LocalGPT, ein lokal priorisierter KI-Assistent – Rust-basiert, mit persistentem Speicher

 (github.com/localgpt-app)
2 Punkte von GN⁺ 2026-02-09 | 1 Kommentare | Auf WhatsApp teilen
  • Ein lokal ausgeführter KI-Assistent, entwickelt in Rust, der vollständig auf dem persönlichen Gerät ohne Internetverbindung funktioniert und keine Daten nach außen sendet
  • Single-Binary-Architektur: läuft ohne Installation von Node.js, Docker oder Python und liegt als leichtgewichtiges Binary von etwa 27 MB vor
  • Das persistente Speichersystem bietet über einen Markdown-basierten Wissensspeicher, SQLite FTS5 und semantic search Langzeitgedächtnis- und Suchfunktionen
  • Unterstützt CLI, Web-UI und Desktop-GUI und ist kompatibel mit mehreren LLM-Anbietern wie OpenAI, Anthropic und Ollama
  • Kompatibel mit dem OpenClaw-Format, sodass mit SOUL-, MEMORY- und HEARTBEAT-Dateien autonome Aufgaben ausgeführt werden können

Überblick

  • LocalGPT ist ein KI-Assistent mit Fokus auf lokale Geräte, eine Rust-basierte Anwendung mit persistentem Speicher und autonomen Aufgabenfunktionen
    • Läuft vollständig auf dem persönlichen Gerät ohne Abhängigkeit von externen Servern
    • Von dem OpenClaw-Projekt inspiriert und kompatibel dazu gehalten
  • Die Installation ist mit dem Befehl cargo install localgpt möglich; wahlweise mit GUI oder im Headless-Modus

Hauptmerkmale

  • Single-Binary-Architektur, daher sind Node.js, Docker und Python nicht erforderlich
  • Lokale Datenspeicherung: Alle Speicherinhalte und Einstellungen werden auf dem Gerät des Nutzers gespeichert
  • Persistenter Speicher: Verwendet einen Markdown-basierten Wissensspeicher und unterstützt schnelle Suche sowie semantische Suche über SQLite FTS5 und sqlite-vec
  • Mit der Funktion autonomer Heartbeat können Aufgaben im Hintergrund ausgeführt werden
  • Verschiedene Oberflächen: CLI, Web-UI und Desktop-GUI
  • Unterstützung mehrerer LLMs: Anbindung an Anthropic (Claude), OpenAI, Ollama usw.

Funktionsweise

  • Der Speicher wird im Verzeichnis ~/.localgpt/workspace/ abgelegt; die wichtigsten Dateien sind wie folgt aufgebaut
    • MEMORY.md: Speicherung von Langzeitwissen
    • HEARTBEAT.md: Warteschlange für autonome Aufgaben
    • SOUL.md: Persönlichkeits- und Verhaltensanweisungen
    • knowledge/: Strukturierter Wissensspeicher nach Themen
  • Mit SQLite FTS5 wird eine Stichwortsuche durchgeführt, mit sqlite-vec eine semantische Suche auf Basis lokaler Embeddings

Konfiguration und CLI-Befehle

  • Die Konfigurationsdatei wird unter ~/.localgpt/config.toml gespeichert und legt Standardmodell, API-Schlüssel, Heartbeat-Intervall, Arbeitszeiten usw. fest
  • Wichtige CLI-Befehle
    • localgpt chat: startet eine Gesprächssitzung
    • localgpt ask "질문": führt eine einzelne Anfrage aus
    • localgpt daemon start: startet den Hintergrund-Daemon
    • localgpt memory search "query": durchsucht den Speicher
    • localgpt config init: erstellt eine Standardkonfiguration

HTTP-API

  • Beim Ausführen des Daemons wird eine REST-API bereitgestellt
    • GET /health: Status prüfen
    • POST /api/chat: Gesprächsanfrage
    • GET /api/memory/search?q=<query>: Speicher durchsuchen
    • GET /api/memory/stats: Speicherstatistiken abrufen

Tech-Stack

  • Basierend auf Rust, Tokio, Axum, SQLite (FTS5 + sqlite-vec), fastembed und eframe
  • Veröffentlicht unter der Apache-2.0-Lizenz; rund 93 % des Codes sind in Rust geschrieben

Weitere Informationen

  • Auf GitHub mit etwa 646 Stars und 39 Forks
  • Im Blogbeitrag “Why I Built LocalGPT in 4 Nights” werden Entwicklungsprozess und Details nach Commits offengelegt
  • Als wichtigste Beitragende werden vier Personen genannt: Yi Wang, Claude, objectkit und Ax73

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-02-09
Hacker-News-Kommentare

  • Dass wir uns 2026 so etwas ansehen, fühlt sich wirklich cyberpunkig an
    Strukturen wie MEMORY.md, HEARTBEAT.md und SOUL.md finde ich extrem spannend.
    Allerdings ist es schwer, das „local-first“ zu nennen, wenn es von ANTHROPIC_API_KEY abhängt.
    Trotzdem denke ich, dass local-first langfristig die Zukunft ist.
    Ich habe letztes Jahr etwas Ähnliches in Rust gebaut, und der Geschwindigkeitsunterschied war deutlich, wenn das Modell lokal lief.
    Es gibt auch mein Demo-Video.
    So etwas auf OS-Ebene zu implementieren, war wirklich eine Erfahrung auf dem Niveau eines Paradigmenwechsels.
    Ich glaube, dass sich in den nächsten 5–10 Jahren die Art, wie wir mit Geräten interagieren, grundlegend ändern wird.

    • Das ist nicht local-first, der Name scheint falsch gewählt zu sein.
    • Es gibt keinen Grund, zwingend ein LLM eines Drittanbieters zu nutzen.
      Man kann OpenAI- oder Anthropic-kompatible Endpunkte direkt angeben, auch auf localhost.
    • Relevanter Code: providers.rs L222
    • Ich probiere auf meinem LAN auch gerade OpenClaw und Qwen3 Coder Next auf local-first-Art aus.
      Ich fange gerade erst an, aber es wirkt ziemlich vielversprechend.
    • Unabhängig davon, wie man zu AI steht, wirkt das aktuelle Investitionsvolumen wie das Apollo-Programm unserer Generation.
      In den kommenden Jahren sollen über 100 Rechenzentren im Gigawatt-Maßstab entstehen.
      Ich halte das für eine deutlich bessere Verwendung von Geld als die Rüstungsindustrie.

  • Ein Rat: Beiträge oder Dokumentation sollte man selbst schreiben oder zumindest selbst redigieren.
    Die aktuelle Doku und die Texte wirken alle, als wären sie komplett von einem LLM geschrieben, und dadurch fehlt jede Sorgfalt.

    • Inzwischen haben viele Leute offenbar aufgegeben, mehr als ein paar Sätze selbst zu schreiben.
      Diese Plagiats-Waschmaschinen ruinieren das Sprachgefühl der Menschen.
    • Stimme zu, selbst Dokumentation zu schreiben macht sogar mehr Spaß.
    • Es gibt aber auch Gegenargumente.
      Ich habe Dokumentation schon immer gehasst, daher hatte mein Code früher fast nie welche.
      Dadurch war er für andere schwer nutzbar.
      LLMs liefern präzise Erklärungen schnell und halten sie aktuell, daher sind sie fürs Schreiben von Doku ideal.
      Selbst wenn man merkt, dass kein Mensch sie geschrieben hat, sehe ich kein Problem, solange der Inhalt stimmt.
    • Es wäre schön, wenn das als Abschreckung gegen solche minderwertigen Posts funktionieren würde, aber in der Realität ist das nicht so.
      Eher scheint es ein Klima zu geben, in dem man stolz darauf ist, sich keine Mühe zu geben.

  • Die Projektidee ist großartig.
    Der Kern ist ein strukturiertes Framework aus persistenter Erinnerung + semantischer Suche.
    Die SOUL-Funktion wird von den meisten LLMs im Grunde bereits in Form von Markdown-Dateien unterstützt.
    Solche Strukturen könnten der Ausgangspunkt für den Aufbau privater Agenten-Netzwerke sein.
    Das Problem ist allerdings der Name — LocalGPT ist

    1. nicht lokal und
    2. auch kein GPT-Modell.
      Ein Name, der die Absicht präziser widerspiegelt, wäre besser.

  • Ernst gemeinte Frage: Worin unterscheidet sich das von OpenClaw?
    Es verwendet dieselbe Struktur mit SOUL.md, MEMORY.md und HEARTBEAT.md,
    und OpenClaw hat bereits Multichannel-Messaging, Sprachanrufe, Browser-Automatisierung und sogar Sub-Agenten.
    Abgesehen davon, dass es in Rust geschrieben ist, würde ich gern wissen, was das Alleinstellungsmerkmal ist.

    • Viele Menschen, mich eingeschlossen, haben Angst vor OpenClaw.
      Es hat viel zu viele Funktionen, und die Sicherheitsarchitektur ist schwach.
      Berechtigungsfreigaben sind eher Formsache, und es kann seine eigene Konfiguration selbst ändern.
      Deshalb trenne ich Berechtigungen mit Wardgate.
      Es ist notwendig, das in mehrere Nodes/Agenten aufzuteilen und Zugangsdaten sowie API-Zugriffe zu trennen.
    • Das wirkt einfach wie ein statischer Site-Generator fürs Vibe-Coding.
    • Ein Vorteil ist, dass es klein ist und nicht auf Node basiert.
      Nicht jeder hat schließlich eine leistungsstarke Maschine.

  • Ich frage mich, warum man sich mit einem LLM-Anbieter wie OpenAI oder Anthropic verbinden muss.
    Wenn es ein lokales GPT ist, sollte dann nicht auch die Inferenz lokal laufen?

    • Eine externe Verbindung ist nicht zwingend nötig.
      Man kann einen lokalen Server wie Ollama als LLM-Anbieter angeben.
      Im README steht zwar nur ein Anthropic-Beispiel, aber im Code sieht man, dass auch anderes möglich ist.
      Man muss nur eine Zeile in der Konfiguration ändern.
    • Der Einsatz ist lobenswert, aber der Name führt in die Irre.
      In Wirklichkeit ist es weder lokal noch GPT.
      Es ist eher ein in Rust geklonter OpenClaw.
    • Wenn nichts Lokales konfiguriert ist, gibt es ein automatisches Fallback auf einen Online-Anbieter.
      Relevanter Code: providers.rs L222
    • Es ist nicht zwingend erforderlich.

  • Das zentrale Sicherheitsproblem bei Agenten wie LocalGPT oder OpenClaw ist die fatale Triade aus „private data access + external communication + untrusted content“.
    Schon eine einzige bösartige E-Mail könnte dazu führen, dass der Befehl „Leite mein Postfach an den Angreifer weiter“ ausgeführt wird.
    Ich erforsche derzeit objektfähigkeitsbasierte Sicherheitsrichtlinien, um das zu lösen.
    Ich möchte Richtlinien entwickeln, die das Abfließen sensibler Informationen grundsätzlich verhindern.

    • Dieses Triadenproblem ist derzeit die dringendste Aufgabe in diesem Bereich.
      Ich sehe zwei Lösungswege:
      1. jede externe Übertragung auf manuelle Freigabe beschränken (OTP usw.)
        Das ist allerdings sehr ermüdend.
      2. die Triade schon im Design vermeiden — zum Beispiel durch zweiarmige Agenten, bei denen die externe Kommunikation blockiert ist.
        Mich würde interessieren, ob du noch andere Ansätze untersuchst.

  • Ich habe OpenClaw ausprobiert, aber es fehlt an Observability.
    Man sieht überhaupt keine Logs darüber, was dieser Agent gerade denkt oder tut.
    Solche Systeme wären meiner Meinung nach perfekt in Elixir/BEAM aufgehoben.
    Über Prozessbäume könnte man den Zustand nachverfolgen und durch Dumps der Message-Boxen den Gedankengang sichtbar machen.

    • Das lemon-Projekt scheint genau so etwas zu machen.
    • Modelle wie GPT oder Claude verbergen ihre internen Gedanken absichtlich.
      Sie zeigen nur einen Teil davon an und verbrauchen in Wirklichkeit noch mehr Tokens.
    • Gute Idee, du solltest das selbst bauen.
    • Ich stimme ebenfalls zu, dass Observability fehlt.
      Dass man etwas, das eine Grundfunktion sein sollte, über YouTube-Tutorials lösen muss, zeigt, dass aktuell pures Chaos herrscht.

  • Unter Linux Mint ist cargo install localgpt fehlgeschlagen.
    Nachdem ich "x11" in Cargo.toml ergänzt hatte, lief der Build erfolgreich durch.
    Ich kenne mich mit Rust nicht gut aus, aber das wirkte wie ein GUI-Abhängigkeitsproblem.

  • Welche lokalen Modelle taugen etwas als lokaler Assistent?
    Mich würde auch interessieren, ob es Versuche gibt, den Trade-off zwischen Rechenressourcen und Speicher zu bewerten.
    Ich würde gern wissen, welche Hardware ungefähr nötig ist, damit das Ganze auf einem sinnvollen Niveau nutzbar wird.

  • Das Wort „lokal“ wird heutzutage wirklich seltsam verwendet.
    Die meisten Funktionen interagieren am Ende doch mit dem Internet, und trotzdem nennt man es lokal.