Local-First Design

ThinkForge stores your data on your machine. This is a design decision, not a limitation.

What local-first means

In ThinkForge, local-first means:

Your project files, documents, and notes live in folders you control
Semantic memory, search indexes, embeddings, and metadata are stored locally inside each workspace
Agents execute locally, with inputs, outputs, and logs stored as files on your disk
No content is uploaded to ThinkForge servers for core functionality
The application is designed to work offline for local operations

What does get sent externally? When you use an AI provider, the prompt and context you provide are sent to that provider's API. ThinkForge does not route those requests through its own servers.

Why this matters

AI workflows generate a lot of valuable content: code, analysis, research summaries, architecture decisions, and meeting notes. Most AI tools keep that content in their cloud, behind their login, on their terms.

ThinkForge takes the opposite approach:

You own your files. They use standard formats you can open in other tools.
You control backups. Use git, Dropbox, Time Machine, external drives, or any backup tool you already trust.
You control transfer between machines. Move or back up workspace files through tools you choose.
No lock-in. If you stop using ThinkForge, your files stay where they are.

What about cloud services?

ThinkForge does not currently offer cloud sync. Your workspace data is designed to remain on your machine. Moving a workspace between machines is handled through files and backups you control.

Account services are separate from workspace storage
Core workspace functionality does not depend on ThinkForge cloud storage
Use your own backup workflow if you want copies elsewhere

File formats

ThinkForge uses open, inspectable formats:

Documents: Markdown with YAML frontmatter
Chat logs: Markdown-based chat format
Memory database: SQLite
Agent definitions: JSON
Settings: JSON