How to Keep AI From Forgetting Your Characters: Why Models Drift and What Actually Fixes It

These are not bugs in particular products. They are the shape of the technology, and understanding the shape is the first step to working around it. This article explains why models forget, compares how the major tools try to compensate, and lays out the workflow that, in my experience, reduces character drift to a revision-pass problem rather than a drafting problem.

Why models forget

A language model has no memory. Each time it generates text, it sees exactly one thing: the context window, a fixed-size buffer of text that includes your instruction and whatever else the tool or you placed in it. When the window is full, something has to go. Chat interfaces drop or summarise the oldest turns. Writing tools decide which parts of your manuscript and notes to include.

Three consequences follow:

1. A fact the model has not been shown does not exist. If chapter four is not in the window when chapter nineteen is generated, the hand is back.
2. Facts in the window are used unevenly. Models attend more reliably to material near the instruction and near the end of the context than to material in the middle of a long paste. A detail on page 40 of an 80-page paste is at real risk of being ignored.
3. Generated text becomes fact. If the model invents a scar in chapter ten and that chapter is fed back in, the scar is now canon as far as the model is concerned. Drift compounds.

Window sizes vary widely and change often. As of September 2026, NovelAI's documentation lists context sizes by tier: 8,192 tokens on the Tablet plan and 28,672 tokens (plus 8,192 of rollover) on Opus. Frontier models accessed through chat interfaces or BYOK tools offer far larger windows, in the hundreds of thousands of tokens. But "the whole manuscript fits" is not the same as "the whole manuscript is used." A larger window reduces the first problem and does nothing for the second and third.

How the tools compensate

Every serious fiction tool has a mechanism for putting your facts in front of the model. They differ in how the facts are selected.

The keyword approach deserves a specific warning because it feels like memory and is not. If your Lorebook entry for Mara triggers on "Mara" and the last 2,000 words refer to her as "she," the entry is not in the context, and the model is writing Mara from nothing. Novelcrafter's Codex adds aliases and a "Progressions" feature (time-based changes to an entry) that address part of this; Sudowrite's Story Bible and SparkLore's bible attach entries by scene rather than by keyword. Whatever tool you use, find out which of these it does before trusting it.

The workflow that works

Whatever the tool, the same five habits produce consistent characters. They are habits of the writer, not features of the software.

1. Keep a character card the model can use

A card is not a biography. It is the set of facts a model needs to write this person in this scene without inventing. Mine are around 150 words:

MARA VELL — POV character
Physical (fixed): 41; left hand lost at the wrist (ch 4), wears a leather cap
over it, uses her right for everything; grey eyes; cropped dark hair; a burn
scar on her right forearm from the archive fire.
Wants: to authenticate the succession document before the coronation.
Wound: she erased her family's name from the archive and believes she deserved
to lose it.
Speech: short sentences; never swears; answers questions with questions when
cornered; calls her brother "Teo," never "Theodric."
Never: explains her feelings; touches anyone first; uses the word "sorry."
Current state (as of ch 18): under escort in Teo's house; knows he is dying;
does not yet know about the second witness.

The "Current state" line is the one most writers omit and the one that prevents the most errors. A character card that says who Mara is but not what she currently knows will have her act on information from the wrong chapter.

Our story bible template has the full format. The character sheet is the long form; the card above is the slice that goes into the context.

2. Include the slice, not the bible

For each generation, the context should hold: the cards for the characters in the scene, the one or two world rules in play, the scene card (goal, obstacle, turn), and the last 300 words of the previous text. Not the whole bible; not the whole manuscript. A structured tool does this by tagging; in a chat window, you paste it.

The reason is the middle-of-context problem. A 40,000-word paste containing the fact about Mara's hand is less reliable than a 150-word card containing it, placed directly above the instruction.

3. Ask for less and stop earlier

Request 400 to 600 words, not 3,000. Drift increases with generation length: the further the model gets from the context, the more it relies on its own prior output, including whatever it invented. Short generations, reviewed and corrected before the next one, keep the compounding under control.

4. Never accept a new fact silently

This is the habit that matters most. When the model writes something you did not establish (the scar, the dog, the sister who was at the wedding), stop and decide:

• If it is true, it goes into the bible now. Not in revision. Now.
• If it is not true, delete it from the draft now, so it is never fed back in.

Most character drift I have seen in other writers' manuscripts came from this step being skipped. The model invented a detail, the writer let it stand because it was harmless, the detail was fed back in as context, and three chapters later it contradicted something that mattered.

5. Run a continuity check every chapter

A model is a bad rememberer and a good comparer. Paste the finished chapter with the relevant cards and ask:

Compare this chapter against the character and setting facts above. List every
contradiction: physical details, timeline, who knows what, setting rules. Quote
the line and the fact it contradicts. If there are none, say so.

Do this at the end of each chapter, not at the end of the book. Fixing one contradiction is a minute; fixing forty is a weekend, and by then some of them have propagated.

Naming and pronoun hygiene

Some drift is caused by the manuscript itself making the model's job harder.

• Distinct names. Two characters starting with the same letter (Mara and Marek) or with the same rhythm (Teo and Leo) get swapped by models and by tired readers. Fix it in the bible before drafting.
• Consistent forms. If she is Mara in the bible, she is Mara in the manuscript, not "M." or "Vell" for variety. Aliases are fine if the bible lists them.
• Re-anchor after long pronoun runs. After several paragraphs of "she," use the name once. This helps keyword-based tools trigger and helps every model attend to the right card.
• Explicit state changes. When a fact changes ("Mara took the cap off and let him see the wrist"), it should be stated plainly in the text and updated in the card's current-state line.

What to expect from each tool, honestly

No tool eliminates the problem. What the structured ones do is turn it from a drafting-time failure into a maintenance task. As of September 2026:

• Sudowrite attaches Story Bible sections (characters, worldbuilding, style) to generations and has a "Chapter Continuity" feature; users still report drift, and the Reddit line "the AI sometimes forgets my protagonist has blue eyes, even when it's in the Bible" is widely quoted. The Bible helps; it does not remove the need for habit 4.
• Novelcrafter has the most elaborate structure (Codex with aliases, relations, Progressions for time-based changes, scene-level tagging) and, because it is BYOK, lets you use whatever model has the largest window. The learning curve is the cost; reviewers describe a rough first hour and several hours to master.
• NovelAI relies on the Lorebook plus Memory and Author's Note fields, with the context sizes noted above. It is a continuation engine without chapter structure, and its own users describe the Lorebook's keyword triggering as the weak point.
• General chatbots with memory features are the least transparent: you cannot see exactly what was retained, and there is no scene structure to attach facts to.
• SparkLore attaches bible entries by scene (the characters and rules tagged to the scene are always in the context), includes the previous scene's ending automatically, generates a chapter summary on close, and runs the continuity check from habit 5 as a one-click action. It still depends on you keeping the bible current, which is why the summary step exists.

The differences are real, but they are smaller than the difference between a writer who updates the bible daily and one who does not.

A short case

Chapter 22, generated with a stale card. The card said Mara's current state was "under escort," which was true in chapter 18. In the intervening chapters she had been released and had found the second witness. The generation had her plotting an escape from a house she had left three chapters earlier. Nothing in the model failed; the writer (me) had not updated the current-state line. Twenty minutes of rewriting, and a rule added to the routine: update the card before closing the file, every time.

That is the whole lesson. The model forgets because it cannot remember. The bible remembers because you keep it. The tools differ in how much of the keeping they do for you, and none of them do all of it.

Try it in SparkLore

SparkLore's bible is structured the way the cards above are: fixed facts, wants and wounds, speech habits, and a current-state line that the chapter summary step prompts you to update when you close a scene. Entries are attached to scenes rather than triggered by keywords, so Mara's card is in the context whether the last paragraph called her "Mara" or "she." If you want to see how much a card changes the output, the free AI story continuation tool accepts a passage plus a few character facts; try it once with the facts and once without. Create a project to keep the cards attached automatically.