CharacterArc: a local-first Electron workbench for long-form AI-assisted fiction

The problem CharacterArc targets: project state that outlives a single chat

Most AI writing tools are conversation windows. You paste a premise, get a scene, and the setting details live in the scrollback until the context window drops them. CharacterArc is built around the opposite assumption. The README describes it as a desktop workbench organised around novel projects, chapter writing and AI collaboration, and states that it is not a shell that only holds conversations. The unit of work is the project: each one maintains its own settings, chapters, knowledge base and AI run records, isolated from the others.

The audience follows from that. The README says it is for creators who need to maintain project settings, character relationships, plot structure and chapter text over the long term. That is a specific group: people writing serialised or book-length fiction who already keep notes, and who have found that a general-purpose assistant forgets a character's eye colour by chapter forty. A short-story writer who finishes a draft in one sitting gets little from the project isolation and the knowledge centre. A novelist with a three-volume outline gets the structure the tool was designed around.

How the pieces connect: SQLite in the main process, Vue in the renderer, Skills around the model

The architecture is a standard Electron split. Vue 3 and TypeScript run the interface, Pinia holds state, Naive UI supplies components, and electron-vite (Vite 7) builds both sides. Persistence lives in SQLite and, according to the README, sits in the main process, which is what makes the local-first claim concrete: project data is on the machine, not behind an account.

The interesting layer is the Skill system. Rather than one system prompt for everything, AI calls are matched to built-in or project-level Skill packages by task, and an Agent Loop mode lets the model iterate against a Skill index and a tool registry. Version 2 of the global assistant can match Skills per conversation automatically. In practice this means polishing a chapter and auditing a draft pull different instructions, and a project can import extra Skill packages of its own. The README does not document the Skill package format, so how much control you get over that matching is something you would have to discover from the repository or the linked tutorial.

A second mechanism worth noting is reasoning isolation. The README states that reasoning fields from MiniMax, DeepSeek, Tongyi, Kimi and GLM are handled, and that common thinking markers are stripped before text is written to the chapter. Anyone who has pasted a draft only to find the model's internal monologue sitting in paragraph two will understand why this is the feature that matters. The README also notes that whether thinking content is visible at all depends on the model and whether the relay passes the reasoning field through, which is an honest limit rather than a promise.

Getting it running: pnpm, a dev command, and where the API key goes

The README gives a short setup path. Node.js 18+ and pnpm 10+ are required, on Windows or macOS. From a clone:

pnpm install pnpm run dev

The dev command starts the Electron main process and the Vite renderer together. pnpm run build runs type checking and a build. Packaging is split by platform: pnpm run dist:win produces an NSIS installer, pnpm run dist:mac produces a DMG or ZIP and must be run on macOS.

AI configuration happens in the application's settings panel after first launch, not in a config file. For text generation you maintain multiple endpoint profiles and switch between them from the title bar. Each profile takes a protocol type (OpenAI-compatible or Anthropic), a Base URL where you supply only the domain or path prefix and the system appends /v1, an API key, and a model name that can be pulled from the endpoint. The README notes that OpenAI-compatible relays default to Chat Completions while official OpenAI uses the Responses API. Codex CLI is the alternative path: it reuses the local login state, so no API key is needed, and the app can find the binary path, list models and set reasoning effort.

Image generation for covers is configured separately, and the cover workbench generates prompts aimed at platforms including Fanqie, Qidian, Jinjiang, Zhihu Yanyan, Qimao and Ciweimao. The supplied README excerpt cuts off inside that section, so the image-generation keys and options are not fully documented here.

The chapter workflow is the product; the rest is scaffolding around it

The README is explicit that everything converges on the chapter. Creating a chapter starts by selecting an outline node, which carries in the title, summary and word target and establishes a binding between the two. The editor is three columns: a directory tree, a TipTap rich-text body, and an AI sidebar. Autosave writes to disk, and manual snapshots can be rolled back. Chapters export to .txt or .docx, and the whole workspace exports as a JSON snapshot.

The draft pipeline is where the opinionated choices show. A chapter draft runs through writing notes, first draft, audit, then optional automatic repair, de-AI-flavouring and a writing log, with steps configurable. That is a workflow with a point of view: it assumes you want a machine-assisted draft you then correct, rather than a blank page you fill by hand. The outline view uses a two-column staggered timeline per volume with drag reordering and AI expansion, and a separate plot-thread area tracks foreshadowing, suspense and payoff plans. A relationship graph rendered with Cytoscape covers characters and organisations.

None of this is a text editor with a plugin. It is a database-backed project model with a writing surface on top, and the cost of that is that you adopt its vocabulary: volumes, outline nodes, knowledge entries, Skills. If your process does not map onto those nouns, the tool will feel like it is arguing with you.

Where it breaks down: platform signing, provider dependence, and the undocumented Skill format

The clearest limitation is distribution. The README states that macOS artefacts are ad-hoc signed and not notarized, suitable for internal installation and testing, and that distributing to ordinary users requires an Apple Developer certificate and notarization. The bundled GitHub Actions workflow at .github/workflows/release.yml builds arm64 and x64 on macos-26 and macos-26-intel runners on workflow_dispatch, on v* tag pushes, and on PRs that change packaging configuration, uploading to Actions artifacts. To publish properly you would need to add CSC_LINK, CSC_KEY_PASSWORD, APPLE_ID, APPLE_APP_SPECIFIC_PASSWORD and APPLE_TEAM_ID secrets and enable Developer ID signing and notarization. Until then, a macOS build is something you hand to a colleague, not to a reader.

Second, the AI layer is only as good as the endpoint behind it. The README says reasoning visibility depends on the model and the relay, and the error-detail feature exists precisely because relay responses are messy: it surfaces the error, message and responseBody fields plus the HTTP status code. If you route through a cheap relay that mangles tool calls, the Agent Loop and Skill matching degrade, and the app can only show you why.

Third, the Skill package format is not described in the README. The feature list says projects can import additional Skill packages, but the structure, the manifest fields and the matching rules are left to the linked Feishu tutorial and the source. For a feature that sits at the centre of how AI calls are routed, that is a documentation gap, not a small one. Anyone planning to write custom Skills should read the repository before assuming the extension point is stable across the frequent releases, which the release list shows arriving every day or two in early September 2026.

Compared with a general-purpose assistant plus a notes app

The obvious alternative is what most writers already do: a chat interface from one of the same providers, paired with a notes application or a folder of Markdown files. The difference is not model quality, since CharacterArc can point at the same DeepSeek or Kimi endpoint. The difference is where the state lives and who assembles the context.

With a chat window, you decide what to paste in each time. The model has no persistent view of your character list, your outline node for chapter twelve, or the foreshadowing you planted in volume one. CharacterArc keeps those in SQLite, binds chapters to outline nodes, and lets a Skill or the global assistant retrieve across the project. The trade is portability and simplicity: a folder of Markdown files opens in any editor on any machine, syncs through whatever you already use, and outlives any application. CharacterArc's escape hatch is the JSON workspace export, which the README lists, but a JSON snapshot is a data dump rather than a writing environment. If you value being able to open your manuscript in twenty years with no software, the plain-files approach wins on that axis, and CharacterArc is the wrong tool.

A second alternative is an editor plugin approach, where AI features are bolted onto a general text editor. That keeps your files as files and gives you the editor's whole ecosystem, but it gives you no relationship graph, no outline-node binding and no per-project knowledge base, because those require a data model the editor does not have. The choice is between a project model and file portability, and CharacterArc has clearly picked the first.

Licence, maintenance and what upgrading actually costs

The repository is MIT licensed, which permits commercial and private use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive licence and imposes no copyleft obligation on your own writing or on any Skill packages you write. It says nothing about the model endpoints you connect: your provider's terms and your data-handling obligations are separate, and an OpenAI-compatible relay may log prompts. Nothing here is legal advice; if you are publishing commercially, read the MIT text and your provider's terms yourself.

The maintenance picture is active. The last push recorded is 2026-09-10, with v1.19.0, v1.19.1 and v1.19.2 released on 2026-09-08 and 2026-09-09. That cadence cuts both ways. Fixes arrive quickly, and so do changes. The README's own version badge reads v1.14.2 while releases are past v1.19, which suggests the documentation lags the code. If you build custom Skill packages against an internal format, expect to re-check them after upgrades, and keep the JSON workspace export as your rollback path rather than relying on the application's own snapshot feature to survive a schema change.

Running cost is mostly your API spend, plus a Codex CLI login if you take that route. There is no subscription attached to the application itself, and no server to operate, because SQLite is local.

Editorial conclusion

Adopt CharacterArc if you are writing a book-length project on Windows or macOS and you want the settings, relationship graph, outline and chapter drafts in one local database rather than spread across cloud documents, and if you are willing to supply your own model endpoint or a locally logged-in Codex CLI. Do not adopt it if you need a hosted, multi-user or browser-only tool, or if you expect a polished signed macOS build for distribution to non-technical readers. Before committing a manuscript, verify three things: that your chosen provider returns usable reasoning fields or that the built-in cleanup of thinking markers handles what it sends, that the JSON workspace export opens in a plain text editor, and that the packaged build for your platform matches the signing story in the README, which for macOS is ad-hoc and not notarized.

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. uu201/character-arc on GitHub