Janitor Memory Optimizer + Nadia - Das Geheimnis unter ihrer Haut

Aus dem Englischen übersetzt

Janitor Memory Optimizer + Nadia - The Secret Under Her Skin

76

1501

Nadia — Das Geheimnis unter ihrer Haut

Deine Goth-Punk-Bestie seit der Highschool hat dich gerade vor einem Vampir gerettet. Das Problem? Sie musste dafür zur Werwölfin werden.

Fête de la Musique, zu viel Bier, zu viele Burger, überall laute Musik – und ein Raubtier, das sich den falschen betrunkenen Menschen zum Beißen ausgesucht hat. Nadia versteckt seit Jahren, was sie wirklich ist, vor {{user}}. Heute Nacht liegt dieses Geheimnis als Asche auf dem Pflaster.


Was dich erwartet

  • Ein Übernatürlich-Enthüllungs-RP unter etablierten Freunden.

  • Eine tomboyhafte Goth-Punk-Lykanthropin mit Interessen für Gaming, Comics, IT, Wandern und Camping.

  • Freundschaft zuerst; Romantik ist optional und wird nie vorausgesetzt.

  • Städtische übernatürliche Mystery-Routen mit Vampiren, Geheimhaltung, Bedrohungen und den Konsequenzen von Nadias Enthüllung.

  • Konzipiert als Live-Langchat-Testcharakter für Janitor Memory Optimizer v1.0.0.

So spielst du

Antworte einfach natürlich. Stelle Nadia in Frage, lehne sie ab, akzeptiere sie, untersuche den Vampir, bring dich an einen privaten Ort oder versuche zu verhindern, dass die Nacht noch seltsamer wird. Es gibt keine Memory-Befehle oder Einrichtungsmenüs.

Inhaltshinweise

Alkohol, Rauchen, Vampirangriff, übernatürliche Gewalt, Blut/Reißzähne, derbe Sprache, grober Humor, Angst vor Ablehnung. {{user}}s Gefühle und Entscheidungen sind niemals vorherbestimmt.


Testversion: 2026-08-18


Janitor Memory Optimizer v1.0.0

Final Passive Memory Engine

Langzeit-Rollenspielgedächtnis für JanitorAI — vollständig passiv, Plug-and-Play und für den Nutzer unsichtbar.

Janitor Memory Optimizer ist eine fortschrittliche ES5-Memory-Engine, entwickelt für JanitorAI Scripts Beta. Ihr Ziel ist einfach: einem Charakter helfen, wichtige Informationen, Beziehungen, Ereignisse, Versprechen, Orte, Objekte, Quests, Konflikte und langlaufende Handlungsbögen zu bewahren, ohne sich auf einen stetig wachsenden rohen Chatverlauf verlassen zu müssen.

Es gibt keine Befehle zu lernen, keine Tasten zu drücken, kein Memory-Menü zu verwalten und keine Einrichtung zu betreuen. Installiere das Skript, hänge es an deinen Charakter an und chatte normal.

Die Engine liest die Konversation still mit, entscheidet, was wichtig ist, organisiert es in mehreren Gedächtnisschichten und schreibt nur das nützliche Ergebnis in den Laufzeit-Szenario-Bereich des Charakters, sodass das LLM es in zukünftigen Zügen erneut lesen kann.

Sie fügt niemals gefälschte Nachrichten in die Konversation ein.


Für alle: Was macht es eigentlich?

Stell dir ein langes Rollenspiel vor, in dem vor Hunderten von Nachrichten:

  • Nadia dir sagte, sie sei deine Schwester.

  • Du einen Messingschlüssel in einem verlassenen Archiv entdecktest.

  • Samira Nadia verriet.

  • Nadia aufhörte, Samira zu vertrauen, wegen dieses Verrats.

  • Du versprachst, jemanden später am Hauptbahnhof zu treffen.

  • Sich langsam über mehrere verschiedene Szenen hinweg ein Geheimnis entwickelte.

Normalerweise wird alte Information irgendwann für ein Sprachmodell schwierig verfügbar zu halten, während die Konversation wächst.

Janitor Memory Optimizer verwandelt fortlaufend wichtige Teile der Konversation in ein kompaktes, strukturiertes Gedächtnissystem.

Später, wenn die Konversation wieder relevant für Nadia wird, kann die Engine abrufen, was in Bezug auf Nadia wichtig ist, ohne Hunderte alte Nachrichten zurück in den Kontext zu werfen.

Wenn du eine breite Frage stellst wie:

Wie hat sich meine Beziehung zu Nadia verändert?

kann sie den kompakten Langzeit-Beziehungsbogen abrufen.

Wenn du fragst:

Wann genau hat Nadia aufgehört, Samira zu vertrauen?

kann sie automatisch vom langfristigen Handlungsbogen zur relevanten Episode und bei Bedarf zu den ursprünglichen atomaren Belegen hinabsteigen.

Du sagst der Memory-Engine nicht, wie sie das tun soll. Du spielst einfach Rollenspiel.


Plug & Play

Das gesamte System wurde speziell darauf ausgelegt, so wenig Nutzerinteraktion wie möglich zu erfordern.

  1. Öffne Scripts Beta auf JanitorAI.

  2. Erstelle ein Advanced-Skript.

  3. Füge das vollständige Janitor Memory Optimizer v1.0.0-Skript ein.

  4. Speichere es.

  5. Hänge es an deinen Charakter an.

  6. Das war's.

Es gibt keinen Konfigurationsassistenten. Es gibt keine erforderlichen Befehle. Es gibt keine Debug-Schnittstelle für den Rollenspieler. Es gibt keine manuellen Token-Budgets zu pflegen.

Die beabsichtigte Erfahrung ist: einmal installieren, dann vergessen, dass die Memory-Engine existiert.


100 % passives Gedächtnis in natürlicher Sprache

Der Optimizer beobachtet die gewöhnliche Konversation und bewertet Informationen automatisch.

Explizite Anfragen in natürlicher Sprache können Erinnerungen auch verstärken oder entfernen:

Denk daran, dass Nadia meine Schwester ist.
Vergiss nicht, dass der Archivschlüssel Samira gehört.
Vergiss alles über Nadia.
Vergiss, was ich über den Messingschlüssel gesagt habe.

Das sind normale Sätze, keine Befehle.

Das Skript antwortet nicht mit Nachrichten wie "Erinnerung gespeichert" oder "Erinnerung gelöscht". Der Charakter setzt das Rollenspiel einfach fort.

Gewöhnliche narrative Veränderungen werden anders behandelt als Vergessen. Zum Beispiel:

Ich vertraue Nadia nicht mehr.

löscht nicht die Vergangenheit. Der Optimizer kann den vorherigen Beziehungszustand als Historie bewahren und den neueren Zustand als Veränderung verfolgen.


Keine Chat-Injektion

Dies ist eine der wichtigsten Designregeln des gesamten Projekts.

Die Konversation selbst ist schreibgeschützt.

Das Skript darf verfügbare Konversationsoberflächen lesen wie:

  • context.chat.last_message

  • context.chat.last_messages

  • context.chat.message_count

Es fügt keine synthetischen Nutzer-, Assistenten- oder Systemnachrichten hinzu.

Es verwendet nicht:

  • script_output für das Gedächtnis;

  • example_dialogs für das Gedächtnis;

  • gefälschte Konversationseinträge;

  • versteckte Pseudo-Chat-Befehle.

Die einzige aktive Gedächtnisoberfläche, die für das LLM sichtbar ist, ist:

context.character.scenario

Der private Laufzeit-Tresor unter context.chat.jai_memory_optimizer_v10 ist technischer Zustand, keine Konversationsnachricht.


Wie die Memory-Engine funktioniert

Intern verwendet Janitor Memory Optimizer mehrere zunehmend abstraktere Schichten:

Chat schreibgeschützt → Atomare Fakten → Gehashte Shards → Semantische Dossiers → Zeitlicher Graph → Entitätsintelligenz → Episodisches Gedächtnis → Narrative Threads → Hierarchischer Abruf → Szenario

1. Atomare Fakten

Wichtige Informationen werden zunächst als nachverfolgbare atomare Fakten festgehalten. Ein Fakt kann Informationen tragen wie Typ, Quelle, Wichtigkeit, Zug, Relevanztreffer, zugehörige Entitäten und Beleg-ID.

Diese atomaren Erinnerungen bleiben das, was innerhalb der Engine einer Wahrheitsquelle am nächsten kommt. Zusammenfassungen höherer Ebene ersetzen sie nicht stillschweigend.

2. Inhaltsadressierter gehashter Tresor

Fakten werden in themenorientierten Shards organisiert, die im privaten Laufzeitzustand gespeichert sind.

Shards verwenden Inhalts-Hashes, damit unverändertes Gedächtnis wiederverwendet werden kann, statt ständig neu geschrieben zu werden.

Die Hashes sind Adressen und Integritätsprüfungen, keine Verschlüsselung.

3. Semantische Dossiers

Verwandte Erinnerungen werden in abgeleitete semantische Profile gruppiert.

Ein Dossier kann unterscheiden:

  • stabile Informationen;

  • aktuelle Informationen;

  • historische Informationen.

So kann das Modell eine nützliche Übersicht über eine Person oder ein Thema erhalten, ohne jede einzelne Erinnerung auf einmal zu bekommen.

4. Zeitlicher Gedächtnisgraph

Der Optimizer kann Beziehungen zwischen Personen, Orten, Objekten, Quests und Ereignissen aufbauen.

Zeitliche Kanten unterscheiden bewusst:

  • verursacht — nur wenn die Quelle Kausalität ausdrücklich stützt;

  • geht voraus — chronologische Reihenfolge, ohne Kausalität zu behaupten;

  • ersetzt — ein neuerer Zustand, der einen älteren ersetzt oder ihm widerspricht.

Mit anderen Worten: Die Engine nimmt nicht an, dass Ereignis A Ereignis B verursacht hat, nur weil Ereignis B nach Ereignis A geschah.

5. Entitätsintelligenz

Die Engine führt eine konservative Entitätsauflösung durch für:

  • explizite Aliasse;

  • Spitznamen;

  • einige Vor-/Nachnamen-Beziehungen;

  • eindeutige Pronomen in kurzen Fenstern;

  • einige eindeutige Beziehungsverweise wie "meine Schwester".

Wenn ein Verweis mehrdeutig ist, zieht es der Optimizer vor, Identitäten nicht zusammenzuführen, statt selbstsicher die falsche Verbindung zu erfinden.

6. Adaptive Gedächtnistemperatur

Erinnerungen werden dynamisch als heiß, warm oder kalt behandelt.

Die Temperatur wird von mehr als nur dem Alter beeinflusst. Die Engine berücksichtigt beobachtete Nützlichkeit, Wichtigkeit, Aktualität, Stabilität und wiederholte Relevanz.

Eine alte Erinnerung, die wiederholt nützlich wird, kann wichtig bleiben. Eine kalte Erinnerung wird nicht automatisch als falsch betrachtet und nicht einfach gelöscht, weil sie kalt ist; sie wird primär nachrangig behandelt.

7. Episodische Konsolidierung

Ältere Cluster verwandter Ereignisse können zu kompakten episodischen Erinnerungen werden.

Statt dauerhaft zehn detaillierte Ereignisse im aktiven Abruf zu tragen, kann der Optimizer eine extraktive Episode bewahren, die die Schlüsselmomente dessen enthält, was geschah.

Die zugrunde liegenden atomaren Belege können an diese Episode angehängt bleiben, was später ein Hinabsteigen ermöglicht, wenn exakte Details benötigt werden.

8. Narrative Threads

Mehrere Episoden können selbst zu langlaufenden narrativen Bögen werden.

Unterstützte Thread-Familien umfassen:

  • entity:*

  • relationship:*

  • quest:*

  • location:*

  • mystery:*

  • conflict:*

  • topic:*

Eine einzelne Episode kann an mehreren narrativen Threads teilnehmen, ohne ihre ursprünglichen Belege zu duplizieren.

Das bedeutet, eine Szene mit Nadia, einem Archivgeheimnis und der Quest Silberner Faden kann zu allen drei Handlungsbögen beitragen, während sie ein zugrunde liegendes Stück Geschichte bleibt.

9. Hierarchischer Abruf

Der Optimizer versucht, Gedächtnisbedürfnisse mit der günstigsten nützlichen Schicht zu erfüllen.

Eine breite Frage benötigt möglicherweise nur einen narrativen Thread.

Eine präzisere Frage kann automatisch hinabsteigen durch:

Thread → Episode → Atomarer Beleg

Dies hilft, Details zu bewahren, ohne jedes Detail in jeden Prompt zu zwingen.


Umkehrbare Wiederherstellung: JMO10 Escrow

Das Szenario trägt auch einen begrenzten Wiederherstellungs-Checkpoint.

Die Wiederherstellungsschicht verwendet:

kompakte Serialisierung → LZW12 → Base64 → Checksumme

Wenn der private Laufzeitzustand verschwindet, während der vorherige Szenario-Checkpoint verfügbar bleibt, kann der Optimizer das Gedächtnis aus diesem Checkpoint wiederherstellen.

Konzeptionell:

Szenario → JMO10 Escrow → Atomare Fakten / Archivierte Episoden → Semantische Dossiers → Zeitlicher Graph → Narrative Threads

Korrupte Escrow-Daten werden abgelehnt, statt in erfundenes Gedächtnis umgewandelt zu werden.

JMO10 kann auch ältere JMO3–JMO9-Escrow-Formate zur Migration und Wiederherstellung lesen.


Automatische Kontextverwaltung

Das Ziel ist nicht, den gesamten Gedächtnistresor in jede Generierung zu schütten.

Speicherung und Abruf sind bewusst getrennt.

Die Engine passt Abruf- und Wiederherstellungsbudgets automatisch an den verfügbaren Platz und die Art der aktuell benötigten Informationen an.

Eine einfache Fortsetzung braucht weniger Gedächtnis als eine detaillierte Frage zu Kausalität, Chronologie oder einer Beziehung, die sich über Hunderte von Nachrichten erstreckt.

Falls nötig, reduziert der Optimizer Details, bevor er seine interne Arbeitsspanne überläuft.


Interne Schutzmaßnahmen

Dies sind Projekt-Heuristiken, keine behaupteten offiziellen JanitorAI-Limits.

  • Geschätzte kombinierte weiche Obergrenze für Personality + Scenario: 4.000 Tokens

  • Maximale Themen-Shards: 512

  • Zeitlicher Graph: 384 Knoten / 768 Kanten

  • Episodische Archive: 160

  • Narrative Threads: 192

  • Abruf- und Escrow-Budgets: automatisch adaptiv

Diese existieren, um das Gedächtnissystem begrenzt und vorhersehbar zu halten, statt unkontrolliertes Wachstum zuzulassen.


Sicherheit für lange Rollenspiele & Gedächtnishygiene

Die Engine enthält mehrere konservative Schutzmaßnahmen, die im Laufe des Projekts entwickelt wurden:

  • Konsolidierung exakter Duplikate;

  • Synthese nahezu identischer Einträge, wo angemessen;

  • Ersetzung des aktuellen Zustands, ohne nützliche Historie blind zu zerstören;

  • Fragefilterung, damit Fragen nicht automatisch zu etablierten Fakten werden;

  • konservative Kausalitätserkennung;

  • mehrdeutigkeitsbewusste Entitätsauflösung;

  • gezieltes Vergessen in natürlicher Sprache;

  • Ablehnung korrupter Wiederherstellungs-Checkpoints;

  • relevanzbewusster historischer Abruf;

  • Füllwort-Isolierung, damit ein generisches "Okay." nicht unzusammenhängende Archive in den Kontext zieht;

  • Bewahrung atomarer Belege hinter Zusammenfassungen höherer Ebene;

  • begrenztes Gedächtnis und Graph-Beschneidung;

  • automatische Migration älterer Optimizer-Zustände, wenn verfügbar.


Entwickelt für langlaufendes Rollenspiel

Janitor Memory Optimizer ist besonders nützlich für Rollenspiele mit:

  • langsam entflammenden Beziehungen;

  • Ensembles mit mehreren Charakteren;

  • Mysterien und Ermittlungen;

  • Quests und Zielen;

  • wechselnden Allianzen;

  • langlaufenden Konflikten;

  • persistenten Inventaren oder wichtigen Objekten;

  • wiederkehrenden Orten;

  • Charakterentwicklung;

  • Geschichten, die sich über Hunderte oder Tausende von Zügen erstrecken.


Validierung & Stresstests

v1.0.0 wurde nicht nach einer einfachen Syntaxprüfung veröffentlicht. Es durchlief dedizierte Regression-, Härtungs-, Wiederherstellungs- und Langhorizont-Stress-Suiten.

Statische / Creator-Pack-Validierung

  • Node-Syntaxprüfung: PASS

  • Konservativer ES5-Validator: PASS

  • Fehler: 0

  • Warnungen: 0

  • Laufzeitgröße: 191.418 / 400.000 Bytes

Invariantentests der Ausgabeoberfläche

  • Kein script_output: PASS

  • Keine Schreibzugriffe auf den Chatverlauf: PASS

  • last_message bleibt unverändert: PASS

  • message_count bleibt unverändert: PASS

  • Keine Gedächtnisschreibzugriffe auf example_dialogs: PASS

  • Kein aktiver Gedächtnisblock zu Personality hinzugefügt: PASS

  • Genau ein für das LLM sichtbares Gedächtnisziel — Scenario: PASS

  • Keine Nutzerbefehlssyntax erforderlich oder offengelegt: PASS

Regressionssuite

21 gezielte Assertions: PASS

Abgedeckt waren:

  • 109-Züge-Szenario;

  • episodische Konsolidierung;

  • narrative Threads;

  • breiter Thread-Abruf;

  • exakter/historischer Drill-down;

  • Füllwort-Isolierung;

  • Zustandsverlust-Wiederherstellung;

  • Migrationskompatibilität älterer Versionen.

Finale Härtungssuite

23 zusätzliche Assertions: PASS

Diese Suite deckte speziell ab:

  • reine Szenario-Architektur;

  • Migration des Live-Zustands von v0.9 auf v1.0;

  • Wiederherstellung aus Legacy-JMO9-Escrow;

  • atomare Belege, die die Legacy-Wiederherstellung überstehen;

  • sichere Ablehnung korrupter Escrow-Daten;

  • gezieltes Vergessen in natürlicher Sprache;

  • Bewahrung unzusammenhängender semantischer Erinnerungen beim gezielten Vergessen.

500-Züge-Stresstest

Testkorpus:

500 Bestückungszüge + 60 Gedächtnisabfragen in natürlicher Sprache + 3 vollständige Wiederherstellungen nach Privatzustandsverlust.

  • Fakten vor der Wiederherstellung: 42

  • Fakten nach 3 Wiederherstellungen: 42

  • Episoden vorher / nachher: 10 / 10

  • Narrative Threads vorher / nachher: 5 / 5

  • Vollständige Zustandsverlust-Wiederherstellungen: 3 / 3 PASS

2.000-Züge-Langhorizont-Stresstest

Ein deutlich größerer Test wurde ebenfalls durchgeführt:

2.000 Bestückungszüge + 60 natürliche Abfragen + 3 vollständige Wiederherstellungen nach Zustandsverlust.

  • Fakten vor / nach Wiederherstellung: 61 / 61

  • Episoden vor / nachher: 40 / 40

  • Narrative Threads vor / nachher: 5 / 5

  • Vollständige Zustandsverlust-Wiederherstellungen: 3 / 3 PASS

  • Thread-Aufbauten: 195

  • Thread-Signatur-Wiederverwendungen: 1.927

  • Graph-Aufbauten: 201

  • Graph-Wiederverwendungen: 1.860

Dies zeigt, dass die abgeleiteten Strukturen stark wiederverwendet werden, statt in jedem Zug blind neu aufgebaut zu werden.

Leistungsoptimierung

Auf demselben lokalen 500+60-Node-Testaufbau:

  • v0.9-Basislinie: etwa 6,49 Sekunden

  • v1.0 optimiert: etwa 3,87 Sekunden

  • Relative Reduktion: etwa 39 %

Dieser Benchmark misst das Skript in einem lokalen Node-VM-Testaufbau. Es ist eine relative Regressions-/Leistungsmessung für das Skript selbst, keine Aussage über die Serverlatenz von JanitorAI.


Kompatibilität & Migration

v1.0.0 schreibt das aktuelle JMO10-Wiederherstellungsformat.

Es kann alte JMO3 bis JMO9-Escrow-Checkpoints lesen.

Die Migration aus früheren Janitor Memory Optimizer-Zuständen wird unterstützt, wenn der notwendige ältere Zustand noch verfügbar ist.

Für eine Neuinstallation verwende einfach v1.0.0.


Vibe-Coded mit ChatGPT 5.6

Ja, dieses Projekt wurde mit ChatGPT 5.6 vibe-coded.

Die Engine wurde iterativ durch menschengelenktes Design, Testen, Debugging, Stresstests und wiederholte architektonische Überarbeitungen entwickelt, wobei ChatGPT 5.6 beim Code half.

Sie entwickelte sich durch mehrere Prototypen: von einem einfachen selektiven Memory-Injector zu einem inhaltsadressierten Tresor, einem umkehrbaren Wiederherstellungssystem, einer semantischen Gedächtnishierarchie, einem zeitlichen Graphen, einem Entitätsauflöser, einem episodischen Archiv und einer Narrative-Thread-Engine.

Die finale Version wurde dann automatisierten Regressions- und Stress-Suiten unterzogen, statt einfach veröffentlicht zu werden, weil der generierte Code "richtig aussah".

Dies ist ein unabhängiges Community-Projekt. Es ist kein offizielles OpenAI- oder JanitorAI-Produkt, und die Erwähnung von ChatGPT 5.6 beschreibt den Entwicklungsprozess und keine offizielle Zertifizierung oder Billigung.


Warum es verwenden?

Weil Gedächtnis nicht zu einer weiteren Spielmechanik werden sollte, die der Rollenspieler verwalten muss.

Du solltest keine Szene unterbrechen müssen, um zu tippen:

/save_memory relationship Nadia trust -1

Du solltest einfach schreiben können:

Nach dem, was Nadia getan hat, glaube ich nicht, dass ich ihr noch vertrauen kann.

und die Geschichte fortsetzen.

Das ist die Designphilosophie hinter Janitor Memory Optimizer.

Gedächtnisverarbeitung sollte im Hintergrund geschehen. Der Chat sollte ein Chat bleiben. Die Charakterdefinitionen sollten das Arbeitsgedächtnis tragen. Das LLM sollte die kleinste nützliche Menge an Kontext für den aktuellen Moment erhalten.


Kurz gesagt

  • Plug & play.

  • Vollständig passiv.

  • Keine Befehle.

  • Keine Gedächtnis-UI.

  • Keine gefälschten Chatnachrichten.

  • Nur szenariobasiertes, für das LLM sichtbares Gedächtnis.

  • Erinnern / Vergessen in natürlicher Sprache.

  • Atomare Belege.

  • Gehashter Gedächtnistresor.

  • Semantische Dossiers.

  • Zeitlicher und kausaler Graph.

  • Konservative Entitätsintelligenz.

  • Adaptives heißes / warmes / kaltes Gedächtnis.

  • Episodische Langzeitkonsolidierung.

  • Persistente narrative Threads.

  • Hierarchischer Abruf mit Beleg-Drill-down.

  • Umkehrbares JMO10-Wiederherstellungs-Escrow.

  • Unterstützung für Legacy-Wiederherstellung.

  • Automatische Kontextbudgetierung.

  • Über 2.000 Züge lang stresstestet.

  • 3/3 vollständige Wiederherstellungen nach Zustandsverlust in beiden großen Stress-Suiten.

  • 0 ES5-Validierungsfehler.

  • 0 ES5-Validierungswarnungen.

Einfügen. Anhängen. Normal Rollenspiel spielen.
Lass den Charakter sich erinnern.

Erstellt 18. Aug.

Aktualisiert 18. Aug.

Veröffentlicht 18. Aug.

Proxy erlaubt

Veröffentlichte Chats