What Is a Lorebook? AI Worldbuilding, Explained
You spent a Saturday on it. Forty-one entries: every named character, the three rival houses, the rules of your salt-magic, the layout of the harbor district down to which pier the customs office sits on. You hit generate on chapter one, and the model wrote a scene in which your protagonist walks past a generic market and buys generic bread from a man with no name and no allegiance.
The lorebook was right there. The AI acted like it didn't exist.
This is the single most common failure in AI-assisted fiction, and it isn't a bug. It's what happens when you build a lorebook the way you'd build a story bible, without understanding that the two things are aimed at completely different readers.
What a lorebook actually is
A lorebook is a set of worldbuilding entries, each tagged with keywords, that an AI writing tool pulls into the prompt only when one of those keywords shows up in your recent text. It's a reference library with a retrieval rule attached. Nothing in it reaches the model until something triggers it.
NovelAI's documentation puts it plainly: the Lorebook is "a repository for supplemental information that's added to the AI's context as each entry comes up in your story," and "when an activation key is found in the recent context, the entry's text gets inserted into the context." SillyTavern, where a huge amount of this vocabulary was hammered out, describes the same mechanism under the name World Info — "also known as Lorebooks or Memory Books" — a tool "to insert prompts dynamically into your chat." Character.AI shipped its version with the same architecture: "Each entry has keywords. When a keyword comes up in conversation, the Character gets access to that entry and can weave it into its response."
Different products, one idea. You are not writing a document the AI reads. You are writing a set of index cards the AI is handed, one or two at a time, when the story happens to ask for them.
Lorebook vs. story bible: the difference that matters
A story bible is written for you. A lorebook is written for the model, and it's judged on whether it fires.
That's the whole distinction, and it has consequences all the way down. Your story bible can be 14,000 words of loose notes with a half-finished timeline and a paragraph where you argue with yourself about whether the sister should die. It's fine — you're the reader, you have judgment, and you'll notice the contradictions.
A lorebook entry has none of that slack. It gets injected verbatim into a prompt, competing for a fixed token budget, with no human in the loop to say "ignore that part, I changed my mind in March." If it's ambiguous, the model writes the ambiguity into your scene.
Here's the line worth keeping: a story bible is what you know; a lorebook is what the model is holding right now. One is memory. The other is working memory, and it's smaller than you think.
Most tools blur the names, which is why writers get confused. NovelCrafter and NovelMage both call it a Codex. Sudowrite calls its version a Story Bible. Underneath the branding, they're all doing the retrieval trick, and if you've read our breakdown of why AI forgets your story details mid-draft, you already know why that trick exists: context windows are finite and your novel isn't.
How an entry actually fires
Four settings decide whether your entry reaches the model. Learn these and most lorebook mysteries evaporate.
Keys. The trigger words. NovelAI matches them case-insensitively and supports an & operator, so a key of NovelAI & Anlatan only fires when both words land inside the search window. Keys are where beginners lose the most ground — more on that in a second.
Scan depth / search range. How far back the tool looks for those keys. NovelAI searches a set number of characters of recent story, up to a maximum of 10,000. SillyTavern counts messages instead. Either way: text outside that window is invisible to the trigger check. A character mentioned in chapter 9 and never again does not keep their entry alive in chapter 31.
Always-on. Every serious implementation has an escape hatch for entries that must always be present. SillyTavern marks them constant (blue circle) versus keyword-triggered (green). NovelCrafter's Codex tracking settings offer "Always include" — "the entry is always added to the AI context, regardless of whether it was detected in the current text" — against the default, "Include when detected."
Token budget and insertion order. There's a ceiling on how much lorebook material can load at once, and when it's hit, entries get dropped. NovelAI sorts by insertion order, where higher values reserve tokens first. SillyTavern lets you set the World Info budget as a percentage of context or a flat token count, and once it's exhausted, "no additional entries activate." Nothing warns you. The entry just quietly isn't there.
The four reasons your lorebook didn't fire
When a writer posts the AI ignored my entire lorebook, it's almost always one of these.
The cold open. You started a fresh chapter with no keys in the text yet. In a thread from a NovelAI user who'd sunk 14 hours into 40-plus entries only to have every one ignored, the top reply was the diagnosis: "If a lorebook entry doesn't have the 'Always On' option enabled, or if one of its keys hasn't been mentioned in the story context, the AI won't see it." A lorebook can't bootstrap itself. Something in your visible text has to say a name first.
Pronoun drift. Chapter 12 opens with she and stays with she for 900 words. Your entry keys on Wren. The scan window fills with pronouns, epithets, and job titles, and never once contains the string that would fire the card. This is the silent killer, because the writing looks perfectly normal.
Name variants. Possessives, plurals, nicknames, and inflections all break naive matching. NovelCrafter auto-matches common plurals in English projects but warns that "more complex plural forms (e.g. 'Wolf' → 'Wolves') are not automatically matched." If your faction is the Wolves and your key is Wolf, you have a coin-flip lorebook.
Budget eviction. Ten entries fired, six fit. The ones that got cut were the ones you'd have picked.
A worked chapter: 47 entries, three that mattered
Take a concrete case. Maren is 61,000 words into a political fantasy with 47 lorebook entries — 22 characters, 11 locations, 9 factions, 5 magic-system rules. Her entries average about 140 words each. If every one loaded at once, that's roughly 6,600 words of reference material shoved into the prompt ahead of her actual chapter — for many setups, more than the whole context budget, and for all of them, a catastrophic waste.
Chapter 31 is one scene: her spymaster Ilse meets a customs clerk on Pier Four to trade a forged manifest. The entries that genuinely matter are Ilse, Pier Four, and the forgery rules of the salt-magic system. Three. Everything else is noise for this scene, and Maren's job is to make sure exactly those three fire.
So she checks her keys. Ilse is there, but chapter 31 calls her the spymaster for the first four paragraphs, so Maren adds spymaster as a key. Pier Four appears as Pier Four, the fourth pier, and — because she wrote it that way in chapter 22 — Four. That last one is dangerous: bare Four will fire on any number, so it goes in as a phrase, not a bare word. The salt-magic forgery rule she marks always-on, because it constrains every scene in the book and she'd rather pay its 90 tokens permanently than debug why a forgery worked when it shouldn't have.
She also builds one cascade: her Pier Four entry mentions the Harbormaster's Office by name, which fires that entry on the next pass. One trigger, two loaded facts, no extra keys. It's the trick the same NovelAI thread recommends — "a sort of cascade of triggers," where one entry's text contains the keywords that pull in its neighbors.
Result: three to four entries active, maybe 500 words of context, and a scene where the clerk has a name, the pier smells right, and the forgery fails for a reason the magic system already established. Forty-seven entries in the book; three in the prompt. That ratio is the entire skill. Any tool that matches entries as you type and shows you what loaded — NovelMage's Codex does both — turns this from an audit into a glance, but the discipline underneath is tool-agnostic.
Writing entries the model can actually use
Six rules, learned the hard way.
Keep entries between 50 and 150 words. One well-known lorebook playbook puts the floor at 30 words — below that there's no usable detail — and warns that entries over 300 words "consume excessive tokens and crowd out other relevant entries." Assume only a handful are active at once and write each to be useful alone.
Make every entry self-contained. The model may see this card with no siblings. "Her brother's betrayal still defines her" is useless if the brother's entry didn't fire. Name him inside her entry.
Front-load the load-bearing fact. If Ilse's defining trait is that she lies by omission and never outright, that's sentence one, not sentence six. Trimming happens from the end.
Overstock your keys. Name, surname, nickname, title, epithet, plural, and the two misspellings you keep typing. Keys are cheap; a card that never fires costs you the whole entry.
Cap your always-on entries at two or three. They're a permanent tax on every generation. Premise, POV rules, and the one magic-system constraint that governs everything — that's usually the whole list.
Version facts that change. "Ilse trusts the Harbormaster" is true until chapter 24 and poison after. Either date the fact inside the entry ("as of the coronation; after the pier fire, she suspects him") or split it into two entries keyed to terms that only appear in their own half of the book.
And the honest caveat: if your cast is six people in one town, skip the lorebook entirely and put nine sentences in your always-on memory block. Retrieval machinery is for worlds that outgrew a single paragraph.
The part nobody mentions: your lorebook is a prompt
Every entry that fires gets transmitted with your chapter. That's fine when it's a description of a harbor. It's a different conversation when your lorebook contains the ending, the twist, the identity of the traitor, and the unpublished 90,000 words those spoilers belong to — all of it going out to a third-party API on every generation.
Two mitigations. First, most tools have a "never include" setting for spoiler and reference-only entries — NovelCrafter's is explicit about it, and it's the right home for anything you're keeping from the model on purpose. Second, run the model where the manuscript already lives. NovelMage connects to Ollama or LM Studio for fully local generation, which means your Codex and your draft never leave the machine — and if you'd rather use Claude, GPT, or Gemini, you bring your own API key instead of routing through someone else's server.
Frequently Asked Questions
Is a lorebook the same thing as a story bible?
No. A story bible is a reference document you read; a lorebook is a keyword-triggered retrieval system the AI reads. A bible survives being messy because you have judgment; a lorebook entry has to be correct, self-contained, and short enough to survive the token budget. Most writers want both — the bible for planning, the lorebook as its distilled, machine-facing edition.
Why isn't my lorebook entry showing up in the output?
Almost always one of four things: no activation key appears in your recent text (the most common, especially at the start of a chapter), the key doesn't match the form you actually wrote — plurals and possessives break naive matching — the entry sits outside the scan window, or the token budget filled up and lower-priority entries were dropped. Most tools have a context viewer showing exactly which entries loaded on the last generation; check it before you rewrite anything.
Do I still need a lorebook with a million-token context model?
Yes, for two reasons. Attention degrades across very long contexts, so a fact buried at position 400,000 is not as reliable as the same fact injected 200 tokens before the generation point. And you pay for every token you send, on every generation — a lorebook that loads 400 relevant words instead of 6,600 irrelevant ones is both cheaper and sharper. Selective retrieval isn't a workaround for small context windows; it's just better prompting.
Can I keep a lorebook if I write offline?
Yes. Lorebooks are a prompt-assembly feature, not a cloud feature — the tool builds the prompt locally either way. NovelMage's Codex works identically whether you're generating through a local model in Ollama or LM Studio or through a cloud API key, and it's a one-time $99.99 lifetime license covering up to three devices, with a 7-day free trial and no card required if you want to test your own entries first.
Start with three entries, not forty
The writers who get the most out of lorebooks don't build them in a weekend. They add an entry the first time the AI gets something wrong, key it to whatever word was actually on the page when it happened, and let the book grow out of real failures rather than an imagined index.
If you want a lorebook that fires without you babysitting it, NovelMage's Codex is built for exactly this loop — entries pulled in automatically as you write, on a desktop app where your manuscript stays on your own disk. You can try it free for seven days and see how many of your forty-one entries you actually needed.