Memory that
outlives the
context window.

Why not Redis, SQLite, or a vector store?

You almost certainly run a database already, and you can absolutely build an agent memory layer on Postgres and pgvector — plenty of teams have.

What you end up writing is everything the database doesn't give you: the distinction between an event and a fact that gets corrected, the expiry rules, the supersession rules, the ranking, the graph traversal, the per-prompt recall budget. AegisDB is that layer already built and benchmarked, in one binary that speaks a line of JSON.

what you still have to build

redis      → fast, but evicts on its own TTL
sqlite     → durable rows, no recall by meaning
pgvector   → similarity; events, expiry, graph are yours
aegisdb    → events, facts, working + a graph, each lifecycled

Fewer tokens spent re-teaching the model.

Pasted-in context is billed again on every turn it stays in the window. AegisDB holds it outside the prompt and injects a ranked slice per request, so the window carries the task instead of the backstory.

• Recall, don't re-explain — your stack, conventions, and past decisions are already known, so you stop re-pasting them each session.
• A relevant slice, not a dump — each prompt pulls only the top-ranked memories — ranked by similarity × importance — instead of replaying entire transcripts; the model never sees the rest.
• Short sessions, full knowledge — start fresh instead of dragging a giant transcript whose every turn re-bills the whole context.
• Distilled & shared — capture stores salient outcomes, not raw logs, and a team reuses context established once.

Fast enough to be invisible.

Recall sits in the agent's inner loop, so latency is the whole game. Vector search stays sub-millisecond at 100k memories, and recall@10 holds at 1.00 on the bench corpus.

These are AegisDB's own numbers, not a comparison — and you can reproduce them yourself: make bench (vector recall + latency) and make wire-bench (end-to-end over TCP).

make bench · make wire-bench

vector recall  → 0.14 ms @ 10k · 0.22 ms @ 100k
recall@10      → 1.00  (384-dim, HNSW)
ping           → 158k ops/s · p50 0.05 ms
read (get)     → p50 0.8 ms over the wire

Intel Core i7-1355U · loopback · single node

Does the memory actually work? Run the benchmark.

Memory only earns its tokens if it changes outcomes, so the benchmark ships with the code. make eval-tasks is a controlled A/B: each task teaches a fact in one session, then asks about it in a fresh session — once with recall, once without. Each task runs in its own namespace, and --sandbox runs the no-memory arm from an empty directory so it can't recover the answer from your repo.

On the bundled 10-task suite the recorded run is 100% with memory, 0% without. The facts are fictional and unguessable, so that 0% is the no-memory arm correctly answering "I don't know" — the number measures the harness's isolation as much as memory's lift. Point it at your own tasks or a different answer model and expect a smaller, more interesting gap. make eval separately gates retrieval quality (recall@k / MRR) so scoring changes can't regress silently.

recorded run · 10 coding-agent tasks

$ make eval-tasks EVAL_ARGS='--model claude-code --sandbox'
with memory (ON)     → 100%
without memory (OFF) →   0%   answers "I don't know"
lift                 → +100%  10 tasks

$ make eval
recall quality       → recall@k / MRR gate

Long-term memory for Claude Code.

An MCP server plus session hooks: relevant memories are recalled into context on every prompt, and the ones worth keeping are captured when the session ends.

• Automatic recall on each prompt, inside a strict time budget.
• Automatic capture at session end, filtered by salience.
• Per-project namespaces — isolated by default, shared by choice.
• No clone — uvx fetches the published package (aegisdb-mcp on PyPI) on demand.
• One-command setup — uvx --from aegisdb-mcp aegisdb-init writes the config below and the hooks; or install the /aegis-setup skill and let Claude do it.
• Fails open — if the backend is down, your session keeps working.

.mcp.json — scaffolded by aegisdb-init

{
  "mcpServers": {
    "memory": {
      "command": "uvx",
      "args": ["aegisdb-mcp"],
      "env": {
        "AEGIS_NAMESPACE": "my-project",
        "AEGIS_EMBEDDING_DIMENSIONS": "1024"
      }
    }
  }
}

One agent learns it. Everyone's agent knows it.

Every developer on a team re-teaches their agent the same things — why the middleware is bypassed in staging, which migration approach was rejected last quarter and why, the gotcha that costs an hour if you miss it. That knowledge dies at the end of each session, per person, and the next agent re-derives it from scratch.

Point the team at one server with a token in a shared namespace, and a decision captured on Tuesday is recalled into someone else's session on Thursday — ranked and budgeted, a slice rather than a dump. A new hire's agent starts on day one already knowing the conventions and the shape of the system.

Self-hosting is load-bearing here, not a preference. The memories a coding agent accumulates are your internal engineering knowledge — architecture rationale, security posture, incident history, unreleased plans. That is the category you can't hand to a third-party SaaS, which is why this is a binary you run, on your box, with a key only you hold.

• Isolated tenants, or one shared pool — a namespace per person or per client project, enforced by the server; quotas and rate limits keep one runaway agent from filling the disk or monopolizing the box.
• Auditable, not a black box — explain shows why a memory ranked, as_of replays what the agent knew at T, and export / purge answer "erase everything about X".
• Read-only tokens for automation — CI, a review bot, or a docs generator reads team memory without writing to it.
• Set up in three commands — mint a token, run the server, drop in a .mcp.json. The recipe is below ↓