Choosing an AI writing tool is also choosing a home for the manuscript. In a cloud-centered product, the canonical project usually lives in the service and appears on each signed-in device. In a local-first product, the durable project lives on a device the writer controls, while network services may be added for sync or AI processing.
Neither architecture is universally safer or more private. Cloud software can offer excellent redundancy and access control. A local folder can be lost with an unbacked laptop. A “local-first” editor can still send selected prose to a remote model. The useful comparison is not a slogan; it is a map of which system is responsible for each copy and each transmission.
The short answer
Choose a local-first workflow when you prioritize file-level ownership, use multiple tools on the same source, want independent version control, or need the manuscript to remain usable without one vendor account.
Choose a cloud-centered workflow when immediate multi-device access, automatic service-managed synchronization, or real-time collaboration matters more than direct control of the canonical files.
Choose a hybrid workflow when you want a local source of truth plus optional encrypted sync, backup, and explicitly initiated cloud model calls. Hybrid systems provide flexibility, but only if the product clearly explains which layer is authoritative.
Decision matrix
| Concern | Local-first tendency | Cloud-centered tendency | Question to ask | | --- | --- | --- | --- | | Canonical copy | Stored in a visible local project | Stored in a service account/database | Can I identify and back up the complete source of truth? | | Multi-device access | Requires chosen sync or file transfer | Usually built into the service | What happens during conflicts or offline edits? | | Recovery | Your backup/versioning practice is critical | Provider often handles autosave; revision depth varies | Can I restore a specific earlier passage after a week? | | Portability | Ordinary files can work with other tools | Depends on export completeness | Does export include structure, notes, metadata, and history? | | AI processing | May still call remote models | Usually calls managed remote models | Exactly what context is transmitted and retained? | | Collaboration | More setup; file conflicts need handling | Often easier to share centrally | Do collaborators need simultaneous editing or occasional handoff? | | Vendor outage | Core local editing can continue | Access may depend on service availability | Which essential tasks work offline? | | Device loss | Dangerous without independent backup | Synced service copy may simplify recovery | Have I tested a full restore? |
“Local-first” describes data gravity
The phrase does not simply mean that an application has a desktop installer. Many desktop apps are clients for a cloud database. Conversely, a web-accessible tool may export excellent portable data.
A strong local-first claim usually means:
- the canonical project is stored in a location the user controls;
- meaningful content is available in documented, inspectable, or broadly readable formats;
- the core project can be opened without contacting the original service;
- sync is an additional capability rather than the only route to the manuscript;
- backup and versioning can be performed independently.
Obsidian is a clear current example of local file gravity. Its official storage documentation says a vault is a folder on the local file system and notes are Markdown plain-text files that other editors can modify. Optional sync choices can be layered onto that folder.
Those properties do not make Obsidian a complete novelist or AI workflow. They demonstrate the architectural distinction: the notes remain files first.
Cloud software makes mobility ordinary
Cloud-centered writing systems reduce the operational work of getting the same current project onto several devices. LivingWriter’s official overview describes cloud sync across mobile and desktop applications, automatic real-time saving, integrated manuscript organization, and version restoration.
That bundle solves practical problems. A writer can capture a scene away from the primary computer, lose a laptop without losing the service copy, and avoid manually merging a phone edit with a desktop folder. The service can also give its AI tools a consistent project context without requiring the writer to configure local indexing.
The cost is dependence. The writer must understand export, account recovery, service availability, subscription changes, and the provider’s data policies. “The service has a copy” is not the same as “I have a complete backup I can restore elsewhere.”
AI location is a separate question
The manuscript can be local while inference is remote. A desktop editor may send a selected scene and story notes to a model API. The project can be cloud-hosted while some language features run on the device. Product comparisons often blur these layers.
For every AI action, ask:
- Which text and metadata are selected as context?
- Is transmission automatic or initiated for a clear task?
- Which company receives it—the writing-app vendor, a model provider, or both?
- Which account and retention settings apply?
- Does the provider use submitted content for training, and under what terms?
- Can the writer choose another model or disable AI while keeping the project useful?
Answers belong in current privacy and provider documentation, not assumptions based on an app-store category. Policies change, so recheck them before processing unpublished, confidential, or contract-restricted material.
Recovery has four different meanings
Marketing pages frequently collapse several safeguards into “your work is safe.” Separate them:
Autosave protects recent typing from an application crash.
Sync copies current state between locations or devices. It can also synchronize an accidental deletion.
Version history preserves earlier states so unwanted changes can be examined and reversed.
Backup is an independent recoverable copy that survives failure of the primary device or service.
A robust workflow usually needs all four. Local writers should use automated backups in addition to Git or document history. Cloud writers should perform periodic complete exports and test whether those exports can recreate a usable project.
AI increases the importance of version history because one approved operation can change far more text than a conventional keystroke. A revision interface should expose the affected material and preserve the prior state even after the session ends.
Portability means more than DOCX
A final DOCX export is essential for many publishing workflows, but it may not be a complete project export. A long-form system can also contain scene order, status, synopsis, character facts, research links, comments, model instructions, and revision history.
Evaluate portability in layers:
- Can you obtain the current prose in a conventional format?
- Does the export preserve chapter boundaries and order?
- Can you export notes, research, and project metadata?
- Is there a documented machine-readable representation?
- Does meaningful version history leave with the project?
- Can another tool use the result without manual reconstruction?
Local text formats often make the first four easier, but only disciplined folder and metadata conventions make them coherent. A cloud product may provide a more complete structured export than a disorganized local folder. Test the actual route out.
Collaboration changes the answer
For a solo novelist, simultaneous multi-user editing may be irrelevant. For a writers’ room, co-authored research project, or editor working directly in the manuscript, cloud coordination can be decisive.
File-based collaboration through Git is powerful when collaborators understand branches, merges, and diffs. It is hostile when they do not. Shared folders can be simpler but still produce conflicts. Cloud document systems can centralize comments and permissions, though access remains tied to the service.
Choose for the real collaborators, not an imagined future team. A solo writer should not accept unnecessary account dependence for a feature never used. A working team should not adopt a technically elegant file workflow that one member cannot safely operate.
A hybrid pattern for sensitive long-form work
A practical hybrid can look like this:
- the manuscript and project notes live in a local, portable folder;
- the folder receives automatic encrypted device backups;
- optional sync is used for the writer’s own devices;
- durable checkpoints preserve accepted states;
- AI requests are bounded to the context needed for a chosen job;
- network activity and model-provider settings are documented;
- complete exports are tested before major product updates.
This pattern places responsibility on both product and writer. It is not zero maintenance. Its advantage is separability: changing the backup provider, model provider, or editor does not necessarily require abandoning the manuscript source.
Calliope: local manuscript, connected agent
Calliope is a concrete hybrid example. The manuscript is a local project on the writer’s Mac. Chapters and scenes are stored as Markdown with structured metadata, and Calliope records durable changes in Git.
The writer can connect that project to Codex. Calliope and Codex then work on the same manuscript: the author can write and edit in Calliope, while Codex can read, revise, and organize manuscript content through Calliope’s agent tools. Inline revisions use an explicitly submitted selection and current-scene context. The local files and Git history remain on the Mac.
An optional private GitHub repository provides an off-device copy and synchronization path. That makes the layers explicit: local files are the working manuscript, Git records versions, GitHub provides remote backup, and Codex supplies the connected AI agent. Calliope is still in development for macOS. Read the detailed Calliope product profile for the current feature record.
A ten-minute architecture audit
Before choosing a product, write down the answers to these questions:
- Where is the canonical manuscript when all devices are offline?
- What is the smallest meaningful export, and what is the most complete one?
- Can the exported project be opened without the original vendor?
- What happens if the account is locked or the subscription ends?
- What happens if the main computer is stolen?
- Can an unwanted edit from last month be restored?
- Which project materials can an AI action transmit?
- Who receives that request and which policy applies?
- Can AI be disabled without losing the manuscript editor?
- Have you personally tested backup restoration and export?
If a vendor’s documentation cannot answer the product-specific questions, contact the vendor before moving a manuscript. If your own workflow cannot answer the backup questions, fix that regardless of which product you buy.
Bottom line
Local-first systems optimize for durable user control and tool interoperability. Cloud systems optimize for managed access, synchronization, and centralized context. Calliope combines a local manuscript and Git history with a connected Codex agent and optional private GitHub backup.
Select the failure mode you can mitigate. If you choose local-first, automate backup and learn recovery. If you choose cloud, export completely and routinely. If AI is involved, trace the data path separately from the storage architecture. The most reassuring label is less valuable than a recovery process you have actually tested.
Product details were checked against the first-party sources linked in this article on 2026-08-12. Features and terms can change; verify them with the vendor before choosing a tool. No vendor reviewed here paid for placement.