ainovel-cli: A Workflow Engine for Long-Form AI Novel Writing

AI can write fast, but the longer it writes, the more it forgets -- characters, plot threads, foreshadowing, and pacing all start to unravel. ainovel-cli exists to solve that specific problem: keeping long-form AI-generated fiction coherent across hundreds of chapters.

What it is

ainovel-cli is a fully automated AI long-form novel creation engine. Its official description calls it a deterministic engine that runs the entire book, with the model invoked precisely at each point where judgment is needed. The engine routes three autonomous creative agents -- Architect, Writer, and Editor -- through a fact-based route table, while a fourth agent called Arbiter is woken only for semantic decisions that cannot be resolved by deterministic logic.

The key architectural claim is that the main loop has zero LLM cost because deterministic code decides the next worker based on stored facts, not by asking a model what to do next. The project supports rolling volume and arc planning, hierarchical summaries, relevant chapter recommendation, a TUI interface, Docker deployment, and multiple LLM providers including OpenRouter, Anthropic, Gemini, OpenAI, Ollama, and Bedrock.

Why it matters

• Long fiction needs memory. A novel spanning hundreds of chapters must remember character states, planted clues, pacing, and how each chapter connects to the ones before it. A simple prompt-and-generate approach breaks down at scale.
• Checkpoint recovery. Every successful tool step writes a checkpoint. If the process crashes or is interrupted, it resumes at the correct step -- plan, draft, check, or commit -- rather than rewriting an entire chapter.
• Rolling planning. Instead of planning all 500 chapters upfront and watching distant arcs turn hollow, ainovel-cli expands each arc as writing progresses, using summaries and character state from what came before. This keeps the story grounded in its own history.
• Hierarchical summaries. Summaries at multiple levels help later chapters stay consistent with earlier ones, maintaining continuity that a flat context window would lose.

How it works

The engine sits at the center. When a user provides a prompt, the engine consults its stored facts and route table to decide which agent should act next. The Architect plans, the Writer drafts chapters, the Editor reviews, and the Arbiter is called only when a semantic judgment is needed that the deterministic route cannot resolve. Each step that succeeds writes a checkpoint. If the process is interrupted, restarting resumes from the last checkpoint rather than from scratch.

The rolling planner works at three layers: volume, arc, and chapter. Initial planning creates early volume and arc structure, but distant arcs remain unexpanded until writing approaches them. When the current arc nears completion, the planner expands it using previous summaries and character state snapshots, so the story grows organically rather than being locked into a rigid outline from chapter one.