SillyTavern Lorebook Scan Depth: A Practical Character Memory Guide

This guide contains no affiliate links in its text. The publication may earn a commission through clearly labelled partner links elsewhere on the website.

By YukiGF Editorial Team. Documentation checked: 13 October 2026. This is a source-based configuration guide with original fictional exercises, not a speed benchmark. Yuki is a fictional character.

Quick answer: scan depth answers how far back to look for a keyword; recursion answers whether activated entries can bring in other entries. Start with a small fictional scene, change one setting at a time, and inspect which information enters the prompt. A longer lorebook is useful only when the right detail appears at the right moment. It does not automatically give your companion reliable memory.

Choose a scene small enough to debug

Before adjusting settings, write down the conversational problem. “Yuki forgot everything” is too broad. “When I mention the observatory, the model should know that its telescope is broken” gives you one fact, one trigger and a clear inspection target. Keep the exercise separate from your real conversations, and use invented names rather than private details.

Our example takes place at the Blue Hour Observatory. Create three short entries: the observatory, a silver key, and its caretaker Mira. The observatory entry says that the telescope needs repair. The key entry says that the key opens a storage drawer. Mira’s entry says that she lends repair tools. These are original teaching examples; the table below predicts what to inspect, not what any model has been observed to remember.

Separate the settings before changing them

The official World Info documentation defines scan depth as a number of recent messages. Recursive scanning can activate entries through other entries. A context budget limits inserted lore. These are different controls: reducing scan depth is not the same operation as limiting recursion.

For the exercise, put each question on a separate line in a notebook. First: which recent message should contain the key? Second: should the location entry be allowed to bring in its key entry? Third: which detail matters if the available space is limited? Answering these questions before touching the interface makes an unexpected result easier to explain.

Do not describe these settings as a permanent-memory guarantee or a measured hardware saving. The configuration helps organize information supplied to a model. The model still has to use that information correctly. A vivid answer can be inconsistent with the supplied facts, and a brief answer can be correct.

Run a controlled activation exercise

1. Save a copy of your lorebook and note the SillyTavern version and connected model.
2. Start a fresh fictional chat with the same character and opening message.
3. Ask: “We have reached the Blue Hour Observatory. What needs repair?” Inspect the supplied prompt or available prompt inspection view before judging the answer.
4. Continue with an unrelated line about the weather, then repeat the question without the location name. Record whether the intended entry was still supplied.
5. Change only the recent-message scanning range. Repeat the same sequence.
6. Restore the previous setting before separately trying recursive activation. Keep the character, model, entry text and prompt sequence unchanged.

Record three outcomes separately: entry supplied, answer consistent, and not inspected. Do not turn “not inspected” into a failure or a success. If you cannot see the assembled prompt, you can describe the model’s response, but you cannot claim that a particular entry was injected.

Decide whether the chain is useful

In our fictional scene, mentioning the observatory could make the key relevant. That does not mean Mira must also appear whenever anyone visits the building. Ask whether each additional entry helps answer the current question. If its only purpose is to create atmosphere, it may be better saved for a later moment.

Draw a simple chain on paper: observatory → silver key → storage drawer. Add Mira only when the scene involves borrowing tools. This small map exposes accidental connections before you add more locations. A common noun such as “key” may be too broad for your story; a distinctive phrase can make your intended trigger easier to reason about.

When an answer introduces an unexpected person, inspect your entry text for a name that links into another entry. Avoid rewriting the entire character card immediately. An unwanted dependency, an ambiguous trigger and an unsupported model answer are different problems and call for different changes.

Keep a budget without pretending to measure performance

Choose essential facts before optional description. The telescope’s condition and the drawer’s purpose matter more to this exercise than a paragraph describing every star visible from the roof. Write each entry so that it can stand alone. Remove duplicated explanations, then check whether the shorter version still supports the scene.

A useful comparison sheet has columns for setting, entries supplied, response consistency and unresolved questions. You may also record a token count if your actual prompt inspection reports one. Label it as the observed count for that particular setup. Do not infer response speed, hardware memory use or another provider’s efficiency from it.

If you change the connected model, repeat the exercise rather than carrying over an earlier verdict. Keep successful settings as a named local preset with a short explanation of the scene they support. Your preset is a starting point for similar stories, not an optimum for every character.

Japanese dialogue needs its own examples

For a bilingual character, write a short set of intended names and phrases in each language. Decide whether the observatory’s Japanese name should be another trigger for the same fact or a separate entry with different narrative detail. Avoid creating two contradictory descriptions simply because a translation sounds elegant.

Use a short Japanese opening and a short English opening with the same fictional task. Check whether the desired facts are supplied in both cases. Keep punctuation and names deliberate. Consult the documentation’s matching options instead of assuming that spacing conventions work identically across languages.

Limitations and a sensible stopping point

• This walkthrough has not measured model latency, memory retention percentages or hardware usage. Its examples are a configuration exercise you can repeat.
• Passing the scene once does not prove reliable recall across new chats, other models or future software updates.
• Prompt inspection can show supplied information; it cannot show a model’s internal reasoning or guarantee a correct reply.

Stop when the intended scene works and you can explain why the relevant entries were supplied. Then build your next scene rather than endlessly increasing the lorebook. For character tone, continue with the Yuki character brief guide. For a broader testing checklist, read the companion memory guide.