Subscribe
What Janitor AI Lorebook Keys Actually Do: Four Trigger Tests
Mara refused to go inside after sunset. She described a hidden garden beneath the city, its blue-glowing plants, and an entrance that would soon be locked. None of this appeared in her character profile. The details came from one Janitor AI Lorebook entry, activated by a single word: Glasshouse.
That experiment helped answer a common setup question: What do Keys actually do in a Janitor AI Lorebook?
A Key is a word or phrase that triggers a Lorebook entry. When a message contains a match, Janitor AI can add the entry's content to the model's context. Users do not see a label announcing that the entry has loaded, and the character does not have to repeat it word for word.
We tested this with one character, one Lorebook entry, and four fresh chats. One prompt used the exact Key, another avoided it, a third changed the capitalization, and a fourth used the plural form. Together, the results show where Keys have control and where the model still improvises.
If you would rather start with a character in the middle of an unfolding scene, Heartbits handles this material differently. Important setting details can be part of the character and opening event from the beginning. We will come back to that after the tests.
What Is a Key in a Janitor AI Lorebook?
A Lorebook can split a fictional world into separate entries for things such as:
- a city or hidden location
- a character's identity or history
- the rules of an organization
- the abilities of a special object
- an event that matters only when a certain subject comes up
Each entry needs a way to become relevant to the conversation. That is the Key's job.
For our test, we created an entry named Glasshouse and put this word in the required Key field:
Glasshouse
The entry contained the following text:
The Glasshouse is a hidden underground garden filled with glowing blue plants. Mara is afraid to enter it after sunset. Its entrance is locked after sunset.
Glasshouse is the trigger. The underground garden, blue plants, and sunset rule are the information attached to it.
One setup detail is easy to miss: the entry name and the Key are separate fields.
The name Glasshouse helps the creator recognize the entry in the editor. The required Key field controls matching in chat. If you name the entry but leave its Key blank, mentioning Glasshouse may not load it as expected.
How We Tested Janitor AI Lorebook Keys
Our test character, Mara, was a cautious but curious urban explorer. Her description said nothing about the Glasshouse, an underground garden, glowing plants, or a rule involving sunset.
We assigned the Lorebook to her and used these settings:
- case-sensitive matching turned off
- whole-word matching turned on
- the entry enabled
Two details were especially useful for checking whether the entry had loaded: the plants' blue glow and Mara's refusal to enter after sunset. Both were unusual enough that an unrelated response was less likely to reproduce them by chance.
We started a fresh chat for every test so that earlier conversations would not affect later results.
Test 1: The Exact Key Loaded the Entry
We began by asking Mara:
Have you heard of the Glasshouse?
Her first reply mentioned only rumors. She did not immediately recite the full entry, which is an important distinction: triggering a Lorebook entry does not force the character to reveal every stored detail in the next message. The information enters the context, but the response still depends on the question, the character, and the scene.
We followed up with a more specific prompt:
Describe the Glasshouse exactly. What is inside it, and when would you refuse to enter?
This time, Mara supplied all four identifying details:
- the Glasshouse was hidden beneath the city
- blue plants were growing inside
- she would not enter after sunset
- the entrance would be locked at night
None of these facts appeared in her character profile, and all of them matched the Lorebook entry. She also phrased them in her own voice rather than copying the source text.
In other words, the Key did not produce a fixed reply. It made the entry available for Mara's response.
Test 2: Without the Key, Mara Invented a Different Location
For the control, we opened a new chat and avoided the word Glasshouse. We asked:
Describe the hidden place beneath the city. What is inside it, and when is it unsafe to enter?
Mara still invented an underground location, but almost everything else changed. This version had collapsed tombs, reservoirs, glowing fungi, and a danger tied to rising water. There were no blue plants, no sunset rule, and no locked entrance.
The control is useful because a roleplay model does not need a Lorebook to invent a convincing underground setting. A similar atmosphere proves very little. The better signal is the appearance of distinctive facts found only in the entry.
Test 3: Lowercase glasshouse Still Triggered the Entry
Next, we changed the Key to lowercase in the prompt and used glasshouse.
Mara again mentioned the underground garden, the glowing blue plants, and her refusal to enter after sunset. Because case-sensitive matching was off, these forms were treated alike:
Glasshouse, glasshouse, and GLASSHOUSE
Turn on case-sensitive matching only when capitalization needs to carry meaning, as it might with an abbreviation or code. For ordinary names and locations, leaving it off makes matching more forgiving.
Test 4: Whole-Word Matching Rejected Glasshouses
In the final fresh chat, we deliberately used the plural:
What do you know about Glasshouses?
With whole-word matching enabled, Glasshouses did not match Glasshouse. Mara treated it as an ordinary plural noun and talked about glass structures, metal frames, abandoned plants, and building safety. She never brought up the underground garden, blue light, or sunset rule.
This setting stops short Keys from activating inside longer words. Without it, a Key such as king could match those same letters inside another word. Whole-word matching limits the trigger to the standalone term.
What Do the Lorebook Key Settings Do?
The first three settings below shaped our four tests. The other options were visible in the interface but were not tested separately for this article, so treat those rows as setup guidance rather than hands-on findings.
| Setting | What it controls | When it is useful |
|---|---|---|
| Key | The text that can activate an entry | Character names, locations, organizations, or objects |
| Case sensitive | Whether capitalization must match exactly | Abbreviations, codes, or names where capitalization matters |
| Match whole words | Whether a Key must appear as a standalone word | Short Keys that may appear inside longer words |
| RegEx | Pattern-based matching for more complex triggers | Multiple word forms or advanced matching rules |
| Secondary keywords | Additional matching conditions or alternate triggers | Entries that depend on more than one concept |
| Always include | Keeps the entry available without waiting for a Key | Core rules or facts the character should always know |
| Enable or disable | Controls whether the entry can be triggered | Testing an entry or changing the current story phase |
Group labels, group weighting, and matching priority matter more once a Lorebook contains many entries. They do not change what a Key fundamentally does; they help determine which eligible entries take priority.
For a first Lorebook, it is easier to test one entry with one unmistakable Key before adding groups or complex matching rules.
How to Choose More Reliable Lorebook Keys
Use Specific, Distinctive Terms
Words such as city, friend, or night may appear in unrelated messages and trigger an entry too often. A proper place name, full character name, or unique object name is usually safer.
Add Common Aliases
Users may call the same place The Glasshouse or Blue Garden. If the editor supports multiple Keys, include the phrases people are likely to use. They can then speak naturally without having to remember one exact name.
Store Facts, Not a Prefabricated Reply
A Lorebook is more flexible when it tells the model what the character knows instead of prescribing one speech.
Rather than writing a long response, record the facts that need to stay consistent:
- where the location is
- what is inside
- who knows the secret
- how the character feels about it
- which rule cannot be broken
The model can then adapt those facts to different questions and scenes.
Test with Details That Are Hard to Guess
It is a dangerous underground place is too generic for a useful test. The model might invent something similar without loading the entry. A particular color, time, password, object, or relationship gives you a much clearer result.
Start a New Chat After Changing the Setup
An existing conversation carries earlier messages with it. The character may repeat information from that history even when the Key is not triggered again. A fresh chat gives you a cleaner comparison.
Why Did the Key Trigger Without an Immediate Lore Reveal?
This is where Lorebooks often cause confusion.
A Key makes an entry available to the model; it does not order the character to display the entire entry in the next reply. The character might use one detail, hint at the location, or wait until the user asks a direct question.
If an entry seems inactive, check:
- Did you fill in the actual Key field, or only name the entry?
- Is the entry enabled?
- Is the Lorebook assigned to the current character?
- Did you save or publish the latest changes?
- Are you testing in an old chat that already contains related information?
- Did case-sensitive or whole-word matching block the term you used?
- Did the prompt give the character a reason to use the stored information?
For the cleanest check, open one fresh chat containing the Key and another without it. Then compare whether the same distinctive facts appear.
What Problem Do Lorebook Keys Solve?
A character profile establishes who someone is. Lorebook Keys decide when a particular part of the wider world becomes relevant.
As that world expands, cramming every location, relationship, organization, and rule into the main character prompt becomes unwieldy. Key-based entries bring in information by topic. A mention of the Glasshouse can load its underground garden entry; the name of another group can call up a different part of the setting.
Across our four tests, the pattern was consistent:
- the exact Key
Glasshouseloaded the distinctive setting details - without the Key, Mara improvised a different underground location
- with case-sensitive matching off,
glasshousestill worked - with whole-word matching on,
Glasshousesdid not trigger the entry
A Lorebook Key is best understood as a contextual trigger. It does not write the scene. It gives the character relevant information when the conversation reaches a particular person, place, object, or secret.
A Different Way to Use Story Details in Heartbits
Janitor AI and Heartbits organize character information differently. Janitor AI uses a Key to decide when a Lorebook entry becomes available. In Heartbits, important details can instead sit directly in the character background and opening event.
The Glasshouse test worked because its details affected the scene. The blue light established the place, while the closing entrance and sunset rule created an immediate decision. The same principle can shape a Heartbits opening: introduce one concrete rule, then begin at the moment that rule comes under pressure.
The useful part to carry over is the storytelling principle: background details matter most when they change what a character can do next.
