WHY local embeddings
Embeddings are what make semantic retrieval possible.
They turn note text into vectors that can be compared by meaning, so Smart Connections and Smart Lookup can surface useful notes even when the wording is different.
The important question is not only whether embeddings work.
It is:
Where does your vault text go to create them?
The cloud-embedding tradeoff
A cloud embedding service cannot create an index of your vault without receiving the source material being embedded.
For whole-vault semantic retrieval, that means every eligible note or block must cross the provider boundary as it is processed.
The provider may receive notes one request at a time rather than as one giant upload, but the practical boundary is the same:
To create cloud embeddings for the vault, the cloud provider must receive the text of the vault content included in that index.
That can be reasonable for some workflows.
It is still a significant trust decision.
Your vault may contain:
- private notes
- client work
- unpublished research
- journals
- plans
- credentials or operational details
- unfinished ideas that were never meant to leave your device
Local embeddings avoid making broad vault transfer the prerequisite for semantic retrieval.
What local embeddings change
With local embeddings:
- Eligible notes are read inside Obsidian.
- A local embedding model turns the text into vectors on your device.
- The vectors are stored in the local Smart Environment index.
- Connections and Lookup compare the current note or query against that local index.
- Related results can be returned without sending the vault text to an embedding provider.
The source notes stay on the device for this retrieval path.
The embedding index stays local.
Semantic retrieval can continue after indexing without a cloud embedding request for every search.
Callum explains the practical shape of embeddings: note text becomes numbers, those vectors are compared by similarity, and related notes appear from the local index.
Why this matters
Your whole vault does not need to become a cloud request
A single provider-backed chat request can be scoped to a few notes you intentionally selected.
Cloud embedding is a different boundary.
To make the whole vault searchable through that provider's embeddings, every eligible source must be sent for processing.
Local embeddings keep broad retrieval local, then let you decide which small, reviewed context set should cross a provider boundary later.
That produces a safer sequence:
search locally
-> review the results
-> select the smallest useful context
-> send only that context when a cloud workflow is chosen
Privacy is the default, not an afterthought
You do not need to remember to protect every note before semantic retrieval starts.
The default retrieval path can stay on-device.
Provider-backed chat, generation, ranking, media, and action workflows remain separate choices with their own explicit scope.
Retrieval works without a standing cloud dependency
After the local model and index are available, Core semantic retrieval can work without sending each query and source set to a remote embedding API.
That helps preserve:
- offline access
- predictable behavior
- independence from provider outages
- independence from API pricing changes
- portability of the retrieval index with the local environment
Better retrieval does not require broader disclosure
The goal is not to keep AI disconnected from your notes.
The goal is to control the order of operations.
First, use the local index to find what matters.
Then review the proposed sources.
Only after that should a configured cloud provider receive the context required for the selected task.
This turns data disclosure from a whole-vault prerequisite into a per-workflow decision.
Local embeddings vs cloud embeddings
| Boundary | Local embeddings | Cloud embeddings |
|---|---|---|
| Source text during embedding | Processed on the device | Sent to the configured provider |
| Whole-vault indexing | Can remain local | Every eligible source must cross the provider boundary |
| Retrieval after indexing | Runs against the local index | Depends on the cloud-derived index or provider workflow |
| Internet dependency | Usually needed for the initial model download, not normal local retrieval | Required for embedding requests |
| API usage cost | No per-note embedding API charge | Can grow with vault size and re-indexing |
| Provider dependency | Local model and runtime | Provider availability, policy, limits, and pricing |
| Best fit | Private-by-default vault retrieval | Workflows that intentionally accept remote processing |
Cloud embeddings may offer different models, performance characteristics, or operational convenience.
Local embeddings provide a stronger default boundary:
Your entire eligible vault does not need to be sent to a third party just to make your own notes searchable by meaning.
What stays explicit
Local embeddings do not mean nothing can ever leave the device.
Different workflows have different boundaries:
| Workflow | What happens |
|---|---|
| Core Connections and Lookup with a local embedding model | Notes and vectors remain local for semantic retrieval |
| Clipboard export | Content leaves Obsidian when you paste it elsewhere |
| Cloud chat or generation | The provider receives the prompt and context you send |
| Cloud ranking or embedding | The provider receives the source text required for that operation |
| Local chat model | The selected prompt and context are processed by the local model runtime |
Use this rule:
Retrieve broadly on-device. Send narrowly and intentionally.
The honest trade
Local embeddings use local resources.
Depending on the model, device, vault size, and indexing settings, they can require:
- an initial model download
- processing time during the first index
- local CPU, GPU, memory, and storage
- re-indexing after changing the embedding model or embedding policy
- a smaller or less specialized model than a remote provider might offer
Those costs are visible and bounded.
The alternative cost is less visible:
A cloud embedding index requires sending every eligible source to the cloud provider that creates it.
For a private knowledge base, local compute is often the better default trade.
Why this compounds
When semantic retrieval is local by default, users can capture more freely.
More trusted notes create a better local index.
A better index makes it easier to recover prior work, build reviewed context, and delegate from grounded source material.
The workflow compounds without requiring the vault itself to become a standing cloud data source.
Next step
- Open Smart Environment settings.
- Review eligible sources and exclusions.
- Confirm the current embedding model is local.
- Wait until Smart Environment shows Ready.
- Open one meaningful note and run Smart Connections, or search one real idea with Smart Lookup.
- Preview the strongest result before using it.
- Send only the reviewed notes required by any later provider-backed workflow.
You know it worked when:
One useful result appears from the local vault index without sending the eligible vault corpus to a cloud embedding provider.