Eight coding-agent memory systems, four deciding axes, and an honest build-vs-adopt verdict. The short version: the tools that need no second API key tend to hoard noise; the ones that curate well make you run a server and pay a second provider; and none capture corrections, tests, git events or skill upgrades as typed signals. reflect is the row that holds all four — so we ported the good retrieval ideas and built the thin layer nobody else does.
Every coding harness gives you exactly one persistent-memory primitive: a static
instructions file you maintain by hand — CLAUDE.md, AGENTS.md,
MEMORY.md, copilot-instructions.md — front-loaded into the context
window at the start of every session.
That has a hard ceiling. The window is finite and shared with the actual task. Every line you front-load "just in case" is bloat the moment this session doesn't need it, and it crowds out the files, diffs and reasoning the task does need. A bigger instructions file is the wrong axis.
The real questions are temporal and selective: a correction you made three weeks ago should reach the agent only in the session about to repeat the mistake; the architecture reason behind a non-obvious choice should surface when someone questions that code and stay invisible otherwise. That's a retrieval problem — store the signal-bearing moments and query the right one at the right time. It's why a class of "agent memory" products exists. This paper compares them and explains why we built rather than adopted.
Weighted to a coding-agent self-improvement workflow — the priority is capturing corrections and turning them into behaviour, cheaply, without standing up infrastructure. Each criterion scores 1–5; weighted total out of 5.0. (Re-weighting changes the order — see the sensitivity note in §09.)
Each scored on the four most decisive criteria (signal capture · no-extra-key · local-first · retrieval). Weighted total uses all six.
Darker green = stronger fit, rust = weak. The clay outline marks the best cell in each row. Bottom row is the weighted total under §02's coding-agent weights.
| reflect | Hindsight | claude-mem | ByteRover | Mem0 | agentmem | Honcho | OpenViking | |
|---|---|---|---|---|---|---|---|---|
| Signal capture (0.25) | 5 | 2 | 2 | 2 | 2 | 2 | 1 | 2 |
| No extra key (0.22) | 5 | 2 | 5 | 3 | 2 | 3 | 2 | 2 |
| Local-first (0.20) | 5 | 3 | 3 | 4 | 2 | 2 | 2 | 2 |
| Selective / noise (0.16) | 4 | 4 | 2 | 4 | 3 | 1 | 2 | 4 |
| Retrieval quality (0.12) | 4 | 5 | 3 | 3 | 4 | 3 | 4 | 4 |
| License / portability (0.05) | 5 | 5 | 4 | 2 | 4 | 4 | 2 | 2 |
| Weighted total | 4.72 | 3.03 | 3.08 | 3.06 | 2.50 | 2.28 | 1.99 | 2.56 |
The pattern reads straight off the matrix: the only other system that matches reflect on no extra key (claude-mem) collapses on selective/noise; the systems that curate well (Hindsight, OpenViking, ByteRover) lose on no extra key or local-first; and signal capture is a wall of 2s — nobody else treats corrections, tests, git or skills as typed events.
Two diagrams: where reflect operates across a single session, and where it stores what it captures (local by default, optional shared Postgres).
Memory looks cheap if you only price retrieval. The real cost is the write side (LLM extraction / consolidation) plus the read side (context injection). Here's where each system spends.
| System | Write side (capture/extract) | Read side (recall) | Net extra spend |
|---|---|---|---|
| reflect | reuses harness LLM (claude -p), gated + queued; local embed | local — vector + BM25 + graph, no LLM | $0 extra (rides your existing sub) |
| claude-mem | Haiku on your Claude auth, per tool-call batch | FTS5 + local ONNX vectors | $0 extra, but high write volume |
| Hindsight | retain = LLM extraction; cloud $15/M tokens | vector/graph (no LLM); reflect synthesis costs | separate key or $15/M retain |
| Mem0 | OpenAI extraction at ingest (ADD/UPDATE/DELETE) | vector/BM25; graph = Pro $249/mo | separate OpenAI key + tier |
| OpenViking | VLM extraction + L0/L1 summaries at commit | vector recursive (no LLM) | separate provider key |
| Honcho | deriver LLM ("dreaming") per message batch | context() free; dialectic up to $0.50/query | 1–3 keys (self-host) or per-query |
| agentmemory | optional LLM compression (off by default) | local embed; triple-stream RRF | $0 if LLM off — but value degrades |
| ByteRover | curation = own LLM calls (your key or credits) | BM25 → LLM fallback | own key tokens or Pro $19/mo |
Auto-retain every turn + large auto-recall is how memory tools quietly burn a subscription — agentmemory has documented incidents of exhausting a Claude Pro quota in a handful of messages. reflect's capture is gated and queued (not every turn), and recall is OOD-gated + token-budgeted — it injects nothing when nothing fits, rather than paying to surface the least-bad note.
When the memory is wrong, can you see it, edit it, delete it, and trace where it came from? This is where "the store is dumb and human-readable" pays off.
~/.claude/global-learnings — open, edit, or delete a note like any file.:37777, but observations are DB rows, not files.This is the wedge. In every other system, a correction is — at best — a sentence in a transcript that an extraction LLM might turn into a fact. Hindsight literally files the case of capturing a skill update as a bug. There is no mechanism that says "the user said stop doing X → make that a rule the agent follows next time."
reflect routes that path as typed signals at hook time — SG1–SG8:
cross-turn contradiction, git commit/revert (a revert demotes the learnings it produced),
test pass/fail, tool-loop, permission reply, idle sweep, negative-recall gaps — and then
auto-refreshes the skills those learnings affect (R13/R14).
A correction isn't hoping to be extracted from prose; it's captured as a structured event and can
revise a belief or promote a skill deterministically.
Everyone else remembers what was said. reflect captures what changed — and turns it into the next session's behaviour.
Adopt an external memory provider only if it (a) needs no second API key or subscription, (b) runs without a mandatory always-on server, and (c) captures coding signals as typed events. No single external tool clears all three. So: build the thin, differentiated layer (capture + typed signals + local-first), and port — don't re-invent forever — the commodity retrieval, keeping it behind a seam so a stronger backend can be swapped in later.
Verdict: build + port, with eyes open (CAUTION). reflect ported Hindsight's retrieval ideas (graph-expansion arm, RRF fusion, cross-encoder rerank, temporal arm) across a 57-port effort — so it has the retrieval brains without the infra/LLM/ToS baggage, at the cost of owning that code.
Honest sensitivity note. These weights favour self-improvement and zero-friction operation — reflect's strengths. Re-weight toward pure retrieval quality and ecosystem maturity and Hindsight wins: it's MIT, production-grade, benchmarked at 94.6% LongMemEval, with ~48 integrations and 62 releases. If your priority is "best recall, least code I maintain," adopting Hindsight (as a retrieval backend) is the smarter call. The build case rests entirely on valuing no-extra-key capture and typed signals — which is why we keep retrieval swappable rather than sacred.
Before swapping in any external tool, run these. They encode the four axes as pass/fail checks.
Install on a fresh machine with only the coding agent's existing auth. Does memory capture + recall work with no new API key or account?
reflect / claude-mem: pass · most others: failReboot. Does memory work with nothing running in the background — no daemon, no Postgres, no vector DB to babysit?
reflect: pass · daemon-based tools: failCorrect the agent once ("stop bumping the proto without regen"). Next session, does the rule resurface without manual curation?
the typed-signal test — reflect's wedgeRun daily for a month. Is recall still sharp, or flooded with stale / duplicate / fire-hosed entries? Check for a real prune/forget mechanism.
fire-hose tools degrade here