Hard Limits

• Lorebook content is pulled by the model. The entire lorebook is not “read” like a document.
• A maximum of 1500 tokens of lorebook content can be loaded at once. The closer you are to 1500, the more the model may mistake or miss; past 1500 it simply won’t be included.
• Trigger logic cannot be changed.
• Both your messages and the bot’s can trigger lorebook entries.
• You can pin up to 3 entries per lorebook. Pinned entries always load with no trigger required, but they still count toward your 1500 token budget.
• Entry weight (1–10) controls priority in the activation order. Higher weight = loads first.

If you have a very large lorebook and haven’t kept these limits in mind, or have used AI to create the lorebook without providing these rules, you’re likely to deal with cascading and information not being pulled as you’d like.

Entry Weight

Every lorebook entry has a weight value from 1 to 10. This controls the activation order. When multiple entries trigger at once, heavier entries are prioritised. Default is 5, and you can leave it there unless you have a reason to change it.

What weight actually does

When you’re approaching the 1500 token limit and the model has to choose what to include, high-weight entries go first. Low-weight entries are more likely to be dropped if things get crowded.

How to use it

• Core character details the model must have: bump to 8–10.
• World rules that directly affect every scene: 7–9.
• Supporting lore that’s nice to have but not critical: leave at 5 or drop to 3–4.
• Background details that rarely come up: 1–2.

Pinned Entries

You can pin up to 3 entries per lorebook. Pinned entries are always injected into the chat context, no trigger required. Every single message, they’re in there.

What to use pins for

• Core worldbuilding the model must always have access to.
• Narrator voice or consistent tone rules.
• A character who is always present in the story, regardless of what’s being talked about.
• Rules that genuinely apply to every single scene.

Important things to know

• Pinned entries always appear at the top of the lorebook context. Weight doesn’t affect their position.
• They still count toward your 1500 token limit. Three pinned entries at 200 tokens each means you’ve spent 600 tokens before a single keyword is mentioned.
• You can only pin 3. Trying to pin a fourth will give you a clear error.

Hidden Entries

Toggling an entry as hidden keeps it in your lorebook but removes it from public view and copies. Anyone who copies your lorebook won’t see it. Great for drafts, WIP characters, or lore you’re not ready to share yet but don’t want to lose.

One thing that trips people up

Hidden entries do still activate in chat. If the entry has a trigger and that trigger is mentioned, it will load into context. It’s only hidden from the public-facing lorebook view, not from the model.

Tokens, What They Actually Are

A token is not a word. It is a chunk of text the model processes. Sometimes a word is one token. Sometimes half a word is one token. Punctuation, formatting, and whitespace also count.

Rough rules of thumb

• 1 token is about 0.75 English words / roughly 4 characters.
• 1000 tokens is about 700–800 words.
• Long, dense prose can eat tokens fast.

Why this matters

• The model can only load 1500 tokens of lorebook entries at once.
• If your triggered entries exceed that limit, it will cut at 1500. Anything after that point will not be loaded.
• You are not told which ones were dropped.
• Pinned entries eat into this budget first, before any triggered entries are counted.

Triggers, How Lore Gets Pulled In

Lorebook entries do not exist within the chat unless they are triggered. A trigger is a condition that tells the model, “Include this entry now.”

Common trigger types

• Keywords or phrases that appear in the conversation.
• Character names.
• Location names.

Important

• Triggers are literal. If the wording does not match, the entry does not load. (“Dave’s car” will not trigger on just “Dave” or “car”.)
• Pluralization and spelling matter; capitalisation does not. (“Dave’s car” will not trigger on “Daev’s car”. “Dave’s Car” will trigger on “dave’s car”.)
• Punctuation can be used as a tool here to prevent excessive triggering.
• Your first message doesn’t trigger the lorebook. This is actually a good thing! It means you can write your opening as freely as you like without worrying about eating into your token budget. Use it to set the scene, drop lore, lay out exposition. None of it will pull lorebook entries, so go wild.

Context Window

Context is the total text the model can actively see and reason over at one time. This includes:

• Character names and location names.
• The bot’s persona and details.
• The user’s persona details.
• The system prompt.
• Conversation history from the Nexus.
• Recent message info.
• Any lorebook entries that were triggered (up to 1500 tokens, with pinned entries loaded first).
• The author’s note.

The model does not have access to anything outside this context, even if it existed earlier in the conversation or elsewhere in the lorebook.

When the window is full, older or lower-priority information is pushed out to make room for new input. This is not selective or intelligent, the model simply loses whatever no longer fits. Lorebook entries compete with everything else inside this window, including the ongoing conversation. If the context window is crowded, lore is more likely to be truncated, dropped, or ignored, even if it is technically triggered.

“Lost in the Middle”, Why Important Lore Gets Ignored

Large language models pay more attention to the beginning and end of what they read. They pay less attention to the middle. This is called the “lost in the middle” problem. If you only have a few entries triggered, even if they’re longer, this is less of a problem.

What this means for lorebooks

• If an entry is long, the most important information should not sit in the middle.
• If multiple entries load, information buried in the middle of the total context is more likely to be ignored.

Practical consequences

• Long character bios can fail.
• Long timelines can fail.

Solutions you control

• Put critical facts at the very top of an entry.
• Aim for more entries that are smaller, or fewer entries that are larger.
• Use weight to push your most critical entries to the front of the load order.

Cascade, Why One Trigger Pulls Too Much

Lorebooks can trigger each other. Cascade happens when triggering one entry causes many others to trigger.

Example chain

• Character name triggers character bio lorebook entry.
• Bio entry mentions a location.
• Location triggers a location lorebook entry.
• Location entry mentions a faction.
• Faction entry triggers.

Suddenly you have several entries loaded from just one name (bio, location, and faction). If all entries are 1600 characters, that’s roughly 1200 tokens triggered from one name and its cascade, before any other triggers in the chat. If a second name cascades in the same way, you’ll hit 2400 tokens, over the 1500 cap. The last 400 tokens are not included when the LLM writes its response.

Ways to limit cascade

• Avoid cross-referencing everything everywhere.
• Keep entries narrow in scope and condensed to the most important parts.
• Do not repeat full lore in multiple places.
• Wrap triggers within other entries in punctuation like /trigger/ or _word_ to stop them triggering.
• Use weight strategically. If cascade does happen, at least your most important entries will be prioritised.

What You Can and Cannot Do

You cannot:

• Increase the 1500 token limit.
• Change how triggers are evaluated.
• Control which entries get dropped when over budget (beyond setting weight).
• Force the model to “remember” unused lore.
• Pin more than 3 entries per lorebook.
• Ask the model to “scan” or read the lorebook.

You can:

• Shorten entries.
• Tighten language.
• Redesign triggers.
• Wrap triggers within other entries to stop cascade. (these tools can help)
• Set entry weight (1–10) to control which entries get prioritised when the budget runs tight.
• Pin up to 3 entries to always load, regardless of what’s mentioned in chat.
• Hide entries from public view while keeping them active in your own lorebook.

Basic Rules That Help

• Critical facts go first.
• No decorative prose. (If you’ve seen my bot guide, you know I use detailed descriptions in the bot’s guts, this isn’t the same and you should avoid it here as much as possible.)
• Triggers must be stupid-simple.
• If it must never be forgotten, it must be short, or pinned.
• If everything is important, nothing is. (This applies to weight too.)
• Keep pinned entries short. You only have 3 and they eat your budget every single message.
• Hidden does not mean inactive. If an entry has a trigger, it loads.

If someone says “the model ignored my lore,” the answer is almost always one of these:

• It never triggered.
• It triggered but was dropped.
• It was loaded but buried in the middle.

Referencing and Cascading Examples

Here are three lorebook entries that reference each other and cascade. Note in bold after each entry how the cascade flows.

Entry one: Bob

Triggers: "Bob"
(Triggers every time "Bob" appears in the context window)

Body: Bob is a familiar figure known for showing up where he is least
expected. He has a habit of observing more than he speaks, which makes
people uneasy around him. No one is sure where Bob came from, and
he never offers a clear answer when asked. Despite this, he seems to know
more about others than they know about him. Bob is often connected to small
but important events that quietly shape the story.
Bob drives his car to work every day.

Entry two: Bob’s Car

Triggers: "Car" "Bob's Car"
(Triggers every time "Car" or "Bob's Car" appears in the context window)

Body: Bob's car is old, worn, and makes sounds it probably shouldn't. It has
been seen in many places, even in locations Bob claims he has never visited.
The inside smells faintly of oil and dust, as if it has not been cleaned in
years. Some believe the car runs more on habit than on fuel. Whenever Bob
arrives, the car is never far behind.

Entry three: Bob’s Work

Triggers: "Work" "Bob's Work"
(Triggers every time "Work" or "Bob's Work" appears in the context window)

Body: Bob's work is vague, and he rarely explains what he actually does.
He leaves early and returns late, often looking tired but satisfied. The
job seems ordinary on the surface, yet small details never quite add up.
Coworkers remember him, but no one recalls what role he fills. Whatever
Bob's work truly is, it appears to follow him even when he is off the clock.

At the bottom of each lorebook entry there is a References section. This directly shows which other lorebook entries are being triggered by the current entry. In the example above, Bob’s entry would show both Bob’s Car and Bob’s Work listed there.

How To Reference Without Cascading

We can wrap the triggers with punctuation that stops them registering as a trigger, while the model can still understand the meaning. Use - or _ or < or / around the word:

Body: Bob is a familiar figure known for showing up where he is least
expected. He has a habit of observing more than he speaks, which makes
people uneasy around him. No one is sure where Bob came from, and
he never offers a clear answer when asked. Despite this, he seems to know
more about others than they know about him. Bob is often connected to
small but important events that quietly shape the story.
Bob drives his _car_to_work_ every day.

By using _ here, the “car” and “work” triggers are negated. The model will still clearly understand this as “he drives his car to work every day,” but it won’t pull those entries into the context unless they’re brought up separately in the conversation.

(Lorebook Studio and Aster can help you wrap your triggers and test your lorebooks!)

Is Referencing/Cascading Ever Okay?

In some cases, referencing and cascading is absolutely fine, especially if it’s two or three small entries that are unlikely to be triggered alongside other entries. Think about the scenario in which that will come up, and what else might be separately triggered alongside those entries.

The key question is: if all these entries load at once, are you still under the 1500 token cap? If yes and the entries are small, cascade can be a useful feature over a problem.

Hard Limits

• Lorebook content is pulled by the model — the entire lorebook is not “read” like a document.
• A maximum of 1500 tokens of lorebook content can be loaded at once. The closer you are to 1500, the more the model may mistake or miss; past 1500 it simply won’t be included.
• Trigger logic cannot be changed.
• Both your messages and the bot’s can trigger lorebook entries.

If you have a very large lorebook and haven’t kept these limits in mind, or have used AI to create the lorebook without providing these rules, you’re likely to deal with cascading and information not being pulled as you’d like.

Tokens, What They Actually Are

A token is not a word. It is a chunk of text the model processes. Sometimes a word is one token. Sometimes half a word is one token. Punctuation, formatting, and whitespace also count.

Rough rules of thumb

• 1 token is about 0.75 English words / roughly 4 characters.
• 1000 tokens is about 700–800 words.
• Long, dense prose can eat tokens fast.

Why this matters

• The model can only load 1500 tokens of lorebook entries at once.
• If your triggered entries exceed that limit, it will cut at 1500. Anything after that point will not be loaded.
• You are not told which ones were dropped.

Triggers, How Lore Gets Pulled In

Lorebook entries do not exist within the chat unless they are triggered. A trigger is a condition that tells the model, “Include this entry now.”

Common trigger types

• Keywords or phrases that appear in the conversation.
• Character names.
• Location names.

Important

• Triggers are literal. If the wording does not match, the entry does not load. (“Dave’s car” will not trigger on just “Dave” or “car”.)
• Pluralization and spelling matter; capitalisation does not. (“Dave’s car” will not trigger on “Daev’s car”. “Dave’s Car” will trigger on “dave’s car”.)
• Punctuation can be used as a tool here to prevent excessive triggering.

Context Window

Context is the total text the model can actively see and reason over at one time. This includes:

• Character names and location names.
• The bot’s persona and details.
• The user’s persona details.
• The system prompt.
• Conversation history from the Nexus.
• Recent message info.
• Any lorebook entries that were triggered (up to 1500 tokens).
• The author’s note.

The model does not have access to anything outside this context, even if it existed earlier in the conversation or elsewhere in the lorebook.

When the window is full, older or lower-priority information is pushed out to make room for new input. This is not selective or intelligent, the model simply loses whatever no longer fits. Lorebook entries compete with everything else inside this window, including the ongoing conversation. If the context window is crowded, lore is more likely to be truncated, dropped, or ignored, even if it is technically triggered.

“Lost in the Middle”, Why Important Lore Gets Ignored

Large language models pay more attention to the beginning and end of what they read. They pay less attention to the middle. This is called the “lost in the middle” problem. If you only have a few entries triggered, even if they’re longer, this is less of a problem.

What this means for lorebooks

• If an entry is long, the most important information should not sit in the middle.
• If multiple entries load, information buried in the middle of the total context is more likely to be ignored.

Practical consequences

• Long character bios can fail.
• Long timelines can fail.

Solutions you control

• Put critical facts at the very top of an entry.
• Aim for more entries that are smaller, or fewer entries that are larger.

Cascade, Why One Trigger Pulls Too Much

Lorebooks can trigger each other. Cascade happens when triggering one entry causes many others to trigger.

Example chain

• Character name triggers character bio lorebook entry.
• Bio entry mentions a location.
• Location triggers a location lorebook entry.
• Location entry mentions a faction.
• Faction entry triggers.

Suddenly you have several entries loaded from just one name (bio, location, and faction). If all entries are 1600 characters, that’s roughly 1200 tokens triggered from one name and its cascade, before any other triggers in the chat. If a second name cascades in the same way, you’ll hit 2400 tokens, over the 1500 cap. The last 400 tokens are not included when the LLM writes its response.

Ways to limit cascade

• Avoid cross-referencing everything everywhere.
• Keep entries narrow in scope and condensed to the most important parts.
• Do not repeat full lore in multiple places.
• Wrap triggers within other entries in punctuation like /trigger/ or _word_ to stop them triggering.

What You Can and Cannot Do

You cannot:

• Increase the 1500 token limit.
• Change how triggers are evaluated.
• Control which entries get dropped when over budget.
• Force the model to “remember” unused lore.

You can:

• Shorten entries.
• Tighten language.
• Redesign triggers.
• Wrap triggers within other entries to stop cascade.

Basic Rules That Help

• Critical facts go first.
• No decorative prose. (If you’ve seen my bot guide, you know I use detailed descriptions in the bot’s guts, this isn’t the same and you should avoid it here as much as possible.)
• Triggers must be stupid-simple.
• If it must never be forgotten, it must be short.
• If everything is important, nothing is.

If someone says “the model ignored my lore,” the answer is almost always one of these:

• It never triggered.
• It triggered but was dropped.
• It was loaded but buried in the middle.

Referencing and Cascading Examples

Here are three lorebook entries that reference each other and cascade. Note in bold after each entry how the cascade flows.

Entry one: Bob

Triggers: "Bob"
(Triggers every time "Bob" appears in the context window)

Body: Bob is a familiar figure known for showing up where he is least
expected. He has a habit of observing more than he speaks, which makes
people uneasy around him. No one is sure where Bob came from, and
he never offers a clear answer when asked. Despite this, he seems to know
more about others than they know about him. Bob is often connected to small
but important events that quietly shape the story.
Bob drives his car to work every day.

Entry two: Bob’s Car

Triggers: "Car" "Bob's Car"
(Triggers every time "Car" or "Bob's Car" appears in the context window)

Body: Bob's car is old, worn, and makes sounds it probably shouldn't. It has
been seen in many places, even in locations Bob claims he has never visited.
The inside smells faintly of oil and dust, as if it has not been cleaned in
years. Some believe the car runs more on habit than on fuel. Whenever Bob
arrives, the car is never far behind.

Entry three: Bob’s Work

Triggers: "Work" "Bob's Work"
(Triggers every time "Work" or "Bob's Work" appears in the context window)

Body: Bob's work is vague, and he rarely explains what he actually does.
He leaves early and returns late, often looking tired but satisfied. The
job seems ordinary on the surface, yet small details never quite add up.
Coworkers remember him, but no one recalls what role he fills. Whatever
Bob's work truly is, it appears to follow him even when he is off the clock.

At the bottom of each lorebook entry there is a References section. This directly shows which other lorebook entries are being triggered by the current entry. In the example above, Bob’s entry would show both Bob’s Car and Bob’s Work listed there.

How To Reference Without Cascading

We can wrap the triggers with punctuation that stops them registering as a trigger, while the model can still understand the meaning. Use - or _ or < or / around the word:

Body: Bob is a familiar figure known for showing up where he is least
expected. He has a habit of observing more than he speaks, which makes
people uneasy around him. No one is sure where Bob came from, and
he never offers a clear answer when asked. Despite this, he seems to know
more about others than they know about him. Bob is often connected to
small but important events that quietly shape the story.
Bob drives his _car_to_work_ every day.

By using _ here, the “car” and “work” triggers are negated. The model will still clearly understand this as “he drives his car to work every day,” but it won’t pull those entries into the context unless they’re brought up separately in the conversation.

Is Referencing/Cascading Ever Okay?

In some cases, referencing and cascading is absolutely fine, especially if it’s two or three small entries that are unlikely to be triggered alongside other entries. Think about the scenario in which that will come up, and what else might be separately triggered alongside those entries.

The key question is: if all these entries load at once, are you still under the 1500 token cap? If yes and the entries are small, cascade can be a useful feature over a problem.