DEV Community: Richard Harvey

Memory isn't enough. AI needs experience.

Richard Harvey — Mon, 26 Oct 2026 16:19:07 +0000

Twenty runs. The answer to the task was already sitting in <omnimem>. Across all twenty, the agent made zero memory calls of its own.

That result changed how I think about AI memory. Storage was never the hard part. An agent with perfect recall will still walk back into last week's dead end if nothing tells it the dead end matters, and nothing makes it look, and this isn’t how we (humans) use or think about memory. So my approach was to start modelling our behaviours into the recall, and there is much more to come in the future.

Every memory system can remember. <omnimem> is built to gain experience: to know what worked, what failed and what it cost, and to act on that before your agent repeats itself.

A filing cabinet doesn't get better at its job

Most AI memory is a filing cabinet. You put things in, you search, you get things out. Add more and it gets bigger and noisier: old decisions sit beside new ones with equal weight, and a workaround from six months ago ranks as high as the fix that replaced it.

An apprentice works differently. They remember what happened, and they remember how it went. The approach that took four attempts and a weird workaround sticks. The one that wasted a day becomes a note to self: don't do that again. After enough jobs, the lessons stop being memories and become habits.

That's the line between memory and experience.

	Memory	Experience
What it keeps	What happened	What happened, how it went, what it cost
Failures	Stored like anything else, or lost	Kept in a graveyard and used as warnings
Over time	Grows and gets noisier	Fades the stale, strengthens the hard-won
Conflicts	Both versions kept silently	Flagged the moment they're written
End state	A bigger pile	Rules your agent follows

How <omnimem> turns memory into experience

Six mechanisms, all in the same binary, all running on your machine.

[Diagram goes here: the experience loop, 5 stages. It lives in the online doc, so export it from there.]

Put together, it's a loop: what happens in one session shapes how the next one starts.

Experience scoring. Every memory carries an outcome and an effort rating from 1 to 5. Effort raises its weight at recall from 1.0× up to 1.8×, so the lesson that cost you a day outranks the one that cost you a minute. Recall ranks on similarity × surface × recency × experience × date, not similarity alone.

The graveyard. Abandoned approaches aren't thrown away. They're recorded with what was tried, why it failed and how much effort went in. When your agent heads down a path that's already in the graveyard, it gets a warning and the alternatives that worked instead.

A memory lifecycle. Memory isn't binary. Entries move from active (1.0×) to deprioritised (0.2×) to archived (0.0×) to deleted, and a deprioritised memory can come back when a query proves it's relevant again. Recency fades gently: 0.9 at 90 days, then 5% every 30 days, never below 0.3.

Contradiction detection and deduplication. Every write is checked. A near-duplicate returns the existing memory instead of storing a copy. A likely contradiction is stored with a warning, so you resolve it now rather than discovering it mid-task.

Compiled skills. This is where memory becomes habit. compile_skill(domain) reads the reinforced lessons, recurring gotchas and graveyard for a domain and writes a SKILL.md: rules your agent follows, each citing the memories it came from, plus a never-again list from the graveyard. A lesson only becomes a rule once it recurs (twice by default), every change arrives as a diff for you to accept, and the same sources always compile to the same file.

Hooks. The fix for those twenty runs. omnimem hook injects a project briefing when a Claude Code session starts, blocks tool calls that repeat an abandoned approach, and records how the session ended. A briefing takes about 6 ms. Your agent no longer has to remember to remember.

The evidence, and what it doesn't prove yet

I tested the hooks on one task: ten pairs of runs, with and without them.

With hooks, every attempt at the abandoned approach was stopped before it ran, and no run reached a failing test suite.
Without hooks, 8 of 10 runs did.
Runs with hooks cost 27% less.

That's a small test, run by me, on my own data, and I'd rather say so up front. It's exactly the kind of result I want other people to try to break.

On recall, I ran <omnimem> against LongMemEval earlier this year: 5.x scored 65.6% across 500 questions with a GPT-4o judge. The runs also exposed real bugs, including fact extraction replacing verbatim content instead of adding to it, and those got fixed. Those numbers are from 5.x. I haven't re-run it on 7 yet.

It's worth being clear about what LongMemEval measures: whether a system can find facts in long chat histories. It doesn't measure whether an agent learns from outcomes, avoids dead ends or gets cheaper over time. That's the part I care about, and I haven't found a public benchmark for it yet. Maybe we should create one!

7.0: one binary, nothing else to install

6.x was four containers: Valkey, a Python MCP server, a web UI and an RSS worker. 7.0 is one Rust binary.

One file of state. Memories live in SQLite. Vectors are searched exactly, filters are plain SQL, and there's no separate index to drift. A real store of 3,500 memories is a 12.8 MB database.
Local embeddings. all-MiniLM-L6-v2 runs on ONNX Runtime with no GPU. The model downloads once, about 90 MB. Nothing leaves your machine unless you opt in to Claude Haiku for fact extraction, query expansion and summaries.
Same tools. All 48 MCP tools keep their names, parameters and defaults from 6.x.
Desktop or server. A tray app on macOS (Apple silicon), Windows and Linux (Flatpak), or .deb, .rpm and Docker on a server, serving MCP on port 8765 with token or OAuth 2.1 auth.

It works with any MCP client, including Claude Code, Claude Desktop, claude.ai, Codex, Cursor, OpenCode, GitHub Copilot, GitLab Duo and Kiro.

The rough edges, honestly: there's no Intel Mac build yet, and the Windows installer isn't code-signed, so SmartScreen will grumble.

Open source, not open core

<omnimem> is MIT licensed and free forever. Every feature in this post is in the open source core, and it stays there.

I'm planning optional paid services for people who'd rather not run things themselves: hosting, secure tunnels and encrypted backups. They're convenience, not features. Anything they do, you can do yourself with the open source binary, and paying for one funds the project rather than unlocking it.

Get started

Grab the installer for your platform from omnimem.org, or on a Debian or Ubuntu server:

sudo apt install ./omnimem_<version>_amd64.deb
curl http://127.0.0.1:8765/healthz

Then point Claude Code at it:

claude mcp add --transport http --scope user omnimem http://127.0.0.1:8765/mcp

On the desktop, the tray menu does that step for you.

The source lives on Forgejo, with a GitHub mirror. If <omnimem> saves your agent from one dead end, a star helps other people find it. If it doesn't, open an issue and tell me why.

Stop living the same session twice.

OmniMem 7: one app, no Docker

Richard Harvey — Wed, 21 Oct 2026 16:47:47 +0000

OmniMem 7 is out, and it's a different kind of program. 6.x was four containers: Valkey with its search module, the Python MCP server, the web UI and the RSS worker, held together by a Docker Compose file. 7.0 is one Rust binary. It holds its own store, serves MCP, runs the RSS scheduler and the enrichment worker, and on a desktop it sits in your tray or menu bar with a settings window behind it.

Nothing else to install. No Docker, no database server, no Python. Download it, open it, and the embedding model fetches itself on the first start (about 90 MB, once).

Your memories come with you via a simple backup and import process, and they behave the way they did before. The 48 MCP tools have the same names, parameters and defaults, so an agent that knew OmniMem 6 knows OmniMem 7.

The first release is 7.0.3, on the releases page.

Why rewrite it

OmniMem's job is small: embed one memory, embed one query, search, rank. 6.x did that job well, but the machinery around it kept growing. Four images to pull and keep in step. A search index that lived beside the data and could drift from it, with phantom entries, silent index migration failures and tag-query quirks to work around. Each Python service loaded its own copy of the embedding model. And the only way to see your memories was a web UI on a port, which is one more thing listening on your machine. That setup was great for developing and testing the theories behind how memory and experience should live and work together, but I wanted to make this more accessible for everyone.

What 7 is

One process. The MCP server, the memory engine, the embedding model, RSS ingestion and the database all live in one binary. One embedder serves every caller. It's written in Rust, so it's memory safe and fast: a session's briefing arrives in about 6 ms.

One file. Memories live in SQLite. On start, every vector is loaded into one matrix per namespace and searched exactly, not approximately. At OmniMem's scale (tens of thousands of memories) a full scan takes a few milliseconds and gives the same answer every time. Filters are plain SQL, so there's no separate index left to drift from the data. A real 3,500-memory store comes to a 12.8 MB database.

Nothing leaves your machine. The embedding model (all-MiniLM-L6-v2 on ONNX Runtime) runs locally. The Anthropic API is only called if you give OmniMem a key for the optional Claude Haiku features: fact extraction, query expansion, deeper contradiction checks and RSS summaries.

Less on the network. Over HTTP, 7.0 serves /mcp, the OAuth 2.1 routes that protect it and /healthz. That's all. There is no web UI on a port and no /metrics.

On your desktop

There's an installer for each platform: a DMG for macOS (Apple silicon, 13.4 or later), an MSI for Windows 10 and 11, and a Flatpak for Linux desktops on amd64 and arm64.

OmniMem lives in the tray, or the menu bar on a Mac. The menu shows whether it's running and how many memories it holds, and it does the setup for you:

Add to Claude Code and Add to Claude Desktop check the client's settings first and never add OmniMem twice. An old omnimem entry pointing at a 6.x install is offered as Switch Claude Desktop here, which repoints it rather than adding a second.
Copy MCP URL covers every other agent with a bit of manual work.

Settings… opens a window with every page the 6.x web UI had (the dashboard, memories, search, projects, experience and the graveyard, skills with export and import, duplicates, contradictions, telemetry, token overhead, feeds and backups) plus a configuration page for everything a headless install sets in its environment (such as the OAuth settings or the Anthropic API key). The window's pages come from the app itself over a custom URL scheme. Nothing about them is reachable over a network, from your machine or anyone else's.

Secrets (your Anthropic key, the MCP access token, a Hugging Face token) go to the OS keychain: Keychain on macOS, Credential Manager on Windows, the Secret Service on Linux. Once saved they're never shown again.

On a server

omnimem serve is the same binary without the desktop parts, configured with the same environment variables as before.

.deb and .rpm for amd64 and arm64 install it as the omnimem systemd service, running as its own user, with one settings file (/etc/omnimem/omnimem.env) and its data in /var/lib/omnimem. There's a tarball with an install.sh for other distributions.
Docker: richarvey/omnimem:7.0.3, amd64 and arm64, with everything in one /data volume. A token is all it needs.
OAuth 2.1 is rebuilt by hand on axum, and every route, discovery document, challenge and error was checked against a capture of the 6.x server, so claude.ai and other OAuth clients connect as before. Tokens are stored only as SHA-256 hashes and survive restarts.

Linux builds need glibc 2.38 or newer (Debian 13, Ubuntu 24.04, Fedora 39 and later), a floor set by ONNX Runtime's library.

The same memory

This is the part that matters most. A rewrite that ranks your memories differently is a migration dressed up as an upgrade, so 7.0 was checked against 6.x at every step:

The vectors are the 6.7 vectors. The Rust engine was checked against full reference vectors the Python engine wrote, covering accents, CJK, emoji, empty text, truncation past 256 tokens and mixed-length batches. Deduplication, contradiction and skill clustering thresholds don't move.
Recall returns the same results. A real production backup of 3,500 memories was imported, and all 32 query and namespace searches tested returned an identical ordered top 10 to the Python engine's search over the same data. Every field survives an export.
Skills compile the same. Skill rendering matches the Python compiler byte for byte.
RSS reads the same articles. On the project's own reading list, the Rust parser picks out exactly the 59 articles 6.x's feedparser does, with the same keys, titles, dates and text.

Recall scoring has three deliberate changes, all in the changelog:

Recency declines from the day a memory is written, reaching 0.9 at 90 days and then falling 5% every 30 days to a 0.3 floor. 6.x held it flat at 1.0 for 90 days, so yesterday's memory and one from three months ago scored alike. The relevance floor reads raw similarity, so nothing extra is dropped.
An abandoned outcome scores 1.0, not 0.1. The old weight buried the write-up of a failure along with the approach, so the one memory explaining why something didn't work ranked below almost everything else.
Recording an abandonment no longer suppresses anything. Suppression hid the memory that explained the failure, and it was store-wide, so a dead end on one project silenced unrelated memories on another.

Memory your agent doesn't have to ask for

One finding shaped this release more than any other. Across twenty runs with OmniMem attached and the answer already in the store, the agent made zero memory calls of its own. The memory was there. Nothing asked it.

So 7.0 ships Claude Code hooks. omnimem hook puts the project's briefing into every session's opening context, read-only, in about 6 ms. Before a tool call that changes something, it checks the graveyard, and if the call proposes an approach this project already abandoned, it stops it and hands back what was abandoned, why, and what worked instead. It never guards a read, and it fails open on any error. At the end of a session it records what the session did, skips sessions that changed nothing and redacts credentials before writing.

Measured over ten pairs of runs on one task: every attempt at the abandoned approach was stopped before it ran, no run with the hooks reached a failing test suite (against 8 of 10 without them), and the runs cost 27% less.

Hardened before release

The whole Rust workspace was security reviewed before 7.0.0, with fixes in every crate. The headlines: the OAuth routes are size-capped, rate limited and strict about PKCE and redirect URIs; the settings panel carries no inline JavaScript and sends a Content Security Policy; skill bundles are read against their declared sizes, so a zip bomb is refused rather than inflated; RSS fetches refuse private and loopback addresses and re-check every redirect; and the model download verifies a sha256 from the hub. CI now runs cargo audit and gitleaks on every push. The full list is in the changelog.

Coming from 6.x

Your 6.x install keeps working, and nothing upgrades itself. When you're ready:

On 6.x, take a backup: ask your agent to call dump_to_file(), or use the old web UI's Backups page.
Stop 6.x, or at least make sure it isn't on port 8765.
Install 7, then restore the backup on the settings window's Backups page, or run omnimem import omnimem_backup.json.

Backups don't carry vectors, so every memory is embedded again from its text. That's about 8 ms a memory, so a few thousand take well under a minute and 25,000 take roughly three and a half minutes. It also has a side benefit: any memory 6.x had stopped finding, because its stored vector had gone missing or stale, is found again.

If you aren't ready, the 6.x Docker stack carries on from the v6.7.x branch, and the old one-line installer still sets up 6.7.

A few things are gone on purpose: Valkey and every VALKEY_* setting, the Compose stack, the web UI on port 8080, /metrics and the SSE transport. If an agent's config still says "type": "sse" or ends in /sse, point it at http://127.0.0.1:8765/mcp instead. The configuration reference lists every setting that went.

Rough edges

No Intel Mac build. ONNX Runtime ships no prebuilt library for Intel macOS, so the DMG is Apple silicon only.
The Windows installer isn't signed yet, so SmartScreen asks first: More info, then Run anyway.
In the Flatpak, Add to Claude Code can't work, because the sandbox can't see a claude installed outside it. The menu says so, and claude mcp add does the job.
Stock GNOME doesn't show tray icons without the AppIndicator extension. Where there's no tray, OmniMem opens its settings window instead and says which extension to install.

Get it now

OmniMem 7.0.3 on the releases page, with a .sha256 beside every file
Quick start
omnimem.org

OmniMem is open source, MIT licensed, and free. Issues and ideas are welcome on GitHub.

What if the answer to data centre sprawl is small, modular… and underground?

Richard Harvey — Mon, 05 Oct 2026 09:10:05 +0000

Every few months, the same story pops up in the news: a planning row over a data centre. A giant grey box the size of several football pitches, a new substation, an argument about water, and the promise of a few dozen jobs. And every time, nobody seems to ask the obvious question: why does our computing have to arrive in enormous lumps?

We never really had that conversation. So let's have it now.

Small, buried, and close to home

Here's the idea. Picture a precast culvert section, the sort of concrete tube we already bury under roads by the thousand. Now imagine each one holds a couple of server racks. Join a few together, add an access shaft, and bury the lot under a car park, a field, or the corner of a business park.

For want of a better name, let's call this thing a small modular data centre. SMDC, if you like. The energy industry already made "small modular reactor" a household phrase; maybe compute is next.

Why bother? A few metres down, UK ground sits at a steady 10–12°C all year round. That's free, gloriously boring, utterly reliable cooling. There's nothing to look at, not much to object to, and the land above just carries on doing its job: parking cars, growing grass, whatever it was doing before.

And because the units are small, they can go where the users are: a town, a hospital campus, a housing estate. Compute at the edge, owned by the people it actually serves, instead of rented from somebody else's "region" on a map far away.

Heat is a product, not a problem

Big data centres spend serious money throwing heat away. A small one sitting next to buildings can hand it over instead.

A pair of typical racks draws somewhere around 5 to 8 kW each, and essentially every watt of that comes back out as heat (ASHRAE treats the conversion as 100%). So call it 12 to 16 kW of steady warmth, about what a couple of homes need on a cold day. Pipe it into the office above, or the houses along the road, through a low-temperature heat network, and the same electricity gets used twice: once to do the sums, once to keep someone warm. There's something quite pleasing about that.

AI raises the stakes, in a good way. GPU racks run far hotter than ordinary servers and need liquid cooling, which sounds like a headache until you realise that liquid carries heat away at a much more useful temperature. Those workloads might be happiest under a block of flats or an office building, with plenty of people right above them who'd love the warmth.

The awkward bits (let's be honest)

I'm not going to pretend this is solved. A few things genuinely need answering:

Big is cheap. Hyperscale exists for a reason: cost per rack falls as you grow. Small has to earn its keep through heat sales, cheaper land, and quicker planning.
Soil fills up. The ground is not a bottomless heat sink. Push heat into it for years and it warms up, so this needs proper modelling, not optimism.
Summer. Nobody wants heating in July. Without a year-round use for the heat, you still need another way to get rid of it.
Lots of small sites. Hundreds of buried rooms are harder to maintain and secure than one big shed. Flooding, access, and fire safety underground all need real answers.
It won't do everything. Nobody is training a frontier AI model in a culvert. Running one is a different matter: inference, like most of the workloads we actually use day to day, belongs close to the people asking the questions. (Though dense GPU racks will want liquid cooling, mind, not just cool soil alone won't cut it.)

Bigger than the building

One buried room changes nothing. A few thousand small modular data centres, joined up? That might.

If every site speaks the same open standards, they stop being isolated server rooms and start behaving like a cloud. A council, a co-op, or a small business could run its own node, lend out spare capacity, and borrow someone else's when it runs short. No single owner, no proprietary lock-in, and no rent flowing to a handful of companies on another continent.

There's money in it too. A landlord, a homeowner, a group of tenants, a business with a spare patch of ground, any of them could host a unit and earn from it: rent, a share of the hosting income, or simply cheaper heat. Dead space under a car park becomes a revenue stream.

That's the part that interests me most. The culvert is only the catalyst.

So… what if?

I think data centre sprawl is a design choice we've mistaken for a law of physics. I might be wrong, and I'd much rather find that out in public.

So I'd genuinely love to hear from you:

🔧 Work in district heating, civil engineering, or planning? Tell me where this falls over. You won't hurt my feelings.
🌡️ What would you do with a steady supply of low-grade heat in August? (Seriously, someone must have a good answer.)
📍 Where would you bury the first one? Under your supermarket? Your school? Your street?
🗳️ And who should own it? The council? A co-op? You?

The comments are open. Bring a better idea. I'll be in there.

Opus 5.5 Is Brilliant. It Still Forgets You.

Richard Harvey — Tue, 29 Sep 2026 07:30:05 +0000

Anthropic shipped Claude Opus 5.5 on 22 September, and I've spent most of the week since with it open in one terminal or another. It's the first Opus in a while that I've just stopped thinking about. It does the work, it tells me what it did in plain English, and it doesn't burn through my allowance doing it.

I'm clearly not the only one. But alongside the praise there's a quieter thread of people saying the same thing I've been saying about every model for two years: it's brilliant, and it still doesn't remember anything. So let's look at both, and then at what I've been doing about the second one.

What people are saying

The headline numbers are good. Opus 5.5 is priced at $4 in and $20 out per million tokens, 20% cheaper than Opus 5, and it sits at the top of the Artificial Analysis Intelligence Index with a score of 58. eesel's review called it, at medium effort, "the best tool I've used" for genuinely hard, long, agentic work. Subscribers get a slice of the saving too: Memeburn worked out that Pro, Max and Team allowances stretch roughly 25% further than they did on Opus 5.

But the thing people keep coming back to isn't a benchmark. It's how it feels to work with. Opus 5 was verbose to the point of being tiring, and 5.5 has fixed most of that. The team at Every ran a week-long vibe check and it pulled their writers back from Codex; their shortest summary was "Anthropic fixed Opus's personality." Over on Hacker News, one commenter called the change in output style "a very big improvement over Opus 5", and in the main launch thread another simply said "Opus 5.5 is a game changer for me."

The code quality data backs up the vibe. SonarSource ran it through their Java benchmark and found it wrote 27.5% less code and used 40% fewer output tokens than Opus 5, with a pass rate within a point and total findings down 42%. Less code to review is the most underrated feature a coding model can have.

A couple of practical patterns are also emerging:

Medium effort is the sweet spot. Moe Lueker's testing on FrontierCode had medium scoring 54.6% at about $0.80 a task, while max scored slightly lower at nearly eight times the cost.
Plan with one, build with the other. Plenty of Claude Code users are pairing Fable 5.1 for planning and orchestration with Opus 5.5 for execution. One HN commenter, quoted by explainx, boiled it down to "plan with fable, implement with opus."That matches my own week. Opus 5.5 on medium is now my default for anything that isn't trivial.

It's not all roses

In fairness, the reception isn't unanimous. Some HN users found it just as wordy as Opus 5 on day one, and others weren't impressed until they bumped the effort up. CodeRabbit liked its capability but flagged that its code reviews used more tokens and left more comments, so the cheaper sticker price doesn't automatically mean a cheaper bill. Sonar's numbers also showed injection-style findings going up, which is a good reminder that less code isn't the same as safer code. And if you work in bioinformatics or security research, the new safeguards mean many of those requests get routed to an older model instead.

None of that changes my overall view, but you should go in with your eyes open.

The memory complaints

This is the bit that caught my attention, because it's the problem I've been working on.
A GitHub issue on the Claude Code repo, originally about Opus 4.6, lists Opus 5.5 among the affected models and describes the model losing track of repository context within a single conversation. The reporter sums up the symptom as the "model loses track of established facts within a session", with real consequences like files being committed to the wrong repository.

Another issue reports a Max plan user seeing Opus 5.5's context window capped at 150k tokens in Claude Code. And in the HN launch thread, one frustrated developer asked whether 5.5 still skips over CLAUDE.md and reads a couple of lines of a file when asked to read the whole thing.

It's worth pulling these apart, because they're really two different problems.

In-session problems (context caps, compaction losing detail, a model not reading the file you told it to) are Anthropic's to fix, and some of these look like bugs or config issues rather than the model itself. Nothing I'm about to describe will lift a 150k cap.

Cross-session problems are different, and they're not a bug at all. They're simply how these models work. Every new session starts from zero. Your agent doesn't know your stack, doesn't know you tried that library last Tuesday and it segfaulted on Alpine, and doesn't know you prefer Forgejo over GitHub. A 1M-token context window doesn't change that. Buda put it better than I could: "A large window delays forgetting; it does not solve persistence."

The first problem makes the second one worse. If you're relying on a giant CLAUDE.md or on stuffing everything into the context window so the model might remember it, any hiccup in how that context is read or compacted hits you hard.

Where OmniMem fits

OmniMem is the self-hosted memory server I built because I got fed up re-explaining myself every morning. It's an MCP server, so it works with anything that speaks MCP: Claude Code, Claude on the desktop and web, Codex, Cursor, OpenCode, Copilot, Kiro and others. It runs on your own hardware, uses local ONNX embeddings with Valkey vector search, and it's MIT licensed and free.

Rather than a flat file the model may or may not read, OmniMem gives your agent a proper memory it can query:

A one-call briefing. At the start of a session, briefing() hands the agent your project context, recent experience, stale memories, new articles and any contradictions. No warm-up, no hoping a file gets read.
Recall across four namespaces. Episodic memories (decisions, bugs, what you tried), project context, a knowledge base fed from RSS, and your preferences, all searched together and ranked by similarity, recency, lifecycle state and how hard the lesson was to learn.
The graveyard. Every abandoned approach is kept on purpose, along with why it failed and how much effort it burned. Before the agent reaches for that library again, it gets a warning and the thing that worked instead.
Contradiction detection and semantic dedup, so your memory doesn't quietly fill up with conflicting or duplicate facts.- A real lifecycle. "Forget about X" usually means "stop bringing it up", so memories can be deprioritised or archived rather than just deleted, and reinstated if they become relevant again.- Compiled skills. compile_skill() turns accumulated experience into a SKILL.md for a domain, proposed as a diff you review before anything is written.So how does that map to the complaints?
"It forgets established facts": those facts live in OmniMem and come back via briefing and recall, rather than depending on surviving compaction.- "It ignores CLAUDE.md": OmniMem's instructions are injected when the MCP server connects, and memory is pulled in by query when it's relevant.- "Context gets capped": retrieving only what's relevant keeps the context lean, which matters more when the window is smaller than you expected.- "It made the same mistake again": that's exactly what the graveyard is for.To be clear about the limits: OmniMem doesn't change how Opus 5.5 reasons within a session, and it won't fix a platform bug. What it does is make sure the things that matter survive between sessions, between projects and between machines. Pair it with Opus 5.5's much better instruction following and the combination is genuinely lovely to work with. It's how I've been running all week.

Use it today: OmniMem v6

OmniMem v6 is available now (the latest release is 6.7.1). You'll need Docker and Docker Compose, and that's about it. The quickest route is the installer:

curl -fsSL https://code.squarecows.com/ric/omnimem/raw/branch/main/install.sh | bash

Or, if you'd rather see what you're running first (and you should, it's a curl-to-bash), do it by hand:

git clone https://code.squarecows.com/ric/omnimem.git- cd omnimem and cp .env.example .env

Edit .env to set VALKEY_PASSWORD, and optionally ANTHROPIC_API_KEY- docker compose up -d (the web UI is then at http://localhost:8080)Then point your agent at the MCP endpoint, http://localhost:8765/sse . There's a setup guide for each supported client, including the exact Claude Code config, at https://code.squarecows.com/ric/omnimem/src/branch/main/guides

That gives you four containers (Valkey with vector search, the MCP server, the RSS worker and the web dashboard), and nothing leaves your machine.

Coming soon: OmniMem v7

Docker Compose is great if you live on a Linux server like I do, but it's a barrier for a lot of people. v7 is a rebuild as a single Rust binary, and it comes with proper desktop installers: an MSI for Windows, a DMG for macOS and a Flatpak for Linux. Once it's running you'll get a system tray icon that takes you straight to the settings, with no YAML or .env editing required. The Docker image isn't going anywhere, so if you're running headless on a server nothing changes for you.
In short, if v6 is "clone, configure, compose", v7 is "download, double-click, done".

Give your agent a memory

Opus 5.5 is the best model Anthropic has shipped for day-to-day work, and I'd switch to it today. Just don't expect a bigger context window to do the job of memory. Give it somewhere to keep what it learns.
Head over to https://omnimem.org to get started, and if you hit a snag or have an idea, the issue tracker is open at https://code.squarecows.com/ric/omnimem/issues
This article was researched and drafted with help from Claude Opus 5.5, which felt fitting.

Sources

Anthropic, Introducing Claude Opus 5.5: https://www.anthropic.com/claude-opus-5-5
eesel, Claude Opus 5.5 review: https://www.eesel.ai/blog/claude-opus-5-5-review
Every, Vibe Check: https://every.to/vibe-check/vibe-check-opus-5-5-is-pulling-our-codex-converts-back-to-claude
SonarSource evaluation: https://www.sonarsource.com/blog/claude-opus-5-5-an-evaluation/
CodeRabbit, Opus 5.5 for code review: https://www.coderabbit.ai/blog/opus-5-5-model-review
Moe Lueker, Claude Opus 5.5 review: https://moelueker.com/blog/claude-opus-5-5-review
Memeburn, subscriber limits: https://memeburn.com/anthropic-says-opus-5-5-costs-40-less-to-run-claude-subscribers-get-about-25-more-room
explainx, Fable 5.1 vs Opus 5.5: https://explainx.ai/blog/fable-5-1-vs-opus-5-5-comparison -2026- Roo, what breaks when you switch: https://roo.beehiiv.com/p/claude-opus-5-5-review
Hacker News launch thread: https://news.ycombinator.com/item?id=49803892
Hacker News, Artificial Analysis thread: https://news.ycombinator.com/item?id=49804316
GitHub anthropics/claude-code #96527: https://github.com/anthropics/claude-code/issues/96527
GitHub anthropics/claude-code #97387: https://github.com/anthropics/claude-code/issues/97387
Buda, 1M context is not agent memory: https://buda.im/blog/claude-opus-5-5-context-window-agent-memory