Letta Code lokal: Wenn der Agent sein Gedächtnis selbst pflegt

Bei meinen Coding-Agents pflege ich ihr Gedächtnis bisher selbst: AGENTS.md, CLAUDE.md, MEMORY.md und skills/. Letta Code dreht das um. Der Agent verwaltet seine Wissensbasis selbst, und ich lese und korrigiere nur noch mit. Ob das im Alltag besser ist, weiß ich nicht.

Dieses Lab ist ein Zwischenstand, kein Messbericht. Ich habe Letta Code einige Stunden gegen xAI laufen lassen und lokal mit Ollama angestartet. Gezählt oder gemessen habe ich dabei nichts, die Eindrücke unten sind also subjektiv. Die technischen Angaben stammen aus der offiziellen Doku und dem Changelog (Stand 30.10.2026) und können sich bei einem so jungen Projekt schnell ändern.

Woher die Idee kommt

Letta geht auf das MemGPT-Paper der UC Berkeley zurück (Packer et al., arXiv:2310.08560). Die Idee: Das Kontextfenster ist der knappe Hauptspeicher, alles andere liegt außerhalb, und das Modell entscheidet per Funktionsaufruf selbst, was es hineinholt und was es wegschreibt. Letta Code ist das Open-Source-Harness dazu (Apache-2.0), das lokal läuft.

Die Bausteine

• Core Memory: Blöcke im Kontext, die der Agent selbst bearbeiten kann.
• Recall Memory: die durchsuchbare Gesprächshistorie.
• Archival Memory: ein Wissensspeicher zum Lesen und Schreiben. Was ich im Artikel „External Memory“ genannt hatte, heißt bei Letta Archival Memory.
• MemFS: ein Memory-Dateisystem auf Git-Basis. Der Agent liest und schreibt es mit normalen Datei-Werkzeugen, jede Änderung ist ein Commit. Dateien im Root, zum Beispiel persona.md und human.md, landen bei jedem Schritt im System-Prompt. Unterordner mit eigenem MEMORY.md bleiben draußen, bis sie gebraucht werden. Skills sind keine eigene Memory-Stufe, sondern liegen dort unter skills/ im Format SKILL.md.
• Dreaming: Hintergrund-Subagenten gehen vergangene Gespräche durch, fassen Lektionen zusammen und aktualisieren das Memory. Ausgelöst wird das nach einer einstellbaren Zahl von Schritten oder bei der Kontext-Kompaktierung (/sleeptime).
• Mods: Erweiterungen, die Werkzeuge, Befehle, Oberfläche oder die Kontextzufuhr ändern. Der Agent kann sie selbst schreiben.

Worauf ich achten muss

Zwei Punkte aus der Doku sind für mich sicherheitsrelevant:

• Dreaming mit der Option „Agent reviews before applying“ lässt eine zweite Hintergrund-Konversation die Änderungen prüfen. Das kostet mehr Tokens und fragt mich nicht um Freigabe. Memory wird also ohne mein Zutun geändert.
• Mods sind „trusted code“ mit Zugriff auf die Runtime. Ich installiere nur, was ich lesen kann, und nutze die Permission-Modes.

Beides spricht dafür, Berechtigungen nicht nur über Sprachregeln im Prompt abzusichern. Für den Test isoliere ich den State pro Projekt mit LETTA_LOCAL_BACKEND_DIR.

Setup

brew install letta-code
letta --backend local connect ollama
letta --backend local

• Ich habe Letta Code über Homebrew installiert. Wer stattdessen npm (npm install -g @letta-ai/letta-code) nutzt, braucht eine passende Node-Version: Die Doku nennt 22.19+, das npm-Paket 0.34.33 verlangt laut engines aber ^22.23.4 || ^24.22.1 || ^26.12.1. Dann gilt die strengere Angabe.
• Das Backend (lokal) und das Modell (lokal oder Cloud) sind zwei getrennte Entscheidungen.
• Ollama ist als Provider eingebaut, ebenso LM Studio und llama.cpp. Ein Endpoint muss Chat Completions und Tool Calling können. Der Ollama-Provider listet nur Modelle, die die Fähigkeit tools melden.
• Als lokales Modell habe ich qwen3.8:27b genommen (laut Ollama-Library etwa 18 GB, mit tools, thinking und vision). Gegen xAI lief derselbe Aufbau mit einem Cloud-Modell.
• Befehle: /init, /memory, /doctor, /search, /model, /sleeptime, /connect. Der Befehl /remember wurde laut Changelog in Version 0.32.14 entfernt, steht aber auf einigen Doku-Seiten noch. Lektionen gibt man jetzt in normaler Sprache („merk dir, immer pnpm zu nutzen“), Reflexion läuft über /dream oder /reflect.

Erste Eindrücke

• Gegen xAI: Ich habe Letta Code einige Stunden eingesetzt. Die Aufgaben, die ich gestellt habe, wurden bewältigt. Wie gut das Memory danach aussah, habe ich noch nicht systematisch geprüft.
• Lokal mit Ollama: qwen3.8:27b ließ sich starten und läuft grundsätzlich. Zum Programmieren ist mein Mac dafür aber zu schwach. Das ist mein Eindruck von einem Rechner, kein Benchmark. Ob es sich mit den Erfahrungen anderer mit lokalen Qwen-Modellen deckt, kann ich hier nicht belegen.
• Konsequenz: Für den Alltag ist die Cloud-Variante für mich zunächst die praktikable. Das lokale Setup hängt an der Hardware, und die Frage, ob die Tool-Schemas von Letta Code mit lokalen Modellen stabil laufen, bleibt offen, weil ich lokal gar nicht so weit gekommen bin.

So will ich weiter testen

In einem kleinen Testrepo starte ich mit /init und führe mehrere Sitzungen mit wiederkehrenden Vorlieben und einem absichtlichen Fehler. Danach sehe ich mir mit git log im Memory-Repo an, was der Agent gespeichert hat.

Ausgewertet wird erst nach mehreren Sitzungen. Einzelne Läufe sagen bei Sprachmodellen wenig.

Offene Fragen

• Welche Hardware ich für qwen3.8:27b mit ausreichend Kontext zum Coden brauche. Mein Mac reicht dafür nicht, das Modell allein braucht etwa 18 GB, der Kontext kommt dazu.
• Ob die Tool-Schemas von Letta Code mit lokalen Modellen stabil laufen. Dazu steht nichts in der Doku, und ich bin lokal nicht weit genug gekommen, um es zu beurteilen.
• Wie gut sich MemFS mit einem bestehenden AGENTS.md- und Skills-Setup kombinieren lässt.

Quellen: Letta Code Quickstart, Memory, MemFS, Changelog, Repository letta-ai/letta-code