If you work with Claude Code or Cursor daily, you know the ritual: open a new session, and the assistant has no idea who you are, what you were building yesterday, or why you made that one weird architectural decision three weeks ago. Every conversation is a cold start.
You re-paste context, re-explain your stack, re-justify decisions you already justified. The model is smart within a session and amnesiac between them — which means the real bottleneck in AI-assisted development isn't reasoning, it's continuity.
I ran into this constantly while juggling multiple client projects, infrastructure work, and side builds. So I built CRBRO, a local MCP server that gives an AI assistant a memory that actually survives across sessions.
What Is MCP, in 3 Lines
The Model Context Protocol (MCP) is an open standard for connecting AI applications to external systems — data sources, tools, and workflows — instead of forcing every integration to be a custom one-off. Anthropic describes it as "a USB-C port for AI applications": one standardized interface that lets Claude, Cursor, Windsurf, and other clients plug into the same servers. That standardization is exactly what makes a portable, cross-client memory layer like CRBRO possible — write the server once, and any MCP-compatible client can use it.
The Architecture of CRBRO
CRBRO borrows its structure from neuroscience rather than from vector databases, and the metaphor isn't just cosmetic — it maps cleanly onto how the tools actually behave.
Neurons: each unit of knowledge — a fact, a decision, a project detail — is stored as an individual, human-readable JSON file on disk.
Synapses:neurons that get referenced together or relate to the same topic are linked, so recalling one can surface the others, similar to associative memory.
Hippocampus:acts as the encoding and retrieval layer — the process that decides what gets written into long-term storage and what gets pulled back out when the assistant needs context.
Heat scores: a ranking signal that determines what's "top of mind" right now, so the assistant doesn't have to sift through everything you've ever told it.
Heat scores work like a decaying-relevance score: a neuron's heat rises every time it's accessed or reinforced, and decays over time if it's left untouched, similar to how frequently-used memories stay sharp while unused ones fade. A simple version of that logic looks like:
heat = base_weight×𝑒−𝜆⋅Δ𝑡+∑access_boosts
Picture a real example:you tell your assistant on Monday that "the staging DB uses Postgres 15 with a read replica." That neuron gets an initial heat value. If you reference staging-DB details again on Tuesday and Thursday, each access adds a boost, keeping the neuron "hot" and near the top of recall results.
Meanwhile, a neuron about a one-off npm package version you mentioned once a month ago decays toward the bottom — still stored, still inspectable, just no longer competing for the assistant's limited attention. That's the mechanism that keeps recall fast and relevant instead of dumping the assistant's entire history into every prompt.
Why Files, Not a Vector Database
It would have been easy to bolt on a vector store and call it memory. I deliberately didn't, for three reasons:
Inspectable:every neuron is a plain JSON file. You can open it in a text editor, grep it, or diff it — no embeddings to decode, no black box.
Git-friendly: because memory is just files, it versions naturally. Commit your assistant's "brain" alongside your project, branch it, roll it back.
Zero dependencies: no cloud account, no external database, no API keys, no vendor lock-in. Everything lives on your machine.
That's consistent with CRBRO's broader design goal: a fully local, portable memory layer that works identically whether you're using Claude Code, Claude Desktop, Cursor, Windsurf, or any other MCP-compatible client.
Demo: Install, Register, and the Boot → Learn → Recall Flow
Getting started takes three commands:
bash
- npx crbro-memory init # initialize the brain + auto-detect installed IDEs npx crbro-memory status # inspect the current state of the brain npx crbro-memory # start the MCP server (stdio transport)
init scaffolds the neuron/synapse storage on disk and detects which MCP-compatible clients you have installed so it can offer to register itself automatically. Once registered — for example inside Claude Code's MCP server config — the assistant picks up CRBRO as a tool source on startup.
From there, the working loop is simple:
Boot — on session start, the assistant queries CRBRO for the highest-heat neurons, effectively loading "what matters right now" instead of a full history dump.
Learn — as you work, new facts and decisions get written as neurons, and related ones get wired together via synapses.
Recall — when you ask a question that touches prior context, the assistant queries the hippocampus layer, which returns the relevant neurons ranked by heat and relevance instead of a brute-force keyword search.
The result is that a Thursday session actually remembers what you decided on Monday, without you re-explaining it.
What I'd Do Differently, and What's Next
If I rebuilt this from scratch, I'd design the synapse-linking logic earlier instead of bolting it on after neurons were already stable — relationships between facts turned out to matter as much as the facts themselves. On the roadmap: smarter synapse pruning so stale links don't clutter recall, better heat-score tuning per project type, and deeper multi-project isolation so CRBRO doesn't blur memory across unrelated codebases.
CRBRO is open source and runs entirely on your machine — no cloud, no accounts, no lock-in, compatible with Claude Code, Claude Desktop, Cursor, Windsurf, and any other MCP client. If it saves you from re-explaining your own project for the tenth time, check out the CRBRO repo and drop a star if it's useful.
Top comments (0)