A character book — often called a lorebook or world info — is a set of entries that get inserted into the prompt only when their keywords appear in the conversation. Instead of stuffing an entire setting into the character description (where it would consume context on every single message), a lorebook keeps that information dormant until it is relevant. This is the single most important technique for building rich, consistent worlds without wrecking your token budget.
The core idea: conditional context
Each lorebook entry has one or more keywords and a block of content. When a keyword appears in the recent conversation, the entry's content is injected into the prompt so the model "remembers" that piece of the world. When the keyword is absent, the entry stays out of the prompt entirely. A card about a detective might have entries for each suspect, the murder weapon, and the city — but only the ones currently being discussed take up space.
Anatomy of a lorebook entry
A typical entry includes: keys (the trigger words), the content to insert, an enabled flag, an insertion order (which entry wins when several fire at once), and a position/depth setting that controls where in the prompt the content lands. Some entries are marked constant — always inserted regardless of keywords — for information the character must never forget, like their own core backstory.
Insertion depth and why it matters
Where an entry is inserted changes how strongly the model weights it. Content placed near the end of the prompt, close to the latest messages, tends to have more influence than content buried at the top. Frontends expose this as a "depth" or "position" setting. Use shallow, high-priority placement for rules that must hold, and deeper placement for background flavor that only needs to be available.
The token budget trade-off
Lorebooks are efficient, but they are not free. Every triggered entry consumes context, and if too many fire at once you can crowd out the actual conversation. Good practice is to keep individual entries tight, avoid over-broad keywords that trigger constantly, and reserve constant entries for genuinely essential facts. Our guide on token efficiency explains how to measure and manage this.
Where lorebooks live in a card
In V2 and V3 cards, the lorebook is stored in the character_book field embedded in the card itself, so it travels with the character. That is why a well-made V2 PNG can carry an entire setting in a single file. V1 cards have no lorebook field, which is one reason to upgrade legacy cards to V2 or V3. Frontends like SillyTavern also support standalone world-info files that you attach separately.
Lorebooks and conversion
Because the character_book is part of the card data, a clean conversion preserves it when both the source and destination support embedded lorebooks. Converting to a format with no lorebook concept — a flat CharacterAI definition, for example — necessarily drops the world info, since there is nowhere to put it. If you rely on a lorebook, convert to a format that supports it (V2 PNG, V3 CharX) and verify the entries came across.
Building a lorebook that helps
Start with the handful of facts the character must know, mark them constant, and keep them short. Then add conditional entries for people, places, and objects the story might visit, each with specific keywords. Avoid generic triggers like "the" or a common first name that fires every message. Test by steering the conversation toward each topic and confirming the right entry activates. A disciplined lorebook makes a character feel deeply consistent; a sloppy one just burns tokens.
