Loomfield AI
Persistent memory for Claude and Codex: four approaches compared
There are four common ways to give an AI assistant memory that persists across sessions: instruction files, built-in chat memory, MCP memory servers, and a work system that keeps the method behind finished jobs. They remember different things and ask different things of you. Loomfield is the fourth approach, and it sits underneath the others rather than replacing them.
How do you give Claude or Codex persistent memory?
By carrying information into each new session in one of four ways. You can write it in an instruction file the tool reads at the start. You can rely on a memory feature built into the assistant. You can connect a memory server over the Model Context Protocol (MCP). Or you can run a work system that stores finished work and its method and brings it back when related work begins.
None of these is wrong. They differ in what gets remembered and how much upkeep falls on you.
What does each approach remember, and what do you maintain?
This table describes the approaches in general terms. Individual products vary, so check the details of any tool you use.
| Approach | Typically remembers | What you maintain | Where it tends to stop |
|---|---|---|---|
| Instruction files (for example CLAUDE.md in Claude Code) | Standing instructions, conventions, project notes | The file itself, by hand | Holds instructions, not the sources, checks, and corrections behind one finished job |
| Built-in chat memory | Facts and preferences you shared | Little; review what is saved | Tied to one assistant, and generally centered on facts rather than work method |
| MCP memory servers | Stored facts or notes the assistant can look up | Choosing, running, and curating the server | Portable across clients, but what it stores depends on what you or the assistant write into it |
| A work system (Loomfield) | Finished work with its sources, checks, decisions, and corrections | Approving what carries forward | In private beta; learning and reuse are in development |
When are instruction files enough?
Instruction files are a good fit when what you need is stable: coding conventions, tone, folder layout, a few rules the assistant should always follow. They are simple, readable, and fully under your control.
They start to strain when the knowledge is specific to a job. The reason a number was excluded, the source that turned out to be reliable, and the correction you gave last month are rarely worth hand-writing into a standing file, so they disappear when the chat does.
Where does a work system fit?
Loomfield runs on your own computer and drives Claude or Codex using your own login. Around that, it keeps a private knowledge base called the Weave, in your home folder. Sessions and the work they produce are saved there, and the aim is for the method behind a finished job to stay connected to the result.
When a related job begins, Loomfield is built to propose what carried over, and you decide what to reuse. It is a separate layer from the assistant, which is why switching between Claude and Codex does not mean abandoning what was learned. See AI agent memory for how the memory works.
Does Loomfield need an API key?
No. Loomfield uses your own Claude Pro or Max login, or a ChatGPT plan with Codex. Setup is described in the getting-started guide, and it takes about 10 minutes on a Mac with Apple Silicon or a 64-bit Windows 10 or 11 PC.
Which should you choose?
Use instruction files for rules that rarely change. Use built-in memory for preferences. Add an MCP memory server if you want one store shared across several clients. Consider a work system when the pain is recurring reports, reviews, analyses, or follow-ups that you keep rebuilding from scratch. They can be combined.
For the Loomfield approach, start with what Loomfield is for, or request access from the homepage.