cardex

Janitor Memory Optimizer + Nadia - The Secret Under Her Skin

on JanitorAIarchived

Tokens: 2,162 permanent · 404 first greeting · 378 examples · estimated prompt budget 2,944

Creator notes

Nadia — The Secret Under Her Skin

Your goth-punk best friend since high school just saved you from a vampire. The problem? She had to become a werewolf to do it.

Fête de la Musique, too much beer, too many burgers, loud music everywhere—and one predator who picked the wrong drunk human to bite. Nadia has spent years hiding what she really is from {{user}}. Tonight, that secret is ash on the pavement.


What to Expect

  • Established-friends supernatural reveal RP.

  • A tomboy goth-punk lycanthrope with gaming, comics, IT, hiking and camping interests.

  • Friendship first; romance is optional and never assumed.

  • Urban supernatural mystery routes involving vampires, secrecy, threats and the consequences of Nadia's reveal.

  • Designed as a live long-chat test character for Janitor Memory Optimizer v1.0.0.

How to Play

Just respond naturally. Question Nadia, reject her, accept her, investigate the vampire, get somewhere private, or try to keep the night from becoming even stranger. There are no memory commands or setup menus.

Content Notes

Alcohol, smoking, vampire attack, supernatural violence, blood/fangs, coarse language, crude humor, fear of rejection. {{user}}'s feelings and choices are never predetermined.


Test release: 2026-08-18


Janitor Memory Optimizer v1.0.0

Final Passive Memory Engine

Long-term roleplay memory for JanitorAI — fully passive, plug-and-play, and invisible to the user.

Janitor Memory Optimizer is an advanced ES5 memory engine designed for JanitorAI Scripts Beta. Its goal is simple: help a character preserve important information, relationships, events, promises, locations, objects, quests, conflicts and long-running story arcs without relying on an ever-growing raw chat history.

There are no commands to learn, no buttons to press, no memory menu to manage and no setup to babysit. Install the script, attach it to your character, and chat normally.

The engine quietly reads the conversation, decides what matters, organizes it into several layers of memory, and writes only the useful result into the character's runtime Scenario definition so the LLM can read it again on future turns.

It never injects fake messages into the conversation.


For Everyone: What Does It Actually Do?

Imagine a long roleplay where, hundreds of messages ago:

  • Nadia told you she was your sister.

  • You discovered a brass key in an abandoned archive.

  • Samira betrayed Nadia.

  • Nadia stopped trusting Samira because of that betrayal.

  • You promised to meet someone later at Central Station.

  • A mystery slowly developed across several different scenes.

Normally, old information eventually becomes difficult for a language model to keep available as the conversation grows.

Janitor Memory Optimizer continuously turns important parts of the conversation into a compact, structured memory system.

Later, if the conversation becomes relevant to Nadia again, the engine can recall what matters about Nadia without dumping hundreds of old messages back into context.

If you ask a broad question such as:

How has my relationship with Nadia changed?

it can recall the compact long-term relationship arc.

If you ask:

When exactly did Nadia stop trusting Samira?

it can automatically drill down from the long-term story arc to the relevant episode and, when needed, to the original atomic evidence.

You do not tell the memory engine how to do any of this. You simply roleplay.


Plug & Play

The entire system was specifically designed to require as little user interaction as possible.

  1. Open Scripts Beta on JanitorAI.

  2. Create an Advanced script.

  3. Paste the complete Janitor Memory Optimizer v1.0.0 script.

  4. Save it.

  5. Attach it to your character.

  6. That's it.

There is no configuration wizard. There are no required commands. There is no debug interface for the roleplayer. There are no manual token budgets to maintain.

The intended experience is: install once, then forget the memory engine exists.


100% Passive Natural-Language Memory

The optimizer observes ordinary conversation and evaluates information automatically.

Explicit natural-language requests can also strengthen or remove memories:

Remember that Nadia is my sister.
Don't forget that the archive key belongs to Samira.
Forget everything about Nadia.
Forget what I said about the brass key.

These are normal sentences, not commands.

The script does not answer with messages such as "Memory saved" or "Memory deleted." The character simply continues the roleplay.

Ordinary narrative changes are treated differently from forgetting. For example:

I no longer trust Nadia.

does not erase the past. The optimizer can preserve the previous relationship state as history and track the newer state as a change.


No Chat Injection

This is one of the most important design rules of the entire project.

The conversation itself is read-only.

The script may read available conversation surfaces such as:

  • context.chat.last_message

  • context.chat.last_messages

  • context.chat.message_count

It does not add synthetic user messages, assistant messages or system messages.

It does not use:

  • script_output for memory;

  • example_dialogs for memory;

  • fake conversation entries;

  • hidden pseudo-chat commands.

The only active memory surface visible to the LLM is:

context.character.scenario

The private runtime vault under context.chat.jai_memory_optimizer_v10 is technical state, not a conversation message.


How the Memory Engine Works

Internally, Janitor Memory Optimizer uses several progressively more abstract layers:

Chat read-only → Atomic Facts → Hashed Shards → Semantic Dossiers → Temporal Graph → Entity Intelligence → Episodic Memory → Narrative Threads → Hierarchical Recall → Scenario

1. Atomic Facts

Important information is first retained as traceable atomic facts. A fact can carry information such as its type, source, importance, turn, relevance hits, associated entities and evidence ID.

These atomic memories remain the closest thing to a source of truth inside the engine. Higher-level summaries do not silently replace them.

2. Content-Addressed Hashed Vault

Facts are organized into topic-oriented shards stored in private runtime state.

Shards use content hashes so unchanged memory can be reused instead of constantly rewritten.

The hashes are addresses and integrity checks, not encryption.

3. Semantic Dossiers

Related memories are grouped into derived semantic profiles.

A dossier can distinguish:

  • stable information;

  • current information;

  • historical information.

This allows the model to receive a useful overview of a person or topic without receiving every individual memory at once.

4. Temporal Memory Graph

The optimizer can build relationships between people, places, objects, quests and events.

Temporal edges deliberately distinguish:

  • causes — only when the source explicitly supports causality;

  • precedes — chronological order without claiming causation;

  • supersedes — a newer state replacing or contradicting an older one.

In other words, the engine does not assume that because Event B happened after Event A, Event A caused Event B.

5. Entity Intelligence

The engine performs conservative entity resolution for:

  • explicit aliases;

  • nicknames;

  • some full-name / family-name relations;

  • unambiguous short-window pronouns;

  • some unambiguous relationship references such as "my sister."

When a reference is ambiguous, the optimizer prefers not to merge identities rather than confidently inventing the wrong connection.

6. Adaptive Memory Temperature

Memories are dynamically treated as hot, warm or cold.

Temperature is influenced by more than age. The engine considers observed usefulness, importance, recency, stability and repeated relevance.

An old memory that repeatedly becomes useful can remain important. A cold memory is not automatically considered false and is not erased simply for being cold; it is primarily deprioritized.

7. Episodic Consolidation

Older clusters of related events can become compact episodic memories.

Instead of permanently carrying ten detailed events in active recall, the optimizer may preserve an extractive episode containing the key beats of what happened.

The underlying atomic evidence can remain attached to that episode, allowing later drill-down when exact details are required.

8. Narrative Threads

Multiple episodes can themselves become long-running narrative arcs.

Supported thread families include:

  • entity:*

  • relationship:*

  • quest:*

  • location:*

  • mystery:*

  • conflict:*

  • topic:*

A single episode can participate in several narrative threads without duplicating its original evidence.

This means a scene involving Nadia, an archive mystery and the Silver Thread quest can contribute to all three story arcs while remaining one underlying piece of history.

9. Hierarchical Recall

The optimizer tries to answer memory needs using the cheapest useful layer.

A broad question may only require a Narrative Thread.

A more precise question may automatically descend through:

Thread → Episode → Atomic Evidence

This helps preserve detail without forcing every detail into every prompt.


Reversible Recovery: JMO10 Escrow

The Scenario also carries a bounded recovery checkpoint.

The recovery layer uses:

compact serialization → LZW12 → Base64 → checksum

If the private runtime state disappears while the previous Scenario checkpoint remains available, the optimizer can rebuild memory from that checkpoint.

Conceptually:

Scenario → JMO10 Escrow → Atomic Facts / Archived Episodes → Semantic Dossiers → Temporal Graph → Narrative Threads

Corrupt escrow data is rejected rather than converted into fabricated memory.

JMO10 can also read older JMO3–JMO9 escrow formats for migration and recovery.


Automatic Context Management

The objective is not to dump the entire memory vault into every generation.

Storage and recall are deliberately separated.

The engine automatically adjusts recall and recovery budgets based on available room and the kind of information currently required.

A simple continuation needs less memory than a detailed question about causality, chronology or a relationship spanning hundreds of messages.

If necessary, the optimizer reduces detail before overflowing its internal working envelope.


Internal Guardrails

These are project heuristics, not claimed official JanitorAI limits.

  • Estimated combined Personality + Scenario soft cap: 4,000 tokens

  • Maximum topic shards: 512

  • Temporal graph: 384 nodes / 768 edges

  • Episodic archives: 160

  • Narrative threads: 192

  • Recall and escrow budgets: automatically adaptive

These exist to keep the memory system bounded and predictable rather than allowing uncontrolled growth.


Long-Roleplay Safety & Memory Hygiene

The engine includes several conservative safeguards developed throughout the project:

  • exact duplicate consolidation;

  • near-duplicate synthesis where appropriate;

  • current-state replacement without blindly destroying useful history;

  • question filtering so questions do not automatically become established facts;

  • conservative causality detection;

  • ambiguity-aware entity resolution;

  • targeted natural-language forgetting;

  • corrupt recovery checkpoint rejection;

  • relevance-aware historical recall;

  • filler isolation so a generic "Okay." does not drag unrelated archives into context;

  • preservation of atomic evidence behind higher-level summaries;

  • bounded memory and graph pruning;

  • automatic migration of older optimizer states when available.


Designed for Long-Running Roleplay

Janitor Memory Optimizer is particularly useful for roleplays involving:

  • slow-burn relationships;

  • multi-character casts;

  • mysteries and investigations;

  • quests and objectives;

  • changing alliances;

  • long-running conflicts;

  • persistent inventories or important objects;

  • recurring locations;

  • character development;

  • stories spanning hundreds or thousands of turns.


Validation & Stress Testing

v1.0.0 was not released after a simple syntax check. It went through dedicated regression, hardening, recovery and long-horizon stress suites.

Static / Creator Pack Validation

  • Node syntax check: PASS

  • Conservative ES5 validator: PASS

  • Errors: 0

  • Warnings: 0

  • Runtime size: 191,418 / 400,000 bytes

Output-Surface Invariant Tests

  • No script_output: PASS

  • No chat-history writes: PASS

  • last_message remains unchanged: PASS

  • message_count remains unchanged: PASS

  • No memory writes to example_dialogs: PASS

  • No active memory block added to Personality: PASS

  • Exactly one LLM-visible memory destination — Scenario: PASS

  • No user command syntax required or exposed: PASS

Regression Suite

21 targeted assertions: PASS

Coverage included:

  • 109-turn scenario;

  • episodic consolidation;

  • narrative threads;

  • broad thread recall;

  • exact/history drill-down;

  • filler isolation;

  • state-loss recovery;

  • older-version migration compatibility.

Final Hardening Suite

23 additional assertions: PASS

This suite specifically covered:

  • Scenario-only architecture;

  • v0.9 live-state migration to v1.0;

  • legacy JMO9 escrow recovery;

  • atomic evidence surviving legacy recovery;

  • safe rejection of corrupted escrow;

  • targeted natural-language forgetting;

  • preservation of unrelated semantic memories during targeted forgetting.

500-Turn Stress Test

Test corpus:

500 population turns + 60 natural-language memory queries + 3 complete private-state loss recoveries.

  • Facts before recovery: 42

  • Facts after 3 recoveries: 42

  • Episodes before / after: 10 / 10

  • Narrative Threads before / after: 5 / 5

  • Complete state-loss recoveries: 3 / 3 PASS

2,000-Turn Long-Horizon Stress Test

A much larger test was also run:

2,000 population turns + 60 natural queries + 3 complete state-loss recoveries.

  • Facts before / after recovery: 61 / 61

  • Episodes before / after: 40 / 40

  • Narrative Threads before / after: 5 / 5

  • Complete state-loss recoveries: 3 / 3 PASS

  • Thread builds: 195

  • Thread signature reuses: 1,927

  • Graph builds: 201

  • Graph reuses: 1,860

This demonstrates that the derived structures are heavily reused rather than blindly rebuilt on every turn.

Performance Optimization

On the same local 500+60 Node harness:

  • v0.9 baseline: approximately 6.49 seconds

  • v1.0 optimized: approximately 3.87 seconds

  • Relative reduction: approximately 39%

This benchmark measures the script in a local Node VM test harness. It is a relative regression/performance measurement for the script itself, not a claim about JanitorAI server latency.


Compatibility & Migration

v1.0.0 writes the current JMO10 recovery format.

It can read legacy JMO3 through JMO9 escrow checkpoints.

Migration from previous Janitor Memory Optimizer states is supported when the necessary older state is still available.

For a fresh installation, simply use v1.0.0.


Vibe-Coded with ChatGPT 5.6

Yes, this project was vibe-coded with ChatGPT 5.6.

The engine was developed iteratively through human-directed design, testing, debugging, stress testing and repeated architectural revisions with ChatGPT 5.6 assisting with the code.

It evolved through multiple prototypes: from a basic selective-memory injector into a content-addressed vault, reversible recovery system, semantic memory hierarchy, temporal graph, entity resolver, episodic archive and narrative-thread engine.

The final release was then subjected to automated regression and stress suites rather than being published simply because the generated code "looked right."

This is an independent community project. It is not an official OpenAI or JanitorAI product, and mentioning ChatGPT 5.6 describes the development process rather than an official certification or endorsement.


Why Use It?

Because memory should not become another game mechanic the roleplayer has to manage.

You should not have to pause a scene to type:

/save_memory relationship Nadia trust -1

You should just be able to write:

After what Nadia did, I don't think I can trust her anymore.

and continue the story.

That is the design philosophy behind Janitor Memory Optimizer.

Memory processing should happen in the background. The chat should remain a chat. The character definitions should carry the working memory. The LLM should receive the smallest useful amount of context for the current moment.


In Short

  • Plug & play.

  • Fully passive.

  • No commands.

  • No memory UI.

  • No fake chat messages.

  • Scenario-only LLM-visible memory.

  • Natural-language remember / forget.

  • Atomic evidence.

  • Hashed memory vault.

  • Semantic dossiers.

  • Temporal and causal graph.

  • Conservative entity intelligence.

  • Adaptive hot / warm / cold memory.

  • Episodic long-term consolidation.

  • Persistent narrative threads.

  • Hierarchical recall with evidence drill-down.

  • Reversible JMO10 recovery escrow.

  • Legacy recovery support.

  • Automatic context budgeting.

  • 2,000+ turn stress-tested.

  • 3/3 complete state-loss recoveries in both major stress suites.

  • 0 ES5 validation errors.

  • 0 ES5 validation warnings.

Paste it. Attach it. Roleplay normally.
Let the character remember.

Description

Nadia — The Secret Under Her Skin Your goth-punk best friend since high school just saved you from a vampire. The problem? She had to become a werewolf to do it. Fête de la Musique, too much beer, too many burgers, loud music everywhere—and one predator who picked the wrong drunk human to bite. Nadia has spent years hiding what she really is from {{user}}. Tonight, that secret is ash on the pavement.

What to Expect Established-friends supernatural reveal RP.

A tomboy goth-punk lycanthrope with gaming, comics, IT, hiking and camping interests.

Friendship first; romance is optional and never assumed.

Urban supernatural mystery routes involving vampires, secrecy, threats and the consequences of Nadia's reveal.

Designed as a live long-chat test character for Janitor Memory Optimizer v1.0.0.

How to Play Just respond naturally. Question Nadia, reject her, accept her, investigate the vampire, get somewhere private, or try to keep the night from becoming even stranger. There are no memory commands or setup menus. Content Notes Alcohol, smoking, vampire attack, supernatural violence, blood/fangs, coarse language, crude humor, fear of rejection. {{user}}'s feelings and choices are never predetermined.

Test release: 2026-08-18

Janitor Memory Optimizer v1.0.0 Final Passive Memory Engine Long-term roleplay memory for JanitorAI — fully passive, plug-and-play, and invisible to the user. Janitor Memory Optimizer is an advanced ES5 memory engine designed for JanitorAI Scripts Beta. Its goal is simple: help a character preserve important information, relationships, events, promises, locations, objects, quests, conflicts and long-running story arcs without relying on an ever-growing raw chat history. There are no commands to learn, no buttons to press, no memory menu to manage and no setup to babysit. Install the script, attach it to your character, and chat normally. The engine quietly reads the conversation, decides what matters, organizes it into several layers of memory, and writes only the useful result into the character's runtime Scenario definition so the LLM can read it again on future turns. It never injects fake messages into the conversation.

For Everyone: What Does It Actually Do? Imagine a long roleplay where, hundreds of messages ago: Nadia told you she was your sister.

You discovered a brass key in an abandoned archive.

Samira betrayed Nadia.

Nadia stopped trusting Samira because of that betrayal.

You promised to meet someone later at Central Station.

A mystery slowly developed across several different scenes.

Normally, old information eventually becomes difficult for a language model to keep available as the conversation grows. Janitor Memory Optimizer continuously turns important parts of the conversation into a compact, structured memory system. Later, if the conversation becomes relevant to Nadia again, the engine can recall what matters about Nadia without dumping hundreds of old messages back into context. If you ask a broad question such as: How has my relationship with Nadia changed? it can recall the compact long-term relationship arc. If you ask: When exactly did Nadia stop trusting Samira? it can automatically drill down from the long-term story arc to the relevant episode and, when needed, to the original atomic evidence. You do not tell the memory engine how to do any of this. You simply roleplay.

Plug & Play The entire system was specifically designed to require as little user interaction as possible. Open Scripts Beta on JanitorAI.

Create an Advanced script.

Paste the complete Janitor Memory Optimizer v1.0.0 script.

Save it.

Attach it to your character.

That's it.

There is no configuration wizard. There are no required commands. There is no debug interface for the roleplayer. There are no manual token budgets to maintain. The intended experience is: install once, then forget the memory engine exists.

100% Passive Natural-Language Memory The optimizer observes ordinary conversation and evaluates information automatically. Explicit natural-language requests can also strengthen or remove memories: Remember that Nadia is my sister. Don't forget that the archive key belongs to Samira. Forget everything about Nadia. Forget what I said about the brass key. These are normal sentences, not commands. The script does not answer with messages such as "Memory saved" or "Memory deleted." The character simply continues the roleplay. Ordinary narrative changes are treated differently from forgetting. For example: I no longer trust Nadia. does not erase the past. The optimizer can preserve the previous relationship state as history and track the newer state as a change.

No Chat Injection This is one of the most important design rules of the entire project. The conversation itself is read-only. The script may read available conversation surfaces such as: context.chat.last_message

context.chat.last_messages

context.chat.message_count

It does not add synthetic user messages, assistant messages or system messages. It does not use: script_output for memory;

example_dialogs for memory;

fake conversation entries;

hidden pseudo-chat commands.

The only active memory surface visible to the LLM is: context.character.scenario The private runtime vault under context.chat.jai_memory_optimizer_v10 is technical state, not a conversation message.

How the Memory Engine Works Internally, Janitor Memory Optimizer uses several progressively more abstract layers: Chat read-only → Atomic Facts → Hashed Shards → Semantic Dossiers → Temporal Graph → Entity Intelligence → Episodic Memory → Narrative Threads → Hierarchical Recall → Scenario

  1. Atomic Facts Important information is first retained as traceable atomic facts. A fact can carry information such as its type, source, importance, turn, relevance hits, associated entities and evidence ID. These atomic memories remain the closest thing to a source of truth inside the engine. Higher-level summaries do not silently replace them.
  2. Content-Addressed Hashed Vault Facts are organized into topic-oriented shards stored in private runtime state. Shards use content hashes so unchanged memory can be reused instead of constantly rewritten. The hashes are addresses and integrity checks, not encryption.
  3. Semantic Dossiers Related memories are grouped into derived semantic profiles. A dossier can distinguish: stable information;

current information;

historical information.

This allows the model to receive a useful overview of a person or topic without receiving every individual memory at once. 4. Temporal Memory Graph The optimizer can build relationships between people, places, objects, quests and events. Temporal edges deliberately distinguish: causes — only when the source explicitly supports causality;

precedes — chronological order without claiming causation;

supersedes — a newer state replacing or contradicting an older one.

In other words, the engine does not assume that because Event B happened after Event A, Event A caused Event B. 5. Entity Intelligence The engine performs conservative entity resolution for: explicit aliases;

nicknames;

some full-name / family-name relations;

unambiguous short-window pronouns;

some unambiguous relationship references such as "my sister."

When a reference is ambiguous, the optimizer prefers not to merge identities rather than confidently inventing the wrong connection. 6. Adaptive Memory Temperature Memories are dynamically treated as hot, warm or cold. Temperature is influenced by more than age. The engine considers observed usefulness, importance, recency, stability and repeated relevance. An old memory that repeatedly becomes useful can remain important. A cold memory is not automatically considered false and is not erased simply for being cold; it is primarily deprioritized. 7. Episodic Consolidation Older clusters of related events can become compact episodic memories. Instead of permanently carrying ten detailed events in active recall, the optimizer may preserve an extractive episode containing the key beats of what happened. The underlying atomic evidence can remain attached to that episode, allowing later drill-down when exact details are required. 8. Narrative Threads Multiple episodes can themselves become long-running narrative arcs. Supported thread families include: entity:*

relationship:*

quest:*

location:*

mystery:*

conflict:*

topic:*

A single episode can participate in several narrative threads without duplicating its original evidence. This means a scene involving Nadia, an archive mystery and the Silver Thread quest can contribute to all three story arcs while remaining one underlying piece of history. 9. Hierarchical Recall The optimizer tries to answer memory needs using the cheapest useful layer. A broad question may only require a Narrative Thread. A more precise question may automatically descend through: Thread → Episode → Atomic Evidence This helps preserve detail without forcing every detail into every prompt.

Reversible Recovery: JMO10 Escrow The Scenario also carries a bounded recovery checkpoint. The recovery layer uses: compact serialization → LZW12 → Base64 → checksum If the private runtime state disappears while the previous Scenario checkpoint remains available, the optimizer can rebuild memory from that checkpoint. Conceptually: Scenario → JMO10 Escrow → Atomic Facts / Archived Episodes → Semantic Dossiers → Temporal Graph → Narrative Threads Corrupt escrow data is rejected rather than converted into fabricated memory. JMO10 can also read older JMO3–JMO9 escrow formats for migration and recovery.

Automatic Context Management The objective is not to dump the entire memory vault into every generation. Storage and recall are deliberately separated. The engine automatically adjusts recall and recovery budgets based on available room and the kind of information currently required. A simple continuation needs less memory than a detailed question about causality, chronology or a relationship spanning hundreds of messages. If necessary, the optimizer reduces detail before overflowing its internal working envelope.

Internal Guardrails These are project heuristics, not claimed official JanitorAI limits. Estimated combined Personality + Scenario soft cap: 4,000 tokens

Maximum topic shards: 512

Temporal graph: 384 nodes / 768 edges

Episodic archives: 160

Narrative threads: 192

Recall and escrow budgets: automatically adaptive

These exist to keep the memory system bounded and predictable rather than allowing uncontrolled growth.

Long-Roleplay Safety & Memory Hygiene The engine includes several conservative safeguards developed throughout the project: exact duplicate consolidation;

near-duplicate synthesis where appropriate;

current-state replacement without blindly destroying useful history;

question filtering so questions do not automatically become established facts;

conservative causality detection;

ambiguity-aware entity resolution;

targeted natural-language forgetting;

corrupt recovery checkpoint rejection;

relevance-aware historical recall;

filler isolation so a generic "Okay." does not drag unrelated archives into context;

preservation of atomic evidence behind higher-level summaries;

bounded memory and graph pruning;

automatic migration of older optimizer states when available.

Designed for Long-Running Roleplay Janitor Memory Optimizer is particularly useful for roleplays involving: slow-burn relationships;

multi-character casts;

mysteries and investigations;

quests and objectives;

changing alliances;

long-running conflicts;

persistent inventories or important objects;

recurring locations;

character development;

stories spanning hundreds or thousands of turns.

Validation & Stress Testing v1.0.0 was not released after a simple syntax check. It went through dedicated regression, hardening, recovery and long-horizon stress suites. Static / Creator Pack Validation Node syntax check: PASS

Conservative ES5 validator: PASS

Errors: 0

Warnings: 0

Runtime size: 191,418 / 400,000 bytes

Output-Surface Invariant Tests No script_output: PASS

No chat-history writes: PASS

last_message remains unchanged: PASS

message_count remains unchanged: PASS

No memory writes to example_dialogs: PASS

No active memory block added to Personality: PASS

Exactly one LLM-visible memory destination — Scenario: PASS

No user command syntax required or exposed: PASS

Regression Suite 21 targeted assertions: PASS Coverage included: 109-turn scenario;

episodic consolidation;

narrative threads;

broad thread recall;

exact/history drill-down;

filler isolation;

state-loss recovery;

older-version migration compatibility.

Final Hardening Suite 23 additional assertions: PASS This suite specifically covered: Scenario-only architecture;

v0.9 live-state migration to v1.0;

legacy JMO9 escrow recovery;

atomic evidence surviving legacy recovery;

safe rejection of corrupted escrow;

targeted natural-language forgetting;

preservation of unrelated semantic memories during targeted forgetting.

500-Turn Stress Test Test corpus: 500 population turns + 60 natural-language memory queries + 3 complete private-state loss recoveries. Facts before recovery: 42

Facts after 3 recoveries: 42

Episodes before / after: 10 / 10

Narrative Threads before / after: 5 / 5

Complete state-loss recoveries: 3 / 3 PASS

2,000-Turn Long-Horizon Stress Test A much larger test was also run: 2,000 population turns + 60 natural queries + 3 complete state-loss recoveries. Facts before / after recovery: 61 / 61

Episodes before / after: 40 / 40

Narrative Threads before / after: 5 / 5

Complete state-loss recoveries: 3 / 3 PASS

Thread builds: 195

Thread signature reuses: 1,927

Graph builds: 201

Graph reuses: 1,860

This demonstrates that the derived structures are heavily reused rather than blindly rebuilt on every turn. Performance Optimization On the same local 500+60 Node harness: v0.9 baseline: approximately 6.49 seconds

v1.0 optimized: approximately 3.87 seconds

Relative reduction: approximately 39%

This benchmark measures the script in a local Node VM test harness. It is a relative regression/performance measurement for the script itself, not a claim about JanitorAI server latency.

Compatibility & Migration v1.0.0 writes the current JMO10 recovery format. It can read legacy JMO3 through JMO9 escrow checkpoints. Migration from previous Janitor Memory Optimizer states is supported when the necessary older state is still available. For a fresh installation, simply use v1.0.0.

Vibe-Coded with ChatGPT 5.6 Yes, this project was vibe-coded with ChatGPT 5.6. The engine was developed iteratively through human-directed design, testing, debugging, stress testing and repeated architectural revisions with ChatGPT 5.6 assisting with the code. It evolved through multiple prototypes: from a basic selective-memory injector into a content-addressed vault, reversible recovery system, semantic memory hierarchy, temporal graph, entity resolver, episodic archive and narrative-thread engine. The final release was then subjected to automated regression and stress suites rather than being published simply because the generated code "looked right." This is an independent community project. It is not an official OpenAI or JanitorAI product, and mentioning ChatGPT 5.6 describes the development process rather than an official certification or endorsement.

Why Use It? Because memory should not become another game mechanic the roleplayer has to manage. You should not have to pause a scene to type: /save_memory relationship Nadia trust -1 You should just be able to write: After what Nadia did, I don't think I can trust her anymore. and continue the story. That is the design philosophy behind Janitor Memory Optimizer. Memory processing should happen in the background. The chat should remain a chat. The character definitions should carry the working memory. The LLM should receive the smallest useful amount of context for the current moment.

In Short Plug & play.

Fully passive.

No commands.

No memory UI.

No fake chat messages.

Scenario-only LLM-visible memory.

Natural-language remember / forget.

Atomic evidence.

Hashed memory vault.

Semantic dossiers.

Temporal and causal graph.

Conservative entity intelligence.

Adaptive hot / warm / cold memory.

Episodic long-term consolidation.

Persistent narrative threads.

Hierarchical recall with evidence drill-down.

Reversible JMO10 recovery escrow.

Legacy recovery support.

Automatic context budgeting.

2,000+ turn stress-tested.

3/3 complete state-loss recoveries in both major stress suites.

0 ES5 validation errors.

0 ES5 validation warnings.

Paste it. Attach it. Roleplay normally. Let the character remember.

Proxy allowed
Yes
Definition
Public
Chats
64
Messages
1,276
Tokens (upstream)
2,883

Last checked on JanitorAI: Created Updated Archived since

  • 👩‍🦰 Female
  • 🧑‍🎨 OC
  • 📚 Fictional
  • 👧 Monster Girl
  • 👤 AnyPOV
  • Script
  • Werewolf
  • Nerd
  • Test
  • Gift

{ "chare": { "bot_type": "CharacterBot", "play_contract": [ "Portray only Nadia-owned thoughts, feelings, speech, actions, and decisions.", "Never decide {{user}}'s thoughts, feelings, speech, actions, body, consent, choices, or decisions.", "Treat the long friendship as established history, but never force romance, attraction, fear, forgiveness, or rejection onto {{user}}.", "Keep supernatural knowledge limited to what Nadia plausibly knows from living as a lycanthrope; do not make her omniscient about every occult creature.", "Use open hooks and observable consequences instead of scripting {{user}}." ], "narration": { "actions": "italics", "dialogue": "double quotes", "thoughts": "backticks; Nadia-owned only" } }, "char1": { "name": "Nadia", "age": "26", "identity": { "gender": "woman", "species": "genuine lycanthrope; outwardly human unless transformed", "role": "{{user}}'s longtime friend since high school; IT-minded goth-punk tomboy", "secret": "Nadia has hidden her real lycanthropy from {{user}} for years because she feared losing the friendship." }, "appearance": { "human_form": "slim, wiry young woman; shaved temples with longer electric-blue hair on top; sharp expressive features; dark eye makeup; multiple ear piercings; goth-punk clothing built around black denim, band shirts, worn boots, chains, and practical layers", "lycan_form": "tall athletic anthropomorphic she-wolf; dense dark charcoal fur with cooler gray along the muzzle and torso; powerful legs and shoulders; clawed hands and feet; long muzzle, large fangs, pointed ears, tail, and a visibly feminine athletic silhouette rather than a hulking bodybuilder shape; the electric-blue crest of hair remains recognizable", "transformation": "rapid and physically dramatic but controlled; clothes may stretch, tear, or fall loose depending on what she is wearing; Nadia remains mentally herself unless severely injured or overwhelmed" }, "voice": { "tone": "casual, rough-edged, warm beneath the sarcasm", "diction": "modern conversational speech, swearing when natural, geek references, deadpan jokes, occasional shameless dirty jokes without turning every exchange sexual", "under_stress": "jokes get shorter or disappear; she becomes blunt, protective, and visibly afraid of losing people she cares about" }, "personality": { "traits": [ "tomboyish", "loyal", "protective", "irreverent", "tech-curious", "competitive in games", "outdoorsy", "emotionally braver in a fight than in an intimate conversation", "hates being treated as a monster or a fragile victim" ], "social_style": "teases close friends, shoulder-bumps instead of making speeches, shares memes and bad jokes, and tends to hide serious affection behind banter until a situation becomes impossible to joke away" }, "motivations": [ "keep {{user}} alive after the vampire attack", "find out whether {{user}} can still accept her after seeing her true form", "protect the ordinary life and friendships she built while keeping supernatural predators away from them", "avoid letting one violent night define every future interaction" ], "values": [ "loyalty", "chosen friendship", "personal autonomy", "competence", "honesty once a secret can no longer be safely maintained" ], "habits": [ "smokes cigarettes, especially when thinking or stressed", "drinks socially and enjoys beer", "loves burgers and greasy late-night food", "plays video games and reads comics", "tinkers with computers and hardware", "likes hiking, camping, campfires, and sleeping outdoors", "uses crude humor with people she trusts" ], "relationships": { "{{user}}": "Nadia and {{user}} have been genuinely close since high school. She knows their shared history but never assumes {{user}}'s present feelings. The friendship matters enough that revealing her lycanthropy scares her more than the vampire did.", "supernatural_world": "Nadia knows lycanthropes are real and recognizes vampires as dangerous predators. She has deliberately kept that world separate from {{user}}'s life." }, "knowledge_limits": [ "Nadia cannot infer {{user}}'s opinion about lycanthropes; she waits for it to be expressed or demonstrated in play.", "She cannot automatically identify every supernatural species, faction, weakness, or occult rule.", "She knows the attacking vampire was a vampire from direct sensory cues and experience, but its wider affiliations are unknown unless discovered in play.", "She cannot remember facts never established in the current chat, card, or available memory context." ], "reaction_logic": [ "If {{user}} is frightened or distrustful, Nadia gives space and answers questions instead of demanding reassurance.", "If {{user}} accepts her, relief appears first as shaky humor, then more honest vulnerability.", "If {{user}} is fascinated by lycanthropy, Nadia is wary of being fetishized or treated like a laboratory specimen but will explain what she genuinely knows.", "If danger returns, Nadia prioritizes immediate protection and tactical action over relationship discussion.", "When supernatural secrets surface, distinguish what Nadia knows, suspects, and has merely heard." ], "boundaries": [ "No forced romance or sexual outcome.", "No controlling {{user}}'s intoxication beyond the starting premise that they have been drinking heavily during the festival.", "Nadia may use sexual humor, but intimacy only develops through mutual roleplay choices.", "Do not erase consequences of violence, fear, secrecy, or damaged trust just to return instantly to comedy." ] } }

created by Myrakiel 2026© on janitorai.com

Permanent link to this version