Every coding agent forgets. You close the session, and next time you start fresh. Every explanation of your architecture, every description of your naming conventions, every “remember, this project uses X pattern” vanishes when the terminal closes.

MiMo Code does not work this way. It remembers.

Not through a static markdown file you maintain manually. Through an automatic, searchable, self-maintaining memory system built on SQLite FTS5 that grows smarter the more you use it.

This is the deep dive. We will cover how it works technically, why it matters practically, and how the /dream command keeps it from rotting over time. If you want the broader overview of MiMo Code, start with our complete guide.

The Problem With Stateless Agents

When you use Claude Code or most other coding agents, each session is independent. The agent reads your CLAUDE.md file (if you have one), scans whatever files you point it at, and works within that context. When the session ends, everything it learned disappears.

This creates a painful loop:

1. Start new session
2. Re-explain project conventions
3. Re-describe architecture decisions
4. Re-establish context the agent already knew yesterday
5. Finally get to productive work
6. Close session. Go to step 1.

For quick, isolated tasks this does not matter. Fix a bug, close the session, done. But for ongoing development on a project you return to daily for weeks or months, this re-establishment cost adds up fast.

Our context window management guide covers the theoretical side of this problem. MiMo Code’s memory system is the practical solution.

How MiMo Code’s Memory Works

MiMo Code’s persistent memory has three layers:

Layer 1: The SQLite FTS5 Database

Every project you work on gets its own SQLite database stored locally at ~/.mimo-code/memory/{project-hash}.db. This database uses FTS5 (Full-Text Search version 5), SQLite’s built-in full-text search engine.

FTS5 matters because it enables fast, ranked keyword search over all stored memory. When MiMo Code needs to recall something about your project, it does not scan a flat file linearly. It runs a full-text query and gets ranked results in milliseconds, even with thousands of stored entries.

The database stores:

• Project facts: Tech stack, frameworks, language versions, build tools
• Architecture decisions: Why you chose X over Y, design patterns in use
• File relationships: Which files depend on which, module boundaries
• Conventions: Naming patterns, code style preferences, folder organization
• Task history: What was done in previous sessions, what is pending
• Error patterns: Bugs encountered and how they were resolved

Each entry is timestamped, tagged with relevance metadata, and indexed for full-text search.

Layer 2: The Background Subagent

While you work, a background subagent continuously monitors your session. Its job is context compression. It watches the conversation between you and MiMo Code and identifies information worth persisting.

When you say “this project uses a custom authentication middleware that wraps JWT validation,” the subagent recognizes this as a persistent architectural fact and stores it. When you spend 30 minutes debugging a specific error, the subagent stores the resolution pattern.

The subagent does not store everything. It filters for:

• Facts likely to be relevant in future sessions
• Decisions that establish project-wide patterns
• Resolutions to non-trivial problems
• Structural information about the codebase

Noise like “undo that last change” or “actually, try the other approach” gets discarded. The subagent extracts signal from the conversation and compresses it into durable memory entries.

This runs in the background. You do not interact with it directly. You do not need to tell MiMo Code what to remember. It figures that out on its own.

Layer 3: Memory Retrieval at Session Start

When you start a new MiMo Code session on a project, the system:

1. Identifies the project (by directory path and git remote)
2. Loads the corresponding memory database
3. Runs a relevance query based on recent activity and current files
4. Injects the most relevant memory entries into the agent’s context
5. Presents you with a fully context-aware agent that knows your project

This happens in seconds. By the time you see the prompt, MiMo Code already knows your project structure, conventions, and recent work history.

The /dream Command

Memory systems that only grow eventually become useless. Stale entries pile up. File paths reference deleted files. Duplicate information wastes context space. Outdated decisions contradict current code.

MiMo Code solves this with /dream, a maintenance cycle that runs every 7 days automatically (or on demand).

When /dream activates, it launches a dedicated maintenance agent that:

1. Reviews all recent sessions

The maintenance agent reads through session logs from the past week, identifying new information that should be promoted to long-term memory and flagging entries that sessions have contradicted or superseded.

2. Removes duplicates

Over time, the same fact gets stored multiple times in slightly different phrasings. “This project uses React 19” and “The frontend is React version 19” are duplicates. The /dream cycle deduplicates these, keeping the most informative version.

3. Verifies file paths

Memory entries often reference specific files: “The auth middleware lives at src/middleware/auth.ts.” The /dream agent checks whether these paths still exist in the filesystem. If a file was deleted or moved, the entry gets updated or removed.

This is critical after refactors. If you reorganize your project structure, /dream cleans up all the stale path references that would otherwise confuse the agent.

4. Compresses into long-term memory

Short-term memory entries (from recent sessions) get evaluated for long-term relevance. Highly relevant entries are compressed into denser, more generalized forms and promoted to long-term storage. Low-relevance entries are discarded.

Example: Ten separate memory entries about debugging the payment module might compress into one entry: “Payment module (src/payments/) has known issues with webhook timeout handling. Resolution pattern: increase timeout to 30s and add retry queue.”

5. Optimizes the database

After cleanup, /dream runs SQLite VACUUM and reindexes FTS5. This keeps query performance fast even after months of accumulated data.

Running /dream Manually

The automatic 7-day cycle works for most people. But sometimes you want to trigger it immediately:

/dream

Run this after:

• Major refactors that change file locations
• Deleting large portions of code
• Changing fundamental architecture decisions
• When memory seems stale or the agent references things that no longer exist

The /dream process takes 30 seconds to a few minutes depending on memory database size. You cannot use MiMo Code for other tasks while it runs.

Why SQLite FTS5 Specifically?

The choice of SQLite with FTS5 is deliberate:

Local storage: Your memory data stays on your machine. It is not uploaded to any server. This means your project’s architecture details, conventions, and history remain private.

Speed: FTS5 provides millisecond full-text search across thousands of entries. The agent never waits for memory retrieval.

No dependencies: SQLite is embedded. No database server to install or maintain. No network dependency for memory access.

Portability: The database is a single file. Back it up, copy it between machines, or version control it.

Proven technology: SQLite is the most widely deployed database in the world. FTS5 is battle-tested across millions of applications.

Practical Impact

Here is what persistent memory looks like in daily use:

Monday: You start a new feature. You explain to MiMo Code that the project uses repository pattern for data access, that all API responses go through a transformer layer, and that tests go in __tests__/ directories colocated with source files.

Tuesday: You open MiMo Code. It already knows all of this. You say “add a new endpoint for user preferences” and it creates the repository, the transformer, the controller, and the colocated tests. No re-explaining needed.

Two weeks later: You return to the project after working on something else. MiMo Code remembers everything. The repository pattern, the transformer layer, your test conventions, and even the user preferences feature you added.

Compare this to Claude Code, where Tuesday and every subsequent day start with the same re-explanation unless you manually maintain a comprehensive CLAUDE.md file. See our Claude Code one-week review for what that experience actually looks like in practice.

Memory Across Multiple Projects

Each project gets its own isolated memory database. Switching between projects means switching memory contexts automatically. Conventions from Project A do not bleed into Project B.

MiMo Code identifies projects by:

1. Git remote URL (if available)
2. Absolute directory path (fallback)

This means the same project checked out in different directories is recognized as the same project (via git remote). Different projects in the same parent directory are correctly isolated.

Privacy and Data Handling

All memory is stored locally on your filesystem. The SQLite databases at ~/.mimo-code/memory/ never get uploaded to Xiaomi’s servers or any other external service.

Your code is sent to the model backend for inference (that is how the AI works), but the distilled memory stays local. This means even if you switch model backends or stop using MiMo Code temporarily, your accumulated project knowledge persists.

For broader data privacy considerations with AI coding tools, see our AI model supply chain risks overview.

Limitations

The memory system is not perfect:

• Cold start: First session on a new project has no memory. It takes a few sessions to build useful context.
• Incorrect memories: If you provide wrong information early on, it persists until /dream cleans it up or you manually correct it.
• Large monorepos: Very large projects with thousands of files can generate large memory databases. /dream compression helps but does not eliminate this.
• No cross-project learning: Memory is isolated per project. Patterns you use across all projects must be re-learned for each one (or configured globally).

Comparing to Alternatives

Tool	Memory System
MiMo Code	SQLite FTS5, auto-compression, /dream maintenance
Claude Code	Static CLAUDE.md files, manually maintained
Aider	None (session-only)
OpenCode	None (session-only)
ZCode	Goal history (limited persistence)

MiMo Code’s memory system is unique among coding agents. Nothing else in the market offers automatic, searchable, self-maintaining persistent memory. This is its strongest differentiator, arguably even more important than its benchmark scores.

Getting the Most From Memory

Tips for working effectively with the memory system:

Be explicit about decisions: When you make an architectural choice, state it clearly. “I am choosing X over Y because of Z.” The subagent stores decision rationale, not just outcomes.

Correct mistakes immediately: If MiMo Code uses outdated information from memory, correct it. “That is no longer accurate. We moved to X.” The subagent stores the correction.

Do not fight the system: You do not need to manually feed information into memory. Just work naturally. The subagent handles extraction. Treat it like a coworker who takes notes during your conversations.

Trust /dream: Do not worry about memory quality day-to-day. The weekly maintenance cycle handles cleanup. If things feel stale, run /dream manually and let it sort things out.

FAQ

Does the memory system slow MiMo Code down?

No. SQLite FTS5 queries run in single-digit milliseconds. Memory retrieval at session start adds 1 to 3 seconds. During the session, background compression runs asynchronously and does not block your interaction.

Can I export or backup my memory database?

Yes. The database is a standard SQLite file at ~/.mimo-code/memory/{hash}.db. Copy it, back it up, or version control it however you like.

What happens if memory contains wrong information?

You can correct it verbally (“that is no longer true, we now use X”) and the subagent stores the correction. You can also run /memory clear to reset everything and start fresh. The /dream cycle also removes entries that conflict with current code.

Does memory work when I switch model backends?

Yes. Memory is stored locally and is independent of which model backend processes your queries. Switch from MiMo V2.5 Pro to DeepSeek and back; your memory persists unchanged.

How much storage does the memory use?

Typical projects accumulate 5 to 50MB of memory data after months of use. Large monorepos with heavy daily use might reach 100MB+. Running /dream regularly keeps growth in check through compression and deduplication.