How Prometheus works

Prometheus is not “a chat model glued onto Obsidian” — it is local RAG: an index of your Markdown notes, meaning-based retrieval, and answers generated strictly from the retrieved context.

Three processes on your machine

1. Prometheus Plugin — Community Plugin: Chat, Search, Settings, Status, Vault API access, and runtime lifecycle.
2. Prometheus Runtime — local sidecar: parsing, chunking, embeddings, sqlite-vec, retrieval, grounded prompt.
3. Ollama — external local runtime for the LLM you choose.

┌─────────────────────────────────────────────────────────────┐
│                     User's computer                         │
│                                                             │
│  ┌──────────────────────────────┐                           │
│  │     Prometheus Plugin        │                           │
│  │ Chat / Search / Settings     │                           │
│  └──────────────┬───────────────┘                           │
│                 │ HTTP on 127.0.0.1                         │
│                 ▼                                           │
│  ┌──────────────────────────────┐       localhost           │
│  │      Prometheus Runtime      │────────────────────┐      │
│  │ Parser / Chunker / Retrieval │                    ▼      │
│  │ FastEmbed / sqlite-vec       │           ┌────────────┐  │
│  └──────────────────────────────┘           │   Ollama   │  │
│                                             │ Local LLM  │  │
│                                             └────────────┘  │
└─────────────────────────────────────────────────────────────┘

What the plugin does

The plugin stays thin. It:

• renders Chat, Search, Status, and Settings UI;
• reads Markdown through the Obsidian Vault API;
• listens to create / modify / rename / delete;
• downloads, verifies, and starts the managed Runtime (or connects a custom binary);
• opens a note and heading from a source citation;
• sends documents and questions to Runtime over localhost.

The plugin does not compute embeddings, own the vector index, or call the LLM directly.

Vault indexing

When a note changes, the plugin debounces, reads the file, and sends the document to Runtime:

1. validate Vault ID, Document ID, and revision;
2. skip if content_hash is unchanged;
3. parse Markdown and run heading-aware chunking;
4. generate embeddings with FastEmbed;
5. atomically upsert into sqlite-vec and update the SQLite manifest / FTS.

Indexing is idempotent: the same hash does not recompute embeddings. Rename keeps the Document ID; delete removes chunks and vectors.

Query / RAG pipeline

Answering a question (Chat)

1. embed the query;
2. dense search (default) over sqlite-vec;
3. optional hybrid dense + BM25 (FTS5) via weighted RRF;
4. optional reranker (cross-encoder);
5. select context within a token budget;
6. grounded prompt → Ollama → streamed answer + sources.

Semantic search (Search)

Same retrieval component, without calling the LLM: you get a ranked list of fragments and can open notes directly.

Grounding policy

The model is instructed to rely only on the provided context. If retrieved chunks are insufficient, Runtime returns insufficient_context — the product should tell you that, not fill gaps from the model’s general knowledge.

Where data lives

• Vault Markdown — the single source of truth, inside the Obsidian vault.
• Runtime binary, embedding index, models — outside the vault and outside .obsidian/plugins, so they stay out of Obsidian Sync / Git.
• Ollama model weights — in Ollama’s directory on your machine.

Next

UI features guide →
Step-by-step setup →