Anthropic now ships at least three different memory models inside the Claude product family, and they don't behave the same way. Claude.ai has a chat memory feature for Pro, Max, Team, and Enterprise users that summarizes prior conversations and injects that summary into new chats. Claude Code has CLAUDE.md files plus a separate "auto memory" directory the model writes to itself, both loaded at session start. The API ships a memory_20250818 tool that hands a /memories directory to your application code so you can persist anything you want between turns. Three surfaces, three rule sets, three retention postures.

I argued last week on this blog that the model isn't the variable that matters — the wrapper around it is. This is the next claim down the chain: if memory is a feature of that wrapper rather than the model, then vendor fragmentation is a memory problem you cannot solve by picking a surface. Stop trying.

What's actually different across the three

The chat surface remembers conversations as a 24-hour synthesis, project-scoped, controllable through a settings panel. The Code surface uses plain markdown files in your repo plus a per-project memory directory at ~/.claude/projects/<project>/memory/ on the local machine. The API tool defines six file operations (view, create, str_replace, insert, delete, rename) and expects your application to implement the storage. None of these are wrong. They are designed for different jobs. But they share zero common format, no export path between them, and no way to carry context from a Claude.ai chat into a Claude Code session into an API agent without doing the plumbing by hand.

Birgitta Böckeler's writeup on context engineering for coding agents frames the wrapper as everything in an AI agent except the model itself: the tool definitions, the context compaction, the feedback sensors, the system prompt, the memory between sessions. Anthropic's own engineering team calls the same idea context engineering — the work of curating what enters the model's attention budget at each step. Memory sits squarely inside that definition. Which means the choice about where memory lives is a wrapper decision, and the vendor is making it for you on each surface until you take it back.

The trap

The natural reaction when a vendor ships three memory models is to figure out which one to use. Spend an afternoon reading docs, decide that the chat synthesis is for ad hoc queries, the auto memory is for coding work, and the API tool is for production agents. Move on.

That reaction is wrong, and not because any of those choices are bad in isolation. It's wrong because it assumes vendor surfaces are stable. They aren't. Claude.ai's memory was Team-and-Enterprise-only at launch in September 2025, then expanded to Pro and Max in October. Claude Code's auto memory requires v2.1.59 or later and lives in a path tied to the git repo, not the user. The API memory tool is in beta under a header that already changed naming conventions twice. The vendor will keep shipping, the rules will keep shifting, and your context will keep being a second-class object inside someone else's roadmap.

There's also a deeper problem. MindStudio's writeup on behavioral lock-in makes the case that agent memory creates switching costs that data portability rules cannot fix. For example, even if a vendor lets you export your memory directory tomorrow, the operational understanding the agent built — your team's terminology, your exceptions, your shorthand — does not round-trip cleanly into another vendor's surface. Eight months of accumulated context turns into a re-onboarding tax the moment you switch. Parallels' 2026 cloud survey put vendor lock-in concern at 94% across 540 IT leaders; agent memory is exactly the layer where that concern compounds.

What I do instead

My memory lives in a NAS-backed directory called nexus/, in plain markdown, under git. It has a top-level CLAUDE.md that gets auto-loaded into every Claude Code session because it sits at the project root. It has a MEMORY.md for long-term curated state, a SESSION-STATE.md for active context, per-domain context files at agents/<domain>-context.md for finance, health, content, and so on, and daily logs at memory/YYYY-MM-DD.md. Cross-references between entities use [[double brackets]] so they're grep-searchable and Obsidian-renderable. Search across the corpus runs through an Ollama embedding pipeline using nomic-embed-text at 768 dimensions, indexed locally — no vendor API call required to ask "what did I decide about that account fee in February?"

This stack does three things the vendor surfaces cannot.

First, it survives the surface split. The same files load into Claude Code, can be pasted into Claude.ai, and can be served to an API agent through the memory tool's file ops. The format is universal because the format is just files.

Second, it survives the vendor switch. If I move to a different model provider tomorrow, the markdown still parses, the embeddings still resolve, and the wikilinks still work. There is no proprietary memory schema to migrate.

Third, it gives me audit. I can grep my own context. I can diff what changed last week. I can trash something I don't want anymore and recover it if I was wrong. None of those operations exist on the chat memory surface, and they only partially exist on the auto-memory surface.

The general pattern

The vendor's wrapper is not your wrapper. It's theirs, designed around their product roadmap and their retention model and their billing surfaces. When that wrapper includes a memory layer, putting your context in it means putting your operational knowledge in someone else's container. Fine for ephemeral chat. Not fine for the accumulated state of a year of work.

The fix is not to pick the right vendor surface. The fix is to keep your memory outside any vendor surface, in a format you own, with search you control, and let the vendor surfaces read from it as needed. Claude Code already does this for free with CLAUDE.md. The other surfaces will eventually catch up, or they won't, and either way your context survives.

Last week's post argued that the wrapper around the model is what matters. This one finishes the sentence: don't trust theirs with your context.