OpenFic: a self-hosted AI writing workspace for novelists

What OpenFic is for, and who it is not for

OpenFic targets the middle of a novel, not the first sentence. The README describes it as a tool for writers who maintain worldbuilding, characters, foreshadowing and chapter information over months, and who want an agent to help brainstorm, check continuity and fill in detail. The stated design position is that the agent participates in the writing process rather than producing a finished manuscript from a single prompt. That distinction matters because it shapes what the software optimises for: persistent project state and long context rather than one-shot generation quality.

The README is equally direct about the negative case. It says the tool is unsuitable if you expect to type one prompt and receive a whole novel, if you mainly write short copy or social media content, or if you do not intend to maintain setting information and a writing workflow. Those are not edge cases. They are the majority of casual uses of a language model, and OpenFic deliberately does not serve them. If your work is a 600-word product description, the project's own documentation tells you to look elsewhere.

The audience it does fit is narrow but real: someone with a project bible, a folder of chapters, and a preference for keeping all of it on their own disk. The README lists local persistence as a feature, with project data stored locally and no cloud storage dependency.

How the agent, the workflow and the retrieval layer fit together

The architecture visible in the repository is a Python backend serving a prebuilt frontend. The Dockerfile builds the frontend with pnpm in a Node 22 stage, copies the resulting dist directory into the Python image, and points the runtime at it through the OPENFIC_FRONTEND_DIST environment variable. The backend is started with uvicorn against app.main:app on port 8000. Project data goes to /data, set by OPENFIC_DATA_DIR. That is a conventional single-process web application, and it means the whole product is one container plus one volume.

The agent layer is where the project makes its claims. The README describes a highly configurable agent system in which prompts can be modified and workflows built, and it lists semantic retrieval based on vector search, described as Agentic RAG, for finding earlier material in projects of a million characters or more. It also describes multi-layer context management with compression, dynamic truncation and caching, framed as a cost-control measure. Those four items are the substance of the product: retrieval decides what the model sees, context management decides how much of it is paid for, and the prompt configuration decides how the model behaves.

The README does not document the retrieval pipeline in detail. There is no description of which embedding model is used, where vectors are stored, or how chunking is performed. A docs directory exists in the repository, so that is the place to look before assuming the retrieval quality matches the marketing sentence. Treat the million-character figure as a design target stated by the project, not as a measured result.

Model support is described as integration with multiple providers plus any OpenAI-compatible API. That is the pragmatic choice: it means local inference servers and hosted APIs are both reachable, provided they speak the same protocol.

Installing OpenFic with Docker, pip or the desktop build

The README calls the container route the recommended way to self-host. The command below starts the server on port 8000 and mounts a named volume at /data, which is where the application stores project data.

docker run -d -p 8000:8000 -v "openfic:/data" --name openfic ghcr.io/syrizelink/openfic:latest

After that, open port 8000 on the host in a browser and the application should load. The same setup exists as a compose file in the repository, which is easier to keep around:

services:
  openfic:
    image: ghcr.io/syrizelink/openfic:latest
    ports:
      - "8000:8000"
    volumes:
      - openfic:/data
    restart: unless-stopped

volumes:
  openfic:

If you prefer a Python install, the README requires Python 3.12 or newer. The package is published on PyPI under the name openfic, and the serve subcommand starts the service:

pip install openfic
openfic serve

The README does not state which port openfic serve binds to, so check the terminal output on first run. A desktop application is also offered through the releases page, and the README describes it as running natively without extra steps. That is the shortest path for a writer who does not want to touch a terminal, though it is the option with the least documentation in the README itself.

Whichever route you take, the first real task is configuring a model. The README lists support for multiple providers and any OpenAI-compatible endpoint, so have the base URL, key and model name for one provider ready before you start writing.

Where OpenFic gets in your way

The most concrete limitation is the one the project states itself: it will not write the novel for you. Anyone arriving from a demo of a model producing a chapter in one shot will find the setup work disproportionate. You configure a provider, you build or adjust prompts, you maintain character and setting records, and only then does the agent have enough context to be useful. The README's own list of unsuitable cases reads like a warning label, and it is worth taking at face value.

A second limitation is documentation depth. The README covers installation well and the feature list broadly, but it does not document rollback, backup or restore of the /data volume, nor does it describe how to export a project if you decide to leave. Since local persistence is the headline privacy feature, the absence of a documented export path is a gap, not a detail. Before you commit a manuscript, test that you can copy the volume contents somewhere else and read them.

The retrieval claim is the third area to treat carefully. Agentic RAG over a million characters is a strong statement, and the README does not describe the embedding model, index format or chunking strategy. If your novel is large and continuity checks are the reason you are here, that is the feature to evaluate first, on your own text, before you migrate an existing project into the tool.

Finally, the interface is described as responsive across desktop, mobile and browser. That is a claim about layout, not about the ergonomics of editing a long manuscript on a phone. The README offers no detail on mobile editing behaviour.

How OpenFic differs from SillyTavern and from a plain editor

The README credits SillyTavern as an inspiration, and the difference is worth spelling out. SillyTavern is a front end for character-based chat, where the interaction is conversational and the persistent artifact is the chat log. OpenFic inverts that: the persistent artifact is the novel, and the agent is one component inside a project that also holds settings, characters and chapters. The README's phrasing is that the agent should adapt to your writing process rather than the reverse. Practically, that means the retrieval layer and the context management exist to serve a manuscript, not a roleplay session.

The other comparison is against a general-purpose editor with a chat sidebar. A plain editor stores text and leaves context assembly to you: you paste in the relevant chapter, you remember which character has which eye colour, and you decide what the model sees. OpenFic's stated value is doing that assembly automatically through vector retrieval and multi-layer context management. Whether that automation beats careful manual pasting depends on project size. For a short story, manual context is faster and more predictable. For a long novel with hundreds of named entities, the automated path has a real argument.

The cost angle is also a differentiator. The README frames context management as cost-first, with compression, truncation and caching. That is a design decision aimed at writers running long projects against paid APIs, and it is the kind of feature that only shows its value after many sessions.

Maintenance, releases and the Apache-2.0 licence

The repository is not archived, and the last push was on 2026-09-10. Releases have been frequent and small: v0.11.1 on 2026-09-09, v0.11.0 on 2026-08-30, and v0.10.2 on 2026-08-25. The presence of release-please configuration and a changelog file suggests versioning and changelog generation are automated. The project is still on a 0.x version, which in practice means the maintainers reserve the right to change things between minor releases. Pin a version if you are deploying for a writing project you care about.

Upgrade cost depends on your install route. With Docker, pulling a new tag and recreating the container is the whole operation, and the data volume survives because it is separate from the image. With pip, upgrading the package and restarting the service is the equivalent. The README does not document a migration step between versions, so check the changelog before jumping across several minor releases.

The licence is Apache-2.0, which permits commercial use, modification and redistribution provided you keep the licence and notices. If you fork OpenFic and ship it as part of a paid product, that is allowed under those terms. This is not legal advice; read the licence text yourself, and note that the repository also bundles a writing skill adapted from another project, which is credited in the acknowledgements.

Editorial conclusion

Adopt OpenFic if you are writing a long novel, want your settings, characters and drafts stored locally, and are willing to configure models and prompts yourself. Skip it if you want one prompt to produce a finished book, or if you only need short social copy, since the README states those cases are out of scope. Before committing, install it with the Docker command or pip, confirm that the /data volume is where you want project files to live, and check which model provider you can reach from your network.

Frequently asked questions

Official sources

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