The Starting Point: If AI Is Writing Long-Form Fiction, Where Should the Platform Come From?

I’m building an AI long-form fiction production system. The backend isn’t the problem: I already have a self-hosted OpenAI-compatible gateway, plus Alibaba Cloud Bailian’s Qwen family, all running through a pure-text pipeline. What’s missing is the upper layer—a writing workbench that can manage “outline → chapter planning → chapter generation → memory → revision → export.”

A flood of projects in this category appeared on GitHub in 2026. But my situation differs from most people’s in one crucial way: I already have a private writing pipeline in production, with several long-form novels actively running on it. So my research question was not “which one should I choose,” but “should I replace my foundation?” Those two questions lead to completely different answers—as you’ll see below.

I spent two days doing a source-level due diligence pass, using the same method I used last time when I dissected manhua-drama platforms: 57 candidates, 11 shallow clones for deep reading, and 6 rounds of adversarial verification (specifically assigning agents to read the source code, look for counterexamples, and try to overturn the deep-reading conclusions). Here’s the conclusion upfront:

• For readers looking for an open-source foundation: fork nigh/show-me-the-story (MIT); second choice: novelclaw (MIT);
• For myself: do not switch foundations; keep evolving the production pipeline, and borrow designs from 4 open-source projects;
• webnovel-writer, the most-starred project at 6,539★, gets a perfect score for consistency mechanisms, but it is GPL-3.0—so it can only serve as a design textbook.

The Landscape: 57 Candidates, but Only Five Real Schools for Long-Form Writing

After scanning 57 repositories, they fell into five categories: full-chain long-form platforms (webnovel-writer, show-me-the-story, novelclaw, ai_novelgenerator, goink), lightweight CLI engines, Claude Code skill suites, memory frameworks, and a large pile of toys or abandoned projects.

Only five projects truly complete the “outline → chapter → memory → revision” loop. Architecturally, they fall into three schools:

1. Stage-pipeline school: webnovel-writer runs each chapter through five real stages—prepare → draft → review → polish → commit. show-me-the-story uses a four-layer pipeline with an independent fact-checking step. Intermediate stages are persisted to disk, so if the process crashes, it can resume from the chapter.
2. Autonomous-agent school: goink uses a ReAct loop with 31 tools, while awesome-novel-agent splits the work across 9 specialized agents. Flexible, but expensive when you need to rerun chapters.
3. Template-driven school: ai_novel and ainovel-cli. Cheap and deterministic, but with a low ceiling—ai_novel only has a context window of around 3 chapters, which is guaranteed to collapse in a long-form project.

My judgment mirrors the conclusion from the manhua-drama research: long-form serialization is a long-running, chapter-metered batch process that must support checkpoint resume; staged pipelines are better than letting autonomous agents improvise freely. You do not want an agent to rethink its entire life after crashing at Chapter 280.

Finding 1: Consistency Is Life or Death for Long-Form Fiction, and the Gap Between Projects Is Huge

Across three million Chinese characters, readers will instantly notice if a character’s name is wrong, a foreshadowing thread is forgotten, or a personality drifts. Here’s how the projects handle it:

• webnovel-writer: when a chapter is committed, it atomically updates five derived artifacts—state, indexes, summaries, memory, and vectors—and blocks progress with a consistency checker. The deep read gave it a perfect 10/10 (not adversarially verified, so I downgrade confidence by one level);
• ai_novelgenerator: character state is updated chapter by chapter, with a consistency_checker gate. Its three-layer memory—recent full chapters / rolling summaries / Chroma vector retrieval—is basically the standard-answer architecture;
• show-me-the-story: the cleverest mechanism—a foreshadowing state machine (planted → progressing → resolved, with alerts when unresolved threads go overdue) plus post-draft fact checking;
• novelclaw: 18 memory stores plus fact cards, giving it the finest-grained memory model.

Context management also converges on the same answer: full text for recent chapters + rolling summary compression every 5 chapters + long-term RAG vector retrieval. Start with summaries, add vectors only when needed—that’s the most cost-effective path.

Finding 2: Text-Level Providers Are Truly Pluggable—the Exact Opposite of the Manhua-Drama Research

Last time, when I inspected manhua-drama platforms, every claim of “pluggable providers” was disproven in the source code. At the image/video layer, switching providers always meant writing code. This time is completely different: text LLMs have an OpenAI-compatible de facto standard, so config-level integration is real.

show-me-the-story, novelclaw, ai_novel, and ainovel-cli all use the same three-piece setup: base_url / api_key / model. Connecting a self-hosted gateway or Bailian’s compatible mode is a configuration change, not an adapter-writing project. There are still some minor tweaks—hardcoded default model names, assumptions about context length—but those are ten-minute jobs, not four-week jobs.

Finding 3: License Wins Again—This Time, the 6,000-Star Engineering Benchmark Falls

The adversarial verification phase—two “overturners” per project, tasked with reading the source and finding counterexamples—once again proved to be the most valuable part of the process. The most consequential corrections included:

• ai_novel (kele-tao): the README claims MIT, but the actual license is Apache-2.0; code comments say “for learning and personal creation only”; “complete workbench” is exaggerated—it is really a semi-finished product;
• webnovel-writer (6,539★): GPL-3.0. Fine for private use if you don’t distribute it, but a wall if you want to productize or ship closed-source;
• awesome-novel-agent (613★): GPL-3.0 plus “contact the author for commercial use”;
• ai_novelgenerator (5,905★): AGPL-3.0. It has the most complete GUI and the strongest consistency mechanisms, but export capability is only 3/10, and the license is another landmine;
• goink: AGPL-3.0 + EULA double-layer restrictions.

After all that, the only projects with clean licenses (MIT/Apache with no extra terms) and complete-enough architecture are show-me-the-story and novelclaw, both MIT projects with only a few hundred stars. This is exactly the same ending as the manhua-drama research: high-star projects collapse in pieces under license scrutiny, and the usable options turn out to be small but sincere projects.

Finding 4: No Project Can Export “Chapter → Scene → Dialogue” Out of the Box

My downstream use case for novels is a manhua-drama production pipeline, so the novel output needs to be transformable into structured scene/dialogue JSON. The inventory result: zero projects support this out of the box. novelclaw has an endpoint for chapter JSON export, but not scene-level granularity; show-me-the-story stores body text as a Blocks array (paragraph / dialogue / scene transition blocks), so adding one more block type would enable scene JSON—which makes it the closest option. The rest basically have nothing.

This integration layer will always have to be written yourself. For someone like me, who already has a downstream production line, this is the decisive vote for “do not switch foundations.”

Final Choice

For readers starting from zero: fork show-me-the-story. MIT means zero license risk; it has a Go single binary + Svelte WebUI, a real four-layer pipeline, a foreshadowing state machine, rolling summaries, fact checking, OpenAI-compatible integration, progress.json checkpoint resume, and an endpoint for rewriting individual chapters. The deep-read estimate puts the required modification workload at around 30%, mainly extending Blocks into scene/dialogue structures and adding genre templates for Tomato Novel / Qidian-style fiction. If you care more about the memory system and web dashboard, the second choice is novelclaw.

For myself: do not switch foundations. The decision chain is short—the research question was not “which one is best,” but “is switching foundations worth it?” Among the 57 candidates, the only one that has been validated in real production is the pipeline I’m already running. The adversarial verification identified 4 real gaps in it—consistency injection is a bit weak, batch mode defaults to single chapters, export is not componentized, and the repository has no LICENSE—but all of them are incremental fixes, not architectural rot. Betting several ongoing long-form novels on the regression risk of a new foundation would not buy me anything I lack. The designs I do need—foreshadowing state machines, atomic chapter commits, three-layer memory, hook libraries—can all be borrowed from open-source projects, and most of the code can even be copied directly from MIT projects.

Why can’t webnovel-writer, the project with the highest engineering score, serve as the foundation? Three reasons: GPL-3.0, no adversarial verification (that perfect consistency score is the deep-reading agent’s own claim), and zero production validation. Its most valuable idea—“atomic chapter commit”—has already entered my evolution plan. Use the idea, don’t inherit the license. This is structurally identical to the dramaclaw story from the manhua-drama research: engineering score does not equal foundation eligibility.

One honest disclaimer: the deep-read conclusions for show-me-the-story, novelclaw, and webnovel-writer have not gone through adversarial verification (the verification slots went to the top three overall scorers), so it’s worth doing one more round before actually forking. Also, I didn’t have time to deep-read oh-story-claudecode, a 5,629★ MIT project, this time. Its form factor is a Claude Code skill suite, and it’s worth keeping an eye on.

Three Methodological Lessons

1. “Production validation” is the highest-weight dimension, and open-source writing projects are almost all demo-grade. Treat “has completed a million-word novel” in a README as marketing unless you can see the serialization link.
2. Adversarial verification is the cure for deep-reading fluff. Ask an agent to praise a project, and it can find twenty strengths; ask another agent to overturn the conclusion, and only then will you uncover life-or-death details hidden in comments, like “claims MIT but is actually Apache” or “for learning and personal creation only.”
3. The correct way to use GPL/AGPL projects is to copy the design, not the code. Personal creative output is not infected by GPL (the output is not a derivative work), but merging GPL code into a private repository is a violation. Copy ai_novelgenerator’s three-layer memory architecture and webnovel-writer’s chapter-commit idea, and you take on exactly zero legal risk.

The full report—15-dimensional scoring, source-code evidence for each project, a 12-stage evolution plan, and a handoff JSON schema—is in my private repository. This post is the public condensed version. If you’re also choosing an open-source foundation for AI long-form writing, I hope this saves you two days.