Memory

Memory is a local wiki for AI coding agents and assistants: repo context they can load before work, keep current after meaningful changes, and leave reviewable in your project. It is inspired by Andrej Karpathy's LLM Wiki pattern: durable, human-editable project knowledge that models can read before work.

Stop re-explaining the same product intent, architecture decisions, repo conventions, setup steps, and known traps every time a new AI coding session starts. Activate Memory once in a repo: it gives agents a local wiki of durable project knowledge, wires short agent guidance into the project, and loads only the pages that matter for the current task.

Use Memory when:

• You open new AI coding sessions on the same repo and keep repeating the same product intent, architecture choices, setup steps, or known traps.
• Your projects are growing past one-off experiments and the useful discoveries from agent work need to survive into the next session.
• You use more than one agent or assistant and do not want to maintain separate project facts in AGENTS.md, CLAUDE.md, Cursor rules, prompt snippets, and chat history.
• You want agents to load focused context for the task instead of spending tokens on broad rebriefing or stale instruction files.
• You want durable project memory to stay local, inspectable, and reviewable in Git instead of disappearing into hosted memory or an opaque retrieval service.

This repository publishes the npm package @aictx/memory and the Homebrew formula aictx/tap/memory.

Memory works with Codex, Claude Code, Cursor, Cline, OpenCode, and MCP-capable clients. Use the memory CLI by default, then add the local memory-mcp server when you want routine Memory tools inside an MCP client.

Why Memory?

Memory is for the repo wiki agents actually need: durable project context that should survive between agents, sessions, branches, and reviews without making you re-teach the repo each time.

The value stack is practical:

• Better agent work: agents start with the product, architecture, workflow, and gotcha context that matters for the current task.

• Less wasted context: memory load builds a focused pack instead of asking you to paste the same briefing or carry every project fact in a giant prompt.

• Reviewable memory: saved knowledge is local project state that humans can inspect, diff, repair, and keep honest.

• Why not AGENTS.md only? Agent instruction files are good operating manuals. They become too broad and static when they also try to be the whole project wiki.

• Why not a vector DB or RAG stack? Those are useful for large retrieval systems. Memory keeps v1 project memory local, inspectable, Git-aware, and usable without embeddings, hosted infrastructure, or a model API.

• Why not long context? Long context helps inside one session. It does not make memory reviewable, current, reusable across future sessions, or easy to clean up when facts go stale.

• Why local files? Plain files make the wiki reviewable and portable. Memory builds on that foundation with validation, typed memory, a local index, task-focused loading, relation-aware inspection, and a save/no-save discipline.

Inspect the Memory

Memory is not just hidden context for agents. The visual memory viewer is the wiki review surface: a local place where humans can inspect the same schema, objects, facets, relations, provenance, audit advisories, and graph context agents load.

_{Schema, stored objects, relation provenance, maintenance advisories, and graph context in one inspectable local viewer.}

What Gets Stored

The full object taxonomy, facets, and write contracts live in the reference docs.

Memory does not require a cloud account, embeddings, hosted sync, an external model API, or network access for core memory commands. Saved memory is active immediately after Memory validates and writes it.

How It Works

set up once -> agents load wiki context -> save durable updates

The loop is deliberately small after setup. Agents load memory before non-trivial work, use the current repo and tests as evidence, then save only knowledge that should remain in the repo wiki for future sessions, branches, and reviews.

Get Started Quickly

Memory requires Node.js >=22. The Homebrew formula installs Node through Homebrew; npm installs require a compatible Node already on PATH. Core commands run locally; no cloud account, model API, embeddings, or hosted sync are required.

# macOS/Linux with Homebrew
brew install aictx/tap/memory

# or npm
npm install -g @aictx/memory

cd path/to/your/repo
memory setup
memory load "onboard to this repository"
memory view

memory setup activates Memory in the current repo. It creates local .memory/ memory, updates the marked Memory sections in AGENTS.md and CLAUDE.md, writes conservative first-run memory, runs checks, and starts the local viewer. Use memory setup --no-view when you do not want the viewer to start, or memory setup --dry-run to preview before writing.

Memory writes local files and never commits automatically.

Project Status and Upgrade Recovery

Memory is not ready for production use yet. Breaking changes should be expected across package versions while the schema and local storage format are still evolving.

If you update to the latest package version and later see errors from existing local Memory storage, reset and re-run setup from the project root:

memory reset
memory setup

memory reset creates a backup archive under .memory/.backup/ before clearing local Memory storage. If useful context is missing after setup, ask your coding agent to inspect the newest backup and add back only relevant durable project knowledge. For example:

Memory was reset after a package upgrade. Inspect the newest archive in
.memory/.backup/, compare it with the current .memory/ contents, and add back
only relevant durable project knowledge that was lost. Do not restore stale
schema files blindly; use current Memory commands and validate with memory check.

Ask an Agent to Activate It

Paste this into Codex, Claude Code, OpenCode, Cursor, Cline, or another CLI-capable coding agent from the project root:

Set up Memory for this repository.

Install Memory with one of:
brew install aictx/tap/memory
npm install -g @aictx/memory

Then run:
memory setup
memory check
memory load "onboard to this repository"

When this is done, report:
- whether setup wrote memory
- whether check passed
- how I can inspect the result with `memory view` or `memory diff`

After setup, the normal agent loop is small:

memory load "<task summary>"
# do the work
memory remember --stdin
memory diff

Save only durable project knowledge. Memory is meant to keep the repo wiki current, not archive every task transcript.

What You Get

Four surfaces ship today. Each one works locally and fits normal Git review.

Works With Your Agent

Distribution Artifacts

The integrations/ directory includes generated skill and plugin artifacts for external agent packaging. They package the same CLI-first guidance as the setup aids and do not add MCP configuration.

Codex users can add this repo's marketplace with one command:

codex plugin marketplace add aictx/memory

Then open Codex Plugins and install Memory.

Claude Code users can add the marketplace and install the plugin from inside Claude Code:

/plugin marketplace add aictx/memory
/plugin install memory@aictx

For official listing paths and release prep, see Publishing agent plugins.

Documentation

• Setup
• Memory recipes
• Agent recipes
• CLI reference
• MCP
• Reference
• Wiki workflow

Contribute

Memory is MIT-licensed and built in the open. Issues, docs fixes, examples, agent recipes, and pull requests are welcome.

Contribute on GitHub

Project identity

Memory by Aictx gives AI coding agents a local wiki for repo context. It stores durable project memory as reviewable local files agents can load before work and update after meaningful changes. It is distributed through the open source npm package @aictx/memory and the Homebrew formula aictx/tap/memory, then runs through the memory CLI and optional memory-mcp server.