claude-mem

Jeder Coding-Agent vergisst. Schließt du eine Claude-Code-Session, ist alles weg: die Kette der Entscheidungen, die Gründe, warum du einen Ansatz verworfen hast, die Datei, die du vor drei Stunden gepatcht hast. Die nächste Session startet kalt, und die ersten zehn Minuten erklärst du dein eigenes Projekt erneut. claude-mem, ein Apache-2.0-Projekt von thedotmack, ist eine persistente Memory-Schicht, die unter dem Agenten sitzt und genau das beheben will. Es läuft als Claude-Code-Plugin, protokolliert im Hintergrund, was der Agent tut, verdichtet diese Aktionen zu kompakten Zusammenfassungen und spielt die relevanten zurück, wenn eine neue Session beginnt. Das Versprechen heißt Kontinuität: Der Agent soll dein Projekt kennen wie ein Kollege, ohne dass du jeden Morgen denselben Kontext einfügst.

claude-mem arbeitet über fünf Lifecycle-Hooks, die in den Agenten eingeklinkt sind: SessionStart, UserPromptSubmit, PostToolUse, Stop und SessionEnd. Der PostToolUse-Hook ist das Herzstück. Nach jedem Tool-Aufruf schickt er einen nicht blockierenden HTTP-POST an einen Hintergrund-Worker, damit die Session nicht stockt, und dieser Worker, gebaut auf Bun mit lokaler HTTP-API und Web-Viewer, verdichtet die Rohausgabe mit dem Claude Agent SDK zu einer strukturierten Observation. Die Observations landen in SQLite mit Volltextsuche, und ein Chroma-Vektorspeicher ergänzt eine semantische Suche darüber. Der Abruf ist bewusst gestaffelt: ein dreischichtiger Ablauf aus Index, Timeline und Volldetail, damit der Agent erst eingrenzt, bevor er teuren Text zieht. Das Projekt berichtet von etwa zehnfacher Token-Ersparnis durch diese Filterung, mit sichtbaren Kostenschätzungen pro Schicht.

Die klare Zielgruppe sind intensive Claude-Code-Nutzer, die durch Kontext-Resets echte Zeit verlieren: Entwickler mit einer großen Codebasis über viele Sessions hinweg oder alle, die lange, mehrtägige Agent-Workflows fahren, bei denen Kontinuität wirklich zählt. Wenn du den Agenten oft fragst, warum ein Modul so strukturiert ist, oder willst, dass er ohne manuelle Zusammenfassung dort weitermacht, wo gestern Schluss war, ist genau das der Einsatzzweck. Die Transparenz bei den Token-Kosten ist hier echt nützlich, denn persistentes Gedächtnis kann die Rechnung still in die Höhe treiben, und geschätzte Kosten pro Abrufschicht lassen dich den Tradeoff einschätzen. Die Privacy-Tags, bei denen in private-Tags eingeschlossener Inhalt nicht gespeichert wird, sind wichtig für alle, deren Sessions Secrets, Kundendaten oder anderes berühren, das nicht in einer lokalen Datenbank landen soll.

Die ehrlichen Einschränkungen sind real. Trotz Marketing, das Gemini CLI, Codex, OpenCode, Copilot und mehr auflistet, ist das Projekt zuerst auf Claude Code zugeschnitten, und die Unterstützung anderer Agenten klingt eher nach Absicht als nach Gleichwertigkeit. Der Dependency-Stack ist schwer für etwas, das konzeptionell ein Memory-Cache ist: Du brauchst Node 18 oder neuer, Bun, SQLite, Chroma und uv, dazu einen Hintergrund-Worker, der einen Port belegt. Das sind viele bewegliche Teile, die auf einer Entwicklermaschine installiert und am Laufen gehalten werden müssen, jedes ein möglicher Fehlerpunkt. Die Versionshistorie ist die lauteste Warnung: Das Projekt steht bei 13.x mit Hunderten Releases, was schnelle Iteration signalisiert, aber auch eine Geschichte von Umbrüchen und Breaking Changes. Die Memory-Qualität hängt zudem am Summarizer, sodass Observations lückenhaft sein oder genau das Detail verfehlen können, das du später brauchst.

Gegen den kommerziellen Strich gebürstet liegt claude-mem im Geist am nächsten an den Memory-Funktionen gehosteter Agent-Plattformen, bleibt aber lokal, offen und einsehbar, und das ist sein Hauptargument. Wenn du in Claude Code lebst, regelmäßig Kontext über Sessions verlierst und keine Scheu hast, einen Stack aus Bun, Chroma und uv zu betreiben und zu debuggen, lohnt sich der Einstieg jetzt und zahlt den Setup-Aufwand wahrscheinlich zurück. Nutzt du überwiegend andere Agenten, sind die agentenübergreifenden Versprechen noch kein Wechselgrund, und das Projekt ist dort zu früh, um sich darauf zu verlassen. Dasselbe gilt, wenn du ein wartungsarmes Tool willst: Der Dependency-Footprint und die schnell laufende 13.x-Release-Linie bedeuten laufende Pflege. Adoptiere es als Komfort für Power-User, noch nicht als stabile Infrastruktur.