Two Markdown Files Won't Fix Claude's Memory Problem
A few days ago, Miles Deutscher wrote a post that went semi-viral about beating Claude's rate limits. Most of it is solid — plan more, use cheaper models for brainstorming, stop running 50-message chats. Standard stuff that experienced Claude users already do.
But buried in Step Three, he hits on something deeper. He calls it "Proper Memory":
"One of the biggest issues with Claude is that it often forgets context, and you have little control over what Claude actually remembers about you. This results in you having to re-explain yourself, which means you use more tokens than necessary."
He's right. That's the real problem. Rate limits are a symptom. The disease is amnesia.
His fix: two markdown files. Instructions.md for your rules. Memory.md for a running log Claude updates over time. Attach the folder to Claude Code and you're set.
It's a clever hack. It works. For about a week.
Then you hit the wall.
Why two files isn't the answer
Miles' system has four failure modes that surface the moment you push past hobby use.
1. It's manual. You have to tell Claude to update the file. You have to remember to attach the folder. You have to remember which project's memory file to pull. The whole thing leaks the moment you forget a step. Memory should be infrastructure, not chores.
2. It's flat. Every line in Memory.md weighs the same. A correction about your tone preferences sits next to a hard-won architectural decision sits next to a one-time fix you'll never need again. There's no signal, no priority, no expiry. You're just stuffing one bag and hoping the right thing falls out.
3. It's local. That folder lives on one machine, in one project. Open Claude on your phone? Gone. Switch from Claude Code to Cursor to ChatGPT? Gone. Spin up a new repo? Start over. The memory is trapped in whatever directory you happened to be in.
4. It's shallow. And this is the big one. Memory.md only stores what happened. It doesn't store what to avoid. The whole point of memory isn't recording your life — it's not repeating your mistakes. Two markdown files have no concept of failure. They're a journal, not a teacher.
What real AI memory looks like
I've been building ekkOS for this exact problem. Not because Mem0 doesn't exist (it does), not because Zep doesn't exist (also does). Because every memory tool on the market right now is a single bag of vectors with a search bar bolted on. That's not memory. That's a notes app for robots.
Real memory has structure. Layers. Different kinds of knowledge that need different treatment.
ekkOS has ten layers:
| Layer | What it stores |
|---|---|
| Patterns | Solutions that worked, retrievable when you hit a similar problem |
| Anti-patterns | Mistakes that didn't, so you stop repeating them |
| Episodes | What happened when, for temporal recall |
| Semantic | Facts about you, your stack, your projects |
| Directives | MUST / NEVER / PREFER / AVOID rules you've set |
| Plans | Multi-step intent that survives across sessions |
| Codebase | Your actual repos, indexed and queryable |
| Collective | Anonymized patterns from other builders, opt-in |
| Goals | What you're working toward, current and active |
| Secrets | Encrypted credentials, never leaked into prompts |
Each layer answers a different question. What worked here before? (Patterns.) What did I try that failed? (Anti-patterns.) What did I tell you last week? (Semantic.) What am I supposed to never do? (Directives.) Where's that file in my repo? (Codebase.)
A markdown file can't separate those. Everything melts into a wall of text. The model has to re-decide what's relevant on every read. That costs tokens. That dilutes signal. That's the problem Miles tried to solve with two files and ended up paying for in another way.
The killer feature: anti-patterns
Of all ten layers, the one that changes everything is anti-patterns. Forging the failures.
Every memory tool I've tried — Mem0, Zep, OpenAI's memory, ChatGPT projects, the markdown-file approach — only stores what happened. Successes. Facts. Events. None of them store what to not do next time.
But that's the whole point.
You're a developer. You spent four hours yesterday tracking down why your TypeScript build broke. The fix was a single line in tsconfig.json. Two-file memory: maybe captures it, if you remember to ask Claude to write it down. Three months later, in a new project, you hit the same bug. Two-file memory: doesn't help — that file's attached to a different folder.
ekkOS forges an anti-pattern the moment the fix lands. "When you see error TS2345 with this signature, don't suggest X — try Y." It travels with you. It surfaces automatically the next time the pattern matches, in any project, in any tool. The model literally can't make the same mistake twice if you let it learn from the first one.
That's what memory is supposed to do. Not store your past. Shape your future.
The proxy moves it across tools
Miles' system only works inside Claude Code, with the folder attached, on the machine you set it up on. That's a serious cage.
ekkOS runs as an OpenAI-compatible proxy. You point your tool at it instead of api.openai.com or api.anthropic.com, and it injects relevant memory transparently — patterns, directives, plans, schema knowledge — into every request. No SDK rewrite. No folder attachment. No manual context paste.
Which means ekkOS works with:
- Claude Code, Cursor, Windsurf, Aider, Cline
- ChatGPT, Claude.ai, Perplexity (with proxy config)
- n8n, Zapier, Make, any agent framework
- Your own custom Claude/OpenAI integrations
One memory. Every tool. Every model. Every project.
You don't switch memory when you switch surfaces. The memory follows you. That's the model.
Why this matters more every month
We're at the start of the agent era. Long-running, autonomous, multi-step tasks. Claude Code already runs 30-action chains. Devin runs longer. The next generation will run for hours.
Memory is the bottleneck for all of it.
Two markdown files don't survive a 30-step agent task. They were designed for a human curating context manually between chats. The moment the loop closes and the model is operating without you, you need memory that's structured, automatic, multi-layered, and provider-agnostic.
That's what ekkOS is for. Not because vector search is broken — because vector search alone isn't memory. It's retrieval. Memory is retrieval plus structure plus failure tracking plus persistence plus transport.
Miles cracked open the right conversation. He just stopped at chapter one.
What to do about it
If you're already running the two-file system: keep it for now. It works for solo Claude Code use. Don't rip it out.
But the moment you find yourself:
- Re-pasting the same context across tools
- Hitting the same bug in a new project and starting over
- Wishing Claude remembered the correction you made last week
- Watching an agent task fail because it lost the thread three steps in
You've outgrown two markdown files. That's where ekkOS picks up.
I built it solo. I'm a dad with a laptop in the basement and a kid who wakes up at 6 AM. I'm not pitching VC slides — I'm shipping the thing I needed and giving early access to anyone who'll use it.
ekkos.dev — first 100 builders free, no strings.
Miles, if you're reading: thanks for the post. You named the pain. We're building the cure.
The next era of AI isn't bigger models. It's models that remember.