> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sovseal.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Embedding Model

> sovseal runs one fixed local embedder — there is no pluggable provider system to configure.

## There is no provider abstraction

Unlike frameworks that let you swap in OpenAI, Vertex AI, or Ollama for embeddings, sovseal deliberately does not — each surface runs one fixed, hardcoded model, entirely on-device via Transformers.js. `@sovseal/mcp-server` runs `Xenova/all-MiniLM-L6-v2` (ONNX, quantized, \~22 MB, 384-dim, SHA-256-pinned); `@sovseal/extension` runs `intfloat/multilingual-e5-small` (also 384-dim).

<Warning>
  **Currently diverged, not unified.** A same-day model-integrity-pinning fix reverted the MCP server off a brief mid-development unification onto the extension's model — the two surfaces do not currently share one vector space (see "Why the embedder is fixed" below for why that matters). This is being reconciled; track `logs/escalation/EMBEDDER-minilm-e5-prefix-mismatch.md` in the source repo for status.
</Warning>

<Warning>
  There is no `embedder.provider` config key, no YAML configuration format, no `server/` directory, and no Docker image to rebuild with a different embedder baked in. If you've seen documentation describing Ollama, Vertex AI, or OpenAI embedder providers for this project, that describes a different project's plugin architecture.
</Warning>

## Why the embedder is fixed, not pluggable

Two reasons, both structural rather than incidental:

1. **One shared vector space is the goal, even though it's not the current state.** The MCP server and the extension both write to the same conceptual memory graph and need to recall each other's writes correctly. If either surface independently chooses a different embedder — which is exactly the current, temporary state, see the warning above — a memory captured in the browser becomes unreliably rankable from the MCP server: mismatched embeddings don't error, they just rank badly, silently. The model being **fixed per surface** (not user-configurable) is what keeps this a tracked, fixable inconsistency rather than an open-ended combinatorial support problem across arbitrary user-chosen models.
2. **Zero-knowledge requires local inference.** A managed embedding provider (OpenAI, Vertex AI) means your raw memory text leaves the device to be embedded — which breaks the entire premise. The only embedder options consistent with the architecture are ones that run **on-device**, and maintaining a matrix of on-device runtimes (ONNX vs. GGUF vs. Core ML, each with different quantization behavior) multiplies the same fork risk described above.

## If you need a different model

This is a real limitation for some workloads — a 384-dim general-purpose multilingual model won't be the best fit for every domain. There are two supported paths:

* **Self-host and modify the source.** `packages/sovseal-mcp-server/src/local/embeddings.ts` (MCP server) and `apps/extension/src/engine/embeddings.ts` (extension) are where each surface's `EMBEDDING_MODEL` is defined. Since both are open source, you can fork and swap the model — but you take on responsibility for keeping every consuming surface in sync, which is exactly the risk the default configuration exists to avoid.
* **Ask for it.** If you have a concrete workload the default model handles poorly, `enterprise@sovseal.com` is the right channel — a per-deployment override is a reasonable request; a general plugin system is not currently planned, for the reasons above.

## The two models, side by side

| Property          | `@sovseal/mcp-server`                               | `@sovseal/extension`                                     |
| ----------------- | --------------------------------------------------- | -------------------------------------------------------- |
| Model             | `Xenova/all-MiniLM-L6-v2`                           | `intfloat/multilingual-e5-small`                         |
| Dimensions        | `384`                                               | `384`                                                    |
| Prefix convention | None                                                | `"query: "` for recall, `"passage: "` for stored content |
| Runtime           | ONNX via Transformers.js, quantized, SHA-256-pinned | ONNX via Transformers.js, quantized                      |
| Where it runs     | On-device                                           | On-device                                                |

<Note>
  The MCP server's embedder does **not** use e5-style prefixes — that convention is specific to the extension's e5 model. Both run entirely on-device regardless.
</Note>

See [Zero-Knowledge](/platform/core-concepts/zero-knowledge) for why local inference is load-bearing to the security model, not incidental to it.