Settings reference
Every knob in the settings panel (the cog at the bottom of the sidebar), with its allowed range, the shipped default, and when to move it. Changes apply on the next request — no restart. The ranges here are the ones the app actually enforces: an out-of-range save is rejected, not silently clamped.
Profile
Who you are and what Om-E should always know. Name, date of birth and the first 300 characters of About Me ride in the system prompt; email and phone stay in searchable profile memory. The first 8 Preferences (key : value pairs) also join the prompt. Always Remember is the facts store — your critical facts, one per line; the summarizer adds polished facts here automatically after chats, and every line is yours to edit or delete.
The Email Sender (SMTP) section holds the credentials Om-E uses when you ask it to send an email. Gmail: smtp.gmail.com, port 587, STARTTLS on, SSL off, with a Google App Password. Sending is always approval-gated — nothing leaves your machine without a yes.
How Always Remember reaches the model each turn. Full list puts every line in the system prompt (simple; cost grows with the list). Relevant only embeds your message and injects just the best-matching facts — scales to hundreds.
After the summarizer adds facts in the background, run a normalized + semantic near-duplicate merge automatically.
tune: Leave on unless you’re debugging fact writes.
Every N successful chat turns, a summarizer-model pass merges paraphrased facts (“wife is Sarah” + “married to Sarah” → one line). 0 disables.
Models
Pick a role, configure its provider, model, and behaviour. Eight roles power different parts of Om-E — main chat, agentic tool turns, summaries, deep verification, document digests, entity extraction, image interpretation, and a shared failover target — and all inherit from the main chat role unless set explicitly. The model picker is a searchable combobox over the live catalog; the Failover Chain is an ordered list of backups (put your floor model last), and Effort Tiersset the models behind the composer's High / eXtreme dropdown — a per-turn choice that outranks everything else for that turn.
Sampling randomness for the selected role: lower = more deterministic and factual, higher = more varied and creative. Disabled automatically for models that don’t support it.
tune: 0.2–0.4 suits summarizer / verifier roles; 0.6–0.8 suits main chat.
Cap on a single response’s length.
tune: Lower to force brevity and bound cost; raise if long answers get cut off mid-thought.
Vectors — search
How retrieval scores and selects from your indexed knowledge.
Blends keyword (BM25) and semantic (vector) matching into one score. Off = pure semantic.
tune: Turn off only to A/B pure-vector recall.
Keyword share of the blended score. 0.4 means 40% keyword, 60% semantic.
tune: Raise toward 0.6 for exact-term content (codes, part numbers, names); lower toward 0.2 for conversational content.
Minimum similarity before a retrieved memory is used at all.
tune: Raise if irrelevant snippets pollute answers; lower if Om-E “can’t find” content you know is there.
How many retrieved hits are injected per turn.
tune: Lower to save tokens; raise for broad synthesis questions.
Cross-encoder second pass over the top ~100 candidates — noticeably better precision, slower queries.
tune: Turn off on weak hardware if searches feel sluggish.
Include neighbouring chunks around every match so answers get surrounding context.
tune: Off if answers quote too much irrelevant surrounding text.
How many neighbour chunks each side when Parent Expansion is on.
tune: Raise for dense technical docs where one chunk rarely stands alone.
Vectors — chunking & indexing
How content is split and embedded on the way in. The Clear Session Vector button wipes the per-topic vector stores for the current KB; content re-indexes on the next ingest.
Content above this many characters gets chunked instead of stored whole.
tune: Lower to chunk more aggressively — finer retrieval, more vectors.
Upper size of each embedded chunk.
tune: Smaller chunks = more precise hits but less context per hit.
Context carried between neighbouring chunks so sentences aren’t cut dead at boundaries.
tune: Lower to shrink index size at a slight recall cost.
Per-chunk embeddings for large payloads (vs one embedding per document).
tune: Leave on; off is a debugging escape hatch.
Prefixes each chunk with [KB | Topic | Date] before embedding — better precision on large multi-topic KBs.
tune: Off only for single-topic KBs where headers add noise.
Embedding batch size — throughput vs memory.
tune: Lower on memory-constrained machines; raise on a strong GPU.
FAISS index. SQ8: quantized, 4× smaller, near-identical recall (recommended). Flat: exact fp32. HNSW: approximate, for stores over ~10K vectors. Applies on the next index rebuild.
tune: flat to rule out quantization in a recall investigation; hnsw for very large KBs.
Graph
Knowledge-graph-enhanced retrieval: entities and relationships extracted from your content boost related results during chat retrieval. A KB with no graph yet degrades gracefully to plain vector search.
Master switch. Off (or no graph built yet) = pure vector search everywhere.
tune: Off to A/B whether the graph is helping a given KB.
Chunks = vector only. Graph Enhanced = vector + 1-hop entity expansion + merged scoring.
tune: chunks if graph results feel tangential for a KB.
Auto-run entity extraction whenever content lands (files, pages, YouTube, topics). Off = the graph only grows manually.
tune: Off to speed up bulk ingests; extract later.
Score multiplier for results that arrive via the graph alone (no direct vector match). Lower = graph-only results rank lower.
tune: Lower if graph neighbours crowd out direct matches.
Minimum score lift for a vector hit that matches a graph entity.
tune: Raise slightly if entity-heavy questions under-rank.
Cap on the total graph lift — prevents runaway boosting.
tune: Lower if graph matches dominate too hard.
Expansion depth from matched nodes. 2+ hops only kick in when 1 hop finds too little.
tune: 2 for sparse graphs where relations chain (A → B → C).
Candidate pool fed into graph scoring — bigger pool, better coverage, slower query.
tune: Raise for very large KBs where relevant chunks miss the top-100.
Include other chats’ history (the cross-chat layer) in retrieval, subject to project-membership rules.
tune: Off for strict chat isolation.
Chat — context & summaries
How many recent tool actions (open tab, list tabs…) stay in the prompt so the model knows what it just did.
tune: Raise for long tool-heavy sessions; lower to save tokens.
Chat messages before a rolling summary fires in the background.
tune: Raise for short chats; lower to compress aggressively.
If token usage hits this first, the summary runs early — before the message-count trigger.
tune: Lower if long individual messages bloat context before the count trips.
Summaries kept in the prompt before older ones consolidate into one.
tune: Raise to preserve more long-range chat memory verbatim.
Chat — loaded topic pipeline
When a loaded (full-payload) topic is too big for one turn, Om-E switches to batch mode: the topic splits into chapters, processed a few per turn, with periodic curated snapshots. These knobs govern that pipeline.
Loaded-topic message count that triggers batch mode.
tune: Lower if big loaded topics blow the context window.
Token estimate that triggers batch mode — whichever threshold trips first wins.
tune: Raise for million-token-window models; lower for small local models.
Target size of each chapter chunk.
tune: Bigger chapters = fewer turns, heavier each.
Preferred floor before a chunk is split (final tail excepted). Keep below Target.
Ceiling before a forced split. Keep above Target.
Auto-size chapters from the active model’s real context window instead of the fixed targets.
tune: Leave on — the fixed targets are the fallback.
Fraction of the model’s effective context used per chapter when adaptive sizing is on.
tune: Raise for huge-window models to finish in fewer turns.
Context held back for everything that isn’t the loaded payload — system prompt, history, tools.
tune: Raise if batch turns overflow; lower for lean chats.
Chapters processed on each turn of a running large-topic job.
tune: Raise on fast, cheap models to finish sooner.
Write a deduplicated curated snapshot every N batches.
tune: Raise to trade snapshot freshness for speed.
Per-chapter excerpt length persisted into the findings file.
tune: Raise for richer citations in findings.
Chat — destructive approvals
Gated (the default) asks before destructive actions — deletes, sends, overwrites. Session auto-approve disables the gates across all chats for this live session only. Two buttons clear remembered "don't ask again" grants for the current chat or all chats. This section saves instantly, not via the Save button. The Chat tab also hosts a live diagnostics card — turn counts, tool error rate and latency percentiles from the app's flight recorder.
MCP
Connect external Model-Context-Protocol tool servers: one-click Docker Desktop gateway, npx / Docker / custom-command registration with local secret storage (raw secrets never live in the registry), curated bundled integrations, per-server and per-tool enable toggles, and per-chat inclusion.
Account
Om-E Cloud sign-in, license state (days remaining, manage / renew in the browser), and usage — monthly totals, recent turns, transaction history. Your LLM traffic runs on your own provider keys from the Models tab.