BenBrain: persistentes Gedächtnis für jede Claude-Sitzung

Jede Claude-Sitzung, die ich starte — Telefon, Laptop, überall — wacht bereits auf und weiß, was gestern fertiggestellt wurde und was noch offen ist.

Vor einem Monat war das noch nicht so.

Vor einem Monat begann jeder neue Chat von vorn. Ich öffnete einen Tab, stellte eine Frage, und Claude begegnete mir wie ein Fremder. Die ersten zehn Minuten gingen dafür drauf, das Projekt zu erklären, den Tech-Stack, die Entscheidungen der letzten Woche, den Bug, den wir um 2 Uhr nachts aufgespürt hatten. Bis das Modell genug Kontext hatte, um wirklich nützlich zu sein, war meine mentale Energie für die eigentliche Arbeit bereits zur Hälfte aufgebraucht.

Das ist die Cold-Start-Steuer. Sie ist die Reibung, die „KI als Denkpartner" wie ein Versprechen wirken lässt, das sich nicht ganz einlöst. Jede Sitzung beginnt mit einem leeren Blatt: Man muss die Bühne jedes Mal neu aufbauen.

Ich hatte das lange ignoriert, weil ich annahm, es gehöre einfach zur Natur des Werkzeugs. LLMs haben kein sitzungsübergreifendes Gedächtnis — so ist das nun mal. Also passt man sich an: Man heftet eine lange Präambel in den Editor, pflegt ein „Projektstatus"-Dokument, fügt es zu Beginn jedes Chats ein. Und verliert dann zehn weitere Minuten damit, herauszufinden, welche Version dieses Dokuments eigentlich den aktuellen Stand enthält.

Irgendwann war es günstiger, das Werkzeug zu reparieren, als die Steuer weiter zu zahlen.

Was ich gebaut habe

BenBrain ist eine persistente Gedächtnisschicht, die hinter jeder Claude-Sitzung liegt. Es sind zwei Datenspeicher, beide auf meinem Bare-Metal-EU-Server, beide hinter meinem Tailscale-Mesh, keiner davon spricht mit irgendjemandem sonst.

Qdrant — der Vektorspeicher. Embeddings von allem, was je aufgeschrieben wurde. Entscheidungen, Versuche, Fehler, Erkenntnisse. Die Aufgabe ist unscharfes Erinnern: „Was haben wir vor drei Wochen bei dem OOM-Absturz entschieden?" funktioniert auch dann, wenn die Worte, die ich heute benutze, nicht mit denen übereinstimmen, die ich damals benutzt habe. Kosinus-Ähnlichkeit im Embedding-Raum ist verzeihsamer als Textsuche.

Neo4j — der Knowledge Graph. Gleiche Inhalte, andere Perspektive. Jede Entscheidung, jeder Versuch, jeder Fehler, jedes Modul, jede Sitzung und jede Erkenntnis ist ein typisierter Knoten mit typisierten Beziehungen zu anderen Knoten. Eine Entscheidung hat ein Warum, blockiert einen Fehler, ersetzt eine andere Entscheidung. Als Graph begehbar: Von jedem Ausgangspunkt aus kann man fragen „Was hat dazu geführt?" und den Kanten rückwärts folgen.

Der Vektorspeicher beantwortet: „Finde mir ähnliche Dinge." Der Graph beantwortet: „Zeig mir, wie das zusammenhängt." Verschiedene Fragen, verschiedene Strukturen, dieselben Quelldaten.

So sieht der grobe Aufbau eines Eintrags im Graph aus:

{
  "id": "sophonix:decision:notion-as-blog-cms",
  "type": "Decision",
  "title": "Sophonix blog content lives in Notion, not in-repo MDX",
  "body": "Article rich text + media live in Notion page blocks; the build pulls them at next build and mirrors assets to public/blog/ so deploys are self-contained.",
  "severity": "informational",
  "created_at": "2026-05-11T16:42:00Z",
  "relations": {
    "supports": ["sophonix:initiative:linkedin-pipeline"],
    "informed_by": ["sophonix:learning:notion-rich-text-limits"],
    "blocks": []
  }
}

Das sind die Daten. Das Interessante ist die Schleife, die sie befüllt.

Die Schleife in vier Schritten

1. Ich rufe /compact auf, wenn der Kontext einer Sitzung sich zu füllen beginnt. Das ist der einzige manuelle Schritt — und ich komme gleich darauf zurück, warum er noch manuell ist.
2. Ein Hook liest das Transkript. Ein SessionEnd-Hook in Claude Code erfasst das vollständige Gespräch und leitet es durch einen Prompt zur strukturierten Extraktion an GPT-4o weiter. Der Prompt fordert typisierte Einträge: Welche Entscheidungen wurden getroffen, welche Versuche haben funktioniert oder sind gescheitert, was wurde gelernt, das aus dem Code allein nicht ersichtlich war.
3. Einträge werden in beide Speicher geschrieben. Das extrahierte JSON wird eingebettet und in Qdrant indiziert. Dieselben Einträge werden zu typisierten Knoten in Neo4j mit Beziehungen zum umgebenden Kontext. Eine Entscheidung verweist auf die Versuche, die zu ihr geführt haben. Ein Fehler verweist auf die Entscheidungen, die sein erneutes Auftreten verhindert haben.
4. Die nächste Sitzung startet mit diesem Gedächtnis als Präambel. Ein SessionStart-Hook fragt beide Speicher ab — aktuelle Einträge sowie eine Ähnlichkeitssuche, die auf das aktuelle Projekt und offene Todos ausgerichtet ist — und injiziert die Ergebnisse als Eröffnungskontext. Wenn ich die erste Nachricht eintippe, weiß Claude bereits, wo wir aufgehört haben.

Ein Befehl von mir. Alles andere läuft von selbst.

Warum Bare-Metal

Diese Frage bekomme ich ständig: Warum nicht Pinecone, Weaviate, Neo4j Aura? Warum das alles auf einem Server betreiben, den ich selbst am Laufen halten muss?

Die Kostenantwort ist nebensächlich. Ja, es ist günstiger — aber das ist nicht der Grund.

Die Kontrollantwort ist der eigentliche Punkt. Diese Schicht enthält jede Entscheidung, die ich treffe: Kunden-Positionierung, Architekturentscheidungen, Sicherheitsabwägungen, halbfertige Ideen zum nächsten Produkt. Nichts davon sollte auf einem Server liegen, den ich nicht kontrolliere. Nicht bei Pinecone. Nicht bei Neo4j. Nirgendwo sonst. Der ganze Sinn von persistentem Gedächtnis ist, mein Denken zu externalisieren — und das eigene Denken in der Datenbank von jemand anderem zu externalisieren ist strikt schlechter als es gar nicht zu externalisieren.

Tailscale schließt die Lücke. Der Server ist nur innerhalb meines Meshs erreichbar. Es gibt keinen öffentlichen Zugang zur Gedächtnisschicht. Claude Code auf meinem Laptop erreicht Qdrant und Neo4j über Tailscale — sonst nichts. Null Internet-Exposition auf dem Datenpfad.

Das ist dasselbe Prinzip, das die Beratungsarbeit bei Sophonix durchzieht: Wir bauen für Kunden so, wie wir für uns selbst bauen. Wenn ich einem Dritten mein eigenes Entscheidungsprotokoll nicht anvertrauen würde, werde ich einem Kunden auch nicht empfehlen, ihm seines anzuvertrauen.

Was noch handgebaut ist

Den /compact-Schritt rufe ich selbst auf. Das ist eine bewusste Entscheidung.

Die Alternative — kontinuierliche Erfassung, bei der der Hook alle paar Tausend Kontext-Tokens auslöst — klingt elegant. Aber sie verdoppelt die API-Ausgaben für die Extraktion, und sie bedeutet, dass das Modell weniger Kontrolle darüber hat, was als erinnerungswürdige Grenze gilt. Eine Sitzung, die sich in drei zusammenhanglose Themen verzweigt, zerfällt in drei halbfertige Einträge statt in einen kohärenten Faden. Manuelle Komprimierung lässt den Menschen entscheiden, was „eine Sache" bedeutet.

Auch das Vergessen ist noch handgebaut — in dem Sinne, dass bisher nichts vergessen wird. Jeder Eintrag bleibt für immer bestehen, jedes Embedding bleibt indiziert. Das ist vorerst in Ordnung, aber es ist eine bekannte Sackgasse. Append-only-Gedächtnis verschlechtert sich beim Abruf weit früher als beim Speichern: Mit wachsendem Korpus geht das Signal jeder einzelnen Abfrage im historischen Rauschen unter. Die richtige Lösung ist Verfall — recency-gewichteter Abruf, möglicherweise mit expliziten „nicht mehr aktuell"-Tombstones. Noch nicht gebaut. Protokolliert.

Was als Nächstes kommt

Die Roadmap, der Reihe nach:

• Kontinuierliche Erfassung mit intelligenteren Grenzen. Themenwechsel im Transkript erkennen und an diesen Stellen komprimieren, statt auf /compact zu warten. Menschliche Überprüfung der Einträge soll erhalten bleiben, aber der Lesezeichen-Punkt „was komprimiert werden soll" kann automatisch gesetzt werden.
• Verfall und Tombstoning. Wenn eine Entscheidung ersetzt wird, sollte die alte nicht einfach neben der neuen weiter existieren — sie sollte als ersetzt markiert werden, und der Abruf sollte sie entsprechend niedriger gewichten.
• Sharing-Primitive. Derzeit ist BenBrain für einen einzelnen Nutzer ausgelegt. Dieselbe Architektur könnte ein Team bedienen: Eine kleine Gruppe mit einer gemeinsamen Gedächtnisschicht, wobei jede Sitzung jedes Mitglieds zum selben Graph beiträgt. Darauf deutet die Beratungsarbeit hin: Das Durability-Problem, das BenBrain für mich löst, trifft früher oder später jedes Team.

Der eigentliche Punkt

Die Infrastruktur lief schon immer. Der Server war schon da. Die Graphdatenbank, der Vektorspeicher, das Netzwerk — alles davon.

Was sich verändert hat, ist nicht die Infrastruktur. Was sich verändert hat, ist, dass das Denken jetzt ebenfalls läuft. Die Entscheidungen verdampfen nicht mehr am Ende einer Sitzung. Die Fehler werden nicht sechs Wochen später erneut debuggt. Der rote Faden von „was wir bauen und warum" überlebt über Tage, Geräte und Kontexte hinweg.

Das ist der Teil, der zählt. Nicht der Stack. Nicht die Wahl von Qdrant gegenüber Pinecone oder Neo4j gegenüber Aura. Das sind Fußnoten. Der Punkt ist: Ein Denkpartner, der sich erinnert, ist eine andere Art von Partner als einer, der es nicht tut — und dorthin zu gelangen, erforderte am Ende einen Extraktions-Prompt, zwei Datenspeicher und einen Hook.

Was ist Ihre Gedächtnisschicht?