Why your AI forgets you.

Somewhere in my ChatGPT history there is a message where I explain, for what must be the fifth time, how I want commit messages written. Imperative mood, ticket reference at the end. The model did it perfectly. Then the thread ended, and everything it understood about me ended with it.

Every person who uses AI assistants seriously has a version of this story. You teach, the tool performs, the tool forgets, you teach again. This post is about why that keeps happening and what we built instead.

Forgetting is an architecture decision

A language model is a stateless function. Tokens in, tokens out; nothing is retained between calls. Every product that appears to remember you has bolted a memory system onto the side of the model, and every question that matters is a question about the bolt: where the memory lives, and what happens to it when you leave. The model is the least interesting part of the memory story. The bolt is everything.

Hosted products answer those questions in ways that serve the host. I do not think this is a conspiracy; it is gravity. If you run the servers, the natural place to put memory is your servers, keyed to your accounts, coupled to your product. And once it is there, the memory quietly becomes retention infrastructure: one more thing a customer loses by leaving. Useful for the vendor. Expensive for you.

ChatGPT's memory: convenient, and structurally someone else's

ChatGPT's memory feature is the most ambitious hosted attempt at this problem, and when it works it feels genuinely good. It watches your conversations and quietly saves the facts it judges worth keeping. Mention once that your product is called Atlas, and weeks later it knows. There was no setup. Users love it for a reason, and pretending otherwise would make everything else I say here less believable.

The mechanics: saved memories appear in a settings page as short summaries, and you can delete any of them. Separately, ChatGPT can draw on your past chat history when it answers. That is the whole visible surface. Underneath it are three structural problems.

It lives on their servers

Your memories are rows in OpenAI's database, attached to your account. Deleting lines is roughly the full extent of your authority over them. Lose the account, or leave it, and your assistant's accumulated understanding of you does not come along, because it was never yours to take. It is a feature of someone else's subscription.

It is coupled to one product

Those memories inform ChatGPT and nothing else. The frontier changes hands regularly, and each time it does, ChatGPT's memory presents you with a quiet ultimatum: the better model, or everything this one knows about you. You cannot carry the memory to Claude or to a local model on your own machine. Memory becomes switching cost. From the vendor's chair, that is not a flaw in the design; it is the design.

You cannot see how it works

The summary list is the entire window. You cannot see which memories were retrieved for a given answer, or why the model has decided you prefer Python when you asked one Python question months ago. When it misremembers, you delete a line and hope. An assistant's beliefs about you deserve a better audit surface than that.

Claude Projects: deliberate walls

Anthropic made a different call, and it deserves a serious look because the design is coherent. A Project is a container. You load files into it, write instructions for it, and every conversation inside shares that knowledge. Nothing leaks between containers, and nothing gets remembered that you did not deliberately put there.

For a real class of work, this is the correct contract. A consultant with six clients gets six clean rooms. Client A's numbers never bleed into client B's draft, and you know exactly what the model knows because you filed all of it yourself. Claude Code's CLAUDE.md pattern pushes the same idea further in a direction I admire: memory as a plain markdown file in your repo, readable in any editor and versioned with the code it describes. Memory you can read is memory you can trust. I mean that as a compliment, and I think it is the best idea in the hosted memory landscape.

But the walls that make Projects predictable also make them static. A Project holds what you filed; it does not learn. Correct the model's tone twenty times inside a Project and the twenty-first conversation starts exactly as wrong as the first, unless you distill the correction into the project instructions yourself. You are the memory system. The container is a folder. And nothing crosses the walls: what you taught Claude in one Project is unknown in the next, and the entire arrangement still lives inside Anthropic's account system, exactly as OpenAI's lives inside theirs.

For completeness: running a local model through Ollama or LM Studio solves data residency and solves nothing about memory. A local chat window forgets exactly as fast as a hosted one. The weights were never where the memory lived.

What memory should be

Our position is simple to state. Memory should belong to you the way your files belong to you: on your disk, indifferent to which subscriptions you happen to hold this month. It should be inspectable, because an assistant's beliefs about you will sometimes be wrong, and you cannot correct what you cannot see. And it should sit above the model boundary, so that the day a better model ships you take everything you have taught your assistant and go, and the models compete for your business instead of holding your context hostage.

None of the hosted designs can offer this, and not for lack of talent. Provider-owned memory is a consequence of the hosting business, and no memory feature, however polished, escapes the incentives of the company that stores it.

Four layers and a Brain

OMEGA is a native macOS app for Apple Silicon, and memory in OMEGA is not a feature of the chat window. It is a subsystem of the Neural-Fractal Agentic AI™ (NFA) core, which is why every surface shares it. It has two parts.

The first part is a four-layer memory, and the layers are scales. Micro is the active conversation: what you are working on right now. Meso is recent-task state: the drafts and intermediate results of the current stretch of work. Macro is the long-term store, indexed and searchable, permanent until you say otherwise. Meta is reflection across all of it: which approaches worked and which quietly failed. Overnight, a consolidation process we call Dreams moves salient material up the stack and lets the noise decay. The analogy to sleep is deliberate. An assistant that never consolidates either forgets everything or drowns in everything, and the useful behavior lives in between.

The second part is the Brain, a knowledge graph. Entities and relationships, with outcomes attached. Your client is a node. The repo is a node. The edge between them knows the staging URL and which deploy approach actually shipped. Retrieval runs vector search alongside graph traversal, and the embeddings are computed on-device by a bundled embedder, so building this memory never requires sending your working life to an API. Everything stays on your Mac unless you explicitly route a call to a cloud provider you configured; the details live on our security page.

Two properties fall out of this design, and they are the entire argument of this post. First, the Brain is inspectable: there is a Brain tab, and you can open the graph, search it, click a node to read what OMEGA currently believes, and delete anything that is wrong. Your assistant's model of you should not be less inspectable than your photo library. Second, the memory sits above the model boundary, so it is provider-portable. Mid-chat, you can move a conversation from a cloud model to a local one served by Omega-MLX on Apple Silicon and keep the full context. You can route through a Claude or Codex subscription, or bring your own API keys, and we take no markup on tokens either way. The Brain does not care which model is on duty this hour. That indifference is the whole point.

And because every surface writes to the same Brain, learning compounds across the product instead of fragmenting per feature. A correction you make in chat holds when you switch to voice. What Project Canvas learns about your repo, the Design Studio copilot already knows when it proposes an edit to your marketing frames. An Automation you described in plain English runs with the same understanding of your project that your conversations built up.

A week of use, concretely

Here is the difference in practice. Suppose you spend one working week in OMEGA on a client project.

Monday, you import the client's repo into Project Canvas and correct two of its assumptions: this project uses pnpm, and staging deploys from a branch named release. Tuesday, you draft the proposal, fix the tone twice because this client reads formal, and export the final version with their Brand Kit applied. Wednesday, you describe an Automation in plain English that watches the shared inbox and files attachments into the project folder, and you let it run. Thursday, on a walk, you think through renaming the product's sections over on-device voice. Friday, you ask one line: what is left before the client build ships.

A chat thread cannot answer Friday's question. A transcript is not memory; it is evidence that memory could have existed. Even a hosted memory feature would surface, at best, a few detached sentences from that week. By Friday, OMEGA's Brain holds, among other things:

• Entities. The client, the repo, the release branch, the staging URL, the shared inbox, the proposal document, and the edges connecting them.
• Preferences. pnpm over npm for this repo, the tone rules for this client, the export format they expect, the Brand Kit that applies to their documents.
• Outcomes. The deploy approach that failed Wednesday morning and the one that worked an hour later, and which proposal structure the client accepted.
• Connections across surfaces. Thursday's voice session about renaming links to the Design Studio frames it changed, which link to the Project Canvas build that implements them.

So Friday's answer comes from state instead of from scrolling: the build is waiting on the renamed sections from Thursday's voice session, and the inbox Automation has filed two attachments you have not reviewed. Nothing was re-explained. No thread was excavated.

And if a better model ships the following Monday, you switch OMEGA over to it and all of this survives, because none of it ever lived inside a provider relationship. It is structure on your Mac.

Own the memory, rent the model

Models are becoming rentable commodities, and the best one changes hands often enough that loyalty to any single provider is expensive. That is good news for everyone except model vendors. Memory is the opposite kind of asset: it compounds, and it is worth more every week you feed it.

The hosted approach couples the compounding asset to the rented one so tightly that you can never separate them, which is precisely why the memory features live where they live. We think that is backwards. Rent whichever model is best this month. Own the memory that makes any of them useful to you. That is the bet OMEGA makes, and it is a bet you can audit yourself: open the Brain tab and look at what your assistant believes. If you want that on your own machine, OMEGA runs natively on macOS 14 and up on Apple Silicon; grab it from the download page.