Writing a book

Books are the original pipeline: multi-chapter works (fiction or nonfiction) where the hard problem is continuity - chapter 12 must remember what chapter 3 established. New projects default to article mode, so switch first with /mode book (or write and pick “book” in the interview).

abstract → directions (pick one) → plan + TOC → per chapter:
  research? → write → critique → revise → commit (+ summary + canon extraction)
→ consolidate (every N chapters) → production (front/back matter) → learn

Canon: the book’s memory

Every committed chapter feeds a durable on-disk store:

• Character facts (capped to the most recent per character in prompts, so late chapters don’t pay linearly growing context)
• World rules and a timeline (events recorded under the chapter that actually committed them)
• Full-text search over committed prose - the writer’s context includes relevant excerpts from outside the dependency chain, the long-range recall summaries can’t provide

The chapter chain is deliberately sequential (each pulls the previous summary); everything independent of prose - research, images, skills for chapter n+1 - is prefetched in parallel while chapter n is written.

Consolidation

Every consolidate_every chapters, a pro-tier pass reads the whole canon, merges duplicates, and flags contradictions. In autonomous mode contradictions are auto-repaired; in manual mode they escalate for review.

Production: the book-shaped parts

After the last chapter, the production layer decides which front/back matter the book needs (genre-aware: a novel gets an epigraph and acknowledgments; technical nonfiction gets a glossary and bibliography), generates them from committed canon and real sources, and assembles the ordered manuscript. Facts it can’t know - copyright holder, author bio - come from your profile or get clearly-marked placeholders. It never fabricates author/publishing facts.

Resumability

The brain on disk is the checkpoint. Every step persists before the state advances, writes are atomic, and resume guards make double-commits impossible. Kill the process mid-chapter, run run again tomorrow - it picks up exactly where it stopped, with nothing lost and nothing duplicated.

Watching (and steering) it

A long book run is easiest to follow in the web dashboard (writing-agent web): a live view over Server-Sent Events, plus per-project Overview, Activity, Evals, Artifacts, a Rejected tab (unused figures and dropped items logged to rejected.jsonl), Export, and Cost. It runs the same pipeline as the TUI, one job at a time, bound to 127.0.0.1. Cost stays lean by default - cost_mode: budget routes the judgment nodes to the flash tier and applies a per-unit token budget (see Cost & performance).