I’ve tried a few solutions. But vector databases are overkill for what should be a simple problem. And Docker-based memory stacks add complexity when all I want is my agent to remember the bug I fixed at 4 PM.

And then Victor Taelin — the creator of HVM and Bend — dropped a 426-token Python script called OptMem. 837 GitHub stars in four days told me I wasn’t the only one interested.

The short version: OptMem is a single Python script that gives your AI agent permanent, append-only memory. No database. No Docker. No npm install. Paste one block into your AGENTS.md and your agent remembers everything across sessions, model swaps, and even vendor changes. I tested it for a full day across three real debugging sessions. Here’s what happened.

What Makes OptMem Different

The idea is deceptively simple. Here’s the workflow: every time your agent finishes a thought, you run memo note "fixed race condition in scheduler.py". So that line goes into an append-only flat file. And next session, memo wake prints the most important memories back into the agent’s context. That’s it.

And the 426-token cost is what caught my eye. Most memory solutions eat up context budget before the agent can do useful work. But OptMem’s prompt is shorter than a tweet — and it only loads what’s needed, not the full history.

Setting Up OptMem in Under 60 Seconds

I ran this on a Ryzen 9 workstation with Ubuntu 24.04, but the install doesn’t care about your OS:

curl -fsSL https://raw.githubusercontent.com/VictorTaelin/OptMem/main/install.sh | sh

The script printed a block of text. So I copied it to the top of my CLAUDE.md:

## Memory

Use `memo` commands to persist context across sessions:

- `memo wake` — print most important memories
- `memo note "..."` — record a decision or finding
- `memo recall <regex>` — search all past memories
- `memo nap` — auto-compress memory tree

Subagents must NOT write memory directly — they return findings to the main agent.

Total time from zero to remembering: about 40 seconds.

Three Real Debugging Sessions

So I deliberately picked a nasty problem — a data pipeline I maintain that keeps producing duplicate records when two ETL workers run concurrently. It’s exactly the kind of multi-session bug that punishes agents with no memory.

Session 1 — Discovery. So I loaded up Claude Code with OptMem. And first thing: memo wake printed nothing — fresh memory. So I described the bug, had Claude trace through the pipeline code, and it identified a race condition in the dedup logic. After that I ran memo note "root cause identified — dedup step at line 87 in pipeline.py runs before both workers finish. Need a write lock."

Session 2 — Attempted fix. I started a new claude session. memo wake showed me Session 1’s finding immediately — no re-explaining needed. So Claude suggested a threading.Lock approach. I implemented it, then ran a test. Still getting duplicates — the lock wasn’t scoped right. So I ran memo note "threading.Lock approach failed — independent processes, not threads. Need file-level locking."

Session 3 — The fix. memo wake printed both previous findings. I told Claude: “Read both memories, then design the fix.” It pulled in a file-level flock() pattern within minutes. And I tested it — zero duplicates across 50 parallel runs. So I ran memo note "fixed with fcntl.flock() on the dedup temp file. 50/50 clean runs. Closing this bug."

After 50 memo commands, I checked the memory file:

wc -l ~/.optmem/memory/LOG.txt
# 50 lines, 2.1 KB

memo wake
# returned in 0.03 seconds

Still, the flat-file approach scales better than I expected. The brief estimates a million memories at 608 MB on disk with the same 0.03s access time due to fixed-width record design.

Where OptMem Could Improve

Honest feedback after a day of use:

• The merge tree is confusing. memo nap auto-compresses, but the tree structure is hard to visualize. I found myself running memo recall more often than memo nap because I couldn’t predict what would survive compression.

• No built-in team sync. If you’re working solo, the local flat file is fine. But teams need git-synced memory — and that means a VPS. I’d love to see an memo sync command in a future update.

• Very new. Four days old as of this writing. The core works, but the ecosystem (IDE plugins, CI integrations, subagent rules for Codex) isn’t there yet. Even so, Victor Taelin’s community reach means it’ll grow fast. Full disclosure: it’s still early days.

The Team Memory Pitch — Why You Might Want a VPS

If you share codebases with teammates, local memory only goes so far. Here’s the setup I’m moving toward: spin up a $6/month droplet on DigitalOcean (affiliate link), init a bare git repo in ~/.optmem/memory/, and have each developer’s machine run a cron job that git pushes after every memo note. Now the whole team’s agents share context — fix a bug on your machine, your colleague’s agent sees the finding next session.

That deployment angle is the only place I’d recommend going beyond the local install. Honestly, the single-user workflow is already solid.

Benchmark: Performance at Scale

Who Should Use This

• Solo developers using Claude Code, Codex, or Cursor — You’re the primary audience. One install, paste one block, and your agent starts remembering today.
• Small teams with shared codebases — If you’re already using git, OptMem’s flat file syncs naturally with a git remote on a cheap VPS.
• Anyone tired of re-explaining project context — If you’ve ever typed “remember, we’re using FastAPI with SQLAlchemy” more than once in the same week, this is for you.

Skip it if: you need a managed memory service with a UI, your team has strict compliance requirements around agent memory, or you prefer a fully Docker-ized stack with persistent storage guarantees.

The Bottom Line

Look, OptMem is one of the simplest solutions I’ve seen to a problem that’s been over-engineered by everyone else. 426 tokens, one Python script, thirty seconds to install. Your agent forgets nothing. Your context budget barely notices.

And I’ve already added it to my daily workflow. Three debugging sessions showed me what happens when your agent carries context across days instead of per-session — you stop repeating yourself and start finishing things.