# Kimi CLI Long-Term Memory Options Consolidated, validated reference for adding durable cross-session memory to Kimi Code CLI. All claims about external repositories were re-verified against upstream sources (May 2026). Unverified or contradicted claims from source drafts are marked or removed. --- ## Verdict ```text Best default (validated) → agentmemory (rohitg00) MCP stdio, 51 tools, local iii-engine + embeddings, REST + viewer Officially supports Claude Code, Cursor, Gemini CLI, OpenCode, Codex CLI, Hermes, OpenClaw, pi. Kimi CLI not on official list, but standard MCP stdio block should work. Best minimal local → ai-memory-mcp (alphaonedev) Rust binary, single SQLite + FTS5, 97.8% R@5 on LongMemEval, 26 MCP tools, WAL mode, 79% smaller TOON output, no API cost. Best Kimi-native → kimi-mneme (claimed by source drafts) — UNVERIFIED ⚠️ Could not be located on GitHub or PyPI in May 2026. Do not include in install plan until existence confirmed. Best minimal Python → rekal (janbjorge) Python 3.11+, single SQLite + FTS5 + sqlite-vec (384-dim), 16 MCP tools, simple stdio, primary target Codex CLI / OpenCode. Best MCP graph route → mem0-mcp-selfhosted (elvismdev) Qdrant + optional Neo4j + Ollama, ~11 tools, fully offline. Best multi-agent → HeurChain Confirmed Kimi CLI read/write via MCP SSE in source drafts; Redis + vault, ACT-R decay, BM25 only. Best temporal reasoning → Graphiti (Zep) Neo4j/FalkorDB, fact validity windows, NER pipeline. Operationally heavy; specialized use case. Avoid → MemNexus, Mem0 Cloud, Zep Cloud (data leaves machine) Letta, Honcho (replace the agent rather than extend it) Raw vector DBs without memory logic (RAG poisoning over time) SSE-only servers for new setups (SSE deprecated in MCP spec March 2025) kimi-memory-mcp (SARPixelPioneer) — AgentSeal 75/100, DeepSeek required ``` --- ## Kimi CLI Native Memory Surface — What You Get Out of the Box | Feature | What it gives | What it does **not** give | | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ | | Session persistence | Continue a session; context survives compaction via `PreCompact`/`PostCompact` hooks | Durable searchable memory across sessions or projects | | `AGENTS.md` | Project rules and conventions auto-loaded on session start | Automatic extraction of decisions, debugging insights, or evolving facts | | Hooks (Beta) | 13 lifecycle events configured as `[[hooks]]` in `~/.kimi/config.toml` (`SessionStart`, `UserPromptSubmit`, `PreToolUse`, `PostToolUse`, `Notification`, `PreCompact`, `Stop`, etc.); regex matchers, timeouts, blocking via exit code 2 | Storage or retrieval backend by itself | | Skills (`.kimi/skills/`) | Prompt-injected skill instructions, scoped Project > User > Extra > Built-in | Persistent cross-session memory | | MCP (`~/.kimi/mcp.json`) | Any standard MCP server via stdio or Streamable HTTP; managed with `kimi mcp` subcommand | Automatic memory unless the agent actively calls memory tools | | Plugins | Local toolkits packaged via `plugin.json`; OAuth credentials can be injected via `inject` block | Long-term memory unless the plugin implements it | | Agent Flow | Workflow orchestration | Not a memory layer | **Key constraints:** - Hooks are **Beta**. Implementation details and configuration definitions may change in future versions. Plugins relying on hook JSON payload shape may break on minor releases. - Global `~/.kimi/AGENTS.md` is not implemented (issue [#2152](https://github.com/MoonshotAI/kimi-cli/issues/2152)). - Native long-term memory is an open feature request (issues [#1167](https://github.com/MoonshotAI/kimi-cli/issues/1167), [#1283](https://github.com/MoonshotAI/kimi-cli/issues/1283)). - MoonshotAI has stated they have **no plan** to add a lifecycle hooks system internally beyond the current Beta implementation — orchestration is delegated to Agent Flow ([discussion #986](https://github.com/MoonshotAI/kimi-cli/discussions/986)). **Key opportunity:** The hooks system — specifically `SessionStart` for injection and `PostToolUse` for capture — is the correct integration layer for automated memory. It runs silently without consuming agent tokens on explicit tool calls. --- ## Memory Types for a Coding Agent | Type | Purpose | Typical storage | Example | | --------------------- | --------------------------------------- | ------------------------------ | -------------------------------------------------- | | Static instructions | Stable rules and preferences | `AGENTS.md`, config files | Coding style, forbidden libraries, build commands | | Session persistence | Restoring in-progress CLI state | Kimi session store | Resuming an interrupted session | | Episodic | What happened in previous sessions | SQLite, JSONL, vector DB | "We fixed auth timeout by changing retry logic" | | Semantic | Searchable facts retrievable by meaning | SQLite FTS, embeddings, Qdrant | "What did we learn about that auth bug last week?" | | Procedural | How to do recurring tasks | Markdown, command recipes | Release procedure for this repo | | Entity / relationship | Facts connected as a graph | Neo4j, FalkorDB, Graphiti | Service A depends on table B and queue C | | Reflective | Lessons learned, debugging insights | Summaries, memory notes | "Do not use this API — breaks on Windows" | | Multi-agent shared | Shared context across tools | HTTP / MCP service | Kimi + Claude Code + Cursor on one knowledge base | A serious coding-agent memory system should usually combine: static rules + episodic summaries + semantic retrieval + explicit project facts. Graph memory is useful later, but using it on day one is architectural CrossFit. > **A plain vector DB is storage, not memory.** Without capture policy, fact invalidation, deduplication, and retrieval logic, it accumulates contradictions (RAG poisoning). Choose systems with memory logic, not just storage. --- ## Selection Criteria | Criterion | Requirement | | ---------------------- | ----------------------------------------------------------------------------------- | | Kimi CLI compatibility | Works via `~/.kimi/mcp.json` (stdio/HTTP) or `kimi mcp add` | | Install path | ≤5 commands from zero to working; documented; reproducible | | Local / self-hosted | Data stays on machine by default; embeddings via Ollama/FastEmbed/ONNX configurable | | Retrieval quality | Hybrid search (semantic + keyword or graph); handles temporal facts | | Maintenance | Active repo within 90 days; responsive issues; current MCP spec | | Privacy | No mandatory cloud calls for core operations; local LLM support | | Operational complexity | Solo dev: <10 min to working; Docker overhead must be justified | | Token economy | Lazy retrieval, summaries, scoped injection, progressive disclosure | | Extensibility | Can evolve from single local file to multi-agent shared infra | --- ## Master Shortlist | System | Type | Kimi fit | Storage | Transport | Self-hosted | Verdict | | --------------------------------- | ------------------------------- | ---------------------------- | -------------------------------- | ------------ | ------------ | ------------------------------------- | | **agentmemory** | Hybrid semantic + KG + FTS | Direct (stdio) | iii engine (local) | stdio + REST | Yes | **Install now — default** | | **ai-memory-mcp** | SQLite + FTS5 + cosine | Direct (stdio) | Single SQLite + WAL | stdio + REST | Yes | **Install now — minimal** | | **rekal** | SQLite + FTS5 + sqlite-vec | Direct (stdio) | `~/.rekal/memory.db` | stdio | Yes | **Best simple local Python** | | **kimi-mneme** | Claimed Kimi-native plugin | Claimed native hooks | SQLite + sqlite-vec | MCP claimed | Yes | **⚠️ Unverified — do not rely** | | **mem0-mcp-selfhosted** | Semantic + graph | Direct (stdio) | Qdrant + Neo4j | stdio | Yes | **Best graph MCP route** | | **HeurChain** | Tiered universal | Confirmed (SSE) | Redis + vault | SSE | Yes (Docker) | **Best multi-agent** | | **mnemon** | Hybrid BM25 + vector | MCP stdio | SQLite + vector | stdio | Yes | **Best typed Python option** | | **Mnemo** | Hybrid semantic | MCP stdio | SQLite (WASM) + HNSW | stdio | Yes | **Lightest npm option** | | **Engram** | Zero-dep local | MCP stdio | SQLite + ONNX embeds | stdio | Yes | **Zero-config alt to agentmemory** | | **mcp-memory-service** (doobidoo) | Hybrid + KG | Direct (stdio + REST) | SQLite-vec (default) / hybrid | stdio + HTTP | Yes | **Evaluate — general purpose** | | **OpenMemory (Mem0)** | Temporal graph + UI | HTTP MCP | SQLite/Postgres + optional Neo4j | HTTP | Yes (Docker) | **Evaluate — temporal** | | **Hindsight** (Vectorize) | Structured 4-strategy retrieval | HTTP MCP | Postgres + pgvector | HTTP | Yes (Docker) | **Evaluate — best retrieval quality** | | **Graphiti** (Zep) | Temporal knowledge graph | MCP server | Neo4j / FalkorDB | MCP | Yes (heavy) | **Specialized — temporal** | | **@mcp/server-memory** | Official Anthropic KG | Direct (stdio) | JSONL file | stdio | Yes | **Baseline graph starter** | | **ipiton/agent-memory-mcp** | Typed (4 categories) | Direct (stdio) | Files + vector | stdio | Yes | **Strict type safety, full offline** | | **mcp-server-qdrant** (official) | Vector backend | MCP stdio | Qdrant | stdio | Yes | **Scale beyond SQLite** | | **Vestige** | Repo-pinned | Direct (stdio) | SQLite per repo | stdio | Yes | **Evaluate — project isolation** | | **Cognee** | GraphRAG control plane | Adapter required | NetworkX / Neo4j | HTTP | Yes | **Evaluate — repo knowledge** | | **mcp-local-memory** | Entity / relation KG | Direct (stdio) | SQLite + sqlite-vec | stdio | Yes | **Evaluate — structured lightweight** | | Honcho / Letta | Multi-agent platforms | Wrong paradigm for solo Kimi | Postgres + Redis | REST | Yes | **Avoid for Kimi-only** | | MemNexus | Cloud SaaS | HTTP | Cloud | HTTP | No | **Avoid** | --- ## Recommended Options — Detailed ### 1. agentmemory (rohitg00) Persistent memory for AI coding agents — 51 MCP tools, REST API on port 3111, real-time viewer on 3113. Built on iii-engine (Worker/Function/Trigger primitives) with `all-MiniLM-L6-v2` local embeddings. | Field | Assessment | | ----------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Role | Cross-session, cross-agent persistent memory with hybrid search | | Best use | Multi-tool environments (Kimi + Claude Code + Codex CLI etc.) sharing one store | | Kimi fit | **Standard MCP stdio** — Kimi is NOT on the official supported-agent list, but the universal MCP block should work | | Storage | iii-engine state store (SQLite-backed via iii's StateModule) | | Search | Hybrid: semantic (all-MiniLM-L6-v2 local) + FTS + knowledge graph + BM25 | | Self-host | Fully local; binds to 127.0.0.1 by default | | LLM/API | None for base operations; optional for advanced features | | Install | `npx @agentmemory/agentmemory` + JSON block; or full plugin via marketplace on supported agents | | Maintenance | Active (v0.9.x, May 2026); ~6.2k stars; single maintainer; documented governance | | Known issue | **Important:** `@agentmemory/mcp` standalone and `@agentmemory/agentmemory` server are architecturally isolated — they use separate KV stores. Hooks-captured observations are not visible to MCP tools unless you set `AGENTMEMORY_URL` + `AGENTMEMORY_FORCE_PROXY=1` (issue [#159](https://github.com/rohitg00/agentmemory/issues/159), partially addressed in v0.9.7+). | | Risks | iii engine is proprietary; Node.js required; standalone-vs-server isolation; server must be pre-started | | Verdict | **Install now** — maximum compatibility, best tool surface, but verify proxy config to avoid isolated stores | ```bash # Terminal 1 — start the server (background or supervisord) npx @agentmemory/agentmemory # Verify curl http://localhost:3111/agentmemory/health # Viewer open http://localhost:3113 ``` ```jsonc // ~/.kimi/mcp.json { "mcpServers": { "agentmemory": { "command": "npx", "args": ["-y", "@agentmemory/mcp"], "env": { "AGENTMEMORY_URL": "http://localhost:3111", "AGENTMEMORY_FORCE_PROXY": "1", "AGENTMEMORY_TOOLS": "all", }, }, }, } ``` --- ### 2. ai-memory-mcp (alphaonedev) Rust binary memory server — single SQLite + FTS5 with WAL mode, 26 MCP tools, 24 REST endpoints, 26-command CLI. 97.8% R@5 on LongMemEval; TOON output 40–61% smaller than JSON. | Field | Assessment | | ----------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | | Role | Default persistent memory for any MCP client — user prefs, project facts, debugging notes | | Best use | Privacy-first solo dev; zero cloud dependency; benchmarked recall | | Kimi fit | **Direct** — standard MCP stdio | | Storage | Single SQLite file with WAL (safe concurrent reads during writes) | | Search | FTS5 + cosine similarity, fixed 60/40 semantic/keyword blend; 6-factor scoring (relevance, priority, access freq, confidence, tier boost, recency decay) | | Tiers | short (6h TTL) → mid (7d TTL) → long (permanent); auto-promotion on 5+ accesses; TTL extends on recall | | Features | Contradiction detection on store; priority reinforcement (+1 every 10 accesses, max 10) | | Self-host | Fully local; no services; no containers | | LLM/API | None for keyword tier; optional LLM for smart-tier query expansion | | Install | **Pre-built Rust binary** via install script, apt PPA, dnf COPR, or PowerShell; **NOT** an npm package | | Maintenance | Active (April 2026); MIT; AlphaOne LLC | | Risks | Rust binary install adds OS-specific path; smart-tier requires API key | | Verdict | **Install now** — best for minimalism, privacy, token efficiency | ```bash # macOS / Linux curl -fsSL https://raw.githubusercontent.com/alphaonedev/ai-memory-mcp/main/install.sh | sh # Then add to ~/.kimi/mcp.json: ``` ```jsonc { "mcpServers": { "ai-memory": { "command": "ai-memory", "args": ["mcp"], }, }, } ``` --- ### 3. rekal (janbjorge) Minimal Python MCP memory server backed by one SQLite file with FTS5 + 384-dim sqlite-vec semantic index. 16 MCP tools across four categories. | Field | Assessment | | --------------- | --------------------------------------------------------------------------------------------------- | | Role | Compact local-first memory for explicit facts, preferences, and decisions | | Best use | Simplest useful MCP memory; reliability over feature density | | Kimi fit | **Direct** — standard MCP stdio (`command = "rekal"`) | | Storage | `~/.rekal/memory.db` (memories table + FTS5 virtual + sqlite-vec virtual, kept in sync by triggers) | | Search | Hybrid: FTS5 + cosine vector + recency decay | | Self-host | Fully local | | LLM/API | None required | | Install | Python 3.11+; uv tool or pip — auto-creates DB on first run | | Primary targets | Claude Code, Codex CLI, OpenCode — but standard MCP stdio works with Kimi | | Risks | Less rich than semantic + graph stacks; smaller ecosystem signal | | Verdict | **Simplest reliable Python option** | ```bash uv tool install rekal # or: pip install rekal ``` ```jsonc // ~/.kimi/mcp.json { "mcpServers": { "rekal": { "command": "rekal", "env": { "REKAL_PROJECT": "kimi-default" }, }, }, } ``` Then optionally instruct the agent in your project's `AGENTS.md`: ```text Call memory_build_context with your current task before exploring the codebase. ``` --- ### 4. kimi-mneme — ⚠️ Unverified Both source drafts describe `kimi-mneme` (claimed at `github.com/barrelc/kimi-mneme`) as a Kimi-native plugin with 13 lifecycle hooks, SQLite + sqlite-vec storage, OAuth reuse from `~/.kimi/credentials/kimi-code.json`, and automatic silent capture/injection. **Validation result (May 2026):** the repository could not be located via GitHub search, official Kimi CLI plugin showcase, or PyPI. It is also missing from the `kimi-cli` GitHub topic and `awesome-kimi-cli`. Issue [#2161](https://github.com/MoonshotAI/kimi-cli/issues/2161) — claimed to be the kimi-mneme showcase — was not surfaced as such by search. **Conclusion:** do not include in any install plan until existence and maintenance are confirmed in person. If it does exist, the lifecycle-hook architecture would be the most efficient native option — but do not block on it. --- ### 5. mem0-mcp-selfhosted (elvismdev) Self-hosted Mem0 MCP server: ~11 tools, Qdrant vectors, optional Neo4j graph, Ollama for full offline. | Field | Assessment | | ----------- | ---------------------------------------------------------------------------------------- | | Role | Full-featured general-purpose memory with entity relationships | | Best use | Projects needing knowledge graphs, entity linking, contradiction detection, full offline | | Kimi fit | Direct (stdio); `.mcp.json` config | | Storage | Qdrant (vectors) + optional Neo4j (graph) | | Search | Semantic vector + graph traversal | | Self-host | Fully offline with `MEM0_PROVIDER=ollama` | | LLM/API | Default Anthropic; fully switchable to Ollama | | Install | Medium — Qdrant + (optional) Neo4j + Ollama | | Maintenance | Active (April 2026); MIT; community | | Risks | 3-service stack; cold-start latency; not Kimi-specific | | Verdict | Use when knowledge graphs and full offline both matter | ```bash docker run -d -p 6333:6333 --name qdrant qdrant/qdrant docker run -d -p 7474:7474 -p 7687:7687 neo4j # optional, for graph ollama pull qwen3:14b && ollama pull bge-m3 kimi mcp add --transport stdio mem0 \ --env MEM0_PROVIDER=ollama \ --env MEM0_LLM_MODEL=qwen3:14b \ --env MEM0_USER_ID=artur \ -- uvx --from git+https://github.com/elvismdev/mem0-mcp-selfhosted.git mem0-mcp-selfhosted ``` --- ### 6. HeurChain Universal tiered memory layer; source drafts report **confirmed Kimi CLI read/write via MCP SSE** with all 26 tools available. BM25 search, ACT-R cognitive decay, Redis + persistent vault. | Field | Assessment | | --------- | --------------------------------------------------------------------------------------- | | Role | Shared memory infrastructure for multiple agents on one machine | | Best use | Multi-agent setups (Kimi + Claude Code + OpenClaw + CI bots) | | Kimi fit | **Confirmed** via MCP SSE | | Storage | Redis (cache + session) + vault (persistent tier) | | Search | BM25-ranked keyword; automatic tier promotion with ACT-R decay | | Self-host | Docker Compose, 4 containers | | LLM/API | None for core operations | | Risks | No semantic vector search (BM25 only); 4-container overhead; SSE deprecated in MCP spec | | Verdict | Use only if running multiple agents simultaneously and accepting Docker overhead | ```bash git clone && cd heurchain/docker cp .env.example .env docker compose -f docker-compose.standalone.yml up -d --build kimi mcp add --transport http heurchain http://localhost/sse ``` --- ### 7. mnemon (Python) Hybrid BM25 + vector with typed memory schema (decision / preference / observation / antipattern) and composite scoring (relevance + recency + confidence). | Field | Assessment | | --------- | --------------------------------------------------------------- | | Role | Structured long-term memory with typed categories | | Kimi fit | MCP stdio | | Storage | SQLite (local) or PostgreSQL (remote vault) + vector embeddings | | Self-host | Local-only or self-hosted vault | | LLM/API | Optional local 1.7B model for query expansion | | Install | `pip install mnemon-memory` + `mnemon setup` | | Verdict | Best local Python option with explicit memory typing and decay | --- ### 8. Mnemo (TypeScript) Daemonless local-first npm-installable MCP memory — ONNX embeddings, HNSW vector index, sub-100ms at 50K memories. | Field | Assessment | | --------- | ------------------------------------------------------------------------ | | Role | Fast, pure-local semantic memory for decisions, conventions, preferences | | Kimi fit | MCP stdio (designed for Claude Code; standard MCP, untested with Kimi) | | Storage | SQLite (sql.js WASM) + HNSW vector index | | Search | Cosine similarity + recency + access-frequency boost | | Self-host | 100% local; ONNX all-MiniLM-L6-v2 (~25MB); no daemon | | LLM/API | None | | Verdict | Lightest npm option — verify with Kimi before relying on | ```bash npm install -g @mnemo-mcp/cli mnemo init ``` --- ### 9. Engram (@hbarefoot/engram) Zero-dependency local-first MCP memory — SQLite + 23MB ONNX `all-MiniLM-L6-v2` embeddings. | Field | Assessment | | -------- | ------------------------------------------------------------- | | Role | Drop-in persistent memory for any MCP client | | Kimi fit | Direct (stdio) | | Storage | SQLite + ONNX embeddings | | Search | Hybrid: vector + FTS5 | | Install | Single `npm install -g` | | Verdict | Zero-config alternative to agentmemory when Node is available | ```bash npm install -g @hbarefoot/engram kimi mcp add engram -- engram start --mcp-only ``` --- ### 10. mcp-memory-service (doobidoo) Mature hybrid MCP server with REST + stdio, knowledge graph, autonomous consolidation, dashboard. | Field | Assessment | | ----------- | ------------------------------------------------------------------ | | Role | Full-spectrum agent memory with dashboard | | Best use | Multi-client shared memory; KG traversal; UI visibility | | Kimi fit | Direct — stdio or HTTP | | Storage | SQLite-vec by default (no external DB); optional Cloudflare hybrid | | Search | Semantic + KG traversal + tag filtering | | Self-host | Local-first; optional Cloudflare sync (opt-in) | | LLM/API | Embeddings local (Ollama / LiteLLM / vLLM) | | Install | `pip install mcp-memory-service` or Docker | | Maintenance | Active; PyPI | | Verdict | Evaluate for robust general-purpose memory with graph | ```bash pip install mcp-memory-service # or: uv pip install mcp-memory-service ``` ```jsonc { "mcpServers": { "memory": { "command": "memory", "args": ["server"], }, }, } ``` --- ### 11. OpenMemory (Mem0) Local-first temporal memory with dashboard UI, time-aware scoring, Waypoint audit traces. | Field | Assessment | | --------- | --------------------------------------------------------------- | | Role | Explainable temporal memory — facts that change over time | | Kimi fit | HTTP MCP transport | | Storage | SQLite (default), optional Postgres / Neo4j | | Search | Composite: relevance + recency + co-activation; Waypoint traces | | Self-host | Docker Compose; Ollama for local embeddings | | Verdict | Evaluate for workflows needing temporal reasoning | ```bash git clone https://github.com/mem0ai/mem0.git ~/mem0 cd ~/mem0/openmemory echo "EMBEDDING_PROVIDER=ollama" >> .env echo "OLLAMA_BASE_URL=http://localhost:11434" >> .env docker-compose up -d kimi mcp add --transport http openmemory http://localhost:8765/mcp ``` --- ### 12. Hindsight (Vectorize.io) Structured memory with fact extraction, entity resolution, 4 parallel retrieval strategies + cross-encoder reranking. | Field | Assessment | | --------- | ------------------------------------------------------------------------- | | Role | High-quality structured memory with retain / recall / reflect operations | | Kimi fit | HTTP MCP | | Storage | PostgreSQL + pgvector | | Search | Semantic + BM25 + graph + temporal in parallel, then cross-encoder rerank | | Self-host | Docker Compose | | LLM/API | Embedding model + LLM for `reflect` | | Verdict | Evaluate for best retrieval quality at the cost of heavier infra | --- ### 13. Graphiti (Zep) Temporal knowledge graph engine with fact validity windows. Best fit for evolving project architecture tracking. | Field | Assessment | | -------- | ------------------------------------------------------------------------------- | | Role | Temporal semantic memory tracking when facts become true or obsolete | | Kimi fit | Via Graphiti MCP server | | Storage | Neo4j 5.26+ or FalkorDB | | Search | Hybrid: semantic + keyword + graph; temporal validity windows | | LLM/API | Requires capable model (GPT-4o, Claude 3.5, or Llama 3 via Ollama) for NER | | Install | High — Neo4j/FalkorDB + Python 3.10+ + LLM pipeline | | Verdict | Specialized — temporal reasoning is best-in-class; operational overhead is high | ```bash docker run -p 8100:8100 \ -e OPENAI_API_KEY=sk-... \ -e GRAPH_DB_URI=bolt://localhost:7687 \ zepai/knowledge-graph-mcp ``` --- ### 14. @modelcontextprotocol/server-memory (Official Anthropic) Lightweight knowledge graph MCP server — entities, relations, observations in a local JSONL file. | Field | Assessment | | -------- | --------------------------------------------------------------------------- | | Role | Basic persistent structured memory for interconnected facts | | Best use | Codebase architecture relationships, team conventions, simple entity graphs | | Kimi fit | Direct — stdio MCP | | Storage | JSONL file (flat, local) | | Search | Entity graph traversal + observations; no semantic similarity | | Install | Single `npx` | | Risks | Linear search on large files; no vector search; quickly outgrown | | Verdict | Simple graph starter — good baseline, easy to migrate from | ```bash export MEMORY_FILE_PATH="$HOME/.kimi/knowledge-graph.jsonl" kimi mcp add --transport stdio memory -- npx -y @modelcontextprotocol/server-memory ``` --- ### 15. ipiton/agent-memory-mcp Typed persistent memory with 4 categories (episodic, semantic, procedural, working) and Ollama-only mode. | Field | Assessment | | --------- | ----------------------------------------------------------- | | Role | Structured typed persistent memory | | Kimi fit | Direct (stdio) | | Search | Type-aware retrieval; session capture hooks | | Self-host | `MCP_EMBEDDING_MODE=local-only` disables all external calls | | Install | `pip install agent-memory-mcp` | | Verdict | Best for strict type safety and full offline | --- ### 16. qdrant/mcp-server-qdrant Official Qdrant MCP server — backend choice, not a complete memory policy. | Field | Assessment | | -------- | ------------------------------------------------------------------------- | | Role | Scalable semantic vector backend | | Best use | Memory volume beyond what SQLite-vec handles; semantic recall as priority | | Kimi fit | MCP stdio | | Risks | More operational weight than SQLite; a backend, not a memory workflow | | Verdict | Add when memory volume justifies it; pair with a memory-logic layer | --- ## Integration Patterns | Pattern | Model | Best for | Trade-off | | ----------------------------- | ------------------------------------------------------------------ | ---------------------------------------------------------- | -------------------------------------------------------------------- | | **MCP stdio server** | `kimi mcp add` + child process (agentmemory, ai-memory-mcp, rekal) | Universal; most compatible; zero glue code | Agent must proactively call memory tools; server must be pre-started | | **MCP HTTP server** | Separate service (HeurChain, OpenMemory, Hindsight) | Multi-session, shared state, dashboard | Extra running service; network dependency | | **Kimi plugin + hooks** | Lifecycle hook scripts in `config.toml` | Automatic silent capture / injection — no agent token cost | Beta hooks; may change on minor releases | | **SessionStart hook + fetch** | Bash script → stdout `additionalContext` (when supported) | Memory injection without MCP; minimal infra | Not semantic; requires discipline | | **Manual project files** | `AGENTS.md`, `docs/decisions/`, `MEMORY.md` | Zero-infra baseline for stable rules | No search; manual curation | | **External hosted API** | Mem0 Cloud, Zep Cloud | Zero setup | Data leaves machine; vendor lock-in | **Critical insight:** Kimi lifecycle hooks (`SessionStart` for injection, `PostToolUse` for capture) run silently without consuming agent tokens on explicit tool calls. Combined with an MCP server, hooks handle session-level management automatically while MCP tools handle on-demand semantic queries. --- ## Deployment Blueprints ### Blueprint A — Minimal Viable (2 minutes) ```text Kimi CLI └── MCP stdio: agentmemory OR ai-memory-mcp OR rekal └── Local storage (iii engine / SQLite) ``` No containers. No API keys. No daemons beyond the server process. ```bash # Option A: agentmemory npx @agentmemory/agentmemory & # Add JSON block to ~/.kimi/mcp.json (see section 1) # Option B: ai-memory-mcp (Rust binary) curl -fsSL https://raw.githubusercontent.com/alphaonedev/ai-memory-mcp/main/install.sh | sh # Add JSON block to ~/.kimi/mcp.json (see section 2) # Option C: rekal uv tool install rekal # Add JSON block to ~/.kimi/mcp.json (see section 3) ``` --- ### Blueprint B — Robust Semantic + Graph ```text Kimi CLI └── MCP stdio: mcp-memory-service (doobidoo) └── SQLite-vec (hybrid storage) └── Local dashboard ``` ```bash uv pip install mcp-memory-service # Configure ~/.kimi/mcp.json with `command = "memory"` ``` --- ### Blueprint C — Multi-Agent Shared Memory ```text Kimi CLI + Claude Code + OpenClaw + CI/CD bots └── MCP SSE: HeurChain └── Docker Compose stack (Redis + nginx + vault) ``` ```bash git clone && cd heurchain/docker cp .env.example .env docker compose -f docker-compose.standalone.yml up -d --build kimi mcp add --transport http heurchain http://localhost/sse ``` --- ### Blueprint D — Full Offline Graph Memory ```text Kimi CLI └── MCP stdio: mem0-mcp-selfhosted ├── Qdrant (vectors) ├── Neo4j (knowledge graph) └── Ollama (embeddings + LLM) ``` ```bash docker run -d -p 6333:6333 qdrant/qdrant docker run -d -p 7687:7687 neo4j ollama pull qwen3:14b && ollama pull bge-m3 kimi mcp add --transport stdio mem0 \ --env MEM0_PROVIDER=ollama \ --env MEM0_USER_ID=artur \ -- uvx --from git+https://github.com/elvismdev/mem0-mcp-selfhosted.git mem0-mcp-selfhosted ``` --- ## Recommended Architecture ### Layer model ```text Stable project rules → AGENTS.md (project root; global ~/.kimi/AGENTS.md not yet implemented) Session-level capture → SessionStart / PostToolUse hooks → MCP write On-demand semantic recall → ai-memory-mcp / agentmemory / rekal (MCP tools) Knowledge graph (opt-in) → mem0-mcp-selfhosted or Graphiti Codebase index (opt-in) → Qdrant + SKILL.md workflow ``` ### Solo developer — start here 1. `ai-memory-mcp` (Rust, minimal) **or** `agentmemory` (most tools, cross-agent) via `~/.kimi/mcp.json` 2. `AGENTS.md` in each project root for stable conventions 3. Optional `SessionStart` hook for explicit memory injection on session boot ### Multi-project / advanced 1. `agentmemory` as the cross-agent shared store 2. Hook-driven capture into the same store via `PostToolUse` 3. `mem0-mcp-selfhosted` when knowledge graphs are required 4. `Graphiti` only if temporal fact tracking becomes necessary --- ## Privacy, Security, Token Economy ### Data locality | Tier | Systems | What stays local | | ------------ | ----------------------------------------------------------- | ---------------------------------- | | Fully local | ai-memory-mcp, Engram, Mnemo, rekal, ipiton | All data; no network calls | | Local infra | mem0-mcp-selfhosted (Ollama), mcp-memory-service, HeurChain | Data on-machine; Docker containers | | Configurable | agentmemory, OpenMemory, Hindsight | Local by default; cloud opt-in | | Avoid | MemNexus, Mem0 Cloud, Zep Cloud | Data leaves machine | ### LLM / embedding dependency - **No API key:** agentmemory (local all-MiniLM-L6-v2), ai-memory-mcp (FTS5 keyword tier), Engram, Mnemo, rekal, @mcp/server-memory - **Ollama switchable:** mem0-mcp-selfhosted (`MEM0_PROVIDER=ollama`), OpenMemory, mcp-memory-service - **Avoid for private repos:** systems sending code to OpenAI/Anthropic for NER (Graphiti, Cognee, Mnemory default config) ### Security risks and mitigations | Risk | Description | Mitigation | | --------------------- | -------------------------------------------------------------------- | -------------------------------------------------------------------- | | Secret capture | Hooks saving raw stdout may persist env vars, tokens, API keys | Denylist filters; never store raw command output; redact before save | | Cloud summarization | Session content sent to external LLM for extraction | Prefer local-LLM or hook-only flows; configure Ollama backends | | RAG poisoning | Hostile text in `npm install` output → injected into future sessions | Tag tool-output as low trust; require citation verification | | Stale facts | Old decisions override newer fixes | Store `status`, `superseded_by`, `created_at`, `updated_at` | | Cross-project leakage | Facts from one repo pollute another | Always include `project`, `repo_root`, `branch`, `scope` metadata | | SQLite concurrency | Multiple Kimi tabs → `database is locked` | Configure SQLite with WAL mode (ai-memory-mcp does this by default) | ### Never store - API keys, access tokens, SSH private keys - `.env` values, customer data - Raw production logs, private messages - Full proprietary files unless access policy explicitly allows ### Prefer storing - Summaries instead of raw transcripts - Decisions instead of conversations - Stable facts instead of noisy logs - Command recipes without credentials - File paths and symbols without private payloads ### Recommended memory record schema ```json { "id": "uuid", "type": "decision", "project": "repo-name", "repo_root": "/path/to/repo", "branch": "main", "scope": "backend", "title": "Use Alembic for schema changes", "content": "Use Alembic migrations instead of ad-hoc SQL files.", "source": "kimi-session", "confidence": "high", "status": "active", "superseded_by": null, "created_at": "2026-05-15T00:00:00Z", "updated_at": "2026-05-15T00:00:00Z", "tags": ["database", "migration"] } ``` Memory categories that map cleanly across most systems: | Type | Meaning | | ------------- | ------------------------------------------------ | | `fact` | Stable known fact about project / user / tooling | | `decision` | Chosen path and reason | | `constraint` | Rule that should affect future work | | `bug` | Known issue + reproduction / fix | | `procedure` | Repeatable command / process | | `summary` | Session or milestone summary | | `observation` | Lower-confidence note from codebase / session | ### Token economy — progressive disclosure A naive RAG dumps 100 facts into the system prompt. Kimi context limits break fast. Correct systems return only IDs + headlines on initial recall; the agent then calls `get_details(id)` only for relevant ones. Systems with this pattern: `ai-memory-mcp` (79% smaller TOON output), `agentmemory` (configurable response shape). Ranking signals worth combining: - Project match - Current working directory - File path relevance - Recency - Confidence - Memory type - Semantic similarity - Explicit tags --- ## Install Order Use this order to avoid overbuilding. ```bash # 1. Verify Kimi CLI feature surface kimi --version kimi mcp list kimi plugin list # 2. Add stable project memory # Create AGENTS.md in project root (use /init to auto-generate the skeleton) # 3. Install one MCP memory server # Recommended default — ai-memory-mcp (Rust, minimal, validated) curl -fsSL https://raw.githubusercontent.com/alphaonedev/ai-memory-mcp/main/install.sh | sh # Add the JSON block from section 2 to ~/.kimi/mcp.json # 4. Verify memory tools are visible kimi mcp list # (Inside Kimi: try memory_save / memory_recall via tool surface) # 5. (Optional) Add SessionStart hook for explicit memory injection # ~/.kimi/config.toml: # [[hooks]] # event = "SessionStart" # command = "~/.kimi/hooks/memory-inject.sh" # 6. (Optional) Evaluate graph memory if semantic search proves insufficient docker run -d -p 6333:6333 qdrant/qdrant ollama pull bge-m3 # Add mem0-mcp-selfhosted to ~/.kimi/mcp.json (Blueprint D) ``` --- ## Rejected Candidates | Candidate | Reason rejected | | --------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | | **MemNexus** | Cloud-only SaaS; gated preview (May 2026); no self-host; privacy violation | | **Zep Cloud / Mem0 Cloud** | Vendor lock-in; data leaves machine; per-call billing | | **Letta (MemGPT)** | Stateful agent framework that replaces Kimi rather than extending it; REST-only, no MCP | | **Honcho** | Designed as multi-agent platform OS; requires Postgres + Redis + Deriver; overkill for solo Kimi | | **LangGraph memory** | Requires full LangChain adoption; high p95 latency; not a drop-in MCP solution | | **kimi-memory-mcp** (SARPixelPioneer) | Low maintenance signal; AgentSeal 75/100 (RAG poisoning risk); requires DeepSeek API | | **Raw vector DBs** (Chroma, Pinecone, LanceDB standalone) | Storage without memory logic; no capture, invalidation, dedup; accumulates contradictions | | **SSE-only MCP servers** | SSE deprecated in MCP spec (March 2025); prefer stdio or Streamable HTTP for new setups | | **Archived Mem0 MCP repos** | Redirected to cloud path; not a reliable local-first choice | | **claude-mem** | Claude Code–specific hooks; not MCP-based; Kimi compatibility unverified | | **OMEGA / Memento / smolbrain / callmem** | Experimental; unverified benchmark claims; no confirmed install path | | **kimi-mneme** | Repo availability could not be verified in May 2026; **move to Evaluate after confirmation** | | **Cognee (as default)** | Python SDK for document-corpus ingestion; no native MCP server; targets GraphRAG, not session memory | | **DevMemory** | Requires Portkey API key; reduces attractiveness of fully local setups | | **AGENTS.md only** | Static instructions, not queryable evolving memory | | **Browser / localStorage memory tools** | Wrong fit for CLI coding workflows | --- ## Open Questions | Question | Why it matters | | ------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------- | | Does `kimi-mneme` actually exist? | Some research passes failed to locate it; determines whether the best-native option is real | | Will MoonshotAI add native memory to Kimi CLI? | Feature request #1283 / #1167 open; if implemented, most community plugins are superseded | | When will global `~/.kimi/AGENTS.md` ship? | Issue #2152 open; required for cross-project user preferences without per-project files | | Does Kimi `SessionStart` support `additionalContext` injection? | Determines whether hooks can auto-inject memory without MCP tool calls | | Does Kimi CLI support Streamable HTTP MCP transport? | Determines compatibility with next-gen servers as SSE fades | | How does token consumption scale with multiple MCP memory servers? | Community reports ~50K tokens for basic interactions with several servers active | | Can multiple Kimi instances share memory concurrently? | Requires WAL mode (ai-memory-mcp has this); Redis-backed systems (HeurChain) handle this natively | | Is sqlite-vec performance stable at >100K memories? | May need migration to Qdrant at scale | | Correct deduplication policy? | Prevents "semantic landfill" — the natural end state of naive agent memory | | Append-only vs mutable memory? | Append-only improves auditability; mutable summaries reduce noise; tradeoff is real | | Can memories be safely scoped per repo / branch / worktree? | Prevents cross-project contamination in multi-repo workflows | --- ## Final Recommendation ```text Install ai-memory-mcp first. → Rust binary, single SQLite + WAL, 26 MCP tools, 6-factor scoring, TOON output → Zero API keys, fully local, benchmarked recall, ~5 minutes from zero to working Install agentmemory instead if you want maximum tool surface and cross-agent sharing. → 51 MCP tools, REST + viewer, local iii-engine + embeddings → Set AGENTMEMORY_FORCE_PROXY=1 to avoid the standalone-vs-server split-store bug Install rekal if you want the absolute simplest Python option. → Single SQLite, FTS5 + sqlite-vec, 16 tools, `~/.rekal/memory.db` Add AGENTS.md per project for stable conventions. Do not install kimi-mneme until existence and maintenance are confirmed in person. Install mem0-mcp-selfhosted only when knowledge graphs and entity linking actually matter. → Qdrant + Neo4j + Ollama, fully offline, 3-service stack Use HeurChain only when running multiple agents simultaneously. → Confirmed Kimi read/write via SSE; Docker, 4 containers; BM25 only Use Graphiti only for temporal reasoning on long-lived projects. → Fact validity windows; Neo4j + NER pipeline; significant operational overhead Avoid MemNexus, Mem0 Cloud, Zep Cloud (data leaves machine). Avoid Letta and Honcho (they replace the agent rather than extend it). Avoid raw vector DBs without memory logic (RAG poisoning is the natural end state). Start simple. Add complexity only when the simple setup proves insufficient. ``` The best first implementation is deliberately boring: one local memory backend, one project namespace, session-end summaries, explicit saved decisions, semantic retrieval only when useful, no graph database until facts actually have relationships worth querying. This gives Kimi CLI durable cross-session memory without turning your terminal into a distributed-systems dissertation defense. --- ## Sources ### Kimi CLI - — official repository - — MCP configuration - — Hooks (Beta) reference - — Plugin system - — `config.toml` reference - — changelog; hooks Beta status - — Feature request: hierarchical long-term memory - — Feature request: comprehensive memory system - — Feature request: global `~/.kimi/AGENTS.md` - — Hooks system design - — Hooks system discussion ("no plan" statement) - — community curated list ### MCP memory servers — local-first - — agentmemory (51 MCP tools) - — standalone-vs-server isolation bug - — ai-memory-mcp (Rust, 26 MCP tools) - — ai-memory-mcp directory listing - — rekal (Python, 16 MCP tools) - — Engram - — Mnemo (TypeScript) - — mnemon - — mcp-local-memory - — mcp-memory-service - — PyPI listing ### Vector and graph backends - — official Qdrant MCP - — Graphiti - — Zep Graphiti MCP - — mem0 self-hosted stack - — Cognee ### Mem0 / OpenMemory - — Mem0 - — OpenMemory - — State of AI Agent Memory 2026 ### Multi-agent / platform-level - — Honcho - — Letta - — Hindsight ### Reference and comparison - — official Anthropic MCP memory - — claude-mem (workflow reference) - — Zep alternatives comparison ### Unverified - — **not located in May 2026** - — marketplace listing referenced by source drafts; verify before relying