Local Data and Privacy
The default: nothing leaves the machine
A bare install of Free Local — no model key configured — keeps repository
analysis, local work items, checkpoints, and generated local artifacts on
your machine. It does not require a Strata19 account and does not upload
your source code. The deterministic verification gate (the four detectors
behind strata19.verify_implementation) and the Stop-hook variant of it make
no network request while performing that check; they read the repository on
disk and read/write local SQLite state.
Where local state actually lives:
| What | Where |
|---|---|
| Settings | <project>/.strata19/settings.json |
| Model provider credentials | ~/.strata19/credentials.json (never inside a repository) |
| Checkpoints | .praetor/strata19-checkpoints.db (resolved via git, shared across worktrees of the same repo) |
| Model-assist spend ledger | model_spend_events, local to the plugin's own state store |
The exception: BYOK model-assist, and exactly what triggers it
Setting OPENAI_API_KEY (or STRATA19_MODEL_KEY) enables optional
model-assisted output. This changes the boundary only for the specific
tool call that uses it, and only when it runs — it is never automatic on a
bare verify_implementation or compute_change_impact call, and none of the
14 core free-local tools (initialize, verify, change-impact, implementation
context, finding detail, checkpoint, workspace-view, work-item capture, spec
context, and others) degrades its output based on whether a key is present.
Core deterministic tools — initialize, verify, change-impact, implementation context, finding detail, checkpoint, workspace-view, spec context, and others — never degrade their output based on whether a key is present; they have a real free-local implementation and always run it. The tool calls that do send something to your configured model provider, only when a key is set and that specific call is made, are these:
- Work item enrichment — drafting/refining a captured work item
(
manage_work_item). - Spec clause drafting — building Specbook sections
(
spec_generate/spec_sync). - Remediation explanation — explaining a proposed fix for a finding
(
remediate_finding). - Recommendation drafting —
get_next_task-adjacent suggestions. - Query interpretation — turning a natural-language ask into a
structured query (
interpret_query).
Without a key, every one of these degrades to its deterministic output plus
an honest note that model assistance was unavailable — never a fabricated
answer. STRATA19_MODEL_MAX_CALLS (default 50 per process) puts a hard
ceiling on how many of these requests a single process can make, and 0
disables model assist entirely even with a key configured.
Where a request goes is entirely your choice: point
STRATA19_MODEL_BASE_URL at a local Ollama server for zero billed, zero
network-egress inference, or at a cloud provider of your choosing. The
plugin never picks a default remote endpoint for you beyond the
OpenAI-compatible default (https://api.openai.com/v1/chat/completions),
which only activates once a key is present.
Two things this is not
- Not a connected cloud sync.
STRATA19_API_KEY/STRATA19_API_ENDPOINTexist for a future hosted (Pro) tier — deeper cross-repo, cross-file analysis and persistent orchestration. Setting them today changes nothing: every current tool has a real free-local implementation and runs it regardless, and marks the response as locally-answered in its provenance. - Not host control. The plugin cannot steer, interrupt, or drive your coding host from outside your own conversation — that boundary is architectural for this version, not a missing feature. See Limits.
Credentials
Keep provider keys out of repositories. Use your host's environment
configuration or the local Strata19 credentials store
(~/.strata19/credentials.json) rather than committing a key to
.mcp.json or any tracked file.