Memmy: ein lokaler Memory-Hub, der mehrere Coding-Agents auf denselben Kontext bringt

Das Problem: jeder Agent kennt ein anderes Stück von dir

Wer heute mit Claude Code arbeitet, dann zu Codex wechselt und zwischendurch Cursor öffnet, erklärt seinen Projektkontext mehrfach. Jeder Agent hat seinen eigenen Verlauf, seine eigene Sitzung, sein eigenes Gedächtnis. Das README von Memmy formuliert das Versprechen so: die Agents sollen sich an dieselbe Person erinnern. Der Anspruch ist also nicht, einen einzelnen Assistenten klüger zu machen, sondern eine gemeinsame Kontextschicht unter mehreren Werkzeugen zu legen. Angesprochen sind Entwickler, die mehrere Coding-Agents parallel nutzen und den Wechsel als Kontextverlust erleben. Das ist ein konkretes, wiederkehrendes Problem, kein Marketing-Szenario.

Lokaler Dienst statt Cloud-Speicher: die Architektur

Memmy besteht aus zwei Bestandteilen, die als systemd-User-Services laufen. Der Memory-Service hört laut README auf http://127.0.0.1:18960, das Gateway auf Port 18990 und stellt eine OpenAI-kompatible API bereit. Die Agents sprechen den Memory-Service über eine CLI namens memmy-memory an, die Befehle wie init, health, search, add und get kennt. Damit ein Agent tatsächlich mitschreibt, muss der Nutzer memmy-memory init oder memmy-memory init --agent <agent> ausführen; der Installer allein richtet den Dienst ein, ohne Codex, Claude Code oder Cursor anzufassen. Diese Trennung ist bewusst: Infrastruktur und Agent-Integration sind zwei Schritte. Nach außen ist das Angebot damit ein lokal gehosteter Kontextspeicher mit HTTP-Schnittstelle, nicht ein Plugin, das sich in einen bestimmten Editor einklinkt.

Installation über den Installer: was tatsächlich passiert

Der dokumentierte Weg für Linux x64 oder arm64 setzt Node.js 22 oder neuer und eine verfügbare systemd-User-Session voraus. Dann genügen zwei Zeilen: curl -fsSL https://raw.githubusercontent.com/MemTensor/memmy-agent/main/scripts/install.sh | bash und anschließend memmy. Der Installer aktiviert den Memory-Service sofort als memmy-memory.service. Der erste bloße Aufruf von memmy öffnet bei Bedarf den Modell-Assistenten, aktiviert memmy-gateway.service, wartet auf dessen Bereitschaft und startet die TUI. Beide Dienste sind an localhost gebunden und bleiben nach dem Schließen des Terminals aktiv. Sie starten bei späteren Logins erneut, allerdings aktiviert der Installer kein linger. Wer aus dem Quellcode baut, umgeht diese Diensteverwaltung, weil nur der Installer-Launcher sie auslöst. Die Konfiguration liegt in ~/.memmy/config.yaml, ein minimales BYOK-Beispiel nennt agents.defaults mit model, provider und timezone sowie providers.openai.apiKey, der auf ${OPENAI_API_KEY} verweist. Vor jedem Start oder Reconnect schreibt memmy die Datei ~/.memmy/systemd/gateway.env mit Modus 0600 neu, gefüllt mit referenzierten Umgebungsvariablen, Provider-Credentials und dem PATH des Terminals.

Der Preis der Bequemlichkeit: systemd, Linux und eine Lücke im README

Die Installationsanleitung ist auf Linux mit systemd-User-Session zugeschnitten. Wer macOS, Windows oder einen Container ohne systemd betreibt, findet im vorliegenden Material keinen gleichwertigen Weg über den Installer. Dort bleibt nur der Quellcode-Build: git clone, cp .env.example .env, npm install, npm run build, bash scripts/dev-start.sh. Das ist eine reale Einschränkung, keine Formalie, denn die Diensteverwaltung ist der Kern des Installer-Versprechens. Ein zweiter Punkt: Der Installer schreibt Credentials in eine Datei mit Modus 0600. Das ist korrekt, aber es bedeutet, dass Provider-Schlüssel im Klartext auf der Platte liegen und bei jeder Änderung neu geschrieben werden. Wer seine Secrets zentral verwaltet, muss diesen Pfad in seine Überlegungen einbeziehen. Und der Hinweis, dass memmy-memory init die Agents verändert, ist wichtig: Der Installer allein tut es nicht, der Init-Befehl schon.

Zwei Betriebsmodi: Trial-Tokens und BYOK

Memmy bietet zwei Wege, Modelle anzubinden. Wer sich registriert, erhält Trial-Tokens für Agent-Aufgaben; der Kontostand wird in der App angezeigt. Wenn die Tokens aufgebraucht sind, wechselt man laut README in den BYOK-Modus und nutzt die eigene Modell-API. Das ist ein klarer Schnitt: Der Memory-Service bleibt lokal, aber die Modellaufrufe laufen im Trial-Modus über die Infrastruktur des Anbieters. Für Teams, die keine externen Modellaufrufe zulassen, ist damit nur der BYOK-Pfad relevant. Die Konfiguration dafür ist knapp dokumentiert: ein Provider-Block, ein Defaults-Block, fertig. Wer mehrere Provider parallel betreiben will, muss die Struktur aus der Getting-Started-Anleitung selbst erschließen; das README zeigt nur ein Beispiel mit OpenAI.

Die CLI als eigentliche Schnittstelle

Interessanter als die Desktop-App ist die Kommandozeile, weil sie sich skripten lässt. memmy onboard konfiguriert Modelle, Provider, Gateway, Memory und Tools interaktiv, memmy onboard --defaults legt ~/.memmy/config.yaml und den Workspace mit Vorgabewerten an. memmy status prüft Konfiguration, Modell und Provider. memmy agent --message "Introduce the current workspace" führt eine einzelne Aufgabe aus. memmy serve startet die OpenAI-kompatible API auf Port 18990. Für den Memory-Zugriff aus Skripten und Debugging dienen die bereits genannten memmy-memory-Befehle, die sich über --url, --token, --config, --source und --user-id an einen anderen Dienst oder Namespace richten lassen. Diese Flags sind der eigentliche Hebel für Mehrbenutzer- oder Mehrprojekt-Setups, und sie sind im README nur als Aufzählung vorhanden, nicht erklärt.

Alternative: MCP-Server pro Agent

Der naheliegende Vergleich ist ein einzelner MCP-Server, den jeder Agent separat einbindet. Der Unterschied liegt in der Zuständigkeit: Ein MCP-Server stellt Werkzeuge bereit, aber jeder Agent hält seinen eigenen Verlauf und seine eigene Sitzung. Memmy zieht die Speicherung aus den Agents heraus in einen gemeinsamen Dienst auf 127.0.0.1:18960 und lässt die Agents nur noch lesen und schreiben. Das ist der architektonische Kern des Projekts. Der Preis dafür ist ein zusätzlicher Prozess, der laufen muss, bevor irgendein Agent sinnvoll arbeitet. Ein reiner MCP-Ansatz hat diesen Zustand nicht, dafür teilt er den Kontext nicht zwischen Werkzeugen. Wer nur einen einzigen Agent nutzt, gewinnt durch Memmy wenig.

Wartung, Lizenz und was vor dem Einsatz zu klären ist

Die Release-Kadenz ist im vorliegenden Material dicht: v1.1.2, v1.1.3 und v1.1.4 innerhalb von fünf Tagen im September 2026. Das spricht für aktive Entwicklung, bedeutet aber auch, dass sich CLI-Flächen und Konfigurationsschlüssel bewegen können. Wer Memmy produktiv einsetzt, sollte die Version pinnen und die Release Notes vor jedem Upgrade lesen. Die Lizenz ist MIT, was kommerzielle Nutzung und Modifikation erlaubt, solange Copyright- und Lizenzhinweis erhalten bleiben. Das ist keine Rechtsberatung, aber die praktische Konsequenz: Der Code darf weiterverwendet werden, die Verantwortung für Betrieb und Datenschutz bleibt beim Betreiber. Zu klären ist vor dem Rollout, ob der Memory-Service ausschließlich auf 127.0.0.1 lauscht, welche Daten im BYOK-Modus an welchen Provider gehen und ob die Agents, die memmy-memory init anfasst, danach noch ohne Memmy funktionieren.

Redaktionelles Fazit

Wer regelmäßig zwischen Claude Code, Codex und Cursor wechselt und den Projektkontext nicht jedes Mal neu erklären will, findet in Memmy eine lokale, MIT-lizenzierte Lösung mit nachvollziehbaren Befehlen und klarer Trennung zwischen Memory-Service und Gateway. Wer keinen systemd-User-Session auf seiner Maschine hat oder keinen Node.js-22-Stack betreiben will, sollte den Installer nicht blind ausführen: Der Aufruf memmy-memory health und ein Blick auf systemctl --user status memmy-memory.service zeigen zuerst, ob der Dienst überhaupt startet. Vor dem produktiven Einsatz ist zu prüfen, ob der Memory-Service auf 127.0.0.1:18960 beschränkt bleibt und welche Daten der BYOK-Modus mit welchem Provider teilt.

Offizielle Quellen

1. License: MIT
2. MemTensor/memmy-agent on GitHub
3. Project website
4. README
5. Releases