The thing that frustrates me most about working with AI assistants is the amnesia. Every new session starts from zero. Decisions made yesterday are gone. Problems debugged last week are debugged again. Context I painstakingly built up over a long conversation evaporates the moment I close the terminal.
Post-Cortex is my answer to that. It is an MCP server that gives AI assistants long-term memory — a local, searchable knowledge base of conversations, decisions, and insights, with automatic entity extraction and a knowledge graph built on top.
What it is
Post-Cortex sits between your AI client (Claude, Cursor, anything that speaks MCP) and a local store. Every meaningful exchange — a Q&A, a decision, a bug fix, a code change — gets logged into a session. Sessions live in workspaces. Across all of them, semantic search and entity-graph queries let the assistant find what it already knows before it asks you again.
The design constraints are deliberate:
- Local-first. All processing runs on your machine. No external APIs, no telemetry, no opaque cloud index of your work.
- Fast. Lock-free Rust architecture, HNSW vector search at O(log n), sub-10ms queries.
- Flexible storage. Embedded RocksDB by default for zero-config use, SurrealDB when you want distribution.
- Graph-RAG. Search results come back enriched with entity relationships, not just bag-of-text matches.
Install
# Homebrew (macOS / Linux)
brew install julymetodiev/tap/post-cortex
# Or grab the binary directly
curl -L https://github.com/julymetodiev/post-cortex/releases/latest/download/pcx-aarch64-apple-darwin -o /usr/local/bin/pcx
chmod +x /usr/local/bin/pcx
The binary is pcx. Verify with pcx --version.
Wiring
Post-Cortex is registered once, globally, and then every project on your machine gets memory for free.
# HTTP transport (recommended — requires the daemon)
claude mcp add --scope user --transport http post-cortex http://127.0.0.1:3737/mcp
# Stdio transport (no daemon needed)
claude mcp add --scope user --transport stdio post-cortex -- pcx
Then per project:
pcx setup
pcx setup creates a session, a workspace, a CLAUDE.md with memory rules, hooks that enforce them, and installs the agent definitions that let Claude know it has memory tools available. After that:
claude
Claude will search past knowledge before answering, and log new discoveries as it makes them. The whole thing is invisible most of the time — until the moment your assistant says "we already decided this last week, here is the rationale" and you remember why you wanted it in the first place.
Tools
Six tools, deliberately small:
| Tool | Purpose |
|---|---|
session | Create and list sessions |
update_conversation_context | Store knowledge — Q&A, decisions, problems, code changes |
semantic_search | Find related content across sessions, workspaces, or globally |
get_structured_summary | Session overview — decisions, insights, entities |
query_conversation_context | Entity relationships + keyword search |
manage_workspace | Organize sessions into workspaces |
The split between semantic_search and query_conversation_context matters: semantic search is for "what do I already know about X", graph queries are for "how is X related to Y". Both are cheap; both run locally.
Daemon mode
If you run multiple Claude instances — different terminals, different projects, an editor integration on the side — they should all share the same memory. The daemon is what makes that possible.
pcx start # start daemon
pcx status # check status
pcx stop # stop daemon
With the daemon up, the HTTP transport is the right choice:
{
"mcpServers": {
"post-cortex": {
"type": "http",
"url": "http://localhost:3737/mcp"
}
}
}
One process owns the store, every client talks to it over JSON-RPC, and there is no lock contention or split-brain to worry about.
Storage
| RocksDB (default) | SurrealDB | |
|---|---|---|
| Setup | Zero config | Requires server |
| Distribution | Embedded | Distributed |
| Vector search | HNSW O(log n) | HNSW O(log n) |
Both back the same MCP API; the choice is about deployment, not features. RocksDB is what you want on a laptop. SurrealDB is what you want when several machines should share the graph.
Configure in ~/.post-cortex/daemon.toml or override with environment variables:
| Variable | Default | Description |
|---|---|---|
PC_HOST | 127.0.0.1 | Bind address |
PC_PORT | 3737 | Port |
PC_DATA_DIR | ~/.post-cortex/data | Storage location |
PC_STORAGE_BACKEND | rocksdb | rocksdb or surrealdb |
Backups
Memory you cannot back up is not memory you can rely on. Post-Cortex ships export/import as first-class commands:
pcx export --output backup.json # full export
pcx export --output backup.json.gz # compressed
pcx import --input backup.json # restore
The export is a plain JSON document. You can diff it, version it, copy it to another machine, or feed it into your own tooling.
Why local
The reason this had to be local, not a hosted service, comes down to two things:
- Trust. The whole point of memory is that it accumulates over months and years. The notes, the decisions, the half-formed ideas — that is exactly the material I am not willing to hand to a third party indefinitely.
- Latency. Sub-10ms queries change how an assistant uses memory. If every recall is a network round-trip, the model treats memory as expensive and avoids it. If it is a local function call, the model uses it constantly. The behaviour shifts.
Static, on-disk, on-CPU is what makes both of those possible. HNSW gives logarithmic vector search; RocksDB gives durable storage without a server; the lock-free hot path keeps the daemon responsive under concurrent reads.
Future
Post-Cortex is the storage layer in a larger pattern I keep coming back to: assistants should remember, search, and reason locally. Veles does the search side over code. Post-Cortex does the memory side over conversations and decisions. Together they cover most of what an agent needs to act usefully on a long-lived project without sending anything off the machine.
If you try it and something feels off, open an issue — I read all of them.