StoryForge puts a local-first AI writing desk in the browser

A writing workshop that keeps the manuscript in the browser

StoryForge describes itself as an open source, local-first tool for AI narrative writing and play. In practice it is a wide product surface: long novels and short stories, script adaptation, comics, motion drama packages, a world engine, a node canvas, a plugin workshop and several playable works shipped inside the repository. The stack is React with TypeScript and Vite, Zustand for interaction state, TipTap for body text editing, and Three.js for the built-in 3D scenes.

The interesting engineering decision is where the work lives. There is no server component in the repository layout. Manuscripts and saves are held in the browser through Dexie over IndexedDB, and the project advertises that model choice is either your own API or a local model. That combination suits a solo author who wants drafts to survive a network outage and dislikes uploading an unpublished manuscript to a hosted service. It also means the data lifecycle is a first-class concern: unified PROJECT_TABLES drive backup, import, deletion, migration and reference remapping, and exporting body text is deliberately a different operation from taking a full project backup.

assembleContext() for reading, adopt() for writing back

The mechanism that separates StoryForge from a chat window is a pair of registries and a gateway. Context sources are registered and collected through assembleContext(), the Context Gateway retrieves only what a task needs, and the sources are kept alongside the result so a later reader can tell where a fact came from. Writing is the opposite direction and is more constrained: FIELD_REGISTRY, an AdoptionSchema and adopt() define which fields may be written, and only an adopted field enters the manuscript.

Around that sits what the project calls a persistent Harness. A Skill or Run Contract, events, checkpoints, candidates and receipts tie the inputs of a single run to its outputs. Before adoption, scope and version are checked, and a saved candidate can be restored later. The practical result is that a long novel can accumulate a memory of the original text, established facts, summaries and on-demand retrieval, and that a chapter-end tidy-up can push confirmed changes into later work. For the author this is the difference between a model that keeps contradicting itself and one that can be pointed at a prior chapter. The cost is that adoption is a chokepoint: anything not in the registry cannot reach the text, so a workflow built outside those fields needs the schema extended first.

Running the source tree and the checks that guard a release

The repository ships a standard Node toolchain, and the package manifest is where the supported workflows are written down. The identity fields and the module type are plain:

  "name": "storyforge",
  "private": true,
  "version": "4.0.2",
  "license": "MIT",
  "type": "module",

The script names are the documentation for a contributor. A development server comes from Vite, the production build type-checks with tsc before bundling, and the end-to-end suite depends on a separate adventure player bundle being built first:

    "dev": "vite",
    "build": "tsc -b && tsc -p ui-preview/tsconfig.json && npm run build:adventure-player && vite build",
    "test": "vitest run",

The end-to-end command repeats that dependency explicitly, which tells you the adventure player is a separate build artifact rather than a route inside the main bundle:

    "test:e2e": "npm run build:adventure-player && playwright test",

Beyond the tests, the manifest defines a set of repository checks with a scripts folder behind them, covering required tables, source reachability, bundle size, dependencies, release metadata and documentation authority. A check called check:dependencies runs an audit against production dependencies only. This matters for a project that ships a desktop build: the top-level entries include an electron-builder config, a Capacitor config and an android directory, so the same source produces Windows, macOS and Android packages, and the release titles confirm those three targets.

The Mist Harbor work plays without any model API

The fastest way to judge the product is the built-in work that needs no key. On the home page, the work titled as the mist harbour story opens directly, and it is also reachable at a local path:

/storyforge/play/mist-harbor

You pick a visual novel or a text adventure, press start and play. The work carries 18 narrative nodes, 158 beats, three endings and 17 original backgrounds, portraits and CG images. The text adventure branch lets you observe, talk and gather evidence; the visual novel branch reads line by line with branching choices and saves the stage progress. Starting creates an independent world and product release, so existing projects stay untouched, and a full project backup includes the script, the media and the save.

Two caveats are stated plainly in the project documentation and they matter more than the feature list. This is a prewritten work with no runtime model conversation and no voice acting, so it demonstrates the runtime shell rather than general text game generation. Editing the original in the world workspace does not rewrite the published game, which is a deliberate separation between source and published product. The other three 3D narrative games behave the same way, using frozen scripts with no free AI dialogue, and the documentation recommends starting with the short one at /storyforge/play/tidemark-echo, which runs about four to five minutes with two rescue routes, then trying the longer ten chapter works.

A plugin workshop that has to be switched on deliberately

The workshop is where StoryForge is least finished, and the documentation says so with a preview label. Inside the application the discovery route is:

/workshop/discover

You have to enable the development preview explicitly before creating a standalone experience work or world, then confirm trust before installing. Plugins come in three shapes: installable feature plugins, no-code content packs, and combination packs with locked dependencies. Twelve reference packs are named as examples, covering notes, cards, calendars, timelines, plot boards, node flows, custom AI and external tools, with the first dedicated replacement interfaces being world history and story progress. Deactivating or uninstalling keeps the plugin data, and reinstalling the matching version restores the dedicated interaction.

For developers, the route is a public SDK, packaging as .sfplugin, or handing the knowledge base instructions and skill packs to another AI tool to write the plugin. Native interface plugins run in the same process, which means you are trusting the author and the code: the documentation states plainly that a capability declaration is not a malware sandbox. The web workshop and the local installation manager also have different responsibilities, so a plugin installed in one place does not necessarily appear in the other. Plugin API 1 and SDK 0.1 are labelled developer previews, and the node canvas is in the same state, with cross-mode acceptance work still in progress.

Where the delivery package stops before the video

The motion drama pipeline is the most elaborate feature and the most clearly bounded one. From a sentence or an existing novel you move into a series bible, episode planning, character, costume, scene, prop and voice inventories, per-episode beats and scripts, then storyboards and reference frames. Image prompts and motion prompts are maintained separately, a quality review checks continuity, asset rights and target tool constraints, and the result is a package adapted for Seedance, Runway, LTX or a generic tool. The asset lists and deliveries keep versions, and a revision flags the affected shots for review.

The boundary is stated at the end of that description: the delivery endpoint is before external video generation. Video generation, editing, voice and mixing, and the finished piece all happen in later tools, and the adaptation packages do not promise that a third party's current plan supports every capability. The same honesty shows in the table data, where a work can carry a chapter structure, tens of thousands of Chinese characters, hundreds of independent lines and four endings and still be a frozen script with no character voice. A pipeline owner should read that as a clear division of labour: this project plans and packages, other tools perform.

Model access splits into three channels, only one of them keyless

Model configuration is where this kind of tool usually becomes fragile, so the separation of channels is worth reading closely. Cloud APIs are one path. Services compatible with Ollama or LM Studio are the second. The third is the local Codex app-server, which lets a local run reuse an already signed-in ChatGPT account: the settings detect the login, list the models actually available, and assign task presets, with no API key typed into that channel.

The limits are stated rather than implied. That channel handles text and structured output only, so images, speech and vectors need separate configuration, and a purely static web build cannot use it at all. A subscription carries its own model permissions and usage limits, so the account is not an unlimited free resource. After a dropped connection you can inspect the most recent request, but a result of unknown status is not resent automatically, and the application does not silently fall back to a different paid API. The same local-first logic reappears in the shipped games: installing the npm dependencies needs a network connection, and once loading finishes the main story can be played offline.

An MIT licence, a fast release cadence, and a preview-heavy product

The licence field in the repository is MIT, and a LICENSE file sits at the top level next to the README translations. A licence this permissive is a straightforward adoption decision for a tool that stores your manuscript on your own disk, though the assets in the shipped works are a separate question from the code licence, and the third-party font and model terms are outside what the repository can settle.

Activity is high and recent. The last push was on 2026-10-20, and the three most recent releases land inside one week: v4.0.0 on 2026-10-13, v4.0.1 on 2026-10-15 and v4.0.2 on 2026-10-16, the last one titled for Windows, macOS and Android. That pace has a cost. Much of what the documentation presents is explicitly marked as preview, including the node canvas, the interactive products, plugin API 1 and SDK 0.1, and the two completed 3D narrative works are labelled as community previews with public networked multiplayer not deployed. Releases are also pinned: an older release archive will not contain the newer content, so the documentation points at the latest portable build or the latest main branch. Documentation is published in Chinese and English, with nine README translations in the repository, and the changelog is split so that trunk changes, unmerged work and historical evidence can be checked separately.

Editorial conclusion

StoryForge fits a writer or a small studio that wants a single place for long-form manuscripts, adaptation pipelines and versioned AI drafts, and who is willing to read the knowledge base before trusting an adoption chain it cannot audit. It does not fit a pipeline that expects final video, voice or fully free-form game dialogue from one tool, since the delivery packages stop before external video generation and the three 3D works use frozen scripts. Verify three things first: whether your model endpoint of choice is covered by the settings (the Codex app-server path and the Ollama and LM Studio compatible services are named separately), what the licence file in the repository root actually grants for a commercial release, and whether the local route you want runs from the latest main branch or from a fixed release archive, since the two do not carry the same content.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. yuanbw2025/storyforge on GitHub