aiGalen Guan

OptMem: 426 Tokens of AI Memory — A Case Study in Radical Simplification

OptMem: 426 Tokens of AI Memory — A Case Study in Radical Simplification

AI agent memory is undergoing a quiet revolution. For the past two years, the dominant approach has been vector databases + embedding models + RAG pipelines — heavy, slow, and vendor-locked. On July 25, 2026, a project called OptMem appeared on GitHub, hit 289 stars in two days, using only a 426-token system prompt + one zero-dependency Python file.

Its author is Victor Taelin — creator of HVM (Higher-Order Virtual Machine) and the Kind programming language. Someone known for radical minimalism in systems design, turning his attention to agent memory. The result is as uncompromising as expected.

1. What OptMem Is: Six Commands, One File

OptMem's core is a single Python script (memo) with only standard-library dependencies. Installation:

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

It prints a 426-token ## Memory block. Paste it at the top of your agent's AGENTS.md. Done. Six commands:

Command Purpose When
memo wake Read compressed memory context First command, every session
memo note "..." Record a memory (≤280 chars) Agent learns or something worth keeping happens
memo nap Run pending compression merges When note says "time to nap"
memo recall <regex> Regex-search all raw memories Need to find something old
memo zoom <lo>-<hi> Expand a compressed block Need details in an old summary
memo forget <lo>-<hi> Drop a bad summary; nap rebuilds Compression quality degraded

No background processes. No vectorization. No embedding model. The agent only runs nap when note explicitly prompts it.

2. Core Design: Fixed-Width × Binary-Tree Compression

OptMem's philosophy can be summarized in one phrase: position is identity.

Memory Architecture Comparison

Fixed-Width Records: O(1) Addressing

Each memory → fixed 320 bytes → physical offset = logical ID

No B-trees. No inverted indexes. No hash tables. To read memory N, seek to N × 320 bytes. One million memories (608 MB), wake takes 0.03 seconds.

The constraint: each memory ≤ 280 characters (~70–140 words). Not enough for complex narratives, but perfect for "decisions / facts / lessons / preferences" — which is exactly what agents most need to remember.

Binary-Tree Compression: Older Gets Coarser

Memories are not equally weighted. Yesterday's conversation needs verbatim preservation more than last year's. OptMem solves this with adaptive-granularity binary-tree coverage:

Recent N    → verbatim, as-is
Slightly old → 2 records merged into 1 summary line
Older       → 4→1, 8→1…
Ancient     → vast history collapsed into a single summary line

wake output is capped at WAKE_LINES lines (default 208 ≈ 16K tokens). No matter how many memories accumulate, the context budget stays constant — this is the fundamental difference from every "inject everything" approach.

recall bypasses the compression layer entirely — it regex-searches the raw LOG.txt, word for word. Ancient memories don't surface in wake often, but they can be instantly recalled by keyword.

Append-Only: Indestructible

LOG.txt is append-only, never modified in-place. This is an event-sourcing pattern — every note is an immutable event, the compression tree is pure cache, and a deleted tree is fully rebuildable from the log. No corruption risk. No migration lock-in.

3. Three-Way Comparison: OptMem vs Hermes vs nanobot

Three representative memory philosophies exist in the AI agent ecosystem today:

Dimension OptMem Hermes Memory nanobot Dream
Philosophy Minimal tool: memory as file format Integrated system: memory as framework feature Async cycle: memory as background task
Storage Fixed-width append-only text Semantic files (MEMORY.md + USER.md) MEMORY.md + history.jsonl
Retrieval Regex full-text search FTS5 semantic search Full-text context injection
Compression Deterministic binary-tree merge Session compaction summaries Dream periodic LLM extraction
Dedup Agent self-judgment Operation-level replace/remove Dream batch dedup
Write trigger Agent calls note Event-driven (user says "remember") Time-driven (Dream cron tick)
Context mgmt Fixed token budget, adaptive granularity Session window + compaction summaries Full injection + history replay
Cross-model ✅ Fully agnostic ✅ Agnostic ✅ Agnostic
Dependencies Python stdlib Hermes runtime nanobot runtime
Migration cost Copy ~/.optmem/memory/ Export/import Copy workspace
Maturity 2 days Production-grade v0.2.x

Route 1: OptMem — "Memory as File Format"

OptMem's core insight: agent memory should be as portable as a Git repository. No framework lock-in. No platform binding. No model dependency. Switch agent frameworks — copy ~/.optmem/memory/ and you're done.

Its limitations are equally clear:

  • Regex search cannot understand semantics — recall coffee won't find "two lattes daily"
  • 280-char-per-entry is tight for complex context
  • No automatic dedup — the agent may record the same fact twice
  • Sub-agents are explicitly forbidden from writing memory

Route 2: Hermes Memory — "Memory as Framework Feature"

Hermes' memory system is deeply integrated with its runtime: dual-file model (environment vs. preferences), FTS5 semantic search, operation-level dedup, session_search cross-session retrieval. In heavy-use scenarios, this system excels — memory is not just "what was stored" but "how to find it."

The cost: leaving the Hermes ecosystem means exporting and adapting memory data. It's not a portable file format — it's a capability built into the runtime.

Route 3: nanobot Dream — "Memory as Background Task"

nanobot's Dream is an async periodic job: read accumulated conversation history on a timer, use an LLM to extract key facts, update MEMORY.md. The benefit: it never interrupts the agent's main workflow — memory updates don't consume primary session token budget.

The cost: timeliness lag. After an important conversation, critical information may not enter long-term memory until the next Dream cycle. If Hermes is "instant write" and OptMem is "on-demand write," Dream is "delayed write."

4. Why OptMem Matters: The Unix Philosophy of AI Memory

OptMem's importance isn't the technical implementation — it's the design attitude.

Current AI memory solutions have fallen into "framework-ization" — to use memory, you must use the entire agent framework. Vector databases, embedding models, RAG pipelines, token budget management — every piece is a heavyweight dependency that needs rebuilding on every platform switch.

OptMem returns to the Unix philosophy: do one thing, do it well. One file. Six commands. Zero dependencies. Memory becomes a portable "external brain" the agent carries with it, not something locked inside a framework.

Victor Taelin's previous best-known work is HVM (Higher-Order Virtual Machine) — a computational model that replaces Lambda Calculus with "interaction combinators." His design signature is consistently eradicating complexity rather than managing it. OptMem continues this lineage.

5. Selection Guide

Choose OptMem if you:

  • Use Claude Code / Codex CLI / Cursor — agents that aren't framework-bound
  • Value zero dependencies and portability above all
  • Memory is primarily short facts / decisions / preferences
  • Don't need semantic search

Choose Hermes Memory if you:

  • Are already a deep Hermes user with skills and cron pipelines
  • Need FTS5 semantic search and cross-session retrieval
  • Have large memory volume and need automatic dedup
  • Accept framework binding

Choose nanobot Dream if you:

  • Need async, non-interrupting memory updates
  • Run nanobot with multi-channel setup
  • Can tolerate delayed write timing

Using All Three Together

These aren't mutually exclusive. OptMem can serve as an "external memory layer" for any agent, while Hermes / nanobot native memory handles their respective deep scenarios. Use OptMem for "my common git aliases," use Hermes FTS5 for "that Redis discussion three weeks ago."

Conclusion

OptMem is the most radical simplification in AI agent memory systems in 2026. It asks a fundamental question the industry has overlooked: does memory have to be bound to a framework?

426-token prompt + one Python file = a portable agent external brain. The simplicity of this formula is itself a manifesto: AI infrastructure doesn't need to get heavier. Sometimes, subtraction is harder — and more valuable — than addition.

Our take: OptMem won't replace Hermes Memory or nanobot Dream — they solve different layers of the problem. But the "memory as file" philosophy OptMem represents may outlast its current functionality in shaping agent design. The best tool is the one you can walk away with, unlocked.

References

  1. VictorTaelin/OptMem GitHub Repository — 289 stars, created 2026-07-25
  2. OptMem README — Full documentation
  3. Victor Taelin's HVM Project — Higher-Order Virtual Machine
  4. Hermes Agent Memory System
  5. nanobot Architecture Docs — Dream memory mechanism