Romance chapter continuity: 32k context vs chunked retrieval

This guide shows romance authors how to keep chapter continuity across a 100,000-word novel using a bounded 32k-token context window.

It prescribes a per-chapter handoff ledger and injection of only that ledger plus the previous chapter.

How 32k Context Actually Fails Romance

Start with the arithmetic, because it decides everything else. A 100,000-word romance manuscript converts to roughly 130,000–150,000 tokens at the standard ratio of about 0.75 words per token for English prose. A 32k-token context window holds about 24,000 words at that same ratio. Divide 24,000 by 100,000 and you get 24% — at most, one quarter of your novel is visible to the model at any moment. Run the check on your own manuscript: take your word count, divide by 0.75, and compare the result to your model's window size. If the token count exceeds the window, no amount of prompting will make the full book fit.

That 24% figure has a second consequence most authors miss. The window is not reserved for your manuscript alone. The current chapter draft, the system prompt, your style instructions, and the model's own in-progress output all consume tokens from the same 32k budget. If your previous chapter runs 4,000 words (about 5,300 tokens), your effective manuscript visibility drops well below 24%. The practical rule: budget the window explicitly — ledger, previous chapter, current draft, output — and write the budget down before drafting, not after.

The failure mode is not hypothetical. Users on community.openai.com have documented repeated continuity and retrieval failures, both within conversations and across conversations and projects, reporting that the model cannot reliably remember the contents of its own last few messages in extended sessions. If a model can lose track of what it said two messages ago in a long session, it cannot be trusted to hold a promise made in chapter three while drafting chapter twenty-four. Treat model memory as a cache, not an archive.

This is why the failure pattern in romance is specific. Romance continuity lives in small, scattered facts — a scar introduced in chapter two, a promise made on the porch in chapter seven, a timeline where the harvest must precede the wedding. None of these facts is large, but each one is far from the drafting point, and anything outside the window is effectively deleted. The model does not "forget slowly"; it forgets completely, the moment the fact scrolls out of context.

The check that catches this: after each drafting session, compare your ledger's open promises and physical states against the chapter you just wrote. If the ledger was not in the window during drafting, assume any fact from earlier chapters was invisible to the model, and verify each one against the ledger rather than against the model's confidence. The model will sound certain either way — certainty is not evidence of visibility.

The Evidence: What Sources Converge

The pattern behind this book's method is not a hunch. Three independent sources, arriving from different directions, converge on the same conclusion: retrieval structure beats raw context length. This section states that convergence once, plainly, so you can weigh it yourself.

The first source is Satya Anudeep's June 24, 2026 dev.to post on building RationaleVault. The core admission is blunt: plain RAG document retrieval "does not help an AI continue work." That distinction — cognitive continuity versus document lookup — is exactly the distinction a romance manuscript needs. Fetching a scene where the heroine's sister appeared is not the same as knowing the sister is currently mid-flight and owes the heroine an apology from two chapters ago. RationaleVault exists because lookup alone fails at continuation, which is the entire job of drafting chapter forty-one.

The second source is the getcontinuity.io documentation. Its shipped production pattern is not a bigger window. It is git-owned decision files, a session handoff document, and bounded search triggered only on file-touching calls. Read that as an engineering verdict: the teams shipping this chose structured state plus a small injected handoff over raw long context. The structural parallel to a novel is direct — a per-chapter ledger is your decision file, and the previous chapter is your handoff.

The third source is the failure side. The OpenAI community thread on GPT-5.6 documents repeated continuity and retrieval failures both within conversations and across projects, with the reporter pushing OpenAI Support for investigation. Whatever the eventual fix, the reported behavior confirms the risk you are engineering around: a model cannot be trusted to hold its own recent state without external structure. That is the same failure mode that drops a secondary character's eye color between chapters.

Convergence matters because the sources disagree on everything else. One is a memory-platform build log, one is a code-governance product's docs, one is a user complaint thread. They share no vendor, no author, no incentive to agree. Yet all three land on the same rule: maintain state outside the model, inject it deliberately, and search in a bounded way when needed. When independent failures point to the same fix, the fix is probably real.

Your check is simple. Before trusting any drafting workflow, ask whether it maintains a ledger the model does not have to remember. If the answer is "the model will recall it," you are betting on the exact behavior the community thread reports failing. If the answer is "the ledger holds it and you inject it," you are aligned with all three sources.

Full Context vs Ledger vs RAG Compared

Three approaches compete for keeping a romance manuscript coherent: stuffing the full draft into the context window, running pure retrieval-augmented generation over chapter files, or maintaining a handoff ledger. This section gives the verdict the other chapters build toward: the winner is the ledger plus the previous chapter, injected together. It fits any context window regardless of manuscript length, it is human-readable and editable in a text editor, and it survives model or tool changes. The Continuity project's design is the proof this pattern is durable — its `.continuity/` folder stores decisions as plain JSON in git, so the ledger outlives any single model, extension, or vendor.

Full context loses on reach. A 32k-token window holds only a fraction of a 100,000-word manuscript at once, so the model drafts blind to everything outside the slice you feed it. Worse, the slice itself is unreliable: community reports on OpenAI's support forum describe repeated continuity and retrieval failures "both within conversations and across conversations/projects," with the model unable to remember contents of its own last few messages. If in-window content gets dropped in long sessions, the assumption that "more context solves it" collapses. The check: at the end of any drafting session, ask the model to restate a fact from an early chapter in the same session. If it cannot, do not trust the window.

Pure RAG loses on rationale. The dev.to analysis of RationaleVault makes the distinction directly: retrieved passages do not help an AI continue work, because they arrive without the reasoning that connects them. For a romance manuscript, that means a retrieved passage reminding the model that the heroine promised to sell the ranch arrives stripped of why she promised, to whom, and what it cost her — exactly the causal chain that sequence errors break. The fix is structural: the RationaleVault author built a memory platform "designed around cognitive continuity rather than simple document retrieval," which is what a handoff ledger is when you maintain it yourself.

The ledger wins on three testable criteria. First, boundedness: ledger plus one chapter is a fixed, small payload, so it fits any window — verify by checking token count before each session. Second, editability: a plain-JSON or markdown ledger can be corrected by hand when the model writes something wrong, which no opaque context can be. Third, portability: because the ledger lives in your repo, not in a vendor's memory, switching models or tools costs nothing — the same property git ownership gives the Continuity project's decision records.

Run one comparison test before committing. Draft the same transition scene three ways: full-context slice, RAG-retrieved passages, and ledger-plus-previous-chapter. Then audit each output against your ledger for timeline, promises, and physical states. In practice the ledger version is the only one where every fact you check has a visible source you can edit — and that auditability, as the workflow-governance argument puts it, is what makes the process "reviewable later."

Costs: Hours and Tokens Per Chapter

The ledger method's cost case rests on two numbers you can check yourself, and both are estimates of method, not measurements of any particular manuscript. First, maintenance: writing a 10–15 line ledger entry after finishing a chapter — names used, timeline advances, promises made, injuries and physical states carried forward — takes roughly 5–10 minutes while the chapter is fresh in your head. Second, the alternative: re-reading the full manuscript before each drafting session at a typical reading pace of about 250 words per minute means 100,000 words consumes 400 minutes, or roughly 6–7 hours, every single session. Divide it out: 360–420 minutes against 5–10 minutes is a 36–84x difference in preparation time per session, depending on how thorough your ledger entry is.

The token cost tells the same story from the model's side. A 300-word ledger converts to roughly 400 tokens at the standard ratio of about 0.75 words per token for English prose, and a 3,000-word previous chapter adds roughly 4,000 tokens, so a full injection is about 4,400 tokens per session. Compare that to a maxed 32k window, where the usable drafting context — after the model's own instructions and your prompt consume their share — sits around 24,000 tokens. That is roughly a 5x reduction in per-session context spend, which matters because every token of continuity material you inject is a token not available for the actual scene you are drafting.

Here is the practical rule that falls out of the math: budget your ledger entry at the moment you finish a chapter, not the next morning. The 5–10 minute estimate only holds when the details are fresh; reconstructing them a day later is when authors start guessing, and guessed ledger entries are how errors get laundered into the file that is supposed to prevent them. If you find yourself unsure about a detail while writing the entry, mark it "verify" in the ledger rather than writing a plausible guess.

There is also a check for whether your ledger is sized correctly. If your per-chapter entry regularly exceeds 15 lines, you are probably logging scene detail rather than continuity facts — the ledger should hold what a future chapter needs to know, not what happened in the scene. A quick test: could a stranger drafting the next chapter, given only the ledger and the previous chapter, avoid contradicting anything earlier? If not, the entry is missing a fact; if the entry reads like a synopsis, it is carrying dead weight that inflates your token spend.

One honest caveat on the arithmetic: the 250 words-per-minute reading pace and the 5–10 minute entry time are working estimates, not findings from a controlled study of romance authors. The 36–84x and 5x figures are therefore ratios of estimates, useful for deciding between methods but not for predicting your exact session length. What the math does establish is the direction and the magnitude of the gap — and the gap is large enough that the choice between re-reading and ledger maintenance is not a close call.

What the Evidence Does NOT Establish

The only point this section establishes is a lack of measurement: none of the sources in the available sources report a measured continuity-error rate for either approach in fiction. There are no percentages of caught or missed errors, no participant counts, and no controlled trials. With that absence, any tool marketing a specific error-rate figure for romance manuscripts is unsupported by the listed material.

That gap becomes more apparent when looking at cross-domain claims. The Continuity whitepaper (getcontinuity.io/whitepaper#evaluation) does claim benchmarks, but its documentation scope shows those benchmarks are for AI-assisted codebases, not prose manuscripts. The transfer of those results to romance drafting is an analogy, not a validated result. A benchmark existing in one domain does not create one in fiction by default.

Even with the discipline of a ledger, there are edge cases where the rule can break. If a fact is never written to the ledger to begin with, retrieval cannot pull it from outside the context. If the ledger is not updated the moment a fact changes, the injection of only the ledger plus the previous chapter will carry that outdated fact forward. These are not theoretical impossibilities, but they are also unmeasured by the available sources, so they can only be treated as checks to enforce, not as figures to compare.

100k-Word Romance Ledger

Take a 100,000-word romance split into 24 chapters of about 4,200 words, written in dual POV. After each chapter, append one row to the continuity ledger. The next drafting session injects only that ledger, about 300 words, plus the previous chapter, about 4,200 words—roughly 6,000 tokens total. The working set stays small, and the model receives the compressed state plus the immediate scene.

Checkpoint one is chapter 8: the ledger row records the boat promise and the heroine's false belief. Checkpoint two is chapter 17: the injected ledger surfaces that promise, so the model can write the boat-sale scene from the row plus chapter 16 instead of rereading chapters 1 through 16. Checkpoint three is chapter 24: a scan of every ledger row for "promised" shows whether that promise was resolved or still open before the ending.

The ledger row is the unit of memory. A useful row names the chapter, day, fact, and status, not a summary of the scene. The example row above is enough for a later chapter to act on the fact without reconstructing the original conversation.

This keeps dual-POV continuity manageable because both viewpoints' states fit in the same 300-word ledger. The previous chapter supplies voice and immediate momentum; the ledger supplies names, timeline, promises, and physical states. If the two conflict, correct the ledger first, because it is the record you can inspect.

Run two checks after every chapter: the ledger has exactly one new row for the chapter just finished, and any promise, injury, secret, or object introduced in that chapter appears in that row. If a keyword scan at the final chapter finds an unresolved promise, resolve it in revision rather than trusting that the model retained it.

Worked Example: Run the Numbers

Illustration only: a 90,000-word contemporary romance in 30 chapters of 3,000 words each, with a party of two leads, one ex, and one child. Timeline markers are Day 0 first kiss, Day 4 breakup, Day 11 reunion, and Day 18 proposal; the continuity check occurs at Chapter 20. The ledger carries those dated promises, so a Chapter 12 line saying "three days later" conflicts with the Day 11 reunion.

Using the planning ratio of 0.75 words per token (4/3 tokens per word), one chapter is 3,000 × 4/3 = 4,000 tokens and the full manuscript is 90,000 × 4/3 = 120,000 tokens. Assume the cumulative ledger grows by 150 tokens per chapter, so by Chapter 29 it holds 29 × 150 = 4,350 tokens.

For this example, ledger plus previous chapter wins: it is the smallest injection that still contains the immediately prior scene in full, while the ledger preserves the dated facts needed to catch sequence errors. The RAG pull fits but spends most of the spare budget on older prose that may not be the exact scene being continued.

The spare 23,650 tokens are not spare chapters; they cover system instructions, style notes, retrieval formatting, and model output. Break-even occurs when cumulative ledger plus previous chapter plus fixed overhead reaches 32,000 tokens: with a 4,000-token chapter and 2,000-token overhead, the ledger can reach 32,000 − 4,000 − 2,000 = 26,000 tokens, or about 26,000 ÷ 30 ≈ 867 tokens of new continuity facts per chapter. If a chapter adds more than about 867 tokens, compress or split the ledger before the next injection.

Decision Rules: When to Use Which Approach

Use the ledger when the manuscript outgrows a single context window or when drafting spans more than one session; otherwise, keep the workflow simple. A 32k window is a boundary, not a target, and the decision is whether the model can still see every continuity fact at once.

The short-story exception: if the manuscript is under about 20,000 words, roughly 26,600 tokens, skip the ledger. The whole draft fits inside a 32k window, and re-reading the draft is cheaper than maintaining a separate file. Use the ledger only when the draft no longer fits or when you need to resume later.

If you are drafting chapter by chapter across multiple sessions, always inject the ledger plus the previous chapter. Never start a session with only a summary. Per dev.to, summaries without rationale break continuation: they compress events but drop the reasons, constraints, and open promises that the next chapter must honor. The ledger keeps those facts explicit; the previous chapter keeps voice and immediate cause-and-effect intact.

If you switch models or tools mid-draft, treat the ledger as the continuity that survives. Keep it outside the model context in a plain file you own and version, and inject it deliberately at the start of each session. Chat history, project memory, and tool-specific context may not transfer; the ledger does because you control its contents.

When in doubt, default to the ledger plus the previous chapter for any manuscript above the short-story threshold, any draft that will be resumed, or any novella that grows past the threshold during revision. The cost is minutes per chapter; the failure mode is a sequence error that a reader notices before you do.

Frequently Asked Questions

How can I check whether my own manuscript fits in my model's context window?

Take your word count, divide by 0.75, and compare the result to your model's window size.

What happens if my manuscript's token count exceeds the window?

If the token count exceeds the window, no amount of prompting will make the full book fit.

What does the guide prescribe injecting for chapter continuity?

It prescribes a per-chapter handoff ledger and injection of only that ledger plus the previous chapter.

Why is the 32k window not fully available for manuscript text?

The current chapter draft, the system prompt, your style instructions, and the model's own in-progress output all consume tokens from the same 32k budget.

How does a 4,000-word previous chapter affect manuscript visibility?

If your previous chapter runs 4,000 words (about 5,300 tokens), your effective manuscript visibility drops well below that 24% figure.

What is the practical rule for using the context window?

The practical rule is to budget the window explicitly across the ledger, previous chapter, current draft, and output.

Quick answers

Also worth reading: Writing long novels that stay consistent: 214 manuscripts, 35% continuity cut: Writing long novels that stay · Why the 5 time rejected gamma and the lycan king is the next big thing in werewolf romance: Why the 5 time rejected · Spicy fae romance sales: ACOTAR-style BookTok lift 2021-2024, Amazon vs Kobo revenue split: Spicy fae romance sales: ACOTAR-style