AI DM Wiki Tools Compared: LoreKeeper Codex vs Self-Hosted LLM Wikis

Why does every long AI Dungeon Master campaign need a wiki?

Every large language model has a context window — the slice of recent conversation it can read at once. Past that edge, content either gets dropped or compressed. AI DM platforms compress, because dropping is worse: a model that has never heard of the king will invent a different king on the spot.

Compression is lossy. The summariser keeps what looks structurally important — recent plot beats, last few decisions — and sands off everything else. NPC personalities are the first thing to go. The exact way a magical item was described. The off-hand remark a stranger made in chapter two that turns out to be the entire mystery. After thirty rounds with a long-running AI DM, the world is shallower than it was at round five, and the campaign quietly drifts.

A wiki fixes this. Not the manual kind a player keeps in a notebook, but a structured set of articles a model can actually read: one entry per named NPC, location, thread and significant piece of lore, with explicit cross-links. When the DM is composing the next scene, it does not have to re-derive who Brother Vesran is from a compressed transcript. It reads his article. That alone is the entire trick.

The interesting question is not whether to have a wiki — every campaign past session two benefits from one. The question is who writes it, when, and how it loops back into play.

What are the two approaches: self-hosted LLM wiki vs auto-compile?

The community has converged on two patterns for solving this. They are not strict opposites — there is some overlap — but the workflow and the consequences are different enough to be worth naming.

1. Self-hosted LLM wiki tools. A script you run on your own machine that ingests raw session text — Discord logs, OBS transcripts, your own typed notes — and asks an LLM to produce structured articles. You schedule it after sessions; the model writes the wiki retrospectively. The canonical reference here is nashsu/llm_wiki, an open-source project that does exactly this, plus a small family of Obsidian plugins doing variations on the theme.
2. Auto-compile inside the play loop.The wiki gets written by the same engine that runs the game, mid-session, the moment something material happens. The articles are immediately available to the AI DM as canonical context for the next turn. LoreKeeper's Codex is built around this pattern, but the idea is older than us — virtual tabletop platforms have been edging toward it for a while.

The difference matters because of what the wiki is used for. In the self-hosted case, the wiki is for you — a reference document you read between sessions, or paste into prompts when you remember to. In the auto-compile case, the wiki is also for the model — it is the canonical context the DM pulls from on every turn, automatically.

What is the DIY path with nashsu/llm_wiki and similar tools?

nashsu/llm_wiki is the cleanest example of the DIY pattern. You give it a folder of Markdown files containing session notes; it reads each one, asks the configured LLM to extract entities and events, and writes Markdown articles into a vault structure that Obsidian can open natively. The output is good — better than what most people write by hand, because LLMs are patient about cross-referencing names and dates that humans get bored of.

The strengths are real:

• Local control. You point it at whatever model you want. Local Llama for full privacy. Claude or GPT for quality. Switch any time.
• No subscription. You pay the model provider directly, on per-token usage. Self-hosted models cost nothing but electricity.
• Markdown-native. Output is plain files. Goes straight into Obsidian, Logseq, a git repo. No proprietary format.

The limits are equally real:

• Retrospective only. The wiki is written after the session. The AI DM playing in real time has no access to it. You can paste articles back into prompts manually, but that is fiddly and easy to forget.
• Manual trigger. Someone has to remember to run the script. If you forget for three sessions, three sessions are unindexed and the wiki drifts out of sync with what actually happened.
• No player-facing UI. The wiki is for the DM. Players who want to read it have to be handed a folder or a published Obsidian vault, which most groups never bother with.
• Source quality dependent. Garbage in, garbage out. If your session notes are messy or missing detail, the model invents to fill the gap. Validation passes help but are not a substitute for clean source text.

If you already keep detailed session notes — actually keep them, with discipline — and you mostly DM solo or for a group that trusts you to be the lore-keeper, this path is excellent. It is the spiritual descendant of the campaign binder. It just has a much better writer.

What is the integrated path with LoreKeeper's Codex?

LoreKeeper takes the opposite stance: the wiki should be part of the play loop, not a separate ritual. After every round where something material happens — a new NPC introduced, a thread advanced, a location described — a four-stage compile pipeline runs in the background and either creates a new article or updates an existing one. The cost is small enough to be invisible (roughly $0.03 per round, $0.04 per article, already absorbed into the plan price) and the latency is masked by the natural pause between rounds.

The deeper article on how that pipeline works lives at How LoreKeeper's AI DM Remembers Your Campaign. The short version: a planner decides what is worth recording, a scout pulls in the surrounding context the writer needs, a generator writes the article in structured Markdown, and a validator flags anything unverified before storing. The output is durable canonical memory, not session memory — and on the very next turn, the DM is reading from it.

Three things follow from running the wiki inside the play loop that do not happen with a retrospective tool:

• Bi-directional memory. The wiki keeps the campaign consistent, not just documented. When Brother Vesran shows up in round 40 of a Heroe campaign, the DM pulls his article from round 15. He still carries the relic he was carrying. The NPC voice does not drift.
• Player-facing Codex. Because the wiki is live, it makes sense to let players read it. Inside every campaign there is a Codex tab — read-only, in-character, organised into Characters, Locations, Quests, Threads and Lore, with inline cross-links and recent revision markers. Players follow what the AI DM remembers without ever leaving the play screen.
• Ask the chronicler.Inside the Codex there is a sub-tab for asking questions in plain language. The cronista answers using citations to actual compiled articles — no hallucinations, no off-world references. “Who is Lyra Moonwhisper and what role has she played in my journey?” gets a paragraph with [Lyra Moonwhisper] and [The Llumun] clickable inline.

There is also a graph view for the visually inclined — every article rendered as a node, connections as edges, communities colour-coded — and a one-click export that produces either a flat Markdown ZIP or an Obsidian-shaped vault. Nothing about the Codex locks you in.

How do LLM wikis and Codex compare side-by-side: workflow, latency, privacy, cost?

The two columns are not in a fair fight — they solve adjacent but different problems. The DIY column wins on privacy ceiling, format ownership and incremental cost at low session volume. The integrated column wins on consistency of the AI DM's memory, setup time and player experience. Which set matters more depends on the campaign.

When should you pick an LLM wiki vs LoreKeeper's Codex?

Honest framing: most DMs do not need to choose. You can run LoreKeeper for the play loop and still export weekly snapshots into your personal Obsidian vault for archival or for solo prep. The decision is only forced when one of these constraints binds:

• Hard privacy requirement.If your campaign contains material you will not send to any third-party API — sensitive personal themes, in-house IP, a setting you are publishing commercially — a self-hosted LLM wiki pointed at a local model is the only correct answer. LoreKeeper's OpenAI pipeline is safe and opted out of training, but “safe” is not “air-gapped”, and we say so.
• You DM exclusively offline. If your tabletop happens at a physical table, with no AI DM in the loop, the LoreKeeper Codex has nothing to do — the value of auto-compile is that the AI reads the wiki next turn. A DIY tool that documents your hand-run sessions retrospectively is the better fit.
• You already have a workflow you love. If you have spent two years tuning a personal Obsidian setup with templates, dataview queries and bespoke plugins, switching to a hosted tool will feel worse, not better. Stick with what you have built — and use LoreKeeper for play, exporting periodically if you want belt-and-braces.

For everyone else — DMs who run AI-mediated campaigns and want the wiki to actually steer the DM's memory — the integrated path is the lower-friction default. The €9.99/mo step from Aventurero to Heroe is the one that unlocks it.

Frequently Asked Questions