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

What AI Novel Writer actually is, and what it refuses to be

The README is unusually blunt about scope. AI Novel Writer is not a model service and not an online novel platform. It is a creation orchestration layer: it stores project state, assembles prompts and context, manages chapter blueprints and draft versions, and strings generation, review and revision together. You bring the model, local or cloud. The software does not provide or host model quota.

The audience is narrow and specific. Someone drafting a 200-chapter web novel needs continuity across chapters, a place where character sheets, worldbuilding notes and blueprints live, and a way to regenerate one chapter without losing the rest. A person writing a 3,000-word short story gets almost nothing from this. The whole design assumes long-form work where context must be selected rather than dumped into a single chat window. The README says the system organises context around the current chapter blueprint, relevant character material, worldbuilding, historical summaries and optional style references, rather than putting the entire novel into one conversation record.

That framing also explains the local-first claim. Projects, characters, blueprints, drafts and final text live in your project directory and a local SQLite database. Model configuration and API keys sit in ~/.vela/models.json, and application preferences in ~/.vela/config.json. The README tells you to protect your OS account and not share that models file, which is honest about where the security boundary is: your user account, not the app.

The pipeline from premise to final draft, and where context is chosen

The README's flow diagram runs left to right: premise, then characters and worldbuilding, then plot outline and chapter blueprints, then chapter drafts, then a review report, then revision and finalisation, and finally the next chapter's project context. Each stage is a stored asset, not a transient chat message.

The v1.1.0 release notes describe the most interesting mechanism: continuity material is now source-tagged. Author-entered character data, model-extracted dynamic state, and unknown-origin information from older projects are no longer treated as the same kind of fact, and later writing prefers finalised source text that carries a source. Chapter materials are layered too: this chapter's task, plans for things that have not happened yet, finalised history, and candidate drafts are presented separately, with adjacent paragraphs preserved so cross-sentence information such as injuries, negations and item handoffs survives.

Review is per-goal. The release notes state that key events for a chapter are listed individually with a status of completed, not completed, or pending verification, each with corresponding source evidence, so preparation or promises are not counted as completion. Pending verification does not count as a pass. If a goal is incomplete or pending, the author must explicitly choose before the revision flow runs. That is a deliberate friction point: the app would rather stop than let a model's mistaken judgement trigger rework.

Generation failure has its own path. If a chapter fails but visible text already exists, the README says that text is saved as a recovery candidate inside the current project. A candidate is not a formal draft, cannot be continued once the source blueprint or draft changes, and can be discarded. The recovery candidates live only in the local SQLite database and never automatically become drafts, finalised text or continuity facts.

Installing the desktop app and running a first chapter

There is no build-from-source instruction in the README for end users. It points at GitHub Releases for the official installers and says the release page is the authoritative source. On Windows x64 the artifact is an NSIS installer named ai-novel-writer-setup-<版本号>.exe. Download it only from the releases page, and note that the installer is not code-signed, so Windows may show a publisher or reputation warning.

On macOS the README lists two DMGs, one per architecture:

ai-novel-writer-mac-arm64-<版本号>-installer.dmg
ai-novel-writer-mac-x64-<版本号>-installer.dmg

Use arm64 for Apple Silicon (M1 through M4 and later) and x64 for Intel Macs. Drag the app into Applications and launch it. The README states that on macOS the app can check GitHub for the latest official release and show a notice, but it will not download or replace the program itself; updating only opens the official release page for you to download the matching architecture manually.

Once the app is open, the next step is model configuration, because nothing generates without an endpoint. For a local Ollama setup the README gives this configuration, and the /v1 suffix matters:

Provider:  Ollama（本地）或自定义
Protocol:  OpenAI-compatible
Base URL:  http://127.0.0.1:11434/v1
API Key:   可留空；若界面要求，可填任意本地占位值
Model:     你的 Ollama 模型名，例如 qwen3:14b

The README warns explicitly against writing the base URL as http://127.0.0.1:11434/api, because /api is Ollama's native interface path and not the OpenAI-compatible embedding path this application currently uses. Embedding models should use /v1 as well. If you skip embeddings entirely, imported reference material still works through SQLite FTS full-text search.

With a model configured, create a project and fill in the premise, characters and worldbuilding, then generate an outline. The README notes that when generating a plot outline you can specify the chapter range in the AI architecture generation step, and that projects over 20 chapters default to starting at chapters 1 to 20. After finishing a batch you continue from the next chapter. If generation is interrupted and a valid checkpoint was kept, you can resume from it, but if you edited the original outline or the source settings and guidance that fed the generation, the old checkpoint will not attach to the new content and you must regenerate that range. Batch chapter creation is a separate task that can be set to 1 to 10 chapters and supports pause and cancel; a post-processing failure stops subsequent chapters.

Where it breaks: protocol limits, unsigned builds and model drift

Two call protocols are supported: OpenAI-compatible, covering OpenAI, DeepSeek, Ollama, NovelAI presets and other Chat Completions services, and Gemini's native protocol for Google Gemini-compatible endpoints. The README is direct that custom API means custom address, model identifier and credentials within those protocols. It is not an arbitrary HTTP or executable-script editor. Anthropic, Azure and KoboldAI native protocols need separate adapters, and swapping a URL is not enough to guarantee compatibility. If your provider only speaks one of those, this is the wrong tool until an adapter exists.

NovelAI support is explicitly minimal. The preset defaults to https://text.novelai.net/oa with OpenAI-compatible protocol, and the README says the project does not send the standard response_format parameter to it and uses a compatibility branch for thinking parameters. It also states the maintainer has no user NovelAI token and has not validated a full creation workflow on a real account, so account permissions, model names and interface differences are on you and NovelAI's own documentation.

The Windows installer is unsigned, which is a real adoption cost for anyone in a managed environment. The README also notes that the old portable ZIP cannot obtain the first updater version by itself and needs one manual install of the official installer; no new portable ZIPs will be maintained.

Most importantly, the release notes themselves set the ceiling: the v1.1.0 improvements reduce the risk of a wrong summary or stale state affecting later chapters, but they cannot replace author review, and they do not guarantee the model output is free of drift or that every chapter hits its target length. This is a tool for an author who intends to read and correct the output, not a generator you can leave unattended for 100 chapters.

The DeepSeek Harness plugin is a different, smaller product

The repository also carries @ethanyoq/dsh-ai-novel-writer 0.1.0, a development preview published as a separate npm package with its own lockfile, CI and MIT licence, while the repository root remains GPL-3.0 for the desktop application. The README states plainly that the plugin is frozen, will not gain features in the short term, is under 10% of the desktop software's capability, does not read desktop .vela projects, and cannot replace the desktop project tree, batch workflows, mature editor or automatic review.

Its model is different rather than merely smaller. V2 offers a minimal manual-review chain: project settings, story architecture, character settings, whole-book outline, per-chapter blueprint, per-chapter text. Generated suggestions land in a Proposal inbox and are first filled into a local editing form in the right-hand workbench for human review and modification. Only when the user explicitly reviews and applies a Proposal does authoritative project state change.

Installation targets the DeepSeek Harness web profile:

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

After starting the web interface, open the novel workbench and install the "AI 小说作家 V2" preset, then create a session and select that preset. The README warns against running dsh plugin add github:EthanYoQ/AI-Novel-Writer, because the repository root package is the desktop app and not an activatable DSH bundle. Source development, pinned tarball installs and the Windows path-with-spaces limitation are kept in the plugin installation guide rather than the root README.

Alternatives, and what the difference in approach costs you

The closest comparison in this material is the DeepSeek Harness plugin itself, and the contrast is instructive. The plugin keeps a human in the loop at every state change: nothing becomes authoritative until you apply a Proposal, and its chain stops at per-chapter text with no batch workflow or automatic review. The desktop app is the opposite trade: it automates batch chapters, review reports and revision, and in exchange it carries the drift risk the release notes admit to, which is why v1.1.0 added source tagging and per-goal verification statuses.

Against a general-purpose chat interface with a long context window, the difference is state. A chat session has no blueprint objects, no draft versions, no recovery candidates and no review report tied to a specific chapter. AI Novel Writer's value is that the next chapter's context is assembled from stored assets rather than from whatever happened to remain in the conversation. The cost is setup: you must configure an endpoint, and if you want retrieval beyond keyword matching you must configure an embedding model on the /v1 path.

Against a hosted AI novel service, the trade runs the other way. Hosted services bundle the model and the quota; this app bundles neither and tells you so. What you get instead is that projects, characters, blueprints, drafts and finalised text stay in your project directory and local SQLite database, and only prompts and context leave your machine when you deliberately choose a cloud endpoint.

Licence, maintenance and the cost of upgrading

The desktop application is GPL-3.0, and the repository root LICENSE file carries it. The DeepSeek Harness plugin is published under MIT as a separate npm package. If you plan to redistribute the desktop app or build a derivative product on it, the GPL-3.0 terms govern that, and the plugin's separate licence does not change the root licence. This is a factual statement about the licence identifiers in the repository, not legal advice; read the licence text and take your own counsel if redistribution is on the table.

The repository is not archived, and the last push was on 2026-09-08, with v1.1.0 released the same day and v1.0.0 two days earlier. Releases are landing close together, which suggests active work, but the plugin is explicitly frozen, so do not read the desktop cadence as applying to the plugin.

Upgrade cost is low by design. The README states the installer updates the application itself and should not delete novel projects, character cards or existing settings, while still recommending you back up important work before upgrading. Update checks read only public GitHub Releases, run silently at most once per day after a successful check, prompt before downloading, and offer restart-now or later after the download finishes. On macOS the app never replaces itself; it opens the release page. The one migration trap is the old portable ZIP, which cannot bootstrap the updater and needs a single manual install of the official installer.

Editorial conclusion

Adopt it if you write long Chinese fiction and want project state, blueprints and draft versions stored locally in SQLite while you point the app at your own OpenAI-compatible or Gemini endpoint. Do not adopt it expecting bundled model credits, an online platform, or the DeepSeek Harness plugin as a substitute for the desktop build, since the README states the plugin is under 10% of the desktop feature set and does not read .vela projects. Verify first that your chosen endpoint speaks the OpenAI-compatible Chat Completions or Gemini native protocol, that you can live with an unsigned Windows installer, and that your manuscript export path works before you commit a full novel to it.

Frequently asked questions

Official sources

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