Your novel is more than the chapter open on your screen.

Why context matters in a full-length novel

A novel is a network of consequences. A choice in chapter three may matter two hundred pages later. A secondary character carries a secret. An object changes hands. A motive evolves slowly enough that no single paragraph explains it.

EPOS keeps manuscript material, character information, plotlines, and notes in one project. When you start a task, relevant material can be included within the context available to your plan. You still review every result because a large context window can miss a connection, misunderstand a deliberate change, or place too much weight on the wrong passage.

Why an AI genuinely forgets earlier chapters

Every language model works with a context window: the amount of text it can consider at once for a single answer. Whatever falls outside that window simply does not exist for the answer, even if it belongs to the same manuscript. A second problem applies even when a chapter is technically inside the window: according to a study by Liu, Lin, Hewitt, Paranjape, Bevilacqua, Petroni, and Liang, accuracy drops significantly when the relevant information sits in the middle of a long context rather than at the beginning or end, and this holds even for models explicitly built for long contexts (arXiv:2307.03172, published in Transactions of the Association for Computational Linguistics, 2024, accessed 2026-08-08). A large context window on its own does not guarantee that a decision from chapter three actually gets used in a task about chapter thirty. Anthropic describes a related effect in its own technical documentation as "context rot": as more text fills the window, accuracy and recall degrade (platform.claude.com/docs, accessed 2026-08-08). Manuscript memory has to address both parts of the problem: enough window for the size of your project, and a way of handling the middle of a long text that doesn't let earlier findings quietly disappear.

Context windows for long manuscripts, compared

The table below shows the context windows that providers themselves document for common AI chat assistants, next to the manuscript context EPOS provides depending on plan. A token is not a word; as a rough rule of thumb a token is usually shorter than a word, so the figures below don't convert directly into each other.

Sources: platform.claude.com/docs (Anthropic, accessed 2026-08-08), developers.openai.com/api/docs/models (OpenAI, accessed 2026-08-08), ai.google.dev/gemini-api/docs/long-context (Google, accessed 2026-08-08).

A large context window is not an end in itself. As described above, reliability drops for information in the middle of a long text regardless of window size. What matters for evaluating a tool is less which provider quotes the largest number, and more whether the available context actually covers your manuscript and whether relevant passages are found within it.

Three context sizes for different projects

Context size is different from your monthly word allowance. The allowance controls how much text you can process during a billing month. Context controls how much connected project text can be considered in one task.

What connected context can support

Manuscript memory is not perfect recall

That limit matters. A system that treats every deviation as an error would damage surprise, growth, and contradiction, the very things that make fiction feel alive. EPOS should surface connections and questions, not take authorship away from you.

What you're probably already trying, and where it breaks down

Writers who work directly with a general-purpose AI chat tool usually find their own way of coping with a limited context window. Three approaches come up most often. They exist because the problem is real: a single chapter almost always fits inside a context window, a full manuscript of a hundred thousand words or more does not, even with the largest windows documented today.

EPOS does not fully replace this manual work, manuscript memory remains, as described above, a tool with its own limits. The difference is that chapters, characters, and notes stay connected inside the same project instead of being reassembled for every task. If you're already using one of these three approaches, that isn't a mistake, it's a reasonable response to a real limitation of current tools. The question is only whether you want to keep paying that cost every chapter.

Context window or database: two different paths to memory

When a provider talks about "memory" for long texts, they often mean one of two different things. One path is a large context window: the entire relevant text is resupplied for every task, with the middle-of-text limits described above. The other path is a searchable store, from which specific passages are retrieved as needed, which lets the working context window stay smaller because not everything has to fit at once. For a novel with many characters and subplots, which path a tool takes matters, because it changes the kind of error that can occur. With a pure context window, no information is lost, but it gets used less reliably the more it sits in the middle of a long text. With a retrieval store, a relevant passage can be missed entirely if the search for it doesn't match. Neither path is free of trade-offs, and that is part of the limits already stated above on this page. For you as a writer this isn't an academic distinction: a tool that relies only on a large window can hit the limit described above on a very long manuscript, and a tool that relies only on retrieval can miss a connection it never specifically searched for.

From context to a useful task

Frequently asked questions about manuscript memory

Continue with the right workflow