WHY local embeddings

Embeddings are how semantic search works.
Local embeddings are how Core semantic retrieval can run in Obsidian after indexing.

The simple data flow

Your notes stay on your device for the Core retrieval workflow.
An embedding model runs locally to create vectors.
Those vectors are stored locally as an index.
Searches compare your query vector or current-note vector to your local index.
Results are returned without uploading your vault for Core semantic retrieval.

No copy of your notes needs to leave your machine for the Core Connections and Lookup retrieval path to work.

Provider workflows are separate. If you use a configured cloud provider, Smart Chat, Generate, or another provider-backed workflow, that provider receives the context you explicitly choose to send through that workflow.

Why this changes behavior

When the boundary is visible, people can capture and retrieve with less friction.

When they capture more, retrieval gets better.

Better retrieval makes it easier to build grounded context, attach threads to notes, and review AI work from the place where the work already lives.

That is compounding.

The honest trade

Local embeddings can cost:

setup time during the first index
local compute, depending on model, device, and vault size
occasional rebuild time after major model or source changes

But the benefits are structural:

Core semantic retrieval can run locally after indexing
your index stays portable with your vault
provider use remains explicit and configurable
fewer surprise policy boundaries are introduced for first retrieval

Next step

Pick one real note.

Review sources and exclusions in Smart Environment settings.
Confirm the default local embedding model or choose another model intentionally.
Wait until Smart Environment shows import and embedding readiness.
Run one Connections or Lookup test and preview the strongest result.

You know it worked when one useful result appears from your own vault without sending the retrieval context to a cloud provider.