This server provides a memory system for AI coding agents to persistently store, search, verify, and enforce codebase knowledge. Key capabilities include:
Memory Search & Retrieval
memory_search — Find memories by keyword, kind (DECISION, CONVENTION, GOTCHA, etc.), verification status, or file paths.
memory_get_for_files — Retrieve relevant memories for specific files before editing.
memory_status — Summary of memory store counts by status and kind.
Memory Writing & Proposals
memory_write — Persist a falsifiable claim with optional evidence (TEST_RESULT, COMMIT_REF, STATIC_CHECK, etc.).
memory_propose — Queue a memory for human review, ideal for inferred knowledge.
memory_refute — Mark a memory as REFUTED when no longer true, optionally linking a superseding memory.
context_note — Immediately capture a user-stated fact with HIGH trust (HUMAN_ATTESTED).
Verification & Critique
memory_verify — Re-run evidence checks to update verification statuses and flag stale beliefs.
memory_critique — Review planned/completed work against verified memories and guardrails to catch conflicts.
Session Scratchpad
scratchpad_write, scratchpad_read, scratchpad_clear — Manage short-term working notes that auto-expire and are never synced.
Harvesting & Mining
chat_harvest — Extract durable facts from the current chat's user messages, queue for review (with secret redaction).
commits_mine — Scan git history for memory-worthy candidates and queue as proposals.
Proposals & Knowledge Inbox
proposals_pending — List memory proposals awaiting human review.
knowledge_pending — List documents pending summarization into memory proposals.
knowledge_ingest_submit — Submit extracted claims from a pending document as proposals.
Ticketing
ticket_get — Fetch current work ticket (title, description, type) auto-detected from branch.
Help
aidimag_help — Show available tools, prompts, and CLI commands.
Registers as a native memory provider for the Hermes agent, injecting session briefings into the system prompt, prefetching recall per turn, and turning session learnings into review-queue proposals.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@AI Dimag search memory for our API versioning strategy"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Your coding agent forgets your codebase. AIDimag doesn't.
Documentation • Why AIDimag? • Getting Started • Use Cases • Benchmarks • AI Dimag Cloud • Pricing
AI Dimag is a memory system for software engineering — not a general-purpose "AI memory" app. It gives any MCP-compatible agent (Claude, Cursor, Copilot, Windsurf…) a persistent memory of your codebase that survives across sessions — decisions, conventions, gotchas, failed approaches, guardrails, and reusable skills — stored as falsifiable claims with grounding evidence in .aidimag/ next to your code.
The subject of memory is your repository, not your preferences or chat history. Every capability — evidence, git-hook verification, guardrails, pre-commit checks, path-scoped recall, session scratchpad — exists to serve day-to-day development work.
Most memory systems store text and retrieve whatever is similar later — a stored fact is assumed true forever. That's dangerous in a codebase, where a confidently-retrieved stale fact is worse than no memory at all.
Every AI Dimag memory carries evidence (a shell check, an anchored commit, a test) that dim verify re-runs against the current repo — automatically, via git hooks, on every pull, checkout, and rebase. Beliefs that stop being true go STALE instead of silently misleading your AI.
MCP tools (Claude, Cursor, etc.) get real-time memory via the MCP server
Non-MCP tools (Copilot, Windsurf, etc.) get static context files (.cursorrules, CLAUDE.md, AGENTS.md, etc.)
Related MCP server: apex-memory
npm install -g aidimagRequires Node 22+. Ships two equivalent binaries: dim (short) and aidimag.
cd your-repo
dim init # creates .aidimag/, installs additive git hooks
dim bootstrap # optional: LLM-survey the repo into a starter memory set
dim review # approve what enters memory (nothing is stored unreviewed)
dim remember "All DB access goes through src/db/store.ts" -k INVARIANT -p src \
-e "STATIC_CHECK:! grep -rl better-sqlite3 src --include=*.ts | grep -v store.ts"
dim recall db access
dim verify # re-run all evidence; stale beliefs get flagged
dim brief # session-start briefing: in-scope memory, guardrails, gaps
# For non-MCP tools (Copilot, Cursor without MCP, etc.):
dim generate-context --format all --auto # creates .cursorrules, CLAUDE.md, AGENTS.md, etc.dim setup --yes # init + git hooks + MCP configs for detected agents + context files
dim setup-ollama # install Ollama + pull a free local embedding model for semantic search
dim doctor # verify everything is wired correctlyAdd to your agent config (e.g. .mcp.json for Claude Code):
{
"mcpServers": {
"aidimag": {
"command": "npx",
"args": ["-y", "aidimag", "mcp"],
"env": { "AIDIMAG_REPO": "/path/to/your/repo" }
}
}
}MCP Tools get memory_search, memory_propose, context_note (live in-chat fact capture), chat_harvest (live, tool-agnostic session harvesting with server-side secret redaction), memory_critique (a second critic grounded in verified memory), session-start briefings, session-end extraction, and more.
Non-MCP Tools: dim generate-context -f all renders verified memory into .cursorrules, CLAUDE.md, AGENTS.md, .windsurfrules, and .github/copilot-instructions.md (--auto keeps them refreshed).
Hermes Agent: dim hermes install registers aidimag as a native Hermes memory provider — one command, no pip, no venv. A single stdlib-only Python bridge delegates to the MCP server: session briefings are injected into the system prompt, recall is prefetched per turn, and session learnings become review-queue proposals (never silent writes). Then: hermes config set memory.provider aidimag.
Commits, PRs, AI-chat transcripts (Claude Code, Codex, Copilot, Cursor), and pasted docs are mined into proposals. Nothing enters memory until you approve it in dim review (auto-triaged best-first, approve all --min-score 0.7 for batches).
STATIC_CHECK / COMMIT_REF / TEST_RESULT / EXEC_TRACE / HUMAN_ATTESTED evidence. Failing evidence flips memories to STALE and auto-drafts a recovery proposal. Confidence decays without re-confirmation.
Shell-command evidence that arrives via team sync is never executed until you inspect and approve it (dim verify --trust).
FTS5 keyword + vector KNN (OpenAI, local Ollama, or AWS Bedrock; auto-detected except Bedrock, which is explicit opt-in; works keyword-only with none).
Behavioral rules (never / ask-first / always) and step-by-step procedures, enforced by dim check (pre-commit) and memory_critique.
dim serve + dim sync: local-first replicas, device-code login, brain-scoped API keys, hashed credentials, cross-machine verification consensus.
Drop design docs / ADRs / PDFs / DOCX into knowledge/ and they're summarized into reviewed, pinned memories.
dim scratch (and the scratchpad_* MCP tools) hold short-term session notes — TTL-expiring, never synced, never durable memory. dim audit lists memories resting on the weakest ground (agent-authored, evidence-free, stale, or long-unverified) so you can fix them up like a dependency audit for your repo's knowledge.
dim ui — run checks, session briefings, bootstrap, harvest, and context generation from the browser — plus VS Code and IntelliJ extensions.
Commits tell you what changed; tickets hold the why. aiDimag connects to your ticketing system so that context flows into your memory — ticket titles, types, and statuses appear next to mined proposals during dim review, and agents can fetch tickets via the ticket_get MCP tool.
Jira, GitHub Issues, Linear, GitLab Issues, Azure DevOps, ClickUp, Shortcut, YouTrack, Asana, Trello, Notion, Pivotal Tracker, a custom HTTP middleware, or Remote (team sync server — zero local credentials).
# Connect a provider (interactive)
dim ticket connect
# Check status
dim ticket status
# View a specific ticket
dim ticket show XXX-2100
# Share credentials with your team (admin)
dim ticket shareTicket credentials are stored per-repo in .aidimag/config.json under tickets.token (with file mode 0o600), matching the same pattern as cloud sync tokens. Credentials never leak between projects. You can also set the AIDIMAG_TICKET_TOKEN environment variable, which takes precedence over the config file.
One admin shares their ticket credential via the sync server (dim ticket share). Team members select "Remote (team sync server)" as their provider — they resolve tickets through the server and hold zero ticket credentials locally. When a cloud server is linked, the dashboard auto-discovers the team's ticket provider and shows a "Connect now" button.
Define a branch-naming convention and have aiDimag warn or block on violations:
dim ticket branch-rule # manage the convention
dim branch XXX-2100 # create a conforming branch (fetches title for slug)Enforcement | Effect |
| No checking |
| Heads-up at branch creation ( |
| Blocks pushing non-conforming branches ( |
Full guide: Connecting tickets
AI Dimag follows a claim-and-verify model; other memory systems follow store-and-retrieve. The short version:
Conversational memory layers | Vector-store memory plugins | Hand-maintained context files | AI Dimag | |
Built for | Chat assistants remembering users | General recall over embedded text | Static instructions for coding agents | Coding agents in a living repo |
Unit of memory | Extracted facts / chat summaries | Embedded text chunks | Prose | Falsifiable, typed claims with evidence |
How memory gets in | Automatic capture | Automatic embedding | Manual edits | Human-gated review queue |
When the code changes | Nothing — stored facts stay "true" | Nothing | File silently rots | Evidence re-runs via git hooks; broken claims flip STALE |
Trust model | Write-time label, never re-checked | Similarity ≈ trust | "It's in the file" | Verification status + decaying confidence; trust-ranked retrieval |
Enforcement | None — injection only | None | Hope the model reads it | Guardrails + pre-commit |
Failure mode | Confidently recalls outdated facts | Retrieves similar, true or not | Instructions drift from reality | Says "this went STALE" instead of guessing |
Full comparison: aidimag.com/comparison
How aiDimag relates to the memory tools people usually ask about. These solve a different problem (remembering users and conversations); aiDimag remembers your repository and proves its memories are still true:
aiDimag | Mnemosyne | mem0 | Letta | Honcho | SuperMemory | Hindsight | ChromaDB | |
Subject of memory | Your codebase | Chat/agent sessions | User & agent facts | Agent's own context | User/peer reasoning | Personal + agent | Agent memory | — (vector DB) |
Local-first | ✅ SQLite per repo | ✅ SQLite | ⚠️ Hybrid | ❌ Docker+PG | ⚠️ PG+worker | ❌ SaaS | ✅ SQLite | ✅ Embedded |
MCP server | ✅ Built-in | ✅ | ❌ | ❌ | ❌ | ✅ | ✅ | ❌ |
Verifies memories against code | ✅ Evidence re-runs via git hooks | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
Human-gated writes | ✅ Review queue | ❌ Auto-capture | ❌ Auto | ❌ | ❌ | ❌ | ❌ | — |
Enforcement | ✅ Guardrails + pre-commit + critique | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
Open source | ✅ MIT | ✅ MIT | ✅ Apache 2.0 | ✅ Apache 2.0 | ⚠️ AGPL | ❌ Proprietary | ✅ MIT | ✅ Apache 2.0 |
Published benchmark | Own suite: 100% staleness detection, 0% FP | BEAM 65.2% / LongMemEval 98.9% R@All@5 (self-reported) | LoCoMo | LoCoMo 83.2% | LongMemEval 90.4% | MemoryBench 85.2% | BEAM 73.4% / LongMemEval 94.6% | — |
Chat-memory benchmarks (LoCoMo, LongMemEval, BEAM) score recall over conversation histories, so they don't apply to aiDimag — its memory subject is the repo. Instead aiDimag publishes its own reproducible suite (below), including the metric none of the chat benchmarks measure: does memory notice when the code changes?
Reproducible performance and quality suites live in benchmark/
(npm run bench, npm run bench:quality). Headline results (Apple M4, Node 24,
10,000-memory brain — full tables at aidimag.com/benchmarks):
Metric | Result |
FTS keyword search | 1.45ms p50 |
Vector KNN (768-dim, sqlite-vec) | 4.15ms p50 |
Memory writes (transactional, incl. FTS + event log) | ~5,400/s |
CLI cold start ( | ~41ms p50 |
Staleness detection (broken claims → STALE, real git fixture) | 100% (4/4) |
False positives (intact claims wrongly flagged) | 0% (0/4) |
Retrieval, keyword queries (Recall@1 / MRR, FTS-only) | 1.00 / 1.00 |
Retrieval, paraphrase queries (FTS-only; hybrid closes this gap) | 0.25 / 0.27 |
Getting Started
Overview
Guides
Full documentation: aidimag.com
Contributions welcome! See CONTRIBUTING.md for dev setup, project principles, and the PR checklist. All participation is governed by our Code of Conduct.
AI Dimag is open source under the MIT License — free for everyone, any team size, forever. Use it, fork it, embed it.
The entire local-first product is free: CLI, MCP server, verification, guardrails, skills, IDE extensions, local dashboard, and self-hosted team sync (dim serve).
Want team sync without running a server? AI Dimag Cloud is an optional managed sync subscription — that's how the project stays funded and open source. See Pricing.
Built by Anup Khanal
Website • Documentation • Cloud • npm • License
Show what aidimag offers: available tools, prompts (slash commands), resources, and the companion dim CLI commands. Call this when the user asks what aidimag can do, how to use it, or types 'aidimag help' — then relay the overview to them.
Inputs: no named parameters.
Harvest the CURRENT chat session on the fly: pass the messages the USER typed this session (verbatim) and durable facts are extracted and queued for human review — the live, tool-agnostic equivalent of dim harvest. Works from ANY IDE/agent (Copilot, Cursor, Codex, Claude, Devin, …), including cloud tools with no local transcripts. Call at session end, or after a long exchange rich in project knowledge. Secrets are redacted server-side before any LLM sees the text. For single facts stated in passing, prefer context_note instead.
Inputs: user_messages (required), agent_id, session_id.
Mine git commit history for memory-worthy candidates (same as dim mine). Queues proposals for dim review — never writes active memory directly. Use after meaningful commits, or with full=true to rescan all history.
Inputs: llm, max, full.
Capture a durable fact the USER just stated in chat. Call this IMMEDIATELY when the user shares codebase knowledge — don't wait for session end. ALWAYS trigger on: 'we use X because Y' (DECISION), 'never do X' (GUARDRAIL), 'we always X' (CONVENTION), 'we tried X, it failed' (FAILED_APPROACH), 'the architecture is...' (ARCHITECTURE). Skip task-specific requests like 'fix this bug'. User-stated facts are queued for review with high trust (HUMAN_ATTESTED evidence).
Inputs: kind (required), statement (required), paths, quote, +4 more.
Submit the FALSIFIABLE claims you extracted from a pending knowledge doc (see the knowledge_ingest prompt). Queues them as proposals (source knowledge:), writes the durable summary, backs up the original, and clears the inbox copy. Claims become PINNED memory only after dim review (unless the repo opted out).
Inputs: file (required), claims (required).
List documents waiting in the knowledge inbox to be summarized into pinned-on-approve memory proposals. Use with the knowledge_ingest prompt to process them in-session.
Inputs: no named parameters.
Pre-edit safety check: given a diff or a short description of a change you're about to make, return any FAILED_APPROACH, GUARDRAIL, INVARIANT, or CONVENTION memories that match. Call this BEFORE editing code when the task touches an area with known historical failures or explicit rules. Returns a decision: proceed, ask_first, or stop.
Inputs: diff, task, paths, agent_id.
Review what you just did (or plan to do) against the project's VERIFIED memory and guardrails — a 'second critic' grounded in real, falsifiable beliefs rather than another model's opinion. Call BEFORE committing or proposing memories. Resolve guardrail violations and contradictions first.
Inputs: summary (required), files_changed.
Get all memories relevant to specific files before editing them — conventions, gotchas, and invariants that apply to those paths.
Inputs: paths (required), limit.
Pre-edit guardrail check for a specific file and code snippet. Given a file path and the code you're about to write, check whether it violates any NEVER guardrails or triggers FAILED_APPROACH warnings. Returns a clear STOP/PROCEED decision. Call this before writing to files in protected areas.
Inputs: code (required), file_path (required), agent_id.
Propose a memory for the human review queue. Use at SESSION END for learnings that should persist but warrant review before becoming active memory. Prefer this over memory_write for inferred/uncertain knowledge.
Inputs: kind (required), claim (required), paths, symbols, +6 more.
Mark a memory as REFUTED when you discover it no longer holds. Optionally provide the id of a new memory that supersedes it. Refuted memories are kept as negative knowledge.
Inputs: id (required), superseded_by.
Search the repo's verified memory for decisions, conventions, gotchas, failed approaches, and invariants. Use BEFORE exploring the codebase — past sessions may already know the answer.
Inputs: query (required), kind, limit, paths, +1 more.
Get a summary of the repo's memory store: counts by verification status and kind.
Inputs: no named parameters.
Re-run cheap evidence checks (STATIC_CHECK, COMMIT_REF) and update memory statuses. Use before relying on VERIFIED memories if the repo may have changed, or to verify specific memories by id.
Inputs: ids, deep.
Persist a new memory about this codebase. Write the claim as a FALSIFIABLE statement (something that could be checked against the code). Attach evidence whenever possible. For kind=GUARDRAIL, set guardrail_level (never|always|ask-first).
Inputs: kind (required), claim (required), paths, symbols, +3 more.
List memory proposals awaiting human review.
Inputs: limit.
Clear scratchpad working notes (one session key, or everything). Use when a task completes and its intermediate state is no longer needed.
Inputs: session_id.
Read short-term working notes from the current session's scratchpad (newest first). Use at session start or when resuming a task to recover in-flight state. Expired notes are purged automatically.
Inputs: limit, session_id.
Jot a SHORT-TERM working note for the current session: intermediate findings, plans, hypotheses, task state. Auto-expires (default 24h) and is never synced. NOT durable memory — use memory_write/memory_propose for knowledge that should persist across sessions.
Inputs: content (required), ttl_hours, session_id.
Fetch the ticket behind the current work (title, description, type, status) from the connected ticketing app. Use at session end: the ticket carries the WHY that commits lack. Omit the id to auto-detect it from the current branch name.
Inputs: id.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 21 tools
Most tools have distinct actions and detailed use-case descriptions, but there are overlapping clusters: memory_check_change vs memory_pre_edit both serve as pre-edit guardrails, and memory_write/memory_propose/context_note/chat_harvest/knowledge_ingest_submit all create or propose memory through different paths. An agent can usually pick correctly with careful reading, but the boundaries are not always crisp.
Tool names overwhelmingly use snake_case verb_noun or noun_verb patterns within clear families (memory_*, scratchpad_*, knowledge_*). Minor deviations like ticket_get (reversed order), memory_status, knowledge_pending, and proposals_pending break the otherwise predictable pattern but remain readable.
21 tools sits in the borderline-heavy range for an MCP server. The breadth is somewhat justified by the memory lifecycle, scratchpad, review queue, and external capture sources, but the surface could be tightened by merging the two pre-edit checks and consolidating capture tools.
The tool set covers the core memory lifecycle well: search, write, propose, verify, refute, and pre-edit checking, plus scratchpad and review queue visibility. Minor gaps exist—there is no direct update/edit tool for an existing memory and no in-MCP approval path, but these are workable through refute/supersede and the companion dim review flow.
Team memory for AI coding agents and code reviews, reviewed by humans and served over MCP.
Hosted MCP memory for coding agents: persistent across sessions, editable markdown, team sharing.
Persistent, inspectable memory for AI agents with lineage, correction, and a hosted MCP endpoint.
Persistent memory, knowledge graph, task management and more for AI agents via MCP.