NovelClaw: A Persistent Workspace for Chapter-Based Fiction Writing

What NovelClaw Solves for Long-Form Fiction Authors

Most chat-based fiction tools treat a story as a single large prompt: the user submits, the model generates, and the intermediate state disappears. That design works for short pieces but breaks down across chapters, where continuity depends on remembering character details, world rules, and prior plot decisions.

NovelClaw addresses this by making the writing session the unit of work. Instead of one prompt, the author maintains an ongoing workspace with sessions, storyboards, manuscript surfaces, character panels, and world panels. Chapter output remains accessible throughout a run, and memory banks can be edited to correct or extend the state the model draws from.

The README describes the target audience plainly: authors who want stronger continuity, clearer iteration surfaces, and more direct control over chapter-level progress. It is also positioned for engineers building or evaluating inspectable long-form writing systems.

The Three-Service Architecture and What Each Layer Does

The repository ships three cooperating services, each a separate Python FastAPI application running under uvicorn. The auth-portal (port 8010) provides the public entry point at /select-mode and keeps session authentication separate from the writing logic. The multiagent service (port 8011) offers a faster ideation lane for preparing material before committing to a drafting session. NovelClaw itself runs on port 8012 and is where the sustained writing work happens.

The docker-compose.yml in the repository root wires these three containers together under a shared novelclaw-network, with shared session secrets passed through environment variables. Data directories for each service are mounted as named volumes so run history and generated chapters survive container restarts.

The README is explicit that Portal and MultiAgent are support layers: the main long-form control surface is NovelClaw. An author can bypass the other two once the workspace is configured.

The Dockerfile builds a single image for all three services from python:3.10-slim, installs gcc, g++, and git from the OS package manager, then installs the Python requirements for each app in sequence.

Installing and Accessing the Workspace

Docker is the recommended installation path. On Linux and macOS, the start script handles setup:

chmod +x docker-start.sh
./docker-start.sh

On Windows, the equivalent batch file runs instead:

.\docker-start.bat

For a manual start, the repository provides example environment files for each service. Copy them before the first launch:

cp .env.auth-portal.example apps/auth-portal/.env
cp .env.multiagent.example apps/multiagent/.env
cp .env.novelclaw.example apps/novelclaw/.env

Then start all three services:

docker compose up -d

Once running, open the portal at http://localhost:8010/select-mode to reach the mode selection screen. The main NovelClaw dashboard is at http://localhost:8012/dashboard.

For users who prefer not to run Docker, the repository includes START_LOCAL.bat as a Windows alternative and documents the local-run path in RUN_LOCAL_WEB.md. The README also lists a hosted version at colong-idea-studio.cloud for users who want to try the workspace without any local setup.

The repository has no GitHub releases, so there are no versioned packages to download. The only distribution path is cloning the repository and running the scripts.

Memory Banks, Storyboards, and Run Inspection

The workspace keeps several surfaces visible during and after a drafting run. Storyboards let the author see the planned structure of the story. Manuscript views display the text produced so far. Character panels and world panels hold the entities and settings the model refers to when generating new chapters.

Memory banks are editable. The README presents this as a deliberate design choice: rather than hiding the model's context inside opaque generation, NovelClaw exposes it as a surface the author can revise. If a character detail was recorded incorrectly, or a world rule needs expanding, the author can correct it in the memory bank before continuing.

Run inspection surfaces chapter output, progress traces, and download links throughout a session. The README describes this as making writing work inspectable: the author can see what was generated, where a run stopped, and what the worker produced at each stage.

The distinction from typical chat-based fiction tools is structural. Chat interfaces hide the model's working state; NovelClaw keeps it accessible as a set of panels the author interacts with directly.

Limitations and Cases Where NovelClaw Is the Wrong Tool

NovelClaw requires running three Docker containers for a task that many writers approach with a single chat session. The deployment overhead is justified only when the author needs persistent sessions and editable memory across many writing sessions. For a short story, a blog post, or a one-off creative experiment, that overhead adds complexity without benefit.

The README notes that API keys are optional at startup but required for any actual generation. The system starts cleanly without them, which means a first-time user who skips the .env configuration step will reach the dashboard but find generation non-functional until credentials are provided.

The repository has no GitHub releases as of the last push on 2026-05-31. There are no versioned packages, no changelogs tied to numbered versions, and no published release notes. Authors who need stable, versioned builds will need to pin to a specific commit themselves.

The README is written in a promotional register with emoji formatting and comparison tables. The engineering details of how memory banks are stored, how the RNNLM or provider API is called, and what happens when a run fails partway through are not documented in the materials available.

How NovelClaw Differs from Chat-Based Fiction Generation

The natural alternative to NovelClaw is submitting prompts directly to a chat interface such as ChatGPT, Claude, or a similar LLM frontend. Chat interfaces require no setup, work in the browser, and support fiction writing immediately.

The practical difference is state management. A chat interface keeps the conversation history in the session window. When that window closes, or when context length limits are reached in a long story, continuity becomes the author's problem. The author must paste in summaries, re-describe characters, or accept drift.

NovelClaw externalizes that state into editable panels that persist across sessions. This is a trade-off: the author gains structured continuity at the cost of local infrastructure and a learning curve. The README frames NovelClaw as a workspace rather than a generation tool, which accurately describes the difference in how a writer would interact with it day to day.

For collaborative or supervised drafting where multiple people steer the same project, the persistent workspace model has a clearer advantage over ephemeral chat sessions.

Maintenance, Repository Layout, and Licence

The last push to the repository was on 2026-05-31. The project is not archived. There are no GitHub releases.

The repository is organized with three application directories under apps/, plus scripts/, infra/, and docs/ at the top level. The DEPLOYMENT.md and DOCKER_DEPLOYMENT.md files cover production deployment details. WHAT_IS_SAFE_FOR_GITHUB.md addresses what parts of the private system were made public.

The MIT licence applies to the repository. MIT permits use, modification, and distribution with attribution. It does not require that derivative works be open-source.

The Dockerfile specifies python:3.10-slim as the base image, which is a frozen major version. Applications requiring Python 3.11 or later features would need an image change. The docker-compose.yml uses version '3.8' syntax with restart: unless-stopped on all services, which means containers will attempt to recover after failures automatically.

Editorial conclusion

NovelClaw suits authors who write serial or chapter-based fiction and need explicit control over story state across many sessions. Writers who want a single one-off story pass have no reason to stand up three Docker services for it. Before running, copy all three .env example files in the repository root and add API keys for whichever cloud provider you intend to use; the system starts without them, but generation will not proceed until a valid provider is configured.

Frequently asked questions

Official sources

1. iLearn-Lab/NovelClaw on GitHub
2. Issues
3. License: MIT
4. Project website
5. README