A campaign wiki that is written by the session, not after it

The reason campaign wikis go stale is not that DMs are lazy. It is that writing one is a second job that happens after a four-hour session, at eleven at night.

Entries come out of what was actually said

Once a session is transcribed, the transcript goes through entity extraction: the model reads it and pulls out the NPCs, locations, items and factions that came up, with a description drawn from what happened rather than from a template.

The extraction is given your existing wiki first. Your current entries, your player characters and your recorded aliases go into the prompt, so when the party calls someone "the innkeeper" in session nine, the mention attaches to the entry you already have instead of creating a second one. That is a deliberate design choice: preventing duplicates at the point of creation is far cheaper than merging them later.

Nicknames are first-class

Tables do not use canonical names. "Thordak Ironforge" is "Thordak" by session two and "Thor" by session five, and a wiki that treats those as three people is worse than no wiki. Aliases map nicknames to the canonical entry, and the wiki search matches them server-side — searching "Thor" finds "Thordak Ironforge".

The same alias list also feeds back into transcription, so a nickname you record once makes every future transcript more accurate. The two systems are wired together on purpose.

You stay in charge of it

This is AI-assisted, not AI-governed. Any field you edit by hand is locked per-field, and later AI passes will not overwrite it. That is enforced in the data model rather than being a convention — the system records which specific fields a human edited.

Duplicate detection proposes merges rather than performing them. Off-topic detection flags entries that look like table talk or real-world references rather than campaign content — pizza orders, arguments about rules, someone’s cat — and you review before anything is hidden. Deleting, bulk-deleting and merging are restricted to the GM of the campaign.

Sharing it with players without leaking your notes

A campaign wiki can be published as a read-only page for players via a link. The link expires, can be revoked, and your private GM notes are excluded from the shared payload on every read path — not hidden in the interface, actually not sent.

Share links live for a maximum of 90 days. The tokens are stored hashed, so a copy of the database does not hand someone a working set of share URLs.

What this does not do

It does not build a world you have not played yet. Everything here is derived from what happened at the table. If you want to author a continent, a pantheon and four hundred years of history before session one, use a worldbuilding tool — World Anvil, LegendKeeper and Kanka all do that far better than this does, and we would rather say so than waste your evening.

It is not a virtual tabletop. No maps, no tokens, no combat tracker, no dice.

Extraction is a model reading a transcript, so it is wrong sometimes — it will occasionally promote a throwaway joke to an NPC. The review tools exist because that is expected behaviour, not a defect you should have to tolerate silently.

Which plans include it

Included on every plan. Sharing a wiki with players requires Dungeon Master or above. The free plan covers one campaign; paid plans are unlimited.

Full pricing

The rest of what it does

All features