SillyTavern Lorebooks (2026): How World Info Works, the Settings That Matter and Why Entries Do Not Trigger

A SillyTavern lorebook is a file of entries that are added to the prompt only when one of their keywords appears in the recent chat. By default, “recent” means the last two messages. SillyTavern’s own name for the feature is World Info. Lorebook and World Info mean the same thing, and the interface uses both.

Most questions about lorebooks are one question: I wrote the entry, so why does the character not know it? The answer is nearly always in the rules that decide whether an entry is inserted. There are only a few of them, and SillyTavern publishes all of them.

We read SillyTavern’s World Info documentation, and then the World Info source code and the default settings file on the release branch, which was version 1.19.0 on 6 October 2026. The default values below come from those two files.

New to SillyTavern? Start with the SillyTavern guide. For summaries, vector storage and the other memory tools, see SillyTavern memory.

The Short Answer

• An entry has keys and content. The model only ever sees the content.
• Keys are searched in the last 2 messages by default. That is the Scan Depth setting.
• A blue-circle entry is constant. It is always inserted and needs no key.
• A green-circle entry is normal. It is inserted only when a key matches.
• All entries together may use 25% of your context by default. When that budget is full, the rest are dropped without a message.
• A lorebook does nothing until it is attached to something: all chats (global), a character, a persona or one chat.
• A lorebook inside a downloaded character card is not active until you import it.
• Files are in data/default-user/worlds, one JSON file per lorebook.

What a Lorebook Does

A language model has no memory of your world. It reads the prompt it is given for each reply, and nothing else. Everything the character “knows” must be in that prompt.

You could put your whole world in the character description. Then every reply pays for all of it, in tokens and in attention, even when the scene is two people in a kitchen.

A lorebook is the other way to do it. You write the world as separate entries. SillyTavern reads the recent messages before each reply and adds only the entries whose keywords were mentioned. The documentation describes it as “a dynamic dictionary that only inserts relevant information from World Info entries when keywords associated with the entries are present in the message text”.

Two limits follow from this design, and both are stated in the documentation.

The model sees only the Content field. In the documentation’s words: “Activation keywords, titles, and other information that is not in the Content field is not inserted into context, so each World Info entry should have a comprehensive, standalone description.” An entry titled Queen Maren with the content She rules from the Salt Throne tells the model about an unnamed woman. Write the name inside the content.

Insertion is not obedience. The documentation again: World Info “does not guarantee its appearance in the generated output messages. That depends on how good your model is at making use of additional information”. A lorebook puts facts in front of the model. It does not force the model to use them.

Make Your First Lorebook

1. Open the World Info panel from the top bar.
2. Create a new lorebook file and give it a name.
3. Add an entry.
4. In the key field, write the words that should trigger it, separated by commas: Maren, queen, Salt Throne.
5. In the content field, write the fact as a complete statement: Queen Maren rules the city of Halcyon from the Salt Throne. She is sixty, blind in one eye, and trusts nobody from the northern houses.
6. Attach the lorebook to something (next section).

A new entry starts with these values, read from the source code:

Field	Value for a new entry
Strategy	Normal (green circle), keyword needed
Position	Before Char Defs
Order	100
Trigger %	100
Depth (used only by the @ D position)	4
Optional filter logic	AND ANY
Scan depth, case sensitivity, whole words	Not set, so the global values apply

You can leave all of them alone for a first lorebook.

The Four Places a Lorebook Can Live

A lorebook file that is attached to nothing is never read. This is the first thing to check when no entry fires at all.

Attached to	Active when	How to attach
Global	Every chat	Select it in the World Info panel’s active list
Character	Every chat with that character, including groups	Globe button on the character panel
Persona	Whenever that persona is selected	Persona Lore button in Persona Management
Chat	That one conversation only	Chat Lore button on the character panel

Some details from the documentation that people miss:

• A character has one primary lorebook and can have additional ones. Only the primary one is exported inside the character card. If you share a card and its lore is in an additional lorebook, the other person does not get it.
• A chat lorebook does not follow the character. It “will not carry over to other chats with the same character”. It suits facts that are true in one campaign only.
• A persona lorebook follows you. It is active “regardless of which character or chat is open”. It suits facts about your own character that every bot should know.
• If a lorebook is already attached, the button opens the editor. To change the attachment, use Shift+Click or Alt+Click on desktop, or a long press on mobile.

Which one should you use? Put a shared setting (a world that many characters live in) in a global lorebook, or attach the same file to each character. Put one character’s private history in that character’s lorebook. Put the events of one campaign in a chat lorebook.

When several lorebooks are active

Entries from all active lorebooks are combined. The order is: chat lore first, then persona lore, then character and global lore.

For the last two there is a setting, Insertion Strategy, with three options: Sorted Evenly, Character Lore First and Global Lore First. The documentation calls Sorted Evenly the default. The settings file that SillyTavern installs sets Character Lore First. Look at the dropdown on your own install if the order matters to you. For most lorebooks it does not.

How an Entry Gets Activated

Before each reply, SillyTavern builds a block of text to search. With default settings it contains the last two messages of the chat. Then it goes through every entry of every active lorebook and asks the questions below, in this order. The order is from the source code.

1. Is the entry disabled? Then skip it.
2. Does the entry have a generation type filter (Normal, Continue, Impersonate, Swipe, Regenerate, Quiet) that excludes this request? Then skip it.
3. Does the entry have a character filter that excludes this character? Then skip it.
4. Is the entry under a delay or a cooldown? Then skip it.
5. Is it constant? Then activate it.
6. Is it sticky from an earlier message? Then activate it.
7. Does it have no keys? Then skip it.
8. Does a key appear in the text? If not, skip it.
9. Does it have an optional filter? Then the filter must pass too.

Entries that pass go to a second stage: inclusion groups, the Trigger % roll and the budget. Only entries that survive all of it reach the prompt.

Step 7 is a quiet trap. A green-circle entry with an empty key field can never fire. Nothing warns you.

Scan depth: the two-message window

Scan Depth is the number of recent messages that are searched. The shipped value is 2.

The message you just sent counts as one. So with depth 2, SillyTavern searches your new message and the character’s reply before it. Nothing older.

This explains the most common complaint. You mention the Salt Throne. The entry fires, and the character answers correctly. Three messages later the conversation is still about the throne, but nobody has written the words Salt Throne again. The entry is no longer inserted, and the character starts to invent details.

You have four ways to deal with it:

• Raise the global Scan Depth. A depth of 4 to 6 keeps entries alive through a normal exchange. Each step searches more text, so more entries fire and more budget is used.
• Set a scan depth on the one entry. Each entry has its own optional Scan Depth that replaces the global value. The source code allows up to 1,000.
• Make the entry sticky. A sticky value of 5 keeps the entry active for five messages after it fires (see Timed Effects below).
• Make it constant, if it is short and always needed.

The documentation lists what the values mean: 0 means “only recursed entries and Author’s Note are evaluated”, 1 means the last message only, 2 the last two, and so on.

Keys: what matches and what does not

The matching rules are simple, and they are stricter than people expect.

Keys are not case-sensitive by default. maren matches Maren. There is a global Case-sensitive keys switch and a per-entry override. Turn it on for a key that is also a common word, such as a character named Rose.

Match Whole Words is on in the shipped settings. It works differently for one-word and several-word keys. This is the logic in the source code:

• A one-word key must appear as a whole word. The characters next to it must not be letters, digits or underscores.
• A key of two or more words is matched as plain text anywhere, and the whole-word rule is not applied to it.

In practice:

Key	Text in the chat	Matches?
king	”Long live the king.”	Yes
king	”The king’s guard”	Yes, the apostrophe ends the word
king	”Three kings met”	No
king	”It is not to my liking”	No
Salt Throne	”the salt thrones of old”	Yes, plain text match

The third row is the one that catches people. A plural does not match a singular one-word key. Neither does a nickname, a misspelling or a translation. Add each form as its own key: king, kings, monarch, His Majesty.

The documentation adds a warning for languages that do not put spaces between words, such as Japanese and Chinese: keep Match Whole Words off.

Commas separate keys. A plain key cannot contain a comma.

A key can be a regular expression. Write it between slashes, JavaScript style: /kings?|monarch/i. A regex key overrides the case and whole-word settings. The documentation also describes a way to match only what one speaker said, since each scanned message is prefixed with the speaker’s name.

Names count as text

Include Names is on by default. Each scanned message is prefixed with the name of who wrote it, like Alice: Hello!. The documentation says this “allows activating entries that use names as keywords without directly mentioning the names in messages”.

The consequence: an entry whose key is the character’s own name fires on almost every reply, since the character’s name is in the scanned text whenever one of the last two messages is theirs. If that is what you want, a constant entry says it more honestly. If it is not what you want, do not use the character’s name as a key.

The optional filter

The Optional Filter is a second list of keys. With it, a primary key alone is not enough.

Logic	The entry activates when a primary key matches and…
AND ANY	at least one filter key is also present
AND ALL	all filter keys are also present
NOT ANY	none of the filter keys is present
NOT ALL	not all of the filter keys are present

A use for it: two entries with the key Maren. One has the filter childhood, young, girl and describes her youth. The other has NOT ANY with the same words and describes her as queen. Only one is inserted at a time.

If the filter field is empty, it is ignored.

Constant and Normal Entries

Each entry has a strategy, shown as an icon.

Icon	Name	Behaviour
Blue circle	Constant	Inserted on every reply. No key needed.
Green circle	Normal	Inserted only when a key matches.
Chain link	Vectorized	May also be inserted by similarity, if Vector Storage is set up for it.

A constant entry is the same as text in the character card, with one difference: you can choose where in the prompt it goes, and you can switch it off with one click.

The cost is permanent. A constant entry of 300 tokens is 300 tokens on every reply, and it takes that from the lorebook budget before any keyword entry gets a turn.

A simple rule works well. Constant: the few facts that would break the story if forgotten (the world’s one strange rule, the current year, who is dead). Normal: everything else.

The chain link is extra. A vectorized entry “would still behave like a normal, enabled, non-constant record that will be activated by keywords if they are set”, says the documentation. The similarity matching only happens when the Vector Storage extension is enabled and its “Enable for World Info” box is ticked. The documentation is honest about the result: “it’s impossible to predict exactly what entries will be inserted. If you want deterministic and predictable results, stick to keyword matching.”

The Budget: 25% of Your Context

All activated entries share one allowance. The setting is Context %, and the shipped value is 25. The source code computes it as a plain percentage of your maximum context size.

Your context size	Lorebook budget at 25%
4,096 tokens	1,024 tokens
8,192 tokens	2,048 tokens
16,384 tokens	4,096 tokens
32,768 tokens	8,192 tokens
128,000 tokens	32,000 tokens
200,000 tokens	50,000 tokens

Two different problems come from this one table.

On a small context, the budget is tight. With 2,048 tokens, seven or eight long entries fill it. The documentation states what happens next: “If the budget is exhausted, then no more entries are activated even if the keys are present in the prompt.” There is no warning unless you turn on Alert on overflow, which is off by default. With it on, you get the message “World info budget reached after N entries.”

On a large context, the budget is too generous. Fifty thousand tokens of lore in every prompt is expensive on a paid API, and it buries the conversation under reference text. Use the Budget Cap setting for this. It is a fixed number of tokens, from 0 (off) up to 65,536, and it replaces the percentage whenever the percentage would be larger. A cap of 2,000 to 4,000 tokens is a sensible start on a large-context model.

Which entries win when the budget is short? The documentation says constant entries are inserted first, then “entries with larger order numbers”, and that entries triggered directly by the chat come before entries triggered by other entries. So the Order number is also a priority number. Give your most important entries the highest Order.

An entry can also be marked to ignore the budget. Use that for very few entries, or the budget stops meaning anything.

Recursion: Entries That Trigger Entries

With Recursive Scan on, the content of an activated entry is searched for keys too. The documentation’s example: an entry for Bessie says she is friends with Rufus, and Rufus has his own entry. Mention Bessie, and both are inserted.

Recursive Scan is on in the settings file that SillyTavern installs. This is worth knowing, since it changes how you should write.

The good side: a world written with cross-references unfolds by itself. Mention a city, get the city, its ruler and its ruling house.

The bad side: one common word in one entry can pull in a chain of others and fill the budget. If your entries mention each other freely, one message about a tavern can insert half the world.

Each entry has three switches to control it:

• Non-recursable: this entry cannot be activated by other entries. Only by the chat.
• Prevent further recursion: this entry’s content will not activate others. Use it on long entries that name many things.
• Delay until recursion: this entry can only be activated by other entries, never directly by the chat.

There is also a global Max Recursion Steps. The interface explains the values: 0 is unlimited, 1 scans once and does not recurse, 2 allows one round of recursion. Max Recursion Steps and Min Activations cannot be used together.

Min Activations is a different tool. Set it to a number, and SillyTavern keeps searching further back in the chat, past the scan depth, until that many entries have fired. It is a blunt way to make sure a lorebook always contributes something.

Where the Entry Goes in the Prompt

The Position of an entry decides where its content is placed. Text closer to the end of the prompt has a stronger effect on the reply.

Position	Where the content goes	Effect, per the documentation
Before Char Defs	Before the character description and scenario	Moderate
After Char Defs	After the description and scenario	Greater
Before / After Example Messages	Parsed as example dialogue	For entries written as dialogue
Top / Bottom of Author’s Note	Inside the Author’s Note	Depends on where the note is
@ D	At a chosen depth in the chat, as a system, user or assistant message	Strongest at low depth
Outlet	Nowhere, until you call it with a macro	Manual placement

Three of these have traps.

Author’s Note positions need an Author’s Note. The documentation: “If your Author’s Note is disabled (Insertion Frequency = 0), World Info entries in A/N positions will be ignored!”

Outlet entries are not inserted automatically. Their content appears only where you write the {{outlet::Name}} macro in the Prompt Manager or the Advanced Formatting fields. The name is case-sensitive. An outlet entry with no name is skipped. If you set an entry to Outlet by accident, it activates and then goes nowhere.

@ D with depth 0 is the bottom of the prompt. It is the loudest place you can put text. It is useful for a short rule the model keeps breaking. It is a bad place for three paragraphs of history, which will then read to the model like the latest thing that happened.

Order sorts entries that share a position. In the documentation’s words, “entries with larger order numbers will be inserted closer to the end of the context as they will have more impact on the output”.

For a first lorebook, leave everything on Before Char Defs or After Char Defs. Move single entries to @ D only when the model ignores them.

Timed Effects: Sticky, Cooldown, Delay

Three optional numbers on each entry change activation over time. They are counted in messages.

• Sticky: after the entry fires, it stays active for N more messages, with no keyword needed.
• Cooldown: after the entry fires (and after any sticky period ends), it cannot fire for N messages.
• Delay: the entry cannot fire until the chat has at least N messages.

Sticky is the clean fix for the two-message window. A sticky of 4 on a location entry keeps the location in the prompt for a whole scene after one mention.

Delay is good for spoilers. An entry with a delay of 40 cannot reveal the traitor during the first forty messages, whatever is said.

The documentation lists rules that explain some odd behaviour: a repeated keyword “does not refresh the effect duration if it’s already active”, editing an entry that is under an effect removes the effect, and effects are dropped “if the chat doesn’t advance, e.g. if the last message was swiped or deleted”.

Random and Exclusive Entries

Trigger % adds a roll after activation. At 100, the entry is always inserted when activated. At 50, half the time. At 0, never, which is one more way to switch an entry off by accident. The documentation’s example of a use: a 1% chance per message of waking an elder god when its name is spoken.

Inclusion Group makes entries exclusive. If several activated entries share a group label, only one is inserted. By default the winner is random, weighted by Group Weight (100 by default). With Prioritize Inclusion, the entry with the highest Order wins instead.

This is how you build a random event table inside a lorebook. Ten weather entries, all constant, all in the group weather: each reply gets exactly one.

Importing, Exporting and Card Lorebooks

Importing a file

The import button in the World Info panel accepts .json, .lorebook and .png files. Apart from SillyTavern’s own format, the source code converts three others on import: NovelAI lorebooks, Agnai memory books and Risu lorebooks.

The error messages and what they mean:

Message	Meaning
File is not valid	The file could not be read as JSON, or the PNG has no lorebook data inside
Error parsing file	The JSON is broken (often a file that was edited by hand)
Failed to import World Info	The server refused the file, for example valid JSON that is not a lorebook; look at the SillyTavern console window

A character card file is not a lorebook file. If you import a card’s JSON here, you get one of the messages above. Import the card as a character instead.

Lorebooks inside character cards

A character card can carry a lorebook inside it. Many cards on sharing sites do. SillyTavern does not use that lorebook until you import it.

When you open such a character for the first time, SillyTavern shows a message: “This character has an embedded World/Lorebook.” Depending on a setting in User Settings, it is a dialog that asks, or a short notice. If you close it, you can import later: on the character panel, open More… and choose Import Card Lore.

If a downloaded character seems to know nothing about the world its description promises, check this first.

For where cards come from and how the card file works, see SillyTavern character cards. For lorebooks made on Janitor AI, which are scripts in a different system, see the Janitor AI lorebook guide.

File location and JSON format

Each lorebook is one JSON file:

SillyTavern/data/default-user/worlds/<lorebook name>.json

If you use several SillyTavern user accounts, replace default-user with the account’s folder. Copy the worlds folder to back up every lorebook.

The file is an object with one entries object inside. Each entry is stored under its number. A minimal entry looks like this:

{
  "entries": {
    "0": {
      "uid": 0,
      "key": ["Maren", "queen", "Salt Throne"],
      "keysecondary": [],
      "comment": "Queen Maren",
      "content": "Queen Maren rules the city of Halcyon from the Salt Throne.",
      "constant": false,
      "selective": true,
      "order": 100,
      "position": 0,
      "disable": false,
      "probability": 100,
      "useProbability": true,
      "depth": 4
    }
  }
}

key holds the primary keys, keysecondary the optional filter, comment the title that only you see, and content the text for the model. position is a number: 0 is Before Char Defs, 1 After Char Defs, 2 and 3 the top and bottom of the Author’s Note, 4 is @ D, 5 and 6 are before and after Example Messages, 7 is Outlet.

You can write or generate this file outside SillyTavern and import it. Entries with missing fields receive the default values.

Renaming

Renaming used to break things. A character, persona or chat stores the name of its lorebook, so a renamed file left them pointing at nothing. The release notes show the repair in two steps: version 1.17.0 (28 March 2026) added an optional relink across characters, and version 1.19.0 (14 September 2026) made renaming update chat, character and persona links.

If you renamed a lorebook on an older version and it stopped firing for some characters, update SillyTavern and attach the lorebook again.

Why Your Entry Did Not Trigger: A Checklist

Go through these in order. The early ones are the common ones.

1. Is the lorebook attached? Global list, character, persona or chat. A file that is only open in the editor is not active.
2. Did it come inside a card? Then use More…, Import Card Lore.
3. Is the entry enabled? Each entry has its own switch.
4. Was the keyword written in the last two messages? Not earlier, and not only in the character description. Raise Scan Depth, or set a scan depth or sticky value on the entry.
5. Does the text match the key exactly? Plurals, nicknames and misspellings do not match a one-word key. Add them as keys.
6. Does the entry have any keys at all? A normal entry with no keys never fires.
7. Is there an optional filter? With AND ANY, a filter key must be present too.
8. Is Trigger % below 100? Then it will sometimes not fire, by design.
9. Is the budget full? Turn on Alert on overflow and watch for the warning. Shorten entries, lower the Order of unimportant ones, or raise the budget.
10. Is the position Outlet or an Author’s Note position? Outlet needs the macro. Author’s Note positions need an active Author’s Note.
11. Is there a character filter, a generation type filter, a delay or a cooldown on the entry?
12. Did the entry fire, and the model ignored it? This is a different problem. Move the entry closer to the end of the prompt (After Char Defs, or @ D with a low depth), shorten it, and write it as plain statements.

See what SillyTavern decided

You do not have to guess. The World Info code writes its reasoning to the browser console for every reply.

Press F12, open the Console tab, and make sure verbose or debug messages are shown. Send a message. Lines that start with [WI] appear. They report the context size and the budget, each entry that was activated and why (“activated by primary key match”, “activated because of constant”), each entry that was suppressed and why (“disabled”, “filtered out by character”, “suppressed by cooldown”, “has no keys defined, skipped”), and the point where the budget was reached.

An entry that had no keyword match is not listed. That silence is also an answer: the key was not in the scanned text.

To see the final result, look at the prompt that was sent for the last reply (the prompt view in the message’s action menu, or the SillyTavern console window) and search for your entry’s text. If it is there, the lorebook worked and the model is the problem. If it is not there, the checklist above applies.

How to Write Entries That Work

Most of this follows from the rules above.

Name the subject in the content. The model does not see the title or the keys.

One subject per entry. A single entry called The North with twelve places in it fires as a block or not at all. Twelve small entries fire as needed.

Keep entries short. Fifty to 150 tokens each is a good size. The budget is shared, and a long entry pushes others out.

Write statements, in the present tense. The Ashen Guild controls the docks of Halcyon. Its members wear grey gloves. Models use plain statements more reliably than lists of tags.

Choose keys that people really write. Include plurals, short forms and titles. Avoid keys that are common words, or the entry fires all the time.

Mention other entries with care. With recursion on, every name you write inside an entry can pull that name’s entry in.

Make only a few entries constant.

Do not put the current plot in a lorebook. A lorebook holds facts that stay true. What happened last session belongs in a summary. See SillyTavern memory for that side.

For writing the character itself, see how to write a character card.

Lorebook, Data Bank or Summary?

SillyTavern has three tools that all get called “memory”. They do different jobs.

Tool	You write	It inserts	Predictable?
Lorebook	Entries and keys	Whole entries, on exact keyword match	Yes
Data Bank (Vector Storage)	Nothing; you attach documents	Chunks that an embedding model finds similar to recent messages	Less
Summarize	Nothing, or small corrections	One running summary of the chat	Partly

Use a lorebook for the facts of the world. Use a summary for what has happened in this chat. Use the Data Bank when you have a long existing document, such as a setting book, and no time to cut it into entries.

They can run together. The lorebook budget is separate from the others.

Checklist

• Create the lorebook, then attach it (global, character, persona or chat).
• Write the subject’s name inside the content.
• Add plurals and nicknames as separate keys.
• Raise Scan Depth to 4 or more, or use sticky on scene entries.
• Keep entries short, and make only a few constant.
• On a large context, set a Budget Cap.
• Turn on Alert on overflow while you are testing.
• Use Import Card Lore for lorebooks that come inside cards.
• Read the [WI] lines in the browser console when an entry does not fire.
• Back up the worlds folder.

Frequently Asked Questions

What is a lorebook in SillyTavern?

A lorebook is a file of entries that SillyTavern adds to the prompt only when they are needed. Each entry has keywords and a content text. When a keyword appears in the recent messages, the content is inserted into the prompt for that reply. SillyTavern calls the feature World Info, and the two names mean the same thing.

Why is my SillyTavern lorebook not triggering?

The most common cause is scan depth. By default SillyTavern looks for keywords only in the last two messages, so an entry whose keyword was last written three messages ago is not inserted. Other common causes are a lorebook that is not attached to anything, a plural or nickname that does not match the key, an entry with no keys, and a full lorebook budget.

What is the difference between constant and normal entries in SillyTavern?

A constant entry, shown with a blue circle, is inserted on every reply and needs no keyword. A normal entry, shown with a green circle, is inserted only when one of its keywords is found in the scanned messages. Constant entries cost tokens on every reply, so they suit short facts that must never be lost.

What does scan depth mean in SillyTavern World Info?

Scan depth is the number of recent chat messages that SillyTavern searches for lorebook keywords. The default is 2, which means your new message and the reply before it. A depth of 0 turns keyword scanning of the chat off. Each entry can also override the global value with its own scan depth.

Where are SillyTavern lorebooks stored?

Each lorebook is one JSON file in the worlds folder of your user data. On a default install that is data/default-user/worlds inside the SillyTavern folder. Copying those files is a full backup of your lorebooks.

How do I import a lorebook into SillyTavern?

Open the World Info panel and use the import button to pick a file. SillyTavern accepts its own JSON format and converts NovelAI lorebooks, Agnai memory books and Risu lorebooks. A lorebook that came inside a character card is imported with Import Card Lore in the More menu on the character panel.

How much context does a SillyTavern lorebook use?

By default, lorebook entries may use up to 25% of your context size. On an 8,192 token context that is 2,048 tokens. When the budget is reached, no more entries are added for that reply, even if their keywords are present. A separate Budget Cap setting sets a fixed token limit.

What is the difference between a lorebook and the Data Bank in SillyTavern?

A lorebook inserts whole entries that you wrote, when exact keywords match. The Data Bank stores documents, cuts them into chunks and inserts the chunks that an embedding model judges similar to the recent messages. Lorebooks are predictable and need writing. The Data Bank needs no writing and is less predictable.

---

The default settings (scan depth, budget, recursion, whole-word matching, insertion strategy), the values of a new entry, the order of the activation checks, the key matching logic, the budget calculation, the accepted import formats, the error and console messages, the embedded-lorebook notice and the storage folder were read from SillyTavern’s source code and default settings file on the release branch (version 1.19.0) on 6 October 2026. The descriptions of sources, positions, filters, timed effects, groups, recursion options and vector matching are from SillyTavern’s World Info documentation. Dated changes are from the project’s release notes. The advice on entry length, key choice, Order as priority and budget caps is our reading.

SillyTavern is an open-source project. Arcanum is not affiliated with SillyTavern or any service named here. Product names and trademarks are the property of their respective owners.