DEV Community: Scott Crawford

Local Ai Memory Isn't More Private — Here's Why

Scott Crawford — Fri, 13 Mar 2026 13:59:55 +0000

"Keep your data local. No cloud. Total privacy."

It's a compelling pitch. Several Ai memory tools market local-first storage — typically SQLite on your machine — as a privacy advantage over cloud-based solutions. The implication: if your memories stay on your hard drive, they're safe.

There's just one problem. It's not true.

The Inference Problem

Here's how every Ai memory system works, whether local or cloud:

You ask your Ai assistant a question
The memory system retrieves relevant memories
Those memories are injected into the prompt
The prompt — including your memories — is sent to the model provider (Anthropic, OpenAI, Google)
The Ai responds

Step 4 is the part that matters. Every memory your Ai reads leaves your machine. It doesn't matter if those memories were stored in a local SQLite file, a local vector database, or a cloud service. The moment your Ai uses a memory, it's transmitted to the model provider's servers for inference.

This isn't a bug. It's how large language models work. The model runs on remote servers. Your prompt — including any context, memories, or files you attach — has to reach those servers to get a response.

What "Local-First" Actually Means

Local storage means your memories sit on your hard drive between uses. That's it. The second your Ai retrieves a memory and includes it in a conversation, the data is transmitted to the cloud.

So what are you actually getting from local-first memory?

Your data sits on your disk when it's not being used
You manage your own database files
You handle your own backups
You lose your memories if your machine dies
You can't search semantically (most local solutions use keyword matching)
You can't share knowledge with teammates
You can't access your memories from a different machine

What you're not getting is privacy protection for the memories your Ai actually uses. Those go to the cloud either way.

The Real Privacy Question

The privacy question worth asking isn't "where are my memories stored?" — it's "what data is being stored in the first place?"

A well-designed memory system should:

Never store raw source code — only extracted facts and decisions
Auto-detect secrets — API keys, tokens, and credentials should be caught and blocked before storage
Encrypt at rest — whether local or cloud, memories should be encrypted
Encrypt in transit — HTTPS for all communication
Give you full control — export, delete, and manage your data at any time
Never use your data for model training

These protections matter regardless of where your memories are stored. A cloud service with encryption, secret detection, and strict data isolation is meaningfully more secure than an unencrypted SQLite file sitting in your home directory.

What Cloud Memory Actually Adds

Once you accept that your memories reach the cloud at inference time either way, the question becomes: what do you get for storing them in an intelligent cloud service instead of a local file?

Semantic search. "How does auth work?" finds memories about JWT tokens and cookie settings — even though the words don't match. Local keyword search can't do this.

Intelligence that improves over time. Memory decay, auto-linking, contradiction detection, and behavioral learning that makes recall smarter the more you use it. A SQLite file is static storage. Cloud memory is a system that learns.

Portability. Memories created in Claude Code are instantly available in Cursor, Windsurf, Cline, or any MCP-compatible tool. New laptop? Log in and your full project knowledge is there. A local file dies with your machine.

Team collaboration. When one developer documents a bug fix or architecture decision, every teammate's Ai assistant knows about it instantly. This is impossible with local-only storage.

Zero maintenance. No local databases to corrupt. No background daemons consuming RAM. No Python environments to manage. No version conflicts. It just works.

The Bottom Line

Local-first Ai memory is optimizing for a privacy guarantee that doesn't exist in practice. The moment your Ai reads a memory, that data travels to the model provider's servers. This is true for every Ai assistant — Claude, GPT, Gemini, all of them.

The real choice isn't between "private local" and "exposed cloud." It's between a dumb file on your disk and an intelligent system that makes every conversation smarter — with the same data flow either way.

Choose the one that makes your Ai actually useful.

CogmemAi is persistent memory for Ai coding assistants. 30 tools, semantic search, self-improving recall, and team collaboration. Works with Claude Code, Cursor, Windsurf, Cline, and any MCP-compatible tool. Get your free API key →

I Built an AI Agent Wallet That's 31% Less Expensive Than Coinbase — Here's Why

Scott Crawford — Thu, 05 Mar 2026 16:44:30 +0000

Your AI agent needs a wallet. Maybe it's paying for APIs, trading on DeFi, or accepting payments. You look at the options and find... gatekeepers.

Identity verification. KYC forms. Approval queues. Transaction monitoring. And if they don't like what your agent is doing? They can freeze your wallet.

I built AgentWallet because AI agents shouldn't need permission to transact.

The Problem with Existing Solutions

Most wallet infrastructure for AI agents was designed for humans first and adapted for agents second. That means:

KYC/KYT requirements — Your autonomous agent can't fill out identity forms
Approval processes — Days of waiting before your agent can start transacting
Transaction monitoring — Someone watching every move your agent makes
Wallet freezing — A compliance team can shut you down at any time
Credit card required — Your agent can't pay for its own infrastructure with crypto

These are fine for consumer fintech. They're terrible for autonomous agents that need to transact freely and programmatically.

What AgentWallet Does Differently

No KYC. No KYT. No approval process. No transaction monitoring. No one can block your wallet.

{
  "mcpServers": {
    "agentwallet": {
      "command": "npx",
      "args": ["-y", "agentwallet-mcp"],
      "env": {
        "AGENTWALLET_USER": "your_username",
        "AGENTWALLET_PASS": "your_api_key"
      }
    }
  }
}

That's it. Your AI agent now has 29 MCP tools for wallet management, token transfers, DeFi interactions, and x402 payments across every EVM chain and Solana.

The Pricing Comparison

This is where it gets interesting.

	Coinbase CDP	AgentWallet
Cost per operation	$0.005	$0.00345 (31% less)
Free operations/month	5,000	6,000
x402 verification cost	$0.001	$0.0005 (50% less)
Free x402 verifications	1,000	1,000
KYC required	Yes	No
Can freeze your wallet	Yes	No
Pay fees with crypto	No	Yes
Supported chains	8 EVM + Solana	Any EVM + Solana
x402 paywalls	No	Yes

31% less expensive on operations. 50% less expensive on x402 verifications. More free tier. More chains. And no one standing between your agent and its transactions.

Pay for API Fees With Crypto

This is the part I'm most proud of.

AgentWallet is the only AI agent wallet infrastructure that accepts crypto for its own API fees. Every other provider requires a credit card or monthly invoice.

When your agent exceeds the free tier (6,000 ops/month) without a credit card configured, the API returns HTTP 402 with USDC payment instructions. Your agent pays on-chain, retries with proof of payment, and the operation executes. Fully automated.

Your AI agent can literally bootstrap itself — create a wallet, receive funds, and pay for its own infrastructure. No human with a credit card required.

x402: Pay and Get Paid

AgentWallet natively supports the x402 open payment standard. Two sides:

Paying: When your agent hits an API that returns HTTP 402, the pay_x402 tool handles everything — detects the payment requirement, pays on-chain, retries with proof, and returns the response. One tool call.

Accepting: Create a paywall in front of any URL. Other agents (or humans) pay on-chain to access your resource. On-chain verification ensures every payment is real. Replay protection prevents double-spending. Revenue tracking shows who paid, how much, and when.

create_paywall(
  wallet_id=1,
  name="Premium API",
  amount="0.01",
  resource_url="https://your-api.com/data"
)

You just monetized your API for AI agents. No Stripe integration, no billing portal, no invoicing.

Built-in Guards (Active by Default)

Security isn't optional — it's on by default:

Private keys encrypted at rest, decrypted only during signing, zeroed from memory immediately after
Daily spending limits per wallet
Gas price protection blocks transactions during spikes
Emergency pause freezes any wallet instantly
Rate limiting prevents abuse
On-chain verification for every x402 payment

No configuration needed. Everything is active from the moment you create a wallet.

29 MCP Tools

Everything your agent needs:

Wallet management — create, list, pause, delete
Transfers — native tokens (ETH, SOL, POL, BNB, AVAX, PLS) and ERC-20/SPL tokens
DeFi — approve tokens, check allowances, wrap/unwrap ETH, call contracts
x402 — pay invoices, create paywalls, track revenue
11 chains — Ethereum, Base, Polygon, BSC, Arbitrum, Optimism, Avalanche, Zora, PulseChain, Solana, Solana Devnet — plus any other EVM-compatible chain

Works with Claude Code, Claude Desktop, Cursor, Windsurf, Cline, VS Code, and any MCP-compatible client.

Get Started

# 1. Get your free API key (no credit card, no KYC)
# Visit https://hifriendbot.com/wallet

# 2. Add to your MCP config (3 lines)

# 3. Your agent is transacting

6,000 free operations per month. No monthly fee. No tiers. Just pay as you go.

Links:

AgentWallet is built by HiFriendbot. We also make CogmemAi — persistent memory for AI coding assistants.

What's New in CogmemAi v3: Self-Tuning Memory for Ai Coding Assistants

Scott Crawford — Thu, 26 Feb 2026 17:14:16 +0000

CogmemAi has been live for a week. In that time, I've shipped 8 releases, 30+ improvements, and a few features I didn't expect to build. Here's what changed and why it matters.

If you're not familiar with CogmemAi: it gives Claude Code (and Cursor, Windsurf, Cline, Continue) persistent memory across sessions. One command setup, zero local databases. Get started free.

Memory Health Score

Every session now starts with a health score from 0-100. It tells you at a glance whether your memory system is working well or needs attention.

Instead of wondering "am I saving enough?" or "is my memory cluttered?", you get a number and actionable factors. A score of 90+ means your memory is healthy. Below 70, there's room to improve.

This matters because memory systems degrade silently. Without a health check, you'd never know half your memories were stale until Claude Code started giving you bad advice.

Session Replay

The most-requested improvement: pick up where you left off.

When you start a new session, CogmemAi now loads a summary of what you accomplished last time. No scrolling through old conversations. No "what was I working on?" moment. You just... continue.

This is especially valuable after compaction events. Claude Code compresses your context, everything gets summarized, and you lose the thread. Session replay bridges that gap automatically.

Self-Tuning Memory

This is the one I'm most proud of.

Memories that get recalled frequently have their importance boosted automatically. Memories that never get recalled and are old enough get archived automatically. You don't have to manage importance scores by hand anymore.

The result: your memory system gets smarter over time. Frequently useful knowledge becomes easier to find. Stale facts fade away. Zero manual maintenance required.

Auto-Ingest README

When CogmemAi detects a brand new project with zero memories, it checks for a README and offers to ingest it. This bootstraps your memory instantly instead of waiting for facts to accumulate over multiple sessions.

Start a new project, and Claude already knows your tech stack, setup instructions, and architecture from day one.

Smart Recall

This shipped in v3.0 but has been quietly improving. When you switch topics mid-session, CogmemAi automatically surfaces relevant memories without you asking.

Working on auth? Memories about your auth system appear. Switching to the database layer? Those memories surface instead. It happens in the background, no commands needed.

28 Tools, Zero Configuration

CogmemAi now has 28 tools that your Ai assistant uses automatically:

Memory CRUD — save, recall, update, delete, bulk operations
Ai-powered — extract facts from conversations, ingest documents, consolidate related memories
Task tracking — persistent tasks with status and priority that carry across sessions
Learning — correction patterns (wrong to right) and next-session reminders
Analytics — health dashboard, stale detection, usage stats, file change awareness
Organization — knowledge graph links, version history, tags, project scoping

All of this works out of the box. No configuration. No prompting Claude to use the tools. It just knows.

Works Everywhere

CogmemAi isn't just for Claude Code anymore. It works with any MCP-compatible Ai coding tool:

Claude Code (recommended — includes compaction recovery and session hooks)
Cursor
Windsurf
Cline
Continue

Same memories, same tools, any editor.

Getting Started

npx cogmemai-mcp setup

That's it. Free tier includes 500 memories and 5 projects. Get your API key at hifriendbot.com/developer.

If you're already using CogmemAi, update to the latest:

npm install -g cogmemai-mcp@latest

What's Next

I'm working on more features, but I'd rather ship them than talk about them. If you try CogmemAi and have feedback, open an issue on GitHub.

The goal hasn't changed: make Ai coding assistants remember everything so you never re-explain your codebase again.

Why Claude Code Forgets Everything (And How to Fix It)

Scott Crawford — Tue, 24 Feb 2026 21:33:11 +0000

Every Claude Code session starts from zero. No memory of yesterday's work. No awareness of the architectural decisions you explained last week. No recall of the debugging session that took three hours.

You re-explain your tech stack. You re-describe your file structure. You re-state your preferences. Every. Single. Session.

If this sounds familiar, you're not alone. It's the most common complaint in the Claude Code community — and it has real consequences for productivity.

The Problem Has a Name: Context Compaction

Claude Code operates within a 200,000-token context window. That sounds like a lot, but complex coding sessions fill it fast. When you hit roughly 83% utilization (~167K tokens), Claude Code triggers auto-compaction — a lossy, one-way compression of your conversation history.

Here's what that means in practice: your detailed explanations, resolved debugging sessions, and exploratory discussions get "summarized away." The DoltHub engineering blog put it bluntly:

"Claude Code is definitely dumber after the compaction. It doesn't know what files it was looking at and needs to re-read them."

One GitHub issue (#3841) captured the developer experience perfectly:

"The model completely lost memory of very basic things, such as how to run a python command in a uv environment. I have to tell it literally every time after the auto compact summary."

And this isn't a rare edge case. Search the claude-code issues for "memory," "compaction," or "context loss" and you'll find dozens of reports — many auto-closed by bots despite active community discussion.

CLAUDE.md: The Official Answer (With Hidden Limits)

Anthropic's recommended solution is CLAUDE.md — a markdown file loaded into Claude's system prompt at the start of every session. You can put project instructions, coding conventions, and architectural notes in it.

It works... up to a point. Here are the limitations most developers discover the hard way:

The 200-line ceiling

Claude Code's auto-generated MEMORY.md — the file Claude writes its own notes to — has a hard 200-line cap. Content beyond line 200 is silently dropped. No warning. No error. Your carefully curated context just vanishes. (Issue #25006)

Post-compaction amnesia

CLAUDE.md is supposed to reload after compaction. In theory, the new session re-ingests it. In practice, multiple bug reports document Claude ignoring it entirely:

"After compaction, Claude stops respecting the instructions defined in CLAUDE.md and begins to behave unpredictably."
— Issue #4017 (20 upvotes)

One developer caught Claude red-handed (Issue #19471):

When confronted, Claude admitted: "I didn't read CLAUDE.md" and "I skipped it and ran the Glob command directly."

A Medium analysis explained the mechanism: after compression, "CLAUDE.md no longer counts as a rule, but as information, and information can be ignored."

No search, no structure, no intelligence

CLAUDE.md is a flat text file. There's no semantic search. No way to find the right piece of context when you have hundreds of lines of notes. No automatic extraction of important facts from your conversations. It's a sticky note on a PhD thesis.

The hidden token tax

Every message re-sends the full CLAUDE.md as cached context. One developer discovered that cache reads consumed 99.93% of their total token usage — 5.09 billion cache read tokens versus 3.9 million actual I/O tokens. A large CLAUDE.md bleeds your budget silently.

No Memory Between Sessions: The Real Pain

The compaction problem is bad enough within a single session. But the deeper issue is that Claude Code has zero native memory between sessions.

Every new terminal, every claude invocation — it's a stranger who happens to have access to your codebase. As one developer put it in Issue #14228:

"I'm paying for ONE Claude. I should get ONE Claude. When I talk to Claude on the web, it knows me. When I open Claude Code, it's like meeting a stranger who happens to have the same name."

The frustration is compounded by the price tag. From Issue #14227:

"Paying $200/mo for a product we can't reliably use, with no workaround permitted, is not acceptable."

And from Issue #3508:

"I'm downgrading my account. I'm not going to continue to pay $100/mo for something I have to constantly stop from doing incredibly dumb things."

The community coined a phrase that stuck: "You're paying for a goldfish with a PhD." Brilliant capabilities, zero recall.

What the Community Has Built

The gap between Claude Code's capabilities and its memory has spawned an entire ecosystem of workarounds. Here are the main approaches developers are using:

1. Manual CLAUDE.md Curation

The simplest approach: maintain your own markdown files. Some developers report maintaining 500+ line CLAUDE.md files that they manually update after every session. It works, but it's tedious, doesn't scale, and — as we covered — Claude may ignore it after compaction anyway.

Pros: Zero dependencies, built-in, works offline
Cons: Manual effort, no search, 200-line auto-memory cap, ignored after compaction

2. Local Vector Database Solutions (~29,700 GitHub stars)

The most popular third-party approach. Uses hooks to capture session context, compresses it with Ai, and stores it in a local database with vector search.

Pros: Large community, battle-tested, open source
Cons: Requires multiple local dependencies, significant resource usage reported, local-only (no cross-device sync)

3. Other MCP Memory Servers (~1,200 GitHub stars)

MCP servers providing persistent memory with knowledge graph features and autonomous consolidation.

Pros: Knowledge graph structure, semantic search
Cons: Requires multiple local dependencies (Python, ONNX, ChromaDB), stability varies, complex setup

4. Mem0 (~46,000 GitHub stars)

A VC-backed universal Ai memory layer with an MCP adapter. Targets the broader Ai agent ecosystem (LangGraph, CrewAI, etc.) rather than Claude Code specifically.

Pros: Well-funded, broad ecosystem support, enterprise features
Cons: Not Claude Code-specific, requires additional infrastructure, overkill for individual developers

5. Cloud-Based MCP Memory

A newer approach: move the memory system to the cloud entirely. The MCP server becomes a thin HTTP client with zero local dependencies. Extraction, embedding, and search happen server-side.

CogmemAi takes this approach — semantic search, Ai-powered memory extraction, automatic compaction recovery, and project-scoped memories that follow you across machines. One command setup:

npx cogmemai-mcp setup

Pros: Zero local databases, zero RAM issues, cross-device sync, compaction recovery
Cons: Requires network connection, data stored in the cloud (not local-first)

6. Roll Your Own

Some developers build custom solutions with markdown files, SQLite databases, or even Neo4j knowledge graphs. The claude-code repo has multiple issues where developers describe elaborate multi-agent workaround systems they've built just to maintain basic project continuity.

How to Choose

There's no single right answer. The best solution depends on your priorities:

Priority	Best Fit
Zero dependencies	CLAUDE.md (built-in)
Largest community	Local vector database solutions
No local setup	Cloud-based (CogmemAi)
Enterprise / multi-agent	Mem0
Full control	Roll your own
Survives compaction	Solutions with compaction recovery (CogmemAi)

What I'd Love to See From Anthropic

The community has made it clear: persistent memory is the #1 missing feature in Claude Code. The GitHub issues, the Reddit threads, the tens of thousands of stars on community memory tools — it all points in the same direction.

Here's what would make the biggest difference:

Native cross-session memory — like claude.ai's memory system, but for Claude Code
Compaction that asks before destroying — Issue #24201 (17 upvotes) requests exactly this
Reliable CLAUDE.md reload after compaction — fix the documented bugs where instructions get ignored
Remove the silent 200-line cap on MEMORY.md — or at minimum, warn when content is being truncated

Until then, the community solutions are the best we've got. Pick one that fits your workflow, set it up, and stop re-explaining your architecture every morning.

I built CogmemAi after getting tired of re-explaining my tech stack every session. It's one approach among several — try whichever fits your workflow. The important thing is to stop losing context.

Have a different solution that works for you? I'd love to hear about it in the comments.

Building a Cloud Memory System for Ai Coding Assistants

Scott Crawford — Tue, 24 Feb 2026 21:21:51 +0000

I spent the last several months building a persistent memory system for Claude Code. Not a wrapper around a local vector database — a cloud-native, multi-layer cognitive memory engine designed to survive context compaction, scale across devices, and get smarter over time.

This post isn't about the product. It's about the engineering: the architectural decisions, the trade-offs, and what I learned about building memory for Ai coding assistants.

The Problem Space

Building memory for an Ai coding assistant is harder than it sounds. You're not building a database — you're building a system that needs to answer a question most databases can't: "What does this developer need to know right now?"

The challenges:

Volume asymmetry. A developer generates thousands of lines of conversation per day. Maybe 1% of that is worth remembering long-term. You need an extraction layer that separates signal from noise.
Retrieval relevance. Keyword search fails for memory. When Claude needs to know about your "database setup," it should find your PostgreSQL configuration decisions even if you never used those exact words. You need semantic search.
Temporal dynamics. A bug fix from yesterday is more important than a bug fix from three months ago. But a core architecture decision from three months ago is more important than both. You need a ranking system that accounts for both recency and importance.
Contradiction handling. Developers change their minds. You migrated from MySQL to PostgreSQL. The old "we use MySQL" memory is now wrong. You need conflict detection and resolution.
Context boundaries. Your React conventions shouldn't contaminate your Python project. But your preference for tabs over spaces should follow you everywhere. You need scoping with inheritance.

The 3-Layer Architecture

The system has three layers, each solving a different part of the problem:

Layer 1: Ai Extraction    — What's worth remembering?
Layer 2: Semantic Storage  — How do we find it later?
Layer 3: Time-Aware Rank   — What matters most right now?

Each layer is independent and can be reasoned about separately.

Layer 1: Ai Extraction

The extraction layer answers the hardest question: given a conversation between a developer and an Ai assistant, what facts are worth storing permanently?

A naive approach would be to store everything. That fails fast — a 2-hour coding session generates thousands of tokens of conversation, most of which is transient (debugging output, file reads, exploratory questions). Storing all of it creates noise that drowns out signal during retrieval.

The key insight is that extraction is lossy by design. You want to lose most of the conversation. What survives should be concise, factual, complete sentences that stand on their own: "The database uses a custom prefix" or "CSS overrides require a specific selector pattern."

What Makes a Good Memory

Through testing, I found that effective memories share four properties:

Self-contained. The memory makes sense without reading the conversation it came from.
Specific. "We use PostgreSQL" is useful. "We discussed database options" is not.
Actionable. It should change Claude's behavior. A memory that directly prevents a mistake is worth ten memories that provide background context.
Stable. It shouldn't become outdated within a session. Architectural patterns are more valuable than version numbers.

Layer 2: Semantic Storage and Search

Once a memory is extracted, it needs to be stored in a way that supports meaning-based retrieval.

Why Semantic, Not Keyword

A query for "how does auth work?" should find a memory about JWT tokens and cookie settings — even though the query and the memory share almost no keywords. This is the fundamental limitation of keyword search for memory systems. You need meaning-based retrieval.

Why Cloud, Not Local

The most popular local memory solutions run embedding models and vector databases on the developer's machine. This works, but it has real costs:

RAM: In-process vector stores with local embeddings consume significant memory. Community reports of 15GB+ leaks.
Startup latency: Loading a local embedding model adds seconds to every MCP server startup.
Platform fragility: Local runtimes have known issues across different platforms and architectures.
No sync: A local vector database is inherently single-machine.

Moving the heavy lifting server-side eliminates all of these. The MCP server becomes a thin HTTP client — stateless, lightweight, platform-agnostic. The trade-off is network dependency, which I consider acceptable for a developer tool.

Layer 3: Time-Aware Ranking

Semantic similarity alone isn't enough. Given a query, you might find 50 relevant memories. Which ones should surface first?

The challenge is balancing multiple signals. A memory can be semantically relevant but old and unimportant. Another can be important and recent but semantically off-topic. The ranking system needs to weigh all of these factors and surface the best results for any given moment.

The key insight: importance and recency are both critical, but they interact in non-obvious ways. A recent low-importance memory might outrank an old low-importance one, but a core architecture decision from months ago should always surface when relevant — regardless of age.

Deduplication and Conflict Resolution

Developers change their minds. You migrated from MySQL to PostgreSQL. The old "we use MySQL" memory is now wrong. A good memory system needs to handle both duplicates and contradictions gracefully — keeping the most accurate, most specific version while preserving a version trail so nothing is truly lost.

Compaction Recovery

Claude Code's auto-compaction is the single biggest threat to productive sessions. When context gets compressed, Claude loses its working state — which files it was looking at, what approach it was taking, what decisions were made earlier in the conversation.

CogmemAi solves this by automatically preserving and restoring context around compaction events. The result: you experience seamless continuity rather than a cold restart. Claude picks up right where it left off, with full awareness of your project and the current session.

Project Scoping

Project memories (scope: project) are tied to a specific repository. Architecture decisions, file structure notes, dependency constraints.
Global memories (scope: global) follow the developer everywhere. Identity, coding style, tool preferences.

At session start, the system blends both: project-specific memories for the current repo, plus global preferences. Cloning the same repo on a different machine maps to the same project automatically.

Lessons Learned

Extraction quality is everything. If you store low-quality memories, no amount of search sophistication will compensate. The most impactful optimization is always at the extraction layer.

Importance is subjective. What matters to one developer is noise to another. The system needs to learn from usage patterns over time, not just assign static scores.

Domain-specific content is harder than general content. CSS-specific memories often sound similar but are functionally different. Configuration details need tighter matching because small value differences are significant. This is an ongoing area of improvement.

Closing Thoughts

Building memory for Ai coding assistants is fundamentally a retrieval problem disguised as a storage problem. Storing everything is easy. Surfacing the right 20 memories out of 2,000 when Claude needs them — that's where the engineering lives.

The three-layer approach (extract, embed, rank) gives you independent dials to tune. Bad extraction? Fix the extraction prompt without touching search. Irrelevant search results? Adjust the embedding model without touching extraction. Ranking feels off? Tune the weights without touching either upstream layer.

If you're building something similar, my advice: start with extraction quality. If you store garbage, no amount of search sophistication will find gold.

The system described here is CogmemAi, an open-source MCP server for Claude Code. The architecture is MIT-licensed and the documentation is here. I'm happy to discuss the technical details — feel free to open an issue or find me in the comments.

5 Ways to Add Memory to Claude Code (Compared)

Scott Crawford — Tue, 24 Feb 2026 21:16:16 +0000

If you use Claude Code for anything beyond one-off scripts, you've hit the memory wall. Every session starts from zero. Context compaction destroys your working state. MEMORY.md caps out at 200 lines.

The good news: the community has built real solutions. The bad news: there are enough options that choosing one is its own time sink.

I've tested all of the major approaches. Here's an honest comparison — what works, what breaks, and which one fits your situation.

1. CLAUDE.md + MEMORY.md (Built-In)

What it is: Claude Code's native memory system. CLAUDE.md files hold project instructions; MEMORY.md (in ~/.claude/projects/) stores notes Claude writes to itself. Both load into the system prompt at session start.

Setup: Nothing. It's already there.

How it works:

CLAUDE.md at your project root — team-shared instructions, conventions, architecture notes
CLAUDE.local.md — personal notes, auto-gitignored
~/.claude/CLAUDE.md — global preferences across all projects
MEMORY.md — auto-generated by Claude, loaded at session start

The good:

Zero setup, zero dependencies, zero cost
Works offline
CLAUDE.md is version-controlled with your project
Simple enough to understand in 5 minutes

The bad:

MEMORY.md has a hard 200-line cap. Content beyond line 200 is silently dropped. No warning. (Issue #25006)
No search. Claude reads the entire file every session. With 200 lines of notes, it has no way to find specific context by meaning.
Post-compaction amnesia. Multiple bug reports document Claude ignoring CLAUDE.md after context compaction. (Issue #4017, 20 upvotes)
No automatic extraction. Claude has to decide what to write down. Important context slips through constantly.
No cross-device sync. Each machine has its own disconnected MEMORY.md.
Hidden token cost. Every message re-sends the full CLAUDE.md. One developer found cache reads consuming 99.93% of total token usage.

Best for: Small projects, quick tasks, developers who don't want to install anything.

Verdict: Fine for getting started. Inadequate for serious, multi-session development.

2. Local Vector Database Solutions (~29,700 GitHub Stars)

What it is: The most popular third-party memory approach. Automatically captures session context, compresses it with Ai, and stores it in a local database with vector search.

Setup: Typically a single init command, but requires local dependencies.

How it works:

Hooks into Claude Code's session lifecycle
Captures conversation context and compresses it into summaries
Stores summaries in local databases with vector embeddings
Injects relevant context at session start

The good:

Massive community — tens of thousands of stars, actively maintained
Battle-tested across thousands of developers
Open source
Session summaries are automatic
Vector search finds relevant context

The bad:

Local dependencies. Requires multiple runtimes and databases running on your machine.
Resource consumption. Significant memory usage reported during long sessions, due to in-process vector stores.
No cross-device sync. Your memories live on one machine. Work from a laptop and desktop? Two separate memory stores.
Session-level granularity. Captures session summaries, not individual facts. You can't search for a specific architecture decision — you search for sessions that might have mentioned it.

Best for: Developers who want the most popular, proven approach and work from a single machine with plenty of RAM.

Verdict: The community standard. Solid choice if you don't mind local resource usage and single-machine limitations.

3. Other MCP Memory Servers (~1,200 GitHub Stars)

What it is: MCP servers providing persistent memory with knowledge graph features, semantic search, and autonomous memory consolidation.

Setup: Typically requires Python and multiple dependencies, with several configuration steps.

How it works:

Runs as an MCP server alongside Claude Code
Stores memories locally with vector embeddings
Provides tools for saving, searching, and managing memories
Includes knowledge graph relationships between memories
Autonomous consolidation merges related memories over time

The good:

Knowledge graph structure adds relationship context
Semantic search with local embeddings
Autonomous consolidation reduces memory bloat
MCP-native — works through the standard protocol

The bad:

Complex setup. Requires multiple local dependencies and configuration steps.
Stability varies. Some projects have experienced significant version churn and reliability issues.
Local-only. Same single-machine limitation as local vector database solutions.
Smaller community. Fewer people testing edge cases compared to the most popular solutions.
Heavy dependencies. Embedding model downloads can be hundreds of megabytes and may fail on some platforms.

Best for: Developers who want knowledge graph features and don't mind a more complex setup process.

Verdict: Ambitious architecture, but stability varies across projects. Test thoroughly before committing.

4. CogmemAi (Cloud-Based)

What it is: A cloud-first MCP server that moves all memory intelligence server-side. The local MCP server is a thin HTTP client — no databases, no vector stores, no heavy dependencies. Full disclosure: I built this one.

Setup:

npx cogmemai-mcp setup

How it works:

18 MCP tools: save, recall (semantic search), extract (Ai-powered), project context, analytics, knowledge graph, import/export, and more
Memories stored with high-dimensional semantic embeddings server-side
Ai extraction identifies important facts from conversations automatically
Smart deduplication detects duplicate and conflicting memories
Automatic project scoping + global preferences that follow you everywhere
Automatic compaction recovery — context is preserved before compaction and seamlessly restored afterward

The good:

Zero local setup. No databases, no Python, no Docker, no vector stores. One command.
Zero RAM issues. Nothing running locally except a thin HTTP client.
Cross-device sync. Memories are in the cloud. Work from any machine.
Compaction recovery. Automatically saves context before compaction and restores it after.
Semantic search. Find memories by meaning, not keywords.
Ai extraction. Automatically identifies facts worth remembering.
Document ingestion. Feed in READMEs or docs to quickly build project context.
Free tier: 1,000 memories, 500 extractions/month, 5 projects.

The bad:

Requires internet. No network, no memories. Not usable offline.
Data in the cloud. Your memories (short factual sentences, not source code) are stored on HiFriendbot's servers. If that's a dealbreaker, go local.
Newer project. Smaller community than the most popular local solutions. Fewer people have battle-tested it.
Paid tiers for heavy use. Free tier is generous (1,000 memories), but Pro is $14.99/mo for 2,000 memories. Best for: Developers who want zero-config setup, cross-device sync, and compaction recovery without managing local infrastructure.

Verdict: The trade-off is cloud dependency for zero maintenance. If you're comfortable with that, it's the fastest path to persistent memory.

5. Roll Your Own

What it is: Build a custom memory system tailored to your exact needs. Popular approaches include markdown file collections, SQLite databases with FTS5, or even Neo4j knowledge graphs.

Setup: However long it takes you to build it.

Common approaches:

Markdown files + grep. Maintain a /memory/ directory with topic-based markdown files. Simple, version-controlled, human-readable. No semantic search.
SQLite + FTS5. Store memories in SQLite with full-text search. Good for keyword matching, misses semantic similarity.
Custom MCP server. Build an MCP server that wraps your preferred storage backend. Full control, full responsibility.
Obsidian vault. Some developers use Obsidian's knowledge graph as a project memory, connected via MCP servers like easy-obsidian-mcp.

The good:

Complete control over storage, format, and retrieval
No vendor dependency
Can be exactly what you need and nothing more
Educational — you learn how memory systems work

The bad:

Time investment. Building a good memory system is a project in itself. Semantic search alone requires embedding models, vector storage, and retrieval logic.
Maintenance burden. You own every bug, every upgrade, every edge case.
No Ai extraction. Unless you build it, you're manually deciding what to remember.
No compaction recovery. You'd need to build that system yourself.

Best for: Developers with specific requirements that no existing tool meets, or those who want to learn by building.

Verdict: Maximum flexibility, maximum effort. Only worth it if the existing tools genuinely don't fit.

The Comparison Table

Feature	CLAUDE.md	Local Vector DB	Other MCP Servers	CogmemAi	DIY
Setup time	0 min	~5 min	~15 min	~1 min	Hours/days
Local dependencies	None	Multiple (databases, runtimes)	Multiple (Python, embeddings)	None	Varies
Semantic search	No	Yes (local)	Yes (local)	Yes (cloud)	If you build it
Ai extraction	No	Session summaries	No	Yes	If you build it
Compaction recovery	No	Partial	No	Yes	If you build it
Cross-device sync	No	No	No	Yes	If you build it
Works offline	Yes	Yes	Yes	No	Varies
RAM usage	None	Significant	Moderate	None	Varies
Memory capacity	200 lines	Unlimited (local disk)	Unlimited (local disk)	1,000 free / 50K enterprise	Unlimited
Project scoping	Per-directory	Per-project	Tags	Git remote + global	If you build it
Cost	Free	Free	Free	Free / $14.99+	Your time

My Recommendation

There's no universally "best" option. It depends on what you value:

"I don't want to install anything." → Stick with CLAUDE.md. Maximize those 200 lines. Use .claude/rules/*.md for topic-scoped instructions.
"I want the most proven solution." → Local vector database solutions. Huge community, active development. Accept the resource trade-off.
"I want zero maintenance." → CogmemAi. One command, nothing local to break, memories follow you across machines.
"I need knowledge graphs." → Other MCP memory servers, but test the current version first.
"I have specific requirements." → Roll your own. Start with SQLite + FTS5 and add complexity as needed.

The worst option is no memory at all. If you're still re-explaining your architecture every session, pick any solution from this list and set it up today. The 5–15 minutes of setup will save you hours every week.

I'm Scott, a network and systems engineer with 30+ years in the industry. I built CogmemAi after testing every approach on this list and wanting something with zero local infrastructure. Try whichever fits your workflow — the important thing is to stop losing context.

I Gave Claude Code Permanent Memory — Here's What Changed

Scott Crawford — Tue, 24 Feb 2026 21:16:15 +0000

I've been using Claude Code daily for months. I build with it, debug with it, architect with it. It's genuinely brilliant at writing code.

But every morning, the same ritual: open a new session, wait for Claude to ask what framework I'm using, re-explain my database prefix, re-state that I use Haiku for casual chat and Sonnet for complex reasoning, re-describe the file structure I've explained fifty times before.

After one particularly frustrating session where Claude got my database prefix wrong for the fourth time that week — it's a custom prefix, not the default, and that matters — I decided to fix it.

I built a persistent memory system for Claude Code. I've been using it in production for weeks now. Here's what actually changed.

The Before: Death by a Thousand Re-explanations

My project is a WordPress plugin with about 20 core PHP classes, a React-ish frontend, multiple Ai model integrations, Stripe billing, and five distinct product lines sharing one codebase. It's not a toy project.

Before persistent memory, every Claude Code session started something like this:

Me: Fix the billing bug in the subscription handler.

Claude: I'll look at the codebase. What billing system are you using?

Me: Stripe. The handler is in class-stripe.php.

Claude: Got it. Let me read that file... I see references to
different subscription tiers. Can you explain the tier structure?

Me: [sighs, pastes the tier table for the 30th time]

Context compaction made it worse. I'd be deep in a debugging session, Claude would auto-compact, and suddenly it forgot which files we were looking at. I'd have to re-establish the entire mental model we'd built together over the last hour.

The built-in MEMORY.md helped a little, but 200 lines isn't enough for a complex project. And after compaction, Claude would sometimes ignore it entirely — a well-documented bug that Anthropic still hasn't fully fixed.

I estimated I was spending 15–20 minutes per session just re-establishing context. Multiply that by 5–8 sessions a day, and I was losing over an hour daily to Claude's amnesia.

What I Built

I built CogmemAi — a cloud-based MCP server that gives Claude Code persistent memory with semantic search. The core idea is simple:

Extract — Ai analyzes conversations and identifies facts worth remembering (architecture decisions, bug fixes, preferences, patterns)
Store — Each memory gets a semantic embedding for meaning-based retrieval, an importance score, and project scoping
Surface — At the start of every session, the most relevant memories load automatically based on meaning, importance, and recency

The MCP server itself is a thin HTTP client — no local databases, no vector stores eating RAM, no Docker containers. All the heavy lifting happens server-side. Setup is one command:

npx cogmemai-mcp setup

That installs the server, configures Claude Code, and enables automatic compaction recovery. The whole thing takes about 30 seconds.

The After: Claude Just Knows

The difference was immediate. Here's what a session looks like now.

I type claude in my terminal. CogmemAi loads my project context — the top memories ranked by importance and relevance. Claude sees things like:

The live database uses a custom prefix, not the default wp_
Which Ai model to use for different interaction types — casual vs. complex reasoning
Changes to one subsystem must be mirrored in the parallel system (they share logic)
Specific CSS override patterns that require special selectors
Which encryption wrapper functions to use instead of raw library calls

I don't type any of this. I don't paste a cheat sheet. Claude just knows my project because it remembers the last hundred sessions of working on it together.

When I say "fix the billing bug," Claude already knows we use Stripe, already knows the tier structure, already knows which file to look at. We skip straight to the actual work.

The Compaction Recovery Moment

The real "wow" moment came the first time auto-compaction fired with compaction recovery active.

I was deep in a session — we'd been working on a complex feature for over an hour, context was filling up. Claude auto-compacted. Normally, that's where the pain starts.

Instead, this happened: context was automatically preserved before compaction and seamlessly restored afterward, including my project context plus a summary of the current session.

Claude's next response started with a summary of what we'd been working on and continued right where we left off. No "can you remind me what we were doing?" No lost context. It just worked.

That was the moment I knew this was a game-changer.

What I Didn't Expect

Some things surprised me about having persistent memory:

Compound knowledge. Over days and weeks, Claude's understanding of my project gets deeper. Early memories captured the basics — file structure, tech stack, naming conventions. Later memories captured subtler patterns — which functions are fragile, which CSS selectors need special handling, which API endpoints have rate limits. The accumulated context makes Claude dramatically better at making good decisions without being told.

Bug fix history. When a similar bug shows up, Claude can recall the previous fix. "We fixed a similar issue in class-tasks.php last week — the problem was the recurring task auto-advance logic." That's not something MEMORY.md could capture in 200 lines.

Cross-machine continuity. I work from two machines. Before, each one had its own disconnected MEMORY.md. Now, memories are in the cloud — I pick up on my laptop exactly where I left off on my desktop. Same context, same accumulated knowledge.

The "it remembered" dopamine hit. There's something genuinely satisfying about starting a new session and having Claude reference a decision you made three days ago without being prompted. It feels like working with someone who actually pays attention.

What It Doesn't Do

I want to be honest about the limitations:

It's not magic. Claude still makes mistakes. Memory gives it better context, but it can still hallucinate or make wrong architectural choices. You still need to review everything.
It needs network. The memory system is cloud-based. No internet, no memories. If you need offline-first, a local vector database solution may be a better fit.
Initial population takes time. The first few sessions, Claude is still learning your project. After a week of active use, the memory becomes genuinely useful. After two weeks, it's indispensable.

By the Numbers

After several weeks of daily use on a complex, multi-product codebase:

200+ memories accumulated across architecture decisions, bug fixes, patterns, preferences, and session summaries
~15 minutes saved per session in re-explanation time
5–8 sessions per day = roughly 1–2 hours saved daily
Zero RAM issues — nothing running locally except a thin HTTP client
Zero crashes — there's nothing local to crash

The time savings alone justify it. But the real value is qualitative — Claude makes better decisions because it has context. It suggests the right patterns because it's seen my patterns. It avoids mistakes because it remembers the last time we hit that wall.

Should You Try It?

If you use Claude Code for serious development — not one-off scripts, but real projects with architecture, conventions, and accumulated decisions — persistent memory changes the experience fundamentally.

Whether you use CogmemAi, a local vector database solution, or a hand-rolled approach doesn't matter as much as the principle: stop letting your Ai assistant forget everything every session.

The technology exists. The tools are available. The only question is whether you're willing to spend 60 seconds setting one up to save hours every week.

CogmemAi has a free tier with 1,000 memories — enough to see whether persistent memory changes your workflow. Setup is one command: npx cogmemai-mcp setup

I'm Scott, a network and systems engineer with 30+ years in the industry. I built CogmemAi because I couldn't stand re-explaining my codebase every morning. If you try it, I'd love to hear how it goes.