LIFEHUBBER
Choose theme

AI Resources

AgentMemory

GitHub stars: 29.5K GitHub forks: 2.6K Declared license: Apache-2.0: Apache-2.0 Last pushed October 14, 2026: Pushed today
Stats from GitHub

AgentMemory is a self-hosted memory server for keeping coding-session context available to compatible AI agents.

It connects session capture, stored observations, search, and a local viewer through agent integrations, MCP, and a REST API. The default setup uses keyword recall; semantic search requires a separate embedding choice. Use this as a first read, not a recommendation. Open the original project before trusting details like terms, limits, privacy, cost, setup, or safety.

What it is

Searchable history for coding-agent work

AgentMemory stores activity from connected coding sessions and makes earlier context available for retrieval. It is a memory service around an agent, with a viewer for inspecting the stored work.

Why it stands out

Several agents can use one memory server

The project provides integrations for clients including Claude Code, Codex, Cursor, and Gemini CLI. Hook-based capture depends on the integration; MCP and REST provide other ways to access the same service. This offers a way to carry session context between supported clients.

Availability

Public code with a local server to run

The repository declares Apache-2.0 and documents npm installation with Node.js 20 or newer. The server uses a pinned iii engine. Windows setup has a manual engine step, with WSL2 and Docker Desktop also documented as options.

Why it matters

What makes it useful

You could search for an earlier authentication decision or the discussion behind a retry policy, then read the recovered material before continuing. The project's pairing examples include asking why a library was chosen and finding earlier sessions related to a bug. Those are concrete questions to explore with captured history when returning to a coding task.

Notable points

What stands out

Running without an API key does not mean semantic search is active. The default recall path uses BM25 keyword matching with vector embeddings disabled. Local embeddings are an explicit option and download an embedding model on first use; remote providers are another option. The project's demo includes a meaning-based query that can return no result until embeddings are configured. That distinction helps explain why a keyword query and a differently worded question may behave differently on the same stored sessions.

Before using

What to review

This is a server and integration setup. Check the current Node.js, iii engine, operating-system, and client instructions before trying it. The repository includes a demo with sample sessions for exploring recall.

Review what your selected integration captures and which projects share the server. The release notes describe capture filters; storing session activity creates a record that needs its own access and retention choices.

Choose the provider settings deliberately. LLM-written observation compression requires both a configured provider and an explicit auto-compression setting. Remote model or embedding services can receive the content processed by those features and may charge separately.

Keep track of the configured data directory when restarting or backing up the service. The project documents platform-specific defaults and an override for choosing another location.

The release notes describe authenticated REST access by default. Use the current connection instructions for custom clients, and read recovered history alongside the current code rather than assuming an earlier decision still applies.

Reader fit

Who may find it relevant

Relevant to developers who revisit the same projects across coding sessions or supported agent clients and are comfortable running a local service. The sample-session demo offers an inspection path before connecting real work. Readers looking for a simple note file may find the server, integrations, capture choices, and retrieval settings more setup than their task needs.

Editorial note

Why LifeHubber lists it

We list AgentMemory because a finished code change can leave its reasoning out of view. A developer returning to unfinished work may need the options considered, the problem being investigated, or the reason a change was chosen. Connecting captured sessions to searchable history provides somewhere to look for that context before continuing. A code index answers a different question: where a symbol or relationship exists now. Keeping those questions distinct explains what a session-memory service adds to an existing coding setup.

Source links

Source materials

Reader note

Before relying on this entry

LifeHubber lists entries to help readers inspect AI projects, not to endorse them or prove they are safe, suitable, accurate, maintained, or right for a specific use. We do not verify every entry in depth. Before relying on anything listed, review the original materials, terms, privacy practices, limits, and risks that matter for your situation.

What to explore next

Choose what your agent should carry forward.

Decide what belongs in memory, then compare the ways different projects store and retrieve it.

Advertisements

Advertisements

For project maintainers

Listed here? You can use the badge.

If you maintain a project with a current LifeHubber listing, you may add the optional “Listed on LifeHubber AI Resources” badge to its README, docs, or website. No introduction or permission request is needed.

See what’s moving