# NovelForge: AI-Assisted Long-Form Novel Writing with Schema Cards > NovelForge is a Python-backed AI writing tool for fiction writers working on manuscripts that span hundreds of thousands of words. It organizes every story element as a schema-validated card, injects context through a purpose-built @DSL, and tracks character relationships in a SQLite knowledge graph. **RhythmicWave/NovelForge** — AI辅助长篇小说创作，卡片式创作，支持基于 JSON Schema的结构化 AI 生成与上下文引用，可扩展性强。 - Repository: https://github.com/RhythmicWave/NovelForge - Stars: 1,223 · Forks: 221 - Language: Python - License: AGPL-3.0 - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/rhythmicwave-novelforge ## What Problem NovelForge Solves and Who It Targets Long-form fiction introduces three compounding problems that a general-purpose AI chat window cannot fix: maintaining internal consistency across hundreds of scenes, keeping character details from drifting chapter by chapter, and producing content that fits a deliberately chosen structure rather than whatever the model finds easiest to generate. NovelForge addresses all three through a card-based architecture where every piece of world-building, every character sheet, and every chapter outline is a discrete unit that can be referenced, validated, and queried. The project targets writers who are building novels, serialized fiction, or multi-arc narratives and who are willing to invest time in setting up a schema before drafting. It is not a dictation tool or a prose polisher for short-form work. The README describes its potential as supporting manuscripts in the millions of characters, and the tooling reflects that ambition: the knowledge graph, the @DSL context system, and the workflow engine are all aimed at sustained, large-scale projects rather than one-shot generation. ## Schema-First Cards: Why Structure Comes Before Prose The central design decision in NovelForge is that every content unit, called a card, carries a type definition expressed as a JSON Schema. When the AI generates a character card, for instance, it must fill the fields the schema declares rather than inventing its own format. The README describes this as reducing outputs that "look usable but are structurally incoherent in practice." Generation happens at field granularity through a streaming dialog: the writer inputs a requirement, the model fills fields one by one, and the writer confirms or provides feedback before the session closes. This matters because long-form writing involves incremental refinement. A character's backstory may be accepted immediately, while the motivation field goes through three iterations. The card boundary keeps those iterations scoped to the current unit, preventing accidental changes to adjacent content. Cards can be grouped in folders and cross-referenced from the Ideas Workbench, a separate brainstorming space that supports free-form cards and cross-project references. Content developed in the workbench can be moved or copied into a main project once it reaches usable form. ## Context Injection with @DSL and the Knowledge Graph NovelForge provides a domain-specific language, referred to in the codebase and documentation as @DSL, for injecting project data precisely into prompts. Rather than pasting entire documents into a context window, a writer can reference specific cards by identifier. The system assembles the relevant data and passes it to the model alongside the current task. The knowledge graph layer, introduced in v0.9.1 and stored in SQLite by default, tracks entity relationships extracted from chapter text. After a chapter is drafted, the writer can trigger extraction for characters, locations, organizations, objects, and concepts, review the proposed additions in a preview, adjust them, and then confirm the write-back. The graph supplements the @DSL by making relationship state queryable during generation, so later chapters can draw on the accumulated record of who knows whom and what changed. The changelog for v0.9.1 notes that Neo4j is also supported alongside SQLite for the knowledge graph, giving teams that already run a graph database an alternative to the file-based default. ## Installing NovelForge and Starting the First Session NovelForge requires Python for the backend and Node.js for the frontend. The repository ships with a top-level package.json that automates both processes on Windows. On other platforms, the two services can be started in separate terminals. Clone the repository first: ```bash git clone https://github.com/RhythmicWave/NovelForge ``` Then install frontend dependencies: ```bash npm --prefix frontend install ``` Start the backend, which listens on port 54321 by default: ```bash python backend/main.py ``` In a second terminal, start the frontend: ```bash npm --prefix frontend run dev ``` The backend port is configurable. The v0.9.7 changelog states that setting APP_PORT in backend/.env overrides the default, and the value is validated against the range 1 to 65535. Before generating any content, visit the LLM configuration page and run the compatibility test added in v0.9.6. It checks whether the chosen model handles basic conversation, streaming, structured output, and tool calls. Models that fail the structured-output check will produce malformed card content. ## Code-Style Workflows: Automating Repetitive Creation Steps NovelForge v0.9.0 replaced an earlier DAG-based workflow editor with a code-style system that represents workflows as sequences of statements with special markers. The README contrasts the two approaches: DAG configurations for the same logic often required hundreds of lines of node and connection declarations, while the code-style equivalent runs to a few dozen lines, making the format more readable and better suited to AI-assisted editing. The Workflow Agent, introduced in the same release, accepts natural-language descriptions of a desired automation and generates or modifies the corresponding workflow code. Changes go through a preview step before being applied. The built-in workflow templates include a book-deconstruction workflow that breaks an existing text into cards, which the v0.9.5 update converted to streaming mode to improve completion rates. Workflows can be persistent, surviving across sessions, or temporary, scoped to a single run. They support asynchronous steps using an async flag and can pause at checkpoints with a Logic.Wait marker. Node-level progress tracking and interruption recovery are available as a beta feature as of v0.9.8. ## Chapter Word Count Control: Prompt Mode vs. Control Mode Chapter continuation in NovelForge offers two distinct modes, and the choice between them has real cost implications. Prompt constraint mode adds a word count target to the model prompt and lets the model reach that target naturally. The result is more fluent prose at lower token consumption, but the actual length may drift from the target. Control mode, introduced as a major addition in v0.9.3, divides the target word count into multiple budget rounds and allocates a portion to each. According to the README, this produces more stable length adherence, especially for long chapters, but consumes more tokens because the model is invoked several times per chapter rather than once. The implementation uses a fixed multi-round budget strategy in the current version. For writers working within API cost budgets, the recommendation in the documentation is to start with prompt constraint mode and switch to control mode only for chapters where hitting a specific length matters, such as installment fiction with fixed episode word counts. ## Limitations: Where NovelForge Falls Short NovelForge is Windows-first in its developer scripts: the top-level npm dev command uses PowerShell syntax and the start command, which will not work on macOS or Linux without modification. Writers on those platforms need to manage the backend and frontend processes manually, which is not difficult but is not documented in the main README. The structured-output requirement is a real constraint on model choice. Models that cannot reliably return JSON matching a given schema will produce card content that either fails validation or requires heavy manual correction. The LLM compatibility test added in v0.9.6 helps identify this problem before a writing session, but it does not guarantee that a model which passes the basic test will remain consistent across long card-generation sessions. The current version does not support merging multiple bill files into one project in a single import step. Each import is a separate file. Writers working with data spanning multiple export periods have to consolidate outside the tool. The web interface added in v0.8.6 improves mobile accessibility, but the full card-editing and workflow authoring experience targets a desktop browser. An alternative approach is Scrivener combined with an external AI API, which handles long-form manuscript organization through its own outline and document hierarchy. The key difference is that Scrivener does not enforce a schema on its content units and does not offer AI generation as a first-class feature: it is a writing organizer that a writer wires to an AI separately, while NovelForge integrates those two layers by design. ## Conclusion NovelForge fits writers who are already comfortable running a local Python backend and who want structural discipline from day one rather than retrofitting consistency onto a finished draft. The schema-card system genuinely constrains what the model can invent, which is valuable when a project stretches to half a million words and character continuity becomes the hardest part of the work. Writers who want a hosted, no-setup tool, or whose stories are short enough that a plain chat interface is sufficient, will find NovelForge over-engineered for their needs. Before committing, verify that your chosen LLM provider returns structured output reliably: the LLM configuration page now includes a compatibility test, and models that fail the structured-output check will break schema generation. ## FAQ ### Does NovelForge work with models other than OpenAI's API? The README recommends configuring providers such as DeepSeek and Qwen as OpenAI-compatible endpoints rather than using a dedicated connector, while native OpenAI settings are reserved for official models such as GPT-5. Any model exposed as an OpenAI-compatible API should be usable through the LLM configuration page. ### What database does NovelForge use for the knowledge graph? SQLite is the default storage for the knowledge graph, introduced in v0.9.1. The same release also added Neo4j support for teams that prefer a dedicated graph database, and both options are selectable through the graph management interface. ### How do I change the port NovelForge's backend runs on? Set APP_PORT in the backend/.env file. The default is 54321, and the v0.9.7 update added validation that rejects values outside the range 1 to 65535. ## Sources - [Issues](https://github.com/RhythmicWave/NovelForge/issues) - [License: AGPL-3.0](https://github.com/RhythmicWave/NovelForge/blob/main/LICENSE) - [README](https://github.com/RhythmicWave/NovelForge/blob/main/README.md) - [Releases](https://github.com/RhythmicWave/NovelForge/releases) - [RhythmicWave/NovelForge on GitHub](https://github.com/RhythmicWave/NovelForge) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rhythmicwave-novelforge