L3 long-term memory
Mogick's L3 long-term memory preserves coding preferences, project conventions, and key decisions across sessions. Before each run, Mogick retrieves relevant memories from a local SQLite database and adds them to the model context. After the run, it extracts useful new knowledge from the conversation. Use /memory to turn this feature on or off at any time.
Lifecycle
Memory follows a retrieval, injection, and extraction lifecycle, so each conversation can use relevant prior knowledge while keeping the knowledge base current.
| Stage | Timing | Description |
|---|---|---|
| Retrieval | Before each run | Retrieve candidate memories across four scopes |
| Reranking | After retrieval | Rank by relevance, filter instruction conflicts, and retain up to 10 items |
| Injection | After reranking | Add memories to the model context, capped at 8% of the context window; fewer than 10 may be included |
| Extraction | After each run | Use the LLM to extract new knowledge asynchronously, then save items sequentially |
The process runs automatically in the background; no manual retrieval or storage is required.
Search scope and strategy
Memories are organized into four scopes and retrieved together when relevant.
Global scope stores preferences that apply across projects, such as coding style, toolchain choices, and language preferences. Workspace scope is tied to the current Git repository or project directory and stores project-specific conventions such as branching and deployment workflows. Package-path scope applies to a particular package or module and is useful for library-level conventions. Session scope lasts only for the current session and carries temporary context.
Retrieval combines semantic vector search with full-text keyword search. Vector similarity finds related concepts, while full-text search preserves exact keyword matches. If no embedding model is available, Mogick falls back to full-text search. Memory remains available, but semantic recall may be less precise.
Automatic extraction
After each run, Mogick analyzes the conversation asynchronously and extracts the following kinds of information:
- Coding preferences: Personal conventions such as indentation, naming, and formatting.
- Decision records: Important choices such as error-handling patterns, architectural tradeoffs, and technology-selection rationale.
- Project conventions: Team-level rules such as branching, deployment, and testing practices.
- Explicit instructions: Direct requests such as “remember this” or “do this from now on”; these receive the highest priority.
Extracted items are saved sequentially to avoid write conflicts.
Deduplication and merging
Newly extracted memories may overlap with or contradict existing entries. Mogick handles them as follows:
| Rules | Behavior |
|---|---|
| Expand or refine | Merge the information into a richer, updated memory |
| Contradict | Keep the newer knowledge and replace the old entry |
| Identical | Skip the write to avoid duplication |
| User-created | Do not overwrite automatically; manual memories take precedence |
These rules keep memory current without allowing automatic extraction to erase preferences that you set explicitly.
Commands and configuration
In the TUI, enter /memory to disable memory temporarily—for example, while working on a sensitive project. Run the command again to re-enable it.
Use mogick doctor to check memory-system health, including SQLite schema integrity and embedding-model availability.
Memory is enabled by default. Mogick injects no more than 10 memories and caps their combined size at 8% of the model's context window, preserving room for the task itself. All memory data is stored in <db-path>. Retrieval combines semantic vectors and full-text search, with automatic fallback to full-text search when no embedding model is available.
Path placeholders <config-dir> and <db-path> refer to the effective profile/channel paths; see Data directories.