OpenFic: an AI-native novel-writing workspace where the agent reads your settings before it writes

The problem OpenFic solves: continuity across a long manuscript

A novel is not a prompt. It is a body of accumulated decisions: who a character is, what they know on page 200, which thread was planted in chapter three and has not paid off. The README frames OpenFic around exactly this, describing a tool for writers who are "正在写中长篇小说，需要长期维护世界观、角色、伏笔和章节信息" (writing a medium-to-long novel and needing to maintain the world, characters, foreshadowing and chapter information over time). That is the target user. The README also names the people it is not for: anyone who expects to type one prompt and receive a finished novel, which it calls unrealistic, and anyone who mainly needs short copy, social media content or one-off general text generation. The distinction matters because it sets the cost of admission. OpenFic asks you to build and maintain settings, character definitions and a workflow before the agent is useful. If you are not going to do that, the tool is overhead. If you are, the settings are the thing that keeps a 300,000-word draft from contradicting itself.

How OpenFic works: settings, agents, prompts and vector retrieval

The README describes OpenFic as an all-in-one "Vibe Writing" tool that is "AI Native" and cross-platform, with the agent participating deeply in the writing process rather than generating text on its own. Three mechanisms are named. First, a configurable agent system: the documentation states that any prompt can be modified freely so the agent adapts to your workflow instead of the reverse. Second, semantic retrieval: the README describes a vector-based Agentic RAG layer meant to let the agent find past information efficiently in projects at the million-character scale. Third, multi-layer context management, which the README lists as intelligent compression, dynamic truncation and stable caching, aimed at holding down cost. The data flow implied by these pieces is that your settings, characters, chapter text and prompts live in the project, retrieval pulls the relevant past material into the agent's context, and context management decides what survives the window. The README does not publish the retrieval implementation, the embedding model, or how compression is triggered, so those details cannot be confirmed from the material. What can be confirmed is the design intent: the agent is meant to be grounded in your existing project rather than in a blank prompt.

Installing and starting OpenFic: Docker, pip and the desktop build

The README gives three installation paths. Docker is described as the recommended way to self-host, with this command: docker run -d -p 8000:8000 -v "openfic:/data" --name openfic ghcr.io/syrizelink/openfic:latest. That single line tells you two operational facts. The service listens on port 8000, and all persistent state lives under /data inside the container, which is why the volume mount is not optional if you care about your manuscript. The pip route requires Python 3.12 or newer, which the README flags in a warning block, and then two commands: pip install openfic followed by openfic serve. The third option is the desktop application, downloaded from the GitHub release page, which the README says runs natively on your system without extra steps. Model configuration is described only at the level of capability: the README claims integration with models from multiple providers and with any model that is compatible with the OpenAI API. The specific config keys for provider, base URL and API key are not shown in the supplied material, so check the repository or the running instance's settings screen before assuming a naming convention. The README's own note that all project data is stored locally, with zero cloud storage dependency, is the reason the volume mount and your backup routine matter more than they would in a hosted editor.

Where OpenFic gets in the way

The README is unusually direct about the failure case: it states that expecting a single prompt to produce an entire novel is unrealistic, and lists that expectation as a reason not to use the tool. That is not marketing modesty, it is an architectural consequence. An agent grounded in your settings can only be as useful as the settings you wrote, and the tool asks you to maintain them. The second limitation is scope. If your work is short copy, social posts or one-off text, the worldbuilding and continuity machinery is dead weight, and the README says so. The third is the maintenance surface itself: a highly configurable agent system with freely editable prompts means every workflow you build is something you now own. The README does not describe a prompt library, a versioning scheme or a migration path for prompt changes across releases, and the release cadence visible in the repository, v0.10.2 in late August 2026, v0.11.0 at the end of August, v0.11.1 in early September, suggests configuration can move under you. Before committing a long project, check whether your customized prompts survive an upgrade. The README does not answer that question.

How OpenFic differs from SillyTavern and from generic AI writing assistants

The README credits SillyTavern as an inspiration, and the difference in approach is worth stating plainly. SillyTavern is a front end for conversational roleplay with characters and personas; OpenFic is built around a manuscript, with chapters, settings and foreshadowing as first-class objects, and the agent is meant to assist a writing process rather than sustain a chat. Against general AI writing assistants, the split is context strategy. A hosted assistant typically holds a document and a conversation in a vendor-controlled context window. OpenFic keeps project data locally with no cloud storage dependency, and adds a vector-based retrieval layer plus compression and truncation to stretch that context across a long project. You pay for this in setup: an assistant works the moment you open it, while OpenFic wants a Docker volume, a Python 3.12 environment or a desktop install, and a model endpoint that speaks the OpenAI API. The README also credits oh-story-claudecode as a reference for a built-in writing skill, which indicates the project treats writing skills as bundled artifacts rather than something you assemble from scratch.

Licence, releases and the cost of keeping up

OpenFic is released under the Apache License 2.0, which permits commercial use, modification and redistribution provided the licence and notices are preserved. That is a permissive choice, and it means the code can be embedded in a paid product or a self-hosted internal tool without a copyleft obligation on your own work. This is a description of the licence text, not legal advice; read the Apache 2.0 terms yourself if your situation is unusual. The upgrade cost is more concrete than the licence. The repository shows three releases in roughly two weeks, v0.10.2 on 2026-08-25, v0.11.0 on 2026-08-30 and v0.11.1 on 2026-09-09, so a self-hosted deployment is a moving target. With Docker, pulling ghcr.io/syrizelink/openfic:latest is a one-line upgrade, and the /data volume is what carries your project across it. With pip, openfic is a normal package and pip install --upgrade openfic is the upgrade path, but the Python 3.12 floor means you are also tracking your interpreter version. The README does not document a data migration procedure between versions, so the practical safeguard is a copy of the /data volume before you pull. There is no hosted tier described, so there is no vendor to absorb that work for you.

Who should install OpenFic, and what to check first

The fit is narrow and the README draws it clearly. Install OpenFic if you are writing a medium-to-long novel, you intend to maintain worldbuilding, character and chapter information over months, and you want to shape the agent's prompts and workflow yourself rather than accept a fixed assistant. Install it if local data storage is a requirement, since the README states there is no cloud storage dependency. Do not install it if you want a prompt-to-novel generator, if your output is short-form marketing or social copy, or if you have no appetite for maintaining settings. Three things to verify before you commit a real manuscript. First, that your model provider is reachable through an OpenAI-compatible API, because that is the only integration shape the README names. Second, that your Docker volume or desktop data directory is included in whatever backup you already run, since /data is the whole project. Third, that your customized prompts still behave after an upgrade, given the release cadence. If those three hold, OpenFic is a self-hosted workspace for a specific kind of long project, and the README's own framing of who it is not for is the most useful thing in it.

Editorial conclusion

Adopt OpenFic if you are maintaining a novel-length manuscript and want the worldbuilding, chapter history and prompts in one local project that an agent can read. Skip it if you want a single prompt to return a finished book, or if you write short copy and social posts and have no settings to maintain. Before installing, verify that your model provider is reachable through an OpenAI-compatible endpoint, that the mounted /data volume is backed up, and that the agent and prompt configuration matches your own workflow.

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. syrizelink/OpenFic on GitHub