Persistent local memory lands in Open Free Max 3.0

Open Free Max 3.0 is now public, and it carries a change that reshapes how coding agents behave across sessions: persistent local memory. Your agent no longer starts every conversation from a blank slate. It can recall relevant prior context from earlier work on the same project, and it does so without a single byte of that memory leaving your computer.

This is available now, in the public 3.0 release, on Windows and macOS.

The feature first shipped in the 2.5.0 line, in a commit dated 25 June 2026 that introduced local persistent memory together with MCP exposure, a reworked install-help onboarding flow, and Windows signing. Since then it has been refined and hardened, and the public 3.0 release is the first version where every reader of this article can install it, point it at a project, and see the memory build up as they work. This article explains exactly what changed, why a local-first design matters for both privacy and continuity, how per-project isolation keeps knowledge bases from bleeding into each other, how agents reach the memory through the Model Context Protocol, and where the honest limits sit.

What Open Free Max is, in one paragraph

Open Free Max is a lightweight native desktop IDE built with Tauri, Rust, and TypeScript. Its job is narrow and deliberate: it lets you drive the official coding-agent command-line tools interactively from a clean desktop surface on Windows and macOS. It does not replace those CLIs, and it does not reimplement them. It orchestrates them. Crucially, it does not touch your API keys or tokens. The official CLI you already use handles its own subscription authentication, exactly as it does in a terminal. Open Free Max sits above that layer and gives you a better place to work, plus, as of this release, a memory that survives when the terminal session ends.

That distinction matters for the rest of this article. Because Open Free Max never handles your credentials and never proxies your model traffic, the memory it maintains is genuinely separate from the agent's own account and network activity. The IDE is not in the loop for your prompts and completions. It is only in the loop for the memory you choose to keep locally.

What changed

Before this release, continuity across sessions was something you engineered by hand. You kept notes in a scratch file, you re-pasted context at the start of each session, or you relied on the agent re-reading the codebase every time to reconstruct what it once knew. That worked, but it was manual, lossy, and repetitive.

Persistent local memory removes that chore.

With 3.0, Open Free Max maintains a durable record of relevant context and stores it in a single local file named memory.db. The record is computed and written entirely on your machine. When you return to a project days later, the memory is still there, and an agent working through Open Free Max can consult it to recall decisions, constraints, and prior discussion instead of rediscovering them. The practical effect is continuity: the second session knows what the first session learned.

There are three properties worth pulling apart, because they are easy to blur together and each one carries its own consequence: the memory is local, the memory is isolated per project, and the memory is reachable by agents through MCP. The next three sections take them in turn.

Why local-first memory matters

The defining choice in this feature is where the memory lives. It lives on your machine, and only on your machine.

Everything about the memory is computed and stored on the user's device. There is no server that receives your prompts or the model's replies for the purpose of building memory. There is no upload step. There is no telemetry of the LLM exchanges flowing to Open Free Max. The memory is a local artifact that you own, inspect, search, and delete on your own terms.

This has two payoffs that are worth stating plainly, because they are often promised and rarely delivered together: privacy and continuity. Privacy, because a memory that never leaves the machine cannot be leaked from a service you do not control, cannot be mined, and cannot be retained after you think you deleted it. Continuity, because the memory genuinely persists between sessions and survives restarts, so the agent's recollection of a project does not evaporate when you close the window. Most memory features force a trade between the two. Here the local-first design is what makes both true at once.

Consider what this means in day-to-day terms. Your codebase, your architectural decisions, the reasons you rejected a particular approach three weeks ago, the naming conventions your team argued over, the constraints a client imposed in a meeting you summarized to the agent: all of that context is exactly the kind of material that is sensitive and valuable at the same time. A local memory lets you accumulate that context and reuse it without ever deciding to trust it to a remote store. You keep the benefit and you keep the data.

Deletion is immediate and complete. Because the memory is a single local file, deleting memory.db wipes the memory instantly. There is no cache in a distant data center to worry about, no soft-delete grace period, and no support ticket. You remove the file, and the memory is gone. That is the clearest possible statement of ownership: the off switch is a file you can delete yourself.

Searching your history is a local operation too. You are looking through your own record, on your own disk, without a round trip to anyone's API. The memory is yours to query, not a service's to serve back to you.

How per-project isolation works

A single shared memory pile sounds convenient until you actually use it. In practice, a global memory that mixes every project you have ever touched becomes noisy fast. Context from an unrelated client leaks into suggestions for the project in front of you. Naming conventions collide. The agent recalls a decision that was correct for one repository and wrong for another.

Open Free Max avoids that trap. Each project gets its own isolated knowledge base.

This behavior arrived with the 3.0 release, which established isolated knowledge bases per project. Rather than one global heap that grows without boundaries, the memory is partitioned so that each project accumulates and consults only its own context. When you work in project A, the agent draws on project A's memory. When you switch to project B, it draws on project B's. The two do not contaminate each other.

The reasoning here is not cosmetic; it is about signal quality. An agent's recall is only useful when it is relevant, and relevance is dramatically easier to preserve when the memory it searches is scoped to the work at hand. Per-project isolation means the agent is not sifting through the residue of every other project to find the one fact that applies to this file, which keeps recall focused and keeps unrelated, possibly confidential, context from surfacing where it does not belong. Isolation is therefore both a quality feature and a privacy feature, and it is one of the reasons the local memory stays practical as it grows.

It also maps cleanly onto how developers already think. You reason about your work one project at a time. Your memory of a codebase is bound to that codebase. Making the agent's memory follow the same boundary means the tool matches your mental model instead of fighting it.

How agents access the memory through MCP

Storing memory is only half the problem. The other half is letting the agent actually use it, and doing that in a way that is not tied to a single vendor's agent.

Open Free Max exposes the memory to agents through the Model Context Protocol, commonly abbreviated MCP. MCP is an open protocol for connecting agents to external context and tools. By surfacing the local memory as an MCP capability, Open Free Max lets a CLI agent recall relevant prior context during a session rather than requiring you to re-supply it by hand.

This is what turns a stored file into a working memory.

The advantage of going through MCP rather than a proprietary hook is reach. MCP is spoken by more than one coding-agent CLI, so the same local memory can serve different agents. In practice this means a CLI agent such as Claude Code or Codex, driven interactively through Open Free Max, can consult the project's memory base and bring back the context that matters for the task in front of it. The IDE provides the memory; the protocol provides the bridge; the agent does the recall. Because the bridge is a standard rather than a bespoke integration, the memory is not locked to one assistant, and the design does not bet on a single vendor remaining your only agent forever.

It is worth being precise about the division of labor. Open Free Max maintains and serves the memory locally. The agent decides, within a session, when recalling prior context is useful and requests it through MCP. Your model traffic still flows through the official CLI and its own authenticated connection, exactly as before. The memory layer does not sit in that path. It is a side channel of durable context, held on your disk, offered to the agent when the agent asks for it.

A quick availability summary

The table below separates what is shipping now from where it runs, so there is no ambiguity about status.

Capability	Status	Notes
Persistent local memory	Available now	Public Open Free Max 3.0 release
On-device storage in memory.db	Available now	Single local file; nothing uploaded
Per-project isolated knowledge bases	Available now	Part of the 3.0 release; each project has its own base
MCP access for CLI agents	Available now	Recall of prior context via Model Context Protocol
Windows support	Available now	Native Tauri desktop build
macOS support	Available now	Native Tauri desktop build
Instant local deletion	Available now	Delete memory.db to wipe memory

Every row in that table is available in the public 3.0 release. There is no beta gate, no waitlist, and no server-side rollout to wait through, because the feature runs locally on the machine where you install it.

How to use it

Getting started does not require you to change how you already work with your agent. That is the point of building the memory into the IDE rather than bolting a separate service onto your workflow.

Install Open Free Max 3.0 for your platform. Open a project in the IDE the way you normally would. Work with your chosen official CLI agent interactively, as you already do. As you work, the relevant context is captured locally and written to the project's own memory base in memory.db. When you come back to that project in a later session, the memory is already there, and the agent can consult it through MCP to pick up where the project left off instead of reconstructing everything from scratch.

If you ever want a project to forget, you delete its memory. Because the memory is a local file, that action is entirely in your hands, it takes effect immediately, and it does not depend on anyone else's infrastructure or retention policy. This is the same property that makes the privacy story credible: the control is not a setting you request from a service, it is a file on your disk.

Because the memory is searchable locally, you can also treat it as your own record of a project's evolution. You are querying your history on your own machine, which means you can revisit what the agent knew without exposing that history to a third party.

A concrete example of the difference

To make the change tangible, picture a real week of work on a single repository.

On Monday you sit down with your agent and spend an hour establishing the shape of a new module. You explain the constraints: this service has to stay compatible with an older API contract, a particular library was ruled out after a security review, and the team agreed to a specific naming convention for the new endpoints. The agent helps you scaffold the first files. You close the laptop. In the old world, that hour of shared understanding was fragile. It lived in a chat transcript that the next session would not automatically read, or in your own memory, which is exactly the thing you were trying to offload.

On Thursday you come back to the same repository to continue the module. This is where the change shows.

Because Open Free Max captured the relevant context locally and stored it in that project's own base, the agent can recall on Thursday what was settled on Monday. It does not re-propose the library you already rejected, because the reason you rejected it is in the project's memory and reachable through MCP. It follows the naming convention you agreed on, because that decision persisted. It respects the older API contract, because the constraint was not lost when the Monday session ended. You did not re-paste any of it. The continuity came from a file on your own disk, scoped to this repository and no other.

Now suppose that on Friday you switch to a completely different client's repository. None of Monday's decisions follow you there, and that is correct. The second project has its own isolated memory. The naming convention from the first project does not leak into suggestions for the second, and the first client's constraints stay with the first client. The agent starts the second project with the second project's context, not a blend of everything you have ever touched. That separation is the per-project isolation doing its job, quietly, in the background.

This is the everyday texture of the feature. It is not a dramatic moment; it is the removal of a small, repeated tax you were paying on every session.

The honest limits

A product-news article that only lists benefits is not doing its job. Here is where the feature stops, stated plainly, so expectations match reality.

The memory is local, and that is a deliberate strength, but it is also a boundary. Because nothing is uploaded and there is no server, the memory does not automatically follow you across machines. It lives with the memory.db file on the device where it was created. If you work on two computers, each has its own local memory for a project unless you move the file yourself. This is the natural consequence of a design that refuses to upload your data, and it is a trade we made on purpose: portability across devices is not worth surrendering the guarantee that your memory never leaves your control.

Isolation is per project by design, which is what keeps recall relevant, but it also means there is no shared global memory that spans projects. If you want one project to benefit from another's context, that crossover does not happen on its own. That is intentional, and for most workflows it is the correct default, but it is a limit worth knowing.

The memory improves an agent's ability to recall prior context; it does not turn the agent into something it is not. Recall is a tool the agent can use through MCP, and its usefulness depends on the agent choosing to use it and on the quality of what was captured. It is continuity, not omniscience.

Finally, this article describes what the public 3.0 release ships today. It is not a roadmap. Where a capability is available, it is stated as available. Where a boundary exists, it is stated as a boundary. Anything not described here as shipping should not be read as promised.

How it fits the rest of Open Free Max

Persistent local memory is not a bolt-on. It follows the same principles that shape the rest of the product, which is why it feels consistent with how the IDE already behaves rather than like a separate service you have to manage.

The design is native and local by default.

Open Free Max is a lightweight native desktop application, built with Tauri, Rust, and TypeScript, and it deliberately keeps sensitive responsibilities off the network. It does not handle your API keys or tokens; the official CLI you drive continues to manage its own subscription authentication. Memory follows the same discipline: it is computed and stored on the device, it is not uploaded, and it does not generate telemetry of your model exchanges. The feature is an extension of the product's existing stance, not an exception to it, and that coherence is part of why the privacy guarantees are believable. A tool that already refuses to touch your credentials is a tool whose promise not to upload your memory is easy to trust.

The same coherence applies to how you interact with it. You keep driving the official agent CLIs interactively, exactly as you did before, and the memory works underneath that flow instead of asking you to adopt a new one.

Why this release matters

Persistent memory for AI coding tools is not a new idea. What is distinctive here is the combination: memory that is durable enough to be genuinely useful across sessions, local enough that it never leaves your machine, isolated enough that it stays relevant per project, and open enough, via MCP, that more than one agent can use it. Those four properties usually pull against each other. Delivering them together is the substance of this release.

The result is a workflow where continuity and privacy stop being a trade-off.

For a developer, the day-to-day change is small and constant rather than large and occasional. Every returning session starts a little smarter about your project, because the context you built up last time is still there and still yours. You did not rent that memory from a service, you did not risk it in transit, and you can erase it with a single file deletion. In a landscape where most tools ask you to send more of your work to a remote store in exchange for convenience, Open Free Max 3.0 makes the opposite bet: keep the memory local, keep it isolated, keep it yours, and still let your agent use it.

That bet is now shipping to everyone who installs the public release.

Get it and read more

Open Free Max 3.0 is available as a native download for Windows and macOS. To install it and try persistent local memory on your own projects, head to the download page. To dig into the technical details of how the memory, the per-project isolation, and the MCP integration fit together, read the documentation.

Download Open Free Max: /#download

Read the documentation: /docs