SillyTavern memory explainer

Memory is not magic.

All AI response is currently stateless, meaning the model does not remember anything from one prompt to the next. (We're ignoring caching, which is not a cost-effective way to handle memory and changes with every prompt!) Memory systems are ways of storing information outside the model and adding it into the current prompt. Every โ€œmemory systemโ€ is just a different way of deciding what gets kept, shortened, searched for, tracked, and sent back.

Some users use only one method. Some use multiple. Both are fine!

The memory approaches

Each solves a different problem.

Raw chat history The original messages, sent exactly as written.

Raw history is the chat exactly as it happened. It preserves the dialogue, tone, wording, and tiny details because nothing has been shortened yet.

First problem: it eats context. A long chat cannot stay fully present forever. At some point, older material has to be dropped, summarized, or replaced with something smaller.

Second problem: despite claims that models have millions of tokens in context, the advertised context window only tells you how much text the model can accept, not how reliably it will use all of it. The model may start to forget, hallucinate, or contradict itself even before the context window is full.

Third problem: pay per token cost. If your provider charges per input/output token, then the more text you keep in context, the more expensive every response becomes. (This is not a problem for local LLM or flat-rate services.)

Exact wording Best fidelity Heavy context use Does not scale forever
Summaries Older events compressed into shorter narrative records.

Summaries keep the important shape of what happened without hauling the entire transcript around forever. They are usually the sensible choice once the story gets long.

But compression is compression. Something will be lost. A good summary keeps consequences, decisions, relationship changes, promises, injuries, discoveries, and unresolved problems. But it will not preserve every line of dialogue, every joke, or every tiny detail. It is a tradeoff.

Efficient Good for long stories Information loss Quality depends on prompt
Lorebook or World Info injection Stored entries inserted when their conditions are met.

Lorebooks keep information outside the visible chat and insert selected entries into the prompt. What appears can depend on keywords, character filters, priority, probability, vector similarity, depth, and other rules.

This works well for stable facts and structured memories. The catch is that an entry which never triggers may as well not exist, while too many active entries can bury the model in old, conflicting, or irrelevant information.

Structured Controllable Trigger dependent Can overfill context
Semantic or vector retrieval Searches stored material for passages that appear relevant.

Semantic retrieval searches stored material for things that seem related to the current conversation. It can find useful details even when nobody repeats the exact same words.

โ€œSeems relatedโ€ is both the strength and also the weakness of this method. Retrieval can miss the right memory, return irrelevant memories, or dig up something technically relevant but completely unhelpful to the scene. And unlike keywords, this cannot be fully controlled by the user. Vector matching is a relative black box.

Flexible search Useful for large archives Probabilistic False matches and misses
State trackers Maintain current facts rather than retelling the entire past.

Trackers store what is true right now: location, inventory, wounds, relationships, objectives, disguises, clocks, active threats, and whatever else the bot needs to stop mysteriously forgetting.

Trackers are not history. A tracker may tell the model that one character distrusts another but will not preserve the "why".

Current state Improves consistency Not a full history Needs updating

Where ST Memory Books fits

A durable narrative layer.

ST Memory Books Turns completed portions of a chat into structured, editable memories.

ST Memory Books turns completed scenes or chunks of conversation into structured records that can be recalled by keyword and/or by vector similarity. You can inspect, correct, edit, or manipulate it via the lorebook.

Keyword activation depends very heavily on good keywording. Vector similarity depends heavily on correctly configuring ST's Vectors extension, your embedding model, and match thresholds. Both methods can produce false positives, and neither is guaranteed to find the right memory every time. Also, by their nature, summaries cannot preserve every sentence. They also cannot guarantee that every stored detail appears at exactly the right moment.

Preserves Events, consequences, relationships, discoveries, promises, and unresolved threads.
Reduces The amount of raw transcript that must remain inside the active context window.
Supports Human review, editing, organization, and deliberate control over what becomes memory.
Why people keep running it beside other memory extensions: another system may retrieve fragments or track current state, while ST Memory Books keeps the stable narrative record. There is overlap, but they are not doing the same job.

Which approach should you use?

Start with the problem, then find a solution to fit it.

Practical decision guide Match the memory method to the kind of continuity you need.

Short chat, plenty of context

Do nothing. You do not need a memory system yet.

You need exact old wording

If exact wording matters, keep or retrieve the original messages. You can ask ST Memory Books or another summary tool to preserve selected quotes. Chat vectorization or other RAG systems can retrieve original passages, although retrieval can still miss.

You need long-running narrative continuity

Use ST Memory Books or another structured summarization system that makes the chronology explicit by presenting memories in the order they were made.

You need relevant fragments from a large archive

Use chat vectorization or another RAG system on the stored chat transcript.

You need a current snapshot

Use a tracker for state, inventory, objectives, or relationship status. ST Memory Books has side prompts that serve as extremely customizable and flexible trackers.

You need strong long-term continuity

You need timelines, narrative arcs, and/or chronological memories. ST Memory Books can provide timelines via side prompts, consolidate memories into narrative arcs, and present memories chronologically.

Layered setup examples Common combinations that solve different memory problems together.

Detail-heavy archive

ST Memory Books for the stable record + chat vectorization when you need smaller details dug back up.

World-heavy campaign

Lorebooks for the world as designed + ST Memory Books for what actually happened in this chat.

Short, focused chat

Raw history only, until the context pressure becomes real.

Common weaknesses

No memory system is perfect.

Caveats worth understanding The tradeoffs that apply across most memory systems.
  • Summaries lose things. Compression and consolidation inevitably result in losing some details. Good prompting can help mitigate this.
  • Automatic scene boundaries can be wrong. Stories are not always polite enough to end cleanly. ST Memory Books allows you to manually define scene boundaries.
  • Retrieval can miss. The right memory may stay buried while a vaguely related one gets dragged in. Careful keywording and/or tuning of vector settings can help improve retrieval accuracy.
  • More memory is not automatically better. Too much injected text wastes context and can create contradictions. Tune keywords to be more specific, or set vector thresholds appropriately.
  • Stale state causes nonsense. Trackers should be updated as the story progresses.
  • Memory is not completely hands-off. Automation saves work but needs review before the record can be trusted. Any specific setup may be perfect for one use case but not another.