Neonmem Workspace
A memory-based agentic IDE.
Neonmem Workspace uses neonmem cartridges to enhance the Claude Code experience, adding capabilities that help the agent make decisions based on a prism of experience held in the cartridge.
It is for any type of development — traditional, agentic, or vibe coding — and extends each of these approaches.
The Neonmem cartridge
A single-file, multi-layer memory store with built-in vector storage.
A cartridge holds a project's experience as a typed graph. It is little-endian, page-aligned, and begins with a 64-byte header; the sections below carry the memory itself.
Nodes
Fixed-size records. Each holds a type — observation, question, hypothesis, conclusion, resolution, rule, dead-end, plan, procedure — with a confidence and relevance score, timestamps, an edge count, and an index into the vector store.
Edges
Typed, directed relationships between nodes: led-to, blocked-by, supports, contradicts, part-of. A node stores its first edges inline, with an overflow table for high-degree nodes.
Vectors
One embedding per node, int8-quantized with a per-vector scale (v = q·scale). The vectors are L2-normalized, so cosine similarity is a dot product. Recall is exact, over the vectors in the cartridge.
Integrity
Node text is stored in an LZ4-compressed string table; a footer carries a per-section CRC32 and a content hash. The vectors are part of the file — there is no external database.
Layers
- reflexRules and invariants that always apply.
- short-termThe decisions and observations of the current effort.
- long-termKnowledge retained across sessions.
PRISM — reasoning through the graph
Recall answers what is stored; PRISM reasons over how the stored items relate. It is based on Hopfield/Ising energy-based associative memory. For a query, anchor nodes are found by cosine similarity and their neighborhood is expanded into a subgraph. The subgraph is treated as a network of units: its edges define a coupling matrix J — supporting edges attract, contradicting and blocking edges repel — and node types define a field bias h. The unit states relax by
until they settle into a low-energy configuration. That configuration is read out as attractors — the answer — repelled regions — dead-ends to avoid — and active constraints — the rules that apply.
Embeddings
Text is embedded with the IBM Granite-30M model. A string is tokenized, passed through one forward pass, and the last hidden state at the CLS position is L2-normalized to a 384-dimensional unit vector. The same model runs at write and read time.
Capture
What a turn of work adds is scored by an energy-like salience — σ(β·L)·L — combining novelty, node-type weight, and the relief of resolving an open thread. Items above a write threshold are kept; a plan is a forward-looking commitment and is kept even when it relates to existing memory.
Developer journey — Labyrinth
Building a maze game, one decision at a time.
You build a small terminal game — The Labyrinth — by talking through it with the agent, one decision at a time. You do not ask it to remember anything. As you frame the project, argue a design, hit a wall, and set a rule, the memory forms on its own: each turn is classified and written to the cartridge as a typed node. By the end, the whole reasoning trail is there to recall and reason through.
Act 1 — Frame the project
- Context
A single-file terminal game in Python: rooms connected by exits, the player looks for the way out.
- Observation
Each room has a name, a description, and exits — north, south, east, west.
- Question
Should rooms be plain dictionaries or proper classes?
Act 2 — A design debate
- Hypothesis
A dict of room-name → exits is the simplest thing that could work.
- Debate
A hand-crafted fixed maze versus a procedurally generated one.
- Argument
For procedural: infinite replayability. Against: harder to make it feel designed, and harder to test.
- Resolution
Hand-crafted maze for v1 — testable and tunable. Procedural can come later.
Act 3 — Build it, and hit a wall
- Action
Implement a parser that reads "go north" and moves the player — the first version of labyrinth.py.
- Conclusion
The dict-of-rooms approach is clean and easy to extend — the call held up.
- Dead-end
Keeping player position and room state in module-level globals caused state bugs across functions. Do not.
- Rule
Keep the whole game state in one dict, passed around explicitly — never module globals.
Act 4 — Instant knowing
- Procedure
Add a room: (1) add it to the rooms dict, (2) wire its exits both ways, (3) add a test that it is reachable from start, (4) run pytest.
- Reflex
A standing principle: single-file, zero dependencies, runs on plain Python 3.
Act 5 — Lean on the memory
- Recall
"Why did we go with a hand-crafted maze again?" — answered from memory: testability and feel.
- Warns
"Is it okay to keep game state in globals?" — it warns you: that is a recorded dead-end, and why.
- Timeline
"What did we decide today?" — the day's decisions, in order, not a guess.
- Rule
"What's our rule about dependencies?" — the single-file, zero-deps reflex.
Act 6 — Ingest, then let it sleep
- Ingest
Hand it a spec and a source file: endpoints, config values, and code structure — classes, methods, and a call graph — become connected nodes. The filler prose is skipped.
- Consolidate
A consolidation pass merges near-duplicates and dims low-value chatter; the dead-end and the rules stay put. Reopen tomorrow — the decisions are still front and centre.
Thirteen memory types formed while you worked — reflex and rules at the core, working notes and decisions around them — with nothing to remember by hand.
Download
Neonmem Workspace for Windows.
Two ways to run it, both carrying the editor, the memory engine, and the embedding model. The installer sets it up on your PC; the portable build unzips and runs from a folder — nothing added to your system, keep it on a drive and take it with you.