AI Novel Writer: a local-first desktop workbench for long-form fiction

The problem is context drift, not prose quality

Most AI fiction tooling optimises the sentence. AI Novel Writer optimises what the model is allowed to see when it writes that sentence. The README frames the product as a "创作编排层", an orchestration layer that stores project state, assembles prompts and context, and manages chapter blueprints and draft versions. That framing is the whole pitch: the software does not generate anything by itself and does not host model quota.

The intended user is someone writing a Chinese or English web novel at length, where a single chat window stops working somewhere around the point that character state, unresolved plot threads and prior chapters exceed what can be pasted in. The repository organises the work as premise, characters, worldbuilding, chapter blueprint, draft, review report, revision, final. Each stage is a stored artefact rather than a message in a transcript, which is what makes the later stages addressable at all.

If your project fits comfortably in one prompt, this is overhead. The value only appears when the book is long enough that you cannot remember what a character was carrying in chapter nine.

Chapter-scoped context instead of one long transcript

The README states that generation is organised around the current chapter blueprint, related character material, worldbuilding, historical summaries and an optional reference style, rather than stuffing the whole novel into a single conversation. That is a retrieval design, and the 1.1.0 release notes describe how it was tightened: character material the author wrote, dynamic state extracted by a model, and unknown-provenance information from older projects are no longer treated as the same kind of fact, and later writing prefers finalised source text that carries provenance.

The same release splits chapter material into layers. The current chapter's task, plans for events that have not happened yet, finalised history and candidate drafts are presented separately. The notes give a concrete reason: keeping adjacent paragraphs of the relevant source text helps carry cross-sentence information such as an injury's cause, negations, and the transfer of an object between characters. That is a real retrieval problem in fiction, and treating a plan as though it were history is exactly how a model writes a scene around an event that has not occurred.

Review follows the same pattern. Per-chapter key events are shown individually as completed, not completed, or pending verification, with the corresponding source text as evidence. The notes are explicit that pending verification does not count as a pass, and that unfinished or unverified goals require the author to choose before revision runs. This is a deliberate friction point. It trades throughput for not letting the model grade its own homework.

What you need to configure before the first chapter

The application speaks two protocols: OpenAI-compatible Chat Completions, and Gemini's native protocol. The README is blunt that "custom API" means a custom address, model identifier and credential within those protocols, not an arbitrary HTTP or script editor. Anthropic, Azure and KoboldAI native endpoints need separate adapters and will not work by swapping a URL.

For a local model, the documented configuration is:

Provider: Ollama (local) or custom Protocol: OpenAI-compatible Base URL: http://127.0.0.1:11434/v1 API Key: may be left empty, or any local placeholder if the interface demands one Model: your Ollama model name, for example qwen3:14b

The README warns specifically against writing the base URL as http://127.0.0.1:11434/api, because /api is Ollama's native path and not the OpenAI-compatible embedding path this application uses. Embedding models must also go through /v1. Reference material can be imported as common text formats, and when no embedding model is configured the app still offers SQLite FTS full-text search over it.

Credentials and preferences live outside the project: model configuration and API keys in ~/.vela/models.json, application preferences and update-deferral settings in ~/.vela/config.json. The README asks you to protect the OS account and not share that first file. That is the correct advice and also the honest statement of the threat model: there is no separate secret store.

The batch workflow has boundaries worth knowing

Batch chapter creation is a separate task, configurable from 1 to 10 chapters, with pause and cancel. The README notes that a post-processing failure stops subsequent chapters, so a bad run does not silently continue producing material on a broken foundation.

Outline generation has its own constraint. In the AI architecture generator you specify the chapter range for that run, and projects longer than 20 chapters default to starting at chapters 1 to 20. After finishing a batch you can continue from the next chapter, and if generation was interrupted with a valid breakpoint you can resume from it. The catch is stated plainly: if you have since edited the outline or the source settings and guidance that fed the generation, the old breakpoint will not attach to the new content, and you have to regenerate that range.

Chapter generation failure has a recovery path. If a chapter fails but visible text already exists, that text is saved as a recovery candidate inside the current project. The README is careful here: a candidate is not a formal draft, it cannot be continued once the source blueprint or draft changes, and it can be discarded. It will not become a draft, a final version or a continuity fact on its own.

The release notes end with a limitation the maintainers chose to state rather than bury: the 1.1.0 improvements reduce the risk of a bad summary or stale state affecting later chapters, but they do not replace author review and do not guarantee that model output never drifts or that every chapter hits its word-count target.

The DeepSeek Harness plugin is a preview, and the README says so

The repository also ships @ethanyoq/dsh-ai-novel-writer, published on npm, with its own lockfile, CI and an MIT licence, while the repository root remains GPL-3.0. The README states that the 0.1.0 preview is frozen for maintenance with no feature expansion planned, that its capability is under 10 percent of the desktop version, and that it cannot replace the desktop project tree, batch workflows, editor or automated review. It does not read desktop .vela projects.

What it does provide is a minimal human-in-the-loop chain: project settings, story architecture, character setup, book outline, per-chapter blueprint, per-chapter prose. Model suggestions land in a Proposal inbox and are filled into a local edit form in the right-hand workbench. Project state only changes when the user explicitly reviews and applies a proposal. Installation is:

dsh plugin --profile web add @ethanyoq/dsh-ai-novel-writer dsh --profile web

The README also warns not to run dsh plugin add github:EthanYoQ/AI-Novel-Writer, because the repository root package is the desktop application and not an activatable DSH bundle. If you want the plugin, use the npm package name.

One more thing the README states about NovelAI support: the preset exists at https://text.novelai.net/oa with OpenAI-compatible protocol and minimal parameter compatibility, but because the maintainer does not hold a user's NovelAI token, the full creative workflow has not been verified against a real account. Account permissions, model names and endpoint differences are deferred to NovelAI's own documentation. Treat that preset as unverified.

Where this sits against a general-purpose chat client

The obvious alternative is a capable chat interface with a long context window, or a coding-agent style harness that can read and write files in a project directory. Both can hold a novel's worth of text and both let you paste in whatever context you think matters.

The difference is who maintains the state. In a chat client, continuity lives in the transcript and in your head: you decide what to re-paste, and nothing stops a scene from contradicting chapter four because the relevant paragraph scrolled out of the window. AI Novel Writer moves that responsibility into a schema. Characters, worldbuilding, blueprints, drafts and finals are records with provenance; the blueprint for the current chapter determines what gets retrieved; review output is structured per key event and feeds revision as an input.

That structure is also the cost. A chat client imposes nothing, so it never blocks you. This application asks you to fill in premise, characters and worldbuilding before the drafting stages are useful, and it will refuse to carry a breakpoint across edited source material. If your process is exploratory and you discover the plot by writing it, the schema is a tax you pay before you know whether the book is worth it. A file-based agent harness sits between the two: it can read your notes directory, but it has no notion of "this is a plan, not yet history", which is precisely the distinction the 1.1.0 notes were written to enforce.

Licence, updates and the maintenance you are signing up for

The desktop application is GPL-3.0. The DSH plugin is MIT and published separately with its own lockfile and CI. If you intend to redistribute a modified desktop build, the GPL-3.0 terms apply to that binary; the plugin's separate licence means the two are not governed identically. This is a description of what the repository states, not legal advice, and anyone shipping a derivative should read the licence text rather than this paragraph.

Update mechanics differ by platform. On Windows, the NSIS installer updates the application itself and the README says it should not delete projects, character cards or existing settings, while still recommending you back up important work before upgrading. The app checks for updates silently at most once per day after a successful check, prompts before downloading, and only downloads when you click the download button. Legacy portable ZIP builds cannot obtain the first updater version and need one manual install of the official installer; no new portable ZIPs will be maintained. The installer is not code-signed, so Windows may show a publisher or reputation warning.

On macOS, the DMG comes in arm64 and x64 variants, and the application can check the latest GitHub release and show a notice but will not download or replace itself. Updating means opening the official release page and downloading the matching architecture manually.

Three releases landed in the nine days before the last push, from v0.9.2 through v1.0.0 to v1.1.0, so the surface is moving. The frozen DSH plugin is the one part explicitly declared stable-by-omission, and the 1.1.0 release notes list fixes for duplicate update checks during download, Markdown export now using a separate directory, and workflow completion notifications preserving the full title. Those are the kinds of defects you inherit when you adopt a young desktop application, and the changelog is where you find out whether the next one is already fixed.

Editorial conclusion

Adopt it if you already have a model endpoint you trust and you want the project tree, blueprint and review stages kept on your own disk rather than in a chat log. Skip it if you want a hosted service that supplies model credits, or if you write short fiction where a single prompt fits in one context window. Before committing a manuscript, verify three things: that your chosen endpoint answers at the OpenAI-compatible path (Ollama users must use /v1, not /api), that ~/.vela/models.json is somewhere you are willing to keep credentials, and that the chapter range you set in the architecture generator matches the outline you actually want, because a stale breakpoint will not attach to revised source material.

Official sources

1. EthanYoQ/AI-Novel-Writer on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases