SillyTavern memory reference

Summaryception Memory Books

They overlap more than the usual comparison suggests. Both can automatically summarize older chat, remove processed raw messages from the model’s context without deleting them, and use compressed history to reduce token use. The real difference is how the summaries are organized, compressed again, and returned to the model.

Automatic summarization Non-destructive message hiding Compressed long-term context Editable memory

The short answer

What actually separates them

1

They share the same basic job

Compress older chat so the story can continue without sending the full raw transcript on every generation.

2

They use different memory architecture

Summaryception builds a recursive chronological hierarchy. Memory Books builds separate lorebook entries and retrieves them through SillyTavern’s lorebook system.

3

The choice is coverage versus selectivity

Summaryception emphasizes a continuously available story backbone. Memory Books emphasizes independently managed memories and configurable retrieval.

Do not choose between them based on “automatic versus manual,” “hides versus does not hide,” or “saves tokens versus adds tokens.” Those distinctions are false. Both automate, both hide processed raw chat, and both replace raw history with compressed context.

Core architecture

Same destination, different route

These diagrams show the normal conceptual flow, not every optional setting or tool.

Summaryception
  1. Older raw turns reach the configured batch point
  2. The batch becomes a compact chronological snippet
  3. Snippets fill Layer 0
  4. Older snippets are automatically promoted and recompressed into deeper layers
  5. The layered memory block is supplied with the recent verbatim turns

Primary model: a continuously maintained chronological hierarchy whose deeper layers cover progressively more history.

Memory Books
  1. A selected or automatic message range becomes a scene memory
  2. The memory is saved as an ordinary SillyTavern lorebook entry
  3. Processed raw messages may be hidden from model context
  4. SillyTavern activates entries through constant, keyword, vector, recursion, budget, and routing settings
  5. Older entries may be deliberately consolidated into higher summary tiers

Primary model: separate, inspectable memory objects that are retrieved according to lorebook activation rules.

Feature-by-feature

Direct comparison

“Different” does not mean one approach is universally better.

Question Summaryception Memory Books
Can it run automatically? Yes. It summarizes eligible older turns in configured batches. Yes. It can create memories automatically at configured message intervals after an initial checkpoint is established.
Can it be triggered manually? Yes. It includes Force Summarize and related controls. Yes. Users can mark scenes, specify ranges, run slash commands, or process a catch-up range.
What happens to processed raw chat? Messages are “ghosted” (hidden): excluded from model context but retained in the visible chat. Messages can be hidden ("ghosted"): excluded from model context but retained in the visible chat.
What is the basic memory unit? A compact chronological snippet covering a batch of turns. A lorebook entry covering a selected or automatically determined scene range.
How is older memory organized? Snippets are arranged in recursive layers with progressively broader coverage. Memories remain separate entries. Selected entries can be consolidated into Arc, Chapter, Book, Legend, Series, and Epic tiers.
How does deeper compression happen? Automatically, when a layer reaches its configured capacity and older snippets are promoted. Through a user-confirmed consolidation workflow. A separate Compaction tool can shorten one existing entry.
What is normally returned to the chat model? A bounded chronological memory assembled from the active layers, plus the configured recent verbatim turns. The lorebook entries SillyTavern activates under the current keywords, constant/vector settings, recursion rules, budgets, positions, and character routing.
Primary retrieval emphasis Continuous chronological coverage. Selective relevance and configurable routing.
Can the stored memory be inspected or edited? Yes. The Snippet Browser supports browsing, editing, regenerating, and deleting snippets. Yes. Memories are ordinary lorebook entries and can also use previews, regeneration, compaction, and consolidation review.
Separate summarization connection? Yes. It documents independent connection choices including OpenAI-compatible and Ollama routes. Yes. Profiles can use the active SillyTavern connection or a different provider, model, preset, proxy, or custom connection.
Specialized memory tools The core extension focuses on layered chronological summarization. Community forks add other behaviors. Includes Clips, Topical Clips, Side Prompts, Compaction, tiered Consolidation, context settings, and group/character routing.
Group and character memory The core README points to a community fork for separate per-character memory banks. Native group-chat support includes a canonical group book and optional per-character Memory Books with participant routing.

Open the drawers

Detailed notes

What is objectively the same? The overlap that simplified comparisons often miss
  • Both can generate summaries automatically. Memory Books is not restricted to manually marked scenes.
  • Both remove processed raw messages from model context without deleting the chat. Summaryception calls this ghosting; Memory Books uses SillyTavern’s hide/unhide behavior.
  • Both reduce token use by substituting compressed history for raw transcript.
  • Both can summarize already summarized material. Summaryception does this through automatic layer promotion; Memory Books does it through tiered Consolidation.
  • Both allow the user to inspect and modify stored memory.
  • Both can use a summarization model or connection separate from the main roleplay connection.

The implementations are not identical, but the practical claim that one “ghosts and saves tokens” while the other merely “adds lorebook entries on top of the full chat” is inaccurate.

Where do they genuinely differ? The comparison that is actually useful

Chronological stack versus retrieved entries

Summaryception is designed around a chronological memory stack. Its snippets preserve the continuing sequence of events, and its deeper layers cover increasingly old history.

Memory Books is designed around independent lorebook entries. Those entries can be constant, keyword-triggered, vectorized, delayed until recursion, placed at different prompt positions, assigned budgets, or routed by character.

Automatic promotion versus deliberate consolidation

Summaryception automatically recompresses older snippets as its layers fill. Memory Books can alert the user that a tier is ready, but consolidation still requires review or confirmation. This gives Memory Books more control over grouping and replacement; it also requires more user decisions.

Fixed batching versus scene-oriented boundaries

Summaryception normally processes configured batches of turns. Memory Books can also process fixed intervals, but it additionally supports explicit literary or event-based scene boundaries.

Narrow core versus broader toolkit

Summaryception’s core purpose is continuous layered summarization. Memory Books also maintains facts, topic references, state trackers, group memory copies, character-specific versions, and compacted entries. Those extra systems are optional, but they make Memory Books broader and more configurable.

What are the practical tradeoffs? The other side of each design choice

Summaryception tradeoffs

  • Continuous chronological coverage does not depend on a keyword being mentioned at the right moment.
  • The memory budget is comparatively predictable because the layer structure is bounded by configuration.
  • Automatic promotion requires less curation.
  • Repeated compression can carry an omission or distortion into deeper layers.
  • A broad chronology may include information that is not relevant to the current scene.

Memory Books tradeoffs

  • Selective activation can keep unrelated history out of the current request.
  • Independent entries are easier to inspect, correct, route, and reuse.
  • Users can preserve detailed scene memories until they deliberately consolidate them.
  • A relevant memory can be missed if its activation, budget, recursion, or routing is misconfigured.
  • The larger feature set creates more configuration and more ways to build a poor setup.
Neither system can guarantee lossless memory. Any LLM-generated summary can omit, compress, misinterpret, or distort information. “Lossless” should be treated as an aspiration or marketing claim, not a technical guarantee.
Common false comparisons Claims that should not be used to distinguish the extensions
“Summaryception is automatic; Memory Books is manual.”
False. Memory Books supports automatic interval-based memory creation. Manual scene selection is an additional option.
“Summaryception ghosts old chat; Memory Books leaves the full chat in context.”
False. Memory Books can automatically hide processed messages from the model while leaving them intact in the chat UI.
“Summaryception saves tokens; Memory Books adds token bloat.”
False as a general comparison. Both replace raw chat with compressed memory. Either can be configured inefficiently.
“Memory Books is mainly a state tracker.”
Incomplete. Its core workflow creates scene memories. Trackers are one optional feature among several.
“Memory Books sends every stored memory on every turn.”
False. Lorebook activation determines which entries are inserted. Entries may also be configured as constant, but that is a choice.
“Recursive summaries preserve everything.”
Not guaranteed. Recursive compression can be very efficient, but it remains summarization and therefore can lose or alter information.
Terminology that causes confusion Different words sometimes describe the same practical result

Ghosted versus hidden

Both terms mean that the original message remains in the chat but is excluded from what the model receives. The internal metadata and user interface differ; the token-saving result is substantially the same.

Layer versus tier

A Summaryception layer is part of an automatically maintained recursive hierarchy. A Memory Books tier is a class of consolidated lorebook entry, such as Arc or Chapter. They both represent greater compression, but they are created and retrieved differently.

Memory injection versus lorebook activation

Summaryception assembles its memory into an injected chronological block. Memory Books relies on SillyTavern’s World Info/lorebook engine to decide which saved entries enter the request.

JSON output versus JSON storage

Memory Books asks the generation model for structured JSON so it can reliably separate a title, summary, and keywords. The saved memory itself is an ordinary SillyTavern lorebook entry, not a special JSON memory database.

Decision guide

Which one should you use?

Choose Summaryception when…

You primarily want a continuously maintained chronological backbone.

  • You want automatic recursive compression with minimal curation.
  • You want older chronology supplied without depending on keyword activation.
  • You prefer a bounded hierarchy of snippets over a collection of separate entries.
  • You mainly need plot and state continuity rather than several specialized memory workflows.

Choose Memory Books when…

You want independently managed memories and selective retrieval.

  • You want to inspect, edit, activate, route, compact, or consolidate entries separately.
  • You want event-based scene boundaries as well as automatic interval summaries.
  • You need Clips, topic references, ongoing trackers, or group/character memory routing.
  • You want control over which memories enter a request and where they are inserted.
The simplest rule: choose Summaryception for a continuously compressed chronology; choose Memory Books for discrete memories with configurable retrieval and additional memory-management tools.
Using both is not automatically better. They overlap in summarizing and removing older raw chat from context. Running both over the same history can duplicate memory context and make hiding, boundaries, and troubleshooting harder to reason about.

Documentation basis

Sources

Features can change. Check the current project documentation before relying on a specific setting.

Source links Primary project documentation used for this comparison