Skip to main content
PromptQuorumBuilt for humans. Structured for AI.
Home/Power Local LLM
Creative & Roleplay

Drafting Novels and Screenplays With Local LLMs: 100K+ Word Workflow Guide (2026)

·15 min readBy Hans Kuepper · Founder of PromptQuorum · Discovery engine for open-weight & open-source AI

The main challenge with local LLMs on long-form fiction is context management: plan around about 32K tokens per generation and give the model a compressed "session document" (character sheets, chapter summaries, current scene setup) for one scene at a time, instead of the whole manuscript.

Key Takeaways

  • Context window planning rule: 128K–262,144 tokens listed, about 32K planned. Models use the middle of long inputs less reliably ("Lost in the Middle"), so plan around about 32K tokens (~24,000 words) per generation and use the session document technique, not the full manuscript.
  • Session document technique is the core skill. Maintain a compressed text file containing: active character sheets (one per character, 150 words each), chapter summaries (100–200 words per completed chapter), and the current scene's setup. Inject this at the start of every generation session.
  • Generate one scene at a time. Ask the model to write one scene (200–600 words) per session rather than asking it to "continue" a growing document. One scene per session reduces context drift and helps keep the voice consistent.
  • Beat-sheet-first for screenwriting. Before generating any script pages, generate a scene-level beat sheet (INT./EXT. LOCATION — what happens, what changes, what the scene accomplishes in one sentence). Use the beat sheet as the scaffold for each page generation.
  • Pick a model you can run, then test it on one of your own scenes. Dense models in the 27B–31B class (Qwen3.6 27B, Gemma 4 31B) and Llama 3.3 70B are common starting points; PromptQuorum has not benchmarked any of them for fiction, and public creative-writing leaderboards rank models differently from one another.
  • Ollama + a plain-text writing tool is a dependable integration. Scrivener, Obsidian, and VS Code can all hold the manuscript; Ollama serves the model through an API that companion apps or scripts can call.
  • Low-refusal models (Hermes 4 70B) slot into this workflow without setup changes. For mature fiction, swap the Ollama model; the session document and scene generation techniques are identical. Check each model's licence for your use.
Read in:
🇺🇸en🇩🇪de🇫🇷fr🇯🇵ja🇨🇳zh🇪🇸es🇧🇷pt🇸🇦ar🇰🇷ko

Local LLMs integrated into a screenwriting or novel-drafting workflow let you generate scene drafts, beat sheets, dialogue passes, and revision runs without internet access, cloud logging, or usage limits. This guide covers the full workflow: model selection, context-window management for long-form work, chapter scaffolding, scene generation, and the tools that connect a local LLM to your writing software.

Drafting Novels and Screenplays With Local LLMs: 100K+ Word Workflow Guide (2026)

Quick Facts

  • Model starting points (from the model cards): Qwen3.6 27B (dense, Apache-2.0, 262,144-token context), Gemma 4 31B (dense, Apache-2.0, 256K context), Llama 3.3 70B (dense, 128K context, Llama 3.3 Community License).
  • Context window planning limit: ~32K tokens (~24,000 words) per generation; models list 128K–262,144 tokens, which is a ceiling, not a quality guarantee.
  • Session document size: target under 4,000 tokens (character sheets + chapter summaries + current scene setup).
  • Scene generation target: 200–600 words per generation call; longer scenes via multiple sequential prompts.
  • Screenwriting format: combine Ollama with Fountain-format output instructions for screenplay-format text.
  • Writing tools that pair with Ollama: Scrivener (paste output; no documented plugin API), Obsidian (via local plugin or scripts), VS Code (via Continue.dev or direct API calls), plain terminal.
  • Low-refusal option: Hermes 4 70B (Llama-3.1-70B base) for mature fiction; same workflow, same session document technique.

The Context Window Problem for Long-Form Writing

Plan around about 32K tokens per generation, even when a model lists far more. This is a conservative PromptQuorum planning rule, not a measured limit: long-context research (Liu et al., "Lost in the Middle") found that models use information at the start and end of a long input more reliably than information in the middle, and that quality can fall as inputs grow. Newer models list much larger windows — Qwen3.6 27B lists 262,144 tokens natively and Gemma 4 31B lists 256K — so test your own model. For a novel, pasting the manuscript-so-far and asking for the next chapter is still the least reliable approach, and a long context also uses more memory because the KV cache grows with it.

Kimi-K2.6 from Moonshot AI lists a 256K-token (262,144) context window, the same class as the models above, but it is a mixture-of-experts model with about 1 trillion total parameters (32 billion active) shipped with native int4 weights. Even at 4 bits the weights alone come to roughly 500 GB (PromptQuorum estimate: 1 trillion parameters × 0.5 byte), so it is a server-class model, not a laptop one. The session document technique and scene-by-scene generation apply to locally runnable models of any context size.

📍 In One Sentence

A conservative planning ceiling for context adherence in local LLMs is around 32K tokens (~24,000 words) per generation — beyond this, long-context research finds less reliable use of earlier content, which can show up as voice drift and plot inconsistencies across a long manuscript.

💬 In Plain Terms

You cannot reliably expect a model to remember what happened in chapter 3 while writing chapter 20 just because your whole manuscript fits in its context window. Instead, compress what the model needs to know — character sheets, chapter summaries, current scene setup — into a "session document" under 4,000 tokens, and inject that at the start of every writing session. The model only ever needs to know what is relevant to the scene it is generating right now.

  • Token-to-word conversion: 1 token ≈ 0.75 words in English (rule of thumb). 32K tokens ≈ 24,000 words. 128K tokens ≈ 96,000 words (about one novel); 262,144 tokens ≈ 196,000 words.
  • Attention degradation: models can lose reliable reference to content from early in a long context window. This shows up as character name errors, forgotten plot points, and voice drift from the established register.
  • The asymmetry: in the Lost in the Middle study, models used the beginning and the end of the input best and content in the middle least reliably. The study tested models available in 2023, so test current models rather than assuming the same pattern.
  • Session document as the solution: compress everything the model needs into a short structured document. Inject at the start. Generate the scene. End the session. Reset. Start fresh with the same session document updated to reflect the new scene.
Context planning: a 32K-token (~24,000 words) working limit versus the 128K–262,144 tokens that open models now list.
Context planning: a 32K-token (~24,000 words) working limit versus the 128K–262,144 tokens that open models now list.

⚠️Warning: Do not paste your full manuscript into the context. If your novel is over 10,000 words and you paste the full draft to ask for the next chapter, you risk context drift — the model may forget early character details, contradict established plot points, and regress toward a generic register. Use the session document technique instead.

Session Document Technique

The session document technique is a PromptQuorum workflow recommendation built on the context limits described above. PromptQuorum has not run a controlled test of it, and the sizes below (4,000 tokens, 150 words per character sheet, 100–150 words per chapter summary) are planning guidelines, not measured thresholds.

The session document is a plain-text file you maintain alongside your manuscript — it is the compressed state of your novel that the model needs to know to generate consistent content. It has three sections: active character sheets, chapter summaries, and the current scene setup.

Session Document Template

“# SESSION DOCUMENT — [NOVEL TITLE] ## ACTIVE CHARACTERS [Character Name] Dominant trait: [one trait] Contradicting behaviour: [one behaviour] Speech register: [formal/casual/specific verbal tics] Relationship to [other character]: [brief] [Character Name 2] [same structure] ## CHAPTER SUMMARIES (completed) Chapter 1: [100–150 words — what happened, what changed, where it ended] Chapter 2: [100–150 words] [continue for all completed chapters] ## CURRENT SCENE SETUP Chapter: [N] Scene: [brief description of what this scene needs to accomplish] POV: [character name] Opening state: [where we are at the start of this scene — 1 sentence] Emotional beat to land on: [what the POV character feels at the end — do not state it directly in the scene] Word ceiling: [200–500 words]”
  • Character sheets — target 150 words per active character. Include dominant trait, contradicting behaviour, speech register, and the key relationship to the other active characters. Add or remove characters as they become active or exit the manuscript.
  • Chapter summaries — target 100–150 words per completed chapter. Focus on: what happened, what changed in character relationships, what information the reader now knows, where the chapter ended spatially and emotionally. Do not include every scene — summarise the chapter's net effect.
  • Current scene setup — specific and brief. Name the POV, the scene's purpose (what it needs to accomplish in the story), the emotional beat to land on, and the word ceiling. This is the action the model takes; the character sheets and chapter summaries are the context it uses to do it consistently.
  • Session document size — target under 4,000 tokens (~3,000 words). A session document that exceeds this starts consuming context space that should go to the generation itself. Compress character sheets and summaries aggressively.
  • Update after each session. After generating a scene, add a 1–2 sentence update to the relevant chapter summary and update any character sheet entries that changed. The session document is a living file; keeping it current is the maintenance cost of the technique.

💡Tip: Keep the session document in a plain-text file alongside your manuscript. After each writing session, copy-paste the session document into the system message or the first user turn of the next session. In Ollama, you can create a Modelfile with the session document in the SYSTEM block and refresh it before each session. In SillyTavern, paste it into the system prompt field at the start of each novel session.

Novel Drafting Workflow

The novel drafting workflow with a local LLM has four phases: outline, chapter beat sheets, scene generation, and revision passes. Each phase uses a different prompt structure.

  • Phase 1 — Outline: generate a chapter-level outline (10–30 chapters, one sentence per chapter: what happens, what changes). Prompt: "Genre: [genre]. Protagonist: [Name + core wound]. Central conflict: [in one sentence]. Write a 20-chapter outline — one sentence per chapter, each sentence names the scene and the change." Review and edit the outline before proceeding.
  • Phase 2 — Beat sheets: expand each chapter entry into a scene-level beat sheet (3–8 scenes per chapter). Prompt per chapter: "Chapter [N] summary: [paste the one-sentence outline entry]. Expand into a scene-level beat sheet: 4–6 scenes, each described in one sentence naming location, participants, and the scene's single change. No prose yet."
  • Phase 3 — Scene generation: use the session document + the current scene's beat to generate one scene at a time. See the scene generation templates below. Generate, review, paste into manuscript, update session document. Repeat.
  • Phase 4 — Revision passes: after completing a chapter, run targeted revision prompts on specific scenes. See Local LLM Prompts for Fiction Writers for the revision prompt structures. Do not ask the model to revise more than one scene per generation call.
Four-phase novel workflow with a local LLM: outline, beat sheets, scene generation and revision, around a session document.
Four-phase novel workflow with a local LLM: outline, beat sheets, scene generation and revision, around a session document.

💡Tip: Keep the outline and beat sheets in separate files from the manuscript. They are the skeleton — the manuscript is the flesh. Keeping them separate means you can regenerate any part of either without overwriting the other, and you can paste just the relevant beat-sheet entry into the current scene setup without including the full outline.

Screenwriting Workflow

Screenwriting with a local LLM uses the same session document and beat-sheet techniques as novel drafting, with two additions: format instructions in the system prompt, and scene header (slug line) generation as a separate step from page generation.

Screenwriting System Prompt

“You are a screenplay formatting assistant. All prose you generate is formatted in standard US screenplay format: - Scene headers: INT./EXT. LOCATION — DAY/NIGHT - Action lines: present tense, concrete, maximum 3 lines per block - Character names: ALL CAPS above dialogue - Dialogue: centred, no dialogue tags - Parentheticals: sparingly, only for delivery or action mid-dialogue Generate in Fountain-compatible plain text.”

Scene Beat to Script Page Prompt

“Beat: [paste the one-sentence scene beat from the beat sheet] POV character: [Name] Page target: [1–3 pages] Generate the script pages for this beat. Use standard screenplay format. Begin with the slug line. No narration — action lines and dialogue only.”
  • Format in the system prompt, not the user turn. Putting screenplay format instructions in the system message means every generation in the session follows the format without repeating the instruction.
  • Fountain-compatible output: Fountain is a plain-text markup format for screenplays; Highland and Fade In read it, among other apps listed in the Fountain app directory. Asking the model to generate "Fountain-compatible plain text" produces output you can open in those tools or convert for others (see the Final Draft question in the FAQ).
  • Slug lines first: generate the slug line (INT./EXT. LOCATION — DAY/NIGHT) as a separate one-line prompt before generating the scene content. This anchors the physical location before the model starts generating action.
  • Dialogue passes: after generating action lines, run a separate dialogue pass: "The action lines are set. Write the dialogue for [Character A] and [Character B] in this scene. Character A wants [X]. Character B wants [Y]. No dialogue tags. 5–8 exchanges."
  • Page count management: there is no fixed words-per-page figure, and "one page equals one minute" is only a rule of thumb. Count the average words per page of your own script and set word ceilings from that.

💡Tip: The beat-sheet-first discipline matters more for screenwriting than for novel drafting. A screenplay scene has a specific structural function (setup, confrontation, decision, reversal) and a specific page target. Generating pages without a beat sheet produces scenes that drift in length and lose their structural purpose. Always know what a scene is supposed to accomplish before generating the pages.

Scene Generation Templates for Long-Form Work

Long-form scene generation requires the session document as a prefix and a single scene prompt as the action. The templates below assume the session document is already in the system message or the first user turn.

📍 In One Sentence

For long-form fiction, a dependable generation pattern is: session document in the system prompt → single scene prompt in the user turn → review → update session document → repeat, one scene per session.

💬 In Plain Terms

The model needs to know three things to write the next scene consistently: who these characters are (character sheets), what has already happened (chapter summaries), and what this scene needs to do (scene setup). Give it exactly those three things, nothing more. Then generate the scene, paste it into your manuscript, and update the session document to reflect what changed. Repeat.

Novel Scene Generation Prompt

“[SESSION DOCUMENT ALREADY IN SYSTEM PROMPT] Current scene: Chapter: [N] Beat: [one sentence from the beat sheet] POV: [character name] Opening: [one sentence — where we are, who is present] Emotional landing: [what the POV character feels at the end — show, don't state] Word ceiling: [300–500 words] Write this scene. No summarising. Every sentence renders a moment.”

Continuity Check Prompt

“Before writing the next scene, check for continuity. The session document says: - [Character A] is [trait/state] - The last scene ended with [brief description] The next scene opens with [brief description]. Does this transition make sense? If not, what needs to change in the transition? One paragraph answer only.”

💡Tip: Use the continuity check prompt at chapter transitions — not at every scene. Checking continuity at every scene slows the drafting flow for no consistent benefit. Chapter transitions (where the location, time, or POV character changes) are where continuity breaks most often and where the check pays off.

Tool Integrations for Writers

Ollama exposes an OpenAI-compatible API at localhost that a growing ecosystem of writer-facing tools connects to. The integrations below represent the most established options as of 2026.

Obsidian

Link:
obsidian.md
Integration:
Copilot plugin or Smart Connections plugin → Ollama API. See Obsidian + Local LLM Plugins for the deeper guide on which Obsidian plugins work best with Ollama.
Best For:
Writers who already use Obsidian for notes + manuscript; seamless same-app generation

Scrivener

Link:
literatureandlatte.com/scrivener
Integration:
External script via Ollama API → paste into document
Best For:
Writers who structure novels in Scrivener; AI drafts pasted into the existing project structure

VS Code

Link:
code.visualstudio.com
Integration:
Continue.dev extension → Ollama backend
Best For:
Technical writers and game narrative designers comfortable in a code editor

SillyTavern

Link:
github.com/SillyTavern/SillyTavern
Integration:
OpenAI-compatible API → Ollama
Best For:
Roleplay-style fiction and character-card-driven drafting; persistent character memory
Articles about SillyTavern (10)

+7 more not shown

Plain terminal

Link:
—
Integration:
`ollama run [model]` or curl to Ollama API
Best For:
Scriptable workflows; writers who want maximum control with minimal UI overhead

NovelCrafter

Link:
novelcrafter.com
Integration:
Built-in AI integration; its help pages list LM Studio, Ollama and OpenAI-API-compatible connections
Best For:
Writers who want chapter-level AI assistance inside a single novel-focused app

Plottr

Link:
plottr.com
Integration:
Manual workflow: structure novels in Plottr, paste scenes/beats into Ollama externally (Plottr states it is not adding AI features)
Best For:
Plot-heavy genre fiction (mystery, thriller, fantasy) where structural plotting is the workflow centerpiece

💡Tip: The simplest integration that works for most writers is Obsidian + the Copilot plugin pointed at Ollama. Your session document lives in an Obsidian note, your manuscript chapters live in the same vault, and you generate directly in the same app without switching contexts. The Copilot plugin passes selected text or the current note to Ollama and returns the completion inline. See Obsidian + Local LLM Plugins for the deeper guide on which Obsidian plugins work best with Ollama.

Model Recommendations for Long-Form Work

Long-form drafting has different model requirements than short-form fiction. Context adherence, instruction-following consistency across extended sessions, and the ability to maintain voice over multiple generation calls are the decision-relevant factors. The rows below are starting points taken from each model's card; PromptQuorum has not benchmarked these models for fiction, and public creative-writing leaderboards rank models differently from one another, so test two candidates on one of your own scenes. Server-class open models such as Command A+ (218B total parameters, 25B active, Apache 2.0) and Mistral Large 3 (675B total parameters, 256K context, Apache 2.0) are outside consumer hardware range. For the broader model landscape across all use cases, see Best Local LLMs in 2026.

Novel drafting (primary)

Recommended Model:
Qwen3.6 27B or Gemma 4 31B
Why:
Dense 27B–31B models listing 256K+ context under Apache licences; a size class that suits a 24 GB GPU or 32 GB+ unified memory at 4-bit (estimate)

Screenwriting

Recommended Model:
Qwen3.6 27B or Llama 3.3 70B
Why:
Format adherence depends mostly on the system prompt; test one Fountain scene on two models. Llama 3.3 70B is dense, lists 128K context and needs roughly 40 GB at 4-bit (estimate)

Beat sheet / outline generation

Recommended Model:
Qwen3.6 35B-A3B
Why:
Mixture-of-experts with 3B of 35B parameters active per token (Apache-2.0), so generation is faster per token; outline quality not benchmarked by PromptQuorum

Dialogue passes

Recommended Model:
The model whose samples fit
Why:
Run dialogue as a separate pass on the model whose calibration lines match your character's register; there is no verified ranking of models for dialogue

Revision (structural)

Recommended Model:
The model you drafted with
Why:
Revision prompts that name one structural constraint per call work on any instruction-following model; one scene per call

Mature / dark fiction

Recommended Model:
Hermes 4 70B
Why:
Built on Llama-3.1-70B; Nous Research describes broadly neutral alignment and lower refusal rates; Llama 3 licence; hybrid reasoning mode

Common Mistakes

  • Pasting the full manuscript into the context. Even when a model lists a 128K–262K window, long inputs are used less reliably, so plan around about 32K tokens. Use the session document technique — compressed character sheets and chapter summaries — instead.
  • Asking the model to "continue" an open-ended document. "Continue the novel" produces drift. "Write the next scene: [specific setup, POV, word ceiling]" produces a consistent, bounded output you can evaluate and paste.
  • No beat sheets for screenwriting. Generating script pages without a scene beat produces pages that drift in length and lose their structural function. Generate the beat sheet first, always.
  • Ignoring session document updates. If you do not update the chapter summary after generating a scene, the session document becomes stale. A stale session document produces inconsistencies within a few sessions.
  • Generating more than one scene per session. Multi-scene generation within one context window produces the first scene well and each subsequent scene with lower consistency. One scene per session; reset and reinject.

Sources

Frequently Asked Questions

Can a local LLM write a full novel?

A local LLM can generate the prose for a full novel — but the structural and editorial intelligence has to come from the writer. The model generates scenes when prompted with specific setups; it does not plan, evaluate, or make thematic decisions on its own. Treat it as a fast first-draft generator for scenes you already know how to write: it saves time on the blank-page problem, while the writer still makes every significant decision. Check publisher and platform AI policies before submitting (see the publishers question below).

What is the maximum context window I can use reliably?

Models list 128K to 262,144 tokens, but PromptQuorum recommends planning around about 32K tokens (~24,000 words) per generation, because long-context research finds that models use the middle of long inputs less reliably. That is a conservative planning rule, not a measured limit for every model, so test yours. The session document technique keeps the working context under 4,000–6,000 tokens, so every generation call stays well inside that range.

How do I stop the model from changing my character's voice mid-novel?

Voice drift has two causes: a stale session document (missing recent character developments) and context dilution (the character sheet is too far from the active generation in the context). Fix: keep the character sheet in the system message (not buried in a long user-turn preamble), update the sheet after any scene where the character has a meaningful arc moment, and keep the sheet concise enough to fit in the top section of every session context.

Can I use Scrivener with a local LLM?

Not natively — Scrivener 3 has no documented plugin system, and its official release notes through version 3.5.2 (December 2025) mention no AI integration: the 3.4.0 notes say "Scrivener itself contains no AI" and add support for Apple's Writing Tools, a macOS system feature. A common workflow is: generate in Ollama (via terminal or a companion script), copy the output, paste it into the relevant Scrivener document. Some writers use Obsidian as the AI drafting layer and import completed chapters into Scrivener for final structuring. Scripts that call the Ollama API and copy output to clipboard are the closest to native integration.

Which is better for screenwriting: Ollama or a cloud AI?

For screenwriters who need to generate mature content (violence, dark psychology, morally complex characters), a local model gives you control over the model and its refusal behaviour — some hosted models decline or soften content that appears in dramatic scripts, and hosted policies change over time. A low-refusal local model such as Hermes 4 70B has fewer built-in refusals, though you remain responsible for the content you generate and publish. Format consistency depends mostly on the instructions in the system prompt, which work with both. The choice is mainly about content control, privacy and cost; PromptQuorum has not compared output quality between hosted and local models for screenwriting.

How do I generate dialogue that sounds like a specific character?

Three-step approach: (1) Add the character's speech register to the session document ("formal, avoids contractions, starts sentences with qualifications like 'It seems to me that...'"). (2) Generate 3–5 sample lines of dialogue from this character in a neutral context as a calibration step at session start. (3) Use those sample lines as an example in the dialogue prompt: "Write dialogue in the same register as these examples: [paste samples]." The calibration step is the most effective technique for character-voice consistency.

Do I need a GPU to use a local LLM for novel drafting?

A GPU speeds up generation significantly but is not required. On Apple Silicon, unified memory lets a MacBook Pro with 16 GB run smaller models (roughly the 8B class at 4-bit, an estimate, because macOS keeps about 8 GB) — slower than a 24 GB GPU rig, but acceptable when you read and evaluate output between generations. A 24 GB NVIDIA GPU (RTX 4090, RTX 3090) fits 27B–32B-class models at 4-bit (estimate); 70B-class models need roughly 40 GB or more at 4-bit, so they require two GPUs, a 48 GB card, 64 GB of unified memory, or slower CPU offload.

Can I use local LLMs with Final Draft or other professional screenwriting software?

Not directly. Per Final Draft's help center, Final Draft cannot import .fountain files; its guidance is to save the text as plain .txt and import that file as a script, or to bring it in as FDX from an app that exports that format. Highland converts between Fountain, FDX and PDF, and Fade In imports and exports Fountain (per the Fountain app directory). Workflow: generate Fountain-format text in Ollama, open it in Highland or Fade In, and export FDX for Final Draft.

Can I use Kimi-K2.6 locally for novel drafting?

Kimi-K2.6 lists a 256K-token context window, the same class as Qwen3.6 27B and Gemma 4 31B, but it is a mixture-of-experts model with about 1 trillion total parameters (32 billion active) and native int4 weights. The weights alone come to roughly 500 GB (PromptQuorum estimate), so it needs a multi-GPU server or a very large unified-memory machine and is impractical on consumer hardware. For fully local workflows, a 27B–70B dense model with the session document technique covers novel-length work without a trillion-parameter model.

How do publishers feel about AI-drafted manuscripts?

Policies vary by publisher and platform and are still changing as of 2026, so check the specific one before submitting. Amazon KDP requires you to tell it when text, images or translations are AI-generated, and treats content created by an AI tool as AI-generated even if you edit it substantially; work you wrote yourself that AI only helped edit or refine is "AI-assisted" and needs no disclosure (per Amazon's rules as reported by Publishers Weekly in September 2023). Some magazines reject AI-involved work outright — Clarkesworld's statement on the use of “AI” writing tools such as ChatGPT says it will not consider any submissions translated, written, developed or assisted by those tools. Scene text generated by a local LLM falls under policies like KDP's "AI-generated" definition, so disclose it where required. This is general information, not legal advice.

What hardware do I need for million-token contexts?

Qwen3.6 27B and Qwen3.6 35B-A3B list a native 262,144-token context that can be extended to about 1,010,000 tokens with YaRN scaling (per their model cards). A long context needs memory for the KV cache on top of the weights, so a million-token run needs far more memory than a typical consumer setup; PromptQuorum has not measured the requirement. The session document technique in this article is designed for exactly this gap — consistent long-form output without relying on a million-token window.

← Back to Power Local LLM

MCP