ai-memory: Gemeinsamer Speicher für Claude Code, Codex
ai-memory ist ein quelloffenes Rust-Projekt, das Coding-Agent-CLIs ein Langzeitgedächtnis gibt und Übergaben zwischen Agenten verschiedener Hersteller ermöglicht. Das Problem ist konkret: Der Speicher jedes Agenten lebt auf einer Maschine in einem Tool. Wer Tool oder Kollegen wechselt, muss Architektur, gescheiterte Versuche und offene Fragen neu erklären. ai-memory lässt mehr als zwanzig Harnesses einen gemeinsamen Speicher nutzen und übergibt Fortschritt über ein typisiertes Übergabeprotokoll mit Eigentümer, das nur einmal übernommen werden kann. Die maßgebliche Quelle ist ein git-verwaltetes Markdown-Wiki, die Datenbank ist nur ein wiederaufbaubarer Index. Der Standardpfad ruft kein LLM auf. Das Projekt unterstützt auch projektübergreifende Präferenzen, Sync zwischen Rechnern und Team-Sharing, passend für Einzelne und Teams mit mehreren Coding-Agenten.
Hintergrund
Die meisten Coding-Agenten bringen heute eine Form von Gedächtnis mit. Claude Code führt Notizen, Cursor merkt sich einzelne Fakten, und weitere Plattformen ergänzen ähnliche Funktionen. Diese Speicher teilen eine Grenze: Die Notizen liegen auf einer einzigen Maschine und gehören einem einzigen Agenten. Wer das Werkzeug wechselt oder die Aufgabe an einen Kollegen übergibt, verliert sie aus dem Blick. Dann muss man die Architektur erneut erklären, die bereits gescheiterten Ansätze aufzählen und die offenen Fragen noch einmal darlegen.
Genau diese Lücke nimmt ai-memory ins Visier. Das quelloffene Projekt ist in Rust geschrieben und enthält eine Datei rust-toolchain.toml. Es gibt veröffentlichte Releases, die Website aimemory.sh und eine Open-Source-Lizenz. Auf GitHub hat das Projekt nahezu zehntausend Sterne gesammelt. Es will nicht ein weiterer Agent sein. Es sitzt unter allen Agenten und bildet eine gemeinsame Schicht für das Langzeitgedächtnis.
Das erklärte Ziel ist schlicht. Angenommen, Sie beenden Claude Code mitten in einer Aufgabe und starten im selben Verzeichnis OpenAI Codex. Codex soll die Arbeit dann fortsetzen können, ohne dass Sie das Projekt neu erklären. Dieses Szenario definiert das Produkt.
Tiefenanalyse
Wie teilen Claude Code und Codex mit ai-memory einen gemeinsamen Speicher? Die Antwort besteht aus vier Bausteinen, und jeder ist eine Designentscheidung mit klarer Begründung. Der erste Baustein ist die agentenübergreifende Abdeckung. Mehr als zwanzig Harnesses speisen denselben Speicher, darunter Claude Code, Codex, Cursor, Gemini CLI, OpenCode, Grok, Devin, Kimi und Kiro. Fortschritt wandert über ein typisiertes Übergabeprotokoll zwischen ihnen. Jede Übergabe hat einen Eigentümer und kann nur einmal übernommen werden. Sie hält fest, wie weit der vorherige Agent gekommen ist, was gescheitert ist und was noch offen bleibt. Die Regel der einmaligen Übernahme ist wichtig: Zwei Agenten können nicht versehentlich dieselbe Arbeit aufgreifen.
Der zweite Baustein ist der Befehl `ai-memory run`. Er startet einen Agenten und transportiert die Sitzung selbst, nicht nur eine Zusammenfassung. Nach dem Beenden von Claude Code genügt etwa `ai-memory run codex`. Codex erhält dann den gemeinsamen Arbeitsablauf plus eine private, temporäre lokale Projektion des nativen Verlaufs, den Claude sehen konnte. Diese Projektion ergänzt genaue Details, die das Startpaket kürzen musste. Der entfernte Server erhält nur die Kennungen von Harness und Sitzung. Pfad und Inhalt lokaler Transkriptdateien gelangen nicht zu ihm. Der dritte Baustein ist das Datenformat. Die maßgebliche Quelle ist ein git-verwaltetes Wiki aus einfachen .md-Dateien. Man kann es mit grep durchsuchen, in Obsidian öffnen, von Hand bearbeiten oder mit rsync kopieren. Die Datenbank ist ein abgeleiteter Index, der sich jederzeit aus den Dateien neu aufbauen lässt. Es gibt keinen Vektorspeicher zu pflegen, und nichts steckt in einer Binärdatei fest. Der vierte Baustein ist die stille Erfassung. Lifecycle-Hooks zeichnen Prompts, Werkzeugaufrufe und Sitzungsgrenzen auf. Eine typisierte Datenschutzgrenze bereinigt die Daten vor dem Speichern, danach formt der Server daraus lesbare Seiten. Der Standardpfad macht null LLM-Aufrufe. Erfassung, Suche und Übergabe brauchen keinen API-Schlüssel. Außerdem verblasst das Gedächtnis nach einem einstellbaren, gestuften Plan, auch das ohne LLM.
Branchenwirkung
Das Projekt deckt vier praktische Szenarien ab. Das typischste ist der Werkzeugwechsel mitten in der Aufgabe. Sie arbeiten in Claude Code und stoßen auf ein Kontingent- oder Präferenzproblem. Sie machen in Codex weiter, und der nächste Agent erhält die Übergabenotiz direkt. Das zweite Szenario sind projektübergreifende Präferenzen. Ein kleines persönliches Profil hält fest, welchen Paketmanager, welches Testlayout und welche Architekturgewohnheiten Sie bevorzugen. Es wird zu Beginn einer Sitzung in einem neuen Repository geliefert. Seine Priorität liegt unter den eigenen Regeldateien jedes Repositorys, es dient also nur als Vorgabe. Für einen einzelnen Nutzer ist es standardmäßig aktiv. Auf einem gemeinsamen Server muss man es selbst einschalten, und es ist pro Person getrennt. Die Einzelheiten stehen in docs/cross-project-profile.md.
Das dritte Szenario betrifft mehrere Rechner. Das Gedächtnis liegt auf einem Server, den Sie selbst betreiben. Das kann derselbe Laptop sein, ein Heimserver oder ein anderer Host. Ein Projekt, das Sie am Desktop unterbrochen haben, läuft am Laptop mit demselben Wissen und denselben offenen Fragen weiter. Das vierte Szenario ist die Zusammenarbeit im Team. Alle zeigen auf denselben Server, und was die Sitzung einer Person lernt, können die Agenten aller anderen durchsuchen. Wissen wird pro Projekt geteilt, persönliche Übergaben bleiben privat. Mehrbenutzer-Authentifizierung, personenbezogene Zuordnung und Audit-Protokolle sind eingebaut. Sie gehören nicht zu einer kostenpflichtigen Stufe. Für die Branche bedeutet das eine Verschiebung der Zuständigkeit. Das Gedächtnis ist keine private Funktion eines Anbieters mehr, sondern Infrastruktur unter der Kontrolle des Engineering-Teams. Je mehr Agenten ein Team einsetzt, desto alltäglicher wird der Wechsel zwischen ihnen, und niemand möchte an einen Anbieter gebunden sein. Liegt die maßgebliche Quelle in Klartext und git, ist das Gedächtnis prüfbar, übertragbar und mit der vorhandenen Versionsverwaltung vereinbar. Das passt zu Teams, denen Nachvollziehbarkeit wichtig ist. Auch das Datenschutzdesign verdient Anerkennung. Die typisierte Grenze und die reine Übertragung von Kennungen im run-Modus zeigen Zurückhaltung, wie sie bei sensiblem Code-Kontext nötig ist.
Ausblick
Einige Punkte verlangen Sorgfalt. Die Abdeckung von mehr als zwanzig Harnesses bedeutet, dass man die Hooks und Sitzungsformate jedes Anbieters dauerhaft verfolgen muss. Der Pflegeaufwand für die Kompatibilität ist nicht gering. Im gemeinsamen Teammodus müssen die Nutzer selbst entscheiden, welche Inhalte durchsuchbar sein sollen und wie Berechtigungen verteilt werden. Die hier zusammengefasste Selbstbeschreibung zeigt zudem nur einen Teil des Funktionsumfangs. Details wie die Verfallsstrategie sollte man in der offiziellen Dokumentation prüfen.
Zwei Fragen verdienen als Nächstes Beobachtung. Die erste lautet, ob weitere Werkzeuge das Übergabeprotokoll als De-facto-Standard anerkennen. Die zweite betrifft den Standardpfad ohne LLM: Wie gut sucht er in großen Repositories, wenn die Suche in einfachen Dateien ohne Vektorspeicher skalieren muss? Für Einzelne und Teams, die bereits mehrere Coding-Agenten nutzen, bietet ai-memory eine konkrete und nachprüfbare Antwort auf das Problem der erneuten Erklärung. Den eigentlichen Wert wird der Alltag zeigen: wie oft ein zweiter Agent die Arbeit des ersten wirklich ohne neues Briefing fortsetzen kann.
Sources
FAQ
Was ist ai-memory?
ai-memory ist ein quelloffenes Rust-Projekt, das Coding-Agent-CLIs ein Langzeitgedächtnis gibt. Mehr als zwanzig Harnesses teilen einen gemeinsamen Speicher, und Übergaben zwischen Agenten verschiedener Hersteller laufen über ein typisiertes Protokoll mit Eigentümer, das nur einmal übernommen werden kann.
Warum ist ai-memory für Teams mit mehreren Coding-Agenten wichtig?
Der Speicher eines Agenten liegt meist auf einer Maschine in einem Tool, sodass Architektur und gescheiterte Versuche bei jedem Wechsel neu erklärt werden müssen. ai-memory legt den Speicher in einem git-verwalteten Markdown-Wiki ab, das sich prüfen, übertragen und im Team teilen lässt.
Worauf sollte man vor dem Einsatz von ai-memory achten?
Zu beachten ist der Wartungsaufwand, die Hooks und Sitzungsformate von mehr als zwanzig Harnesses aktuell zu halten. Beim Team-Sharing müssen Nutzer Suchumfang und Berechtigungen selbst steuern. Messwerte zur Suche des Standardpfads ohne LLM in großen Repositories nennt der Artikel nicht.