Origin

Reverie started as a coping mechanism for a horrible memory. Mine.

A coworker would send me a CURL command. Something with a dozen headers, a few query params, an auth token, and a JSON body that varied by environment. I'd save it in Notes.app or a scratch file somewhere, and within a week I'd have lost track of where. Finding it meant rummaging through six unrelated documents. Running it meant copy-paste, edit, copy-paste, swear, try again.

So I wrote a bash script. It saved strings to dot-notation paths in a JSON file, retrieved them by key, and copied them to the clipboard. I called it ccli. It was the kind of thing that took a Saturday and never came up again.

Except it did. I kept adding to it. Aliases for paths I used constantly. Inline editing in $EDITOR. Tree visualization. Encryption for things I shouldn't have been saving in plaintext. A command runner so I could do ccli run paths.deploy instead of ccli get paths.deploy | sh. Each addition was small. Each one I actually used.

The bash version held together until it didn't. I rewrote it in TypeScript with Node.js, and the tool went somewhere new. Search across keys and values. Interpolation so stored commands could reference other stored values. Real composition. The thing that had been a personal cheat sheet became something with shape.

I called this version CodexCLI.

Then AI coding came crashing in, and the ground shifted under the tool. I'd been writing CodexCLI as a memory aid for me. But every AI session had a memory problem too, a worse one. The agent started from zero every time. It read the README, opened files, asked questions, made a small change, the session ended. Whatever it had learned about the codebase along the way vanished. The next session asked the same questions.

I added an MCP server. The change to the codebase was almost trivial. The change to what the tool was for wasn't.

CodexCLI stopped being about me remembering things. It became about agents writing things down. The same dot-notation store; a different center of gravity. The session-amnesia problem turned out to be exactly the shape the tool already had: persistent key-value knowledge that any process could read or write, scoped per-project, committed to your repo. The MCP server just made it speakable by anything that spoke MCP.

At that point the tool had outgrown its own name. CodexCLI was accurate but flat. I called the new thing Reverie.

The bicameral idea

The tagline is "bicameral memory for AI-assisted development," a borrowing from Julian Jaynes that I picked carefully and then stopped using metaphorically. Bicameral here means the agent has one voice (its working context, ephemeral) and the project has another voice (the persistent knowledge base), and the second voice is what the agent reads at session start. The name makes the goal legible: not a database, but a memory the project can speak back from.

Measuring whether it works

A bicameral framing is easy to articulate. Whether it actually saves anything is the harder question.

Reverie tracks this directly. The audit log records every read and write with before/after diffs and per-agent identity. Telemetry tracks bootstrap rate, hit/miss rate by namespace, and per-tool usage. rvr stats surfaces all of it, including self-calibrating exploration cost estimates: what those tokens would have been spent on if the agent had to rediscover the answer.

The honest version of this story is that the numbers vary wildly by project. A green-field repo with three entries in .reverie/ isn't saving much. A mature repo with a populated arch.*, conventions.*, and context.* saves thousands of tokens per session and trends upward as the store fills. Dogfooding gave the clearest signal. Reverie has found and fixed several of its own bugs through its own MCP tools, with the audit log showing exactly which session learned what.

The rest of the writing-down lives in the notes.