Commands, package names, and image names on this page come from the open-source project that Mibyan Desktop is built on, and can differ from the Mibyan Desktop installer. For the supported Mibyan install and update path, see Install and update.
Quick Start
mibyan plugins → Provider Plugins → Memory Provider.
Or set manually in ~/.mibyan/config.yaml:
How It Works
When a memory provider is active, Mibyan automatically:- Injects provider context into the system prompt (what the provider knows)
- Prefetches relevant memories before each turn (background, non-blocking)
- Syncs conversation turns to the provider after each response
- Extracts memories on session end (for providers that support it)
- Mirrors built-in memory writes to the external provider
- Adds provider-specific tools so the agent can search, store, and manage memories
Available Providers
Honcho
AI-native cross-session user modeling with dialectic reasoning, session-scoped context injection, semantic search, and persistent conclusions. Base context now includes the session summary alongside user representation and peer cards, giving the agent awareness of what has already been discussed.
Tools (5):
honcho_profile (read/update peer card), honcho_search (semantic search), honcho_context (session context — summary, representation, card, messages), honcho_reasoning (LLM-synthesized), honcho_conclude (create/delete conclusions)
Architecture: Two-layer context injection — a base layer (session summary + representation + peer card, refreshed on contextCadence) plus a dialectic supplement (LLM reasoning, refreshed on dialecticCadence). The dialectic automatically selects cold-start prompts (general user facts) vs. warm prompts (session-scoped context) based on whether base context exists.
Three orthogonal config knobs control cost and depth independently:
contextCadence— how often the base layer refreshes (API call frequency)dialecticCadence— how often the dialectic LLM fires (LLM call frequency)dialecticDepth— how many.chat()passes per dialectic invocation (1–3, depth of reasoning)
reasoningLevelCap); see Query-Adaptive Reasoning Level.
Setup Wizard:
mibyan honcho setup command still works (it now redirects to mibyan memory setup), but is only registered after Honcho is selected as the active memory provider.
Headless / remote machines: for cloud auth on a box without a browser (SSH, remote VM), pick device at the wizard’s auth-method prompt. The CLI prints a short code and a verification link; open the link in a browser on any other machine, approve, and setup completes — no API key copy-paste. The wizard defaults to this option automatically when it detects no usable local browser.
Config: $mibyan_HOME/honcho.json (profile-local) or ~/.honcho/config.json (global). Resolution order: $mibyan_HOME/honcho.json > ~/.mibyan/honcho.json > ~/.honcho/config.json. See the config reference and the Honcho integration guide.
Multi-peer setup:
Honcho models conversations as peers exchanging messages — one user peer plus one AI peer per Mibyan profile, all sharing a workspace. The workspace is the shared environment: the user peer is global across profiles, each AI peer is its own identity. Every AI peer builds an independent representation / card from its own observations, so a coder profile stays code-oriented while a writer profile stays editorial against the same user.
The mapping:
New profile, fresh Honcho peer
--clone creates a mibyan.coder host block in honcho.json with aiPeer: "coder", shared workspace, inherited peerName, recallMode, writeFrequency, observation, etc. The AI peer is eagerly created in Honcho so it exists before the first message.
Existing profiles, backfill Honcho peers
mibyan block, and creates the new AI peers eagerly. Idempotent — skips profiles that already have a host block.
Per-profile observation
Each host block can override the observation config independently. Example: a code-focused profile where the AI peer observes the user but doesn’t self-model:
Presets via
observationMode:
"directional"(default) — all four flags on. Full mutual observation; enables cross-peer dialectic."unified"— userobserveMe: true, AIobserveOthers: true, rest false. Single-observer pool; AI models the user but not itself, user peer only self-models.
Gateway identity mapping
The peer model above covers CLI, TUI, and desktop sessions, where every conversation resolves topeerName. The gateway adds a second axis: users arrive with platform-native runtime IDs (Telegram UID, Discord snowflake, Slack user), and three keys decide which peer each ID resolves to.
Off-gateway these keys do nothing.
mibyan memory setup only prompts for them when it detects a connected gateway platform. See the Honcho page for the resolver ladder and the setup flow.
See the config reference and Honcho integration guide.
OpenViking
Context database by Volcengine (ByteDance) with filesystem-style knowledge hierarchy, tiered retrieval, and automatic memory extraction into 6 categories.
Tools (6):
viking_search (semantic search), viking_read (tiered: abstract/overview/full), viking_browse (filesystem navigation), viking_remember (store facts), viking_forget (delete a memory file by exact viking:// URI), viking_add_resource (ingest URLs/docs)
Setup:
mibyan memory setup can reuse or copy connection values from
~/.openviking/ovcli.conf. Manual setup uses the active profile’s .env file;
for the default profile that is ~/.mibyan/.env, and for named profiles use
~/.mibyan/profiles/<profile>/.env.
ov.conf (--config,
OPENVIKING_CONFIG_FILE, or ~/.openviking/ov.conf). Client connection values
live in ovcli.conf (OPENVIKING_CLI_CONFIG_FILE or
~/.openviking/ovcli.conf).
When the endpoint is local and nothing is listening, Mibyan starts
openviking-server in the background. That server gets your model-provider
keys (for its embedding and VLM models), your HOME and
OPENVIKING_CONFIG_FILE, but never bot, gateway or relay tokens, and not
Mibyan’s PYTHONPATH. Put anything else the server needs in ov.conf.
Key features:
- Tiered context loading: L0 (~100 tokens) → L1 (~2k) → L2 (full)
- Automatic memory extraction on session commit (profile, preferences, entities, events, cases, patterns)
viking://URI scheme for hierarchical knowledge browsing
OPENVIKING_ACCOUNT and OPENVIKING_USER are used for local/trusted mode.
Peer identity is optional. By default, Mibyan sends no peer ID and writes
explicit memories to viking://user/<user>/memories/.... Setup does not ask
for a peer ID. For separate assistant context, set
memory.openviking.agent: work-assistant in config.yaml.
Existing non-empty peer settings keep their peer-scoped writes and recall.
This includes OPENVIKING_AGENT and actor_peer_id or legacy agent_id in a
linked OpenViking config. Existing memories are not moved or deleted.
With no peer ID, default search covers user memory and existing peer memories
under the same OpenViking user. Old peer memories remain searchable at their
existing paths. Ranking and result limits determine which memories are returned.
Set memory.openviking.agent: mibyan to restore the old peer-scoped writes.
Memories written at user scope before this change stay there and remain
searchable. The setting changes future writes, not existing memory locations.
Mibyan sends User-Agent: openviking-memory-mibyan/<version> on OpenViking
requests. This standard harness identifier contains no per-user identifier and
does not add a separate request.
Mem0
Server-side LLM fact extraction with semantic search, reranking, and automatic deduplication. Three connection modes: Platform (Mem0 Cloud), self-hosted dashboard (a Mem0 server you run via Docker), and OSS (Mem0 in-process with your own LLM + vector store).
The
mem0 SDK extra is excluded on native Windows ARM64. An external Mem0
server over HTTP is a separate mode; a remote service does not imply that the
in-process SDK runs on that target.
Tools (4): mem0_search (semantic search; optional reranking in platform mode, off by default), mem0_add (store verbatim facts), mem0_update (update by ID), mem0_delete (delete by ID)
Setup (Platform):
mem0.json:
X-API-Key and uses the server’s /search / /memories routes. api_key is optional (omit only for AUTH_DISABLED servers). Don’t set mode: oss — it takes precedence over host.
Config: $mibyan_HOME/mem0.json (behavioral settings). Only the secret MEM0_API_KEY belongs in ~/.mibyan/.env.
OSS supported providers:
Switching modes: Re-run
mibyan memory setup mem0 --mode <platform|selfhosted|oss> or edit mem0.json directly.
Hindsight
Plugin catalogHindsight is maintained by vectorize-io and installed from the plugin catalog rather than bundled with Mibyan. Setup details live in the upstream docs: hindsight.vectorize.io/sdks/integrations/mibyan.
hindsight_reflect tool provides cross-memory synthesis that no other provider offers. Automatically retains full conversation turns (including tool calls) with session-level document tracking.
Tools:
hindsight_retain (store with entity extraction), hindsight_recall (multi-strategy search), hindsight_reflect (cross-memory synthesis)
Setup:
~/.mibyan/plugins/hindsight/ (per profile home) and is enabled under plugins.enabled in config.yaml. mibyan memory setup, mibyan memory status, mibyan plugins list and the dashboard Memory settings all work with the catalog-installed plugin. In local embedded mode the plugin installs hindsight-all on first use through Mibyan’ lazy-install path, which honours security.allow_lazy_installs.
Local mode UI: hindsight-embed -p mibyan ui start
Config: $mibyan_HOME/hindsight/config.json
See the upstream Mibyan integration docs for the full configuration reference.
Migrating from bundled Hindsight
Hindsight used to ship inside the Mibyan tree (and as themibyan-agent[hindsight] pip extra). If your config.yaml already has memory.provider: hindsight, there is nothing to do for most users:
mibyan updateinstalls the catalog plugin into every profile home that names the provider (this runs even whensecurity.allow_lazy_installsisfalse).- If the plugin is still missing on the first agent start (
mibyan chat, the gateway, …), Mibyan installs it and prints✓ Memory provider 'hindsight' moved out of core — installed its plugin from the catalog (your memory.hindsight settings and data are unchanged). - With
security.allow_lazy_installs: false, the agent-start path instead logs one line —Memory provider 'hindsight' is not installed; security.allow_lazy_installs is off — run `mibyan plugins install hindsight`.— and you runmibyan plugins install hindsightyourself.
~/.mibyan/plugins/hindsight/ and config.yaml gains plugins.enabled: [hindsight]. memory.provider, memory.hindsight.*, $mibyan_HOME/hindsight/config.json, HINDSIGHT_API_KEY in .env and your memory bank data are untouched. Verify with mibyan memory status (provider active) and mibyan plugins list (plugin installed and enabled).
Holographic
Local SQLite fact store with FTS5 full-text search, trust scoring, and HRR (Holographic Reduced Representations) for compositional algebraic queries.
Tools:
fact_store (9 actions: add, search, probe, related, reason, contradict, update, remove, list), fact_feedback (helpful/unhelpful rating that trains trust scores)
Setup:
config.yaml under plugins.mibyan-memory-store
Unique capabilities:
probe— entity-specific algebraic recall (all facts about a person/thing)reason— compositional AND queries across multiple entitiescontradict— automated detection of conflicting facts- Trust scoring with asymmetric feedback (+0.05 helpful / -0.10 unhelpful)
RetainDB
Cloud memory API with hybrid search (Vector + BM25 + Reranking), 7 memory types, and delta compression.
Tools (10):
retaindb_profile (user profile), retaindb_search (semantic search), retaindb_context (task-relevant context), retaindb_remember (store with type + importance), retaindb_forget (delete memories), plus file tools: retaindb_upload_file, retaindb_list_files, retaindb_read_file, retaindb_ingest_file, retaindb_delete_file
Setup:
ByteRover
Persistent memory via thebrv CLI — hierarchical knowledge tree with tiered retrieval (fuzzy text → LLM-driven search). Local-first with optional cloud sync.
Tools:
brv_query (search knowledge tree), brv_curate (store facts/decisions/patterns), brv_status (CLI version + tree stats)
Setup:
- Automatic pre-compression extraction (saves insights before context compression discards them)
- Knowledge tree stored at
$mibyan_HOME/byterover/(profile-scoped) - SOC2 Type II certified cloud sync (optional)
Supermemory
Semantic long-term memory with profile recall, semantic search, explicit memory tools, and per-turn conversation capture (one document per session per 4-hour window).
Tools:
supermemory_store (save explicit memories), supermemory_search (semantic similarity search), supermemory_forget (forget by ID or best-match query), supermemory_profile (persistent profile + recent context)
Setup:
mibyan memory setup, set base_url in
$mibyan_HOME/supermemory.json:
mibyan memory setup and enter the API key printed by the local
server. Configuring the endpoint first ensures the setup connection probe also
stays local.
Config: $mibyan_HOME/supermemory.json
Environment variables:
SUPERMEMORY_API_KEY (required), SUPERMEMORY_BASE_URL (compatibility fallback when base_url is not configured), SUPERMEMORY_CONTAINER_TAG (overrides config).
Base URL precedence is supermemory.json → SUPERMEMORY_BASE_URL → https://api.supermemory.ai. SDK operations and setup/status probes all use the resolved endpoint.
Key features:
- Automatic context fencing — strips recalled memories from captured turns to prevent recursive memory pollution
- Per-turn capture — each completed turn is written as it happens, one document per session per 4-hour window
- Failed turn writes are retried (at-least-once) on the next turn, session end,
/reset, or shutdown - End-to-end self-hosted routing — SDK and probe requests use the same configured endpoint
- Profile facts injected on first turn and at configurable intervals
- Profile-scoped containers — use
{identity}incontainer_tag(e.g.mibyan-{identity}→mibyan-coder) to isolate memories per Mibyan profile - Multi-container mode — enable
enable_custom_container_tagswith acustom_containerslist to let the agent read/write across named containers. Automatic operations stay on the primary container.
Memori
Structured long-term memory using Memori Cloud, with background completed-turn capture, tool-aware turn context, and explicit recall tools for facts, summaries, quota, signup, and feedback.
Tools:
memori_recall (search long-term memory), memori_recall_summary (summarized context), memori_quota (usage/quota), memori_signup (request signup email), memori_feedback (send integration feedback)
Setup:
mibyan-memori is an external integration, not a managed PM tool name. Follow
its publisher’s instructions to install the CLI in an independent environment.
Before running its installer, confirm that it targets the intended Mibyan home
and supplies a provider with declared Python dependencies. Do not let an external
installer pip-install into Mibyan’s selected environment. CLI availability alone
does not make the Python provider available inside Mibyan; an entry-point-only
distribution needs an owner-managed build that includes it.
mibyan pm install
package command. Restart Mibyan after successful dependency preparation.
Provider Comparison
Profile Isolation
Each provider’s data is isolated per profile:- Local storage providers (Holographic, ByteRover) use
$mibyan_HOME/paths which differ per profile - Config file providers (Honcho, Mem0, Hindsight, Supermemory) store config in
$mibyan_HOME/so each profile has its own credentials - Cloud providers (RetainDB) auto-derive profile-scoped project names
- Env var providers (OpenViking) are configured via each profile’s
.envfile
Providers Moving to the Plugin Catalog
Memory providers are moving out of the Mibyan tree into their maintainers’ own repositories, published through the plugin catalog — Hindsight is the first (see Migrating from bundled Hindsight). Nothing changes for you: the provider name, yourmemory.<name> settings, its data directory and its tools stay the same.
When a provider you have configured stops shipping with Mibyan, mibyan update installs its
catalog plugin for every profile that names it; if you update through the Desktop app, the
agent does the same the first time it starts (unless security.allow_lazy_installs is
false, in which case it logs the mibyan plugins install <name> one-liner instead).

