How to Structure a Large Kobold AI Lorebook Without Wasting Context

A large lorebook should behave like a well-organized reference system, not a second novel pasted into every prompt. The goal is to retrieve the smallest useful set of facts for the current scene while keeping core rules predictable.

Quick answer: split lore by subject, keep entries self-contained, separate permanent rules from situational details, remove repeated facts, and assign context space according to importance. Test ordinary scenes—not just ideal keyword matches—to find entries that fire too often or crowd out more useful information.

Why large lorebooks become difficult

Adding entries feels harmless because inactive entries usually cost little or no prompt space. The problem begins when broad keys, overlapping subjects, and recursive activation cause many entries to appear at once.

That can create three different failures:

important character instructions receive less attention;
old or duplicated lore conflicts with the current scene;
the model spends tokens restating background instead of advancing the story.

The number of entries is therefore less important than the size and relevance of the entries activated during a typical turn.

Design around retrieval units

Treat each entry as a retrieval unit: one piece of information that remains useful when inserted by itself.

A practical unit might cover:

one named location;
one faction and its current goal;
one supporting character;
one item with special rules;
one law, custom, or magic-system constraint.

Avoid entries such as “Northern Continent” that contain every city, ruler, war, and religion in one block. Mentioning a single city would then inject information unrelated to the scene.

Split by trigger, not by document chapter

Your private world bible may have a chapter called “History,” but a lorebook rarely needs a single history entry. Divide it according to the phrases that appear in play: the Ash War, Queen Meriel, the ruined gate, and the peace treaty can be separate entries.

If two facts should activate in different conversations, they belong in different entries.

Use a three-tier information hierarchy

Large projects are easier to manage when facts have an explicit tier.

| Tier | Put here | Retrieval behavior | | --- | --- | --- | | Core | Fundamental world rules that affect nearly every scene | Always active, but extremely short | | Regional | Locations, factions, cultures, and recurring supporting characters | Activated by specific names or aliases | | Scene-level | Temporary rumors, quests, local objects, and current complications | Narrow triggers; archive or revise when resolved |

The core tier should be small. If a rule matters only inside one kingdom, keep it with that kingdom instead of making it globally active.

Scene-level entries also need maintenance. A rumor that was proven false should not remain written as a present fact. Update it, mark it as historical, or remove it from active retrieval.

Give every fact one authoritative home

Duplication is one of the largest hidden context costs. A character's allegiance might appear in the character card, a faction entry, a city entry, and a session summary. When one copy changes, the others become stale.

Choose an authoritative source:

identity and stable voice belong in the character definition;
durable world facts belong in the relevant lore entry;
current location and immediate goal belong in active context;
confirmed story changes belong in a compact memory or summary.

Other entries can point to the authoritative subject without repeating its full description. For example, a city entry can state that Captain Voss commands the harbor guard; her motives and speech pattern can stay in her own entry.

Budget entries by what the model needs to do

There is no universal ideal entry length. Use the shortest text that enables the desired response.

A location entry often needs:

one sentence establishing what the place is;
two or three details that affect the current scene;
one active conflict or constraint.

It usually does not need travel-guide prose, a complete timeline, or descriptions of people who have their own entries.

Compare these approaches:

Overloaded:

Glass Harbor was founded 640 years ago and contains twelve districts, seven temples, four noble houses, a detailed tax code, and a long succession of rulers...

Actionable:

Glass Harbor is an independent fogbound port governed by a five-member council. Unlicensed magic is prohibited within the harbor walls. The Ash Guild controls the lighthouse district after sunset and searches unfamiliar cargo.

The second version gives the model usable constraints for dialogue and action.

Prevent activation cascades

Some lorebook systems can scan inserted entries for additional keys. This is useful when a location should retrieve its governing faction, but it can also create a chain of loosely related entries.

Watch for:

an entry containing many other character names;
generic keys such as city, magic, guard, or school;
circular references between two entries;
a parent entry that activates every child entry at once.

Use recursive or secondary activation deliberately. If the scene only needs one sentence about a faction, include that sentence in the location entry rather than retrieving the faction's entire history.

Organize keys for precision

Each entry should include the language users actually type:

exact name: Glass Harbor;
common short form: the Harbor when unambiguous;
title or alias: Captain Voss;
distinctive associated phrase: eastern cargo gate.

Do not compensate for a vague entry by adding dozens of broad keys. More keys can increase recall while sharply reducing precision.

If your frontend supports filters, groups, priorities, or selective logic, use them to express a real rule. Do not add complicated conditions until a simple key test shows why they are needed.

A maintenance-friendly entry format

Use a consistent internal structure even if the interface stores fields separately:

Subject: Glass Harbor
Type: Location / regional
Keys: Glass Harbor, the Harbor, eastern cargo gate

Facts sent to the model:
Glass Harbor is an independent fogbound port governed by a five-member council.
Unlicensed magic is prohibited within the harbor walls.
The Ash Guild controls the lighthouse district after sunset.

Maintenance note:
Review after the harbor-council storyline is resolved.

Keep maintenance notes outside the text sent to the model when the tool permits it. Their purpose is to help the author, not influence the roleplay.

Audit a large lorebook in four passes

Pass 1: Find oversized entries

Sort or scan for the longest entries. Ask whether every paragraph shares the same trigger and is needed in the same scene. Split entries when the answer is no.

Pass 2: Find repeated facts

Search for proper names, relationships, and world rules. Select one authoritative home for each repeated fact and shorten the others.

Pass 3: Find broad triggers

Review common nouns and short aliases. Test them in unrelated dialogue. Replace false-positive keys with proper names or distinctive phrases.

Pass 4: Test prompt occupancy

Run three representative scenes: a quiet conversation, a busy location with several named entities, and a transition between regions. Inspect the active entries if your frontend exposes them. The busy scene reveals whether the lorebook floods the prompt under realistic load.

What to do when the prompt is still crowded

First, remove repetition. Then shorten activated entries. Only after that should you reduce the number of active subjects.

Useful options include:

moving completed quest details into a session archive;
replacing a long history with its current consequence;
loading supporting-character details only when that character is present;
separating author notes from model-facing text;
creating a concise regional overview and retrieving deep detail only when requested.

Do not solve every problem by increasing the context window. More capacity can help, but irrelevant or contradictory text remains irrelevant or contradictory.

Frequently asked questions

How many entries can a Kobold AI lorebook contain?

The practical limit depends on the frontend, backend, context size, and how many entries activate together. A large collection of precise inactive entries can be easier to manage than a small collection of broad entries that all fire at once.

Should one character have multiple entries?

Yes, when different facts need different triggers or timing. Stable identity can stay in the character definition, while a secret identity or location-specific relationship can live in a narrowly retrieved entry.

Should I put prose or bullet points in lore entries?

Either can work. Direct, unambiguous sentences matter more than format. Use prose for relationships and causality; use compact lists for attributes that are genuinely independent.

Does a larger context window remove the need for a lorebook?

No. A larger window increases capacity, while a lorebook controls relevance. Retrieval still helps keep the current prompt focused.

When should I delete an entry?

Delete or archive it when it no longer describes the current world and has no historical use. If a past event still affects the story, rewrite the entry around its lasting consequence.

A scalable lorebook is not the one with the most text. It is the one that retrieves clear, current, non-duplicated facts at the moment they can change the next response.