Introducing Open Free Max 3.0

Open Free Max 3.0 is available now for Windows and macOS. It is the release where the product stops being "a lighter place to run a coding agent" and becomes a command center for serious AI work: memory that lives on your machine, a live link to your Obsidian notes, seven official agent CLIs under one roof, and a way to hand off repetitive work and walk away.

This post is the map. It covers what shipped, who it is for, and where the honest limits are. The deep dives on memory, Obsidian, the CLI lineup, and Plan follow separately.

None of this changes the two ideas the product started from. Open Free Max is a native desktop application built on Tauri, Rust, and TypeScript — not an Electron shell, not a fork of a heavy editor. And it drives the official agent CLIs interactively, so your usage stays on the subscription you already pay for instead of a metered API path. 3.0 keeps both, and builds on top.

A quick map of 3.0

Here is what is available now, and on which platforms.

Capability	Status in 3.0	Platforms
Persistent local memory (memory.db, over MCP)	Available now	Windows, macOS
Live Obsidian vault connection (via MCP)	Available now	Windows, macOS
Seven official CLIs	Available now	Windows, macOS
Multi-CLI session resume picker	Available now	Windows, macOS
Plan — autonomous bulk runs	Available now	Windows, macOS
Mission Control multi-agent dashboard	Available now	Windows, macOS
Screenshot bridge (paste and drop images)	Available now	Windows, macOS
Native WSL2 projects	Available now	Windows
In-app TOTP two-factor authentication	Available now	Windows, macOS
Shortcuts panel (project or global scope)	Available now	Windows, macOS

Every row is shipping in the public build. WSL2 is Windows-specific by nature; everything else is on both platforms.

Memory that never leaves your machine

The headline of 3.0 is memory.

Agents forget. Close a session, open a new one tomorrow, and the thread of what you were doing is gone. Open Free Max 3.0 answers that with a persistent memory that is computed and stored entirely on your own machine, in a single local memory.db file. There is no account to sync, no cloud store, and no server that your prompts and the agents' replies are sent to.

That last point is the one that matters most, so it is worth stating plainly. Open Free Max does not collect, transmit, or retain your prompts or the models' answers as part of this feature. The memory is yours, it is local, and deleting the file wipes it instantly. You search your own history on your own disk.

The memory is exposed to the agents through MCP, the Model Context Protocol. In practice that means a CLI agent — Claude Code, Codex, and the others — can recall relevant earlier context when you need continuity, without you pasting the same background into every new session. The recall is a tool the agent can reach for, not a hidden rewrite of your prompt.

3.0 also makes the memory per-project. Each project keeps its own isolated knowledge base rather than everything piling into one global heap. Work you did in one repository does not bleed into an unrelated one, and the context an agent recalls is scoped to the project you are actually in. For anyone who juggles several codebases in a week, that isolation is the difference between memory that helps and memory that gets in the way.

Consider a concrete case. You spend a morning in a payments service, teaching an agent the quirks of a webhook flow and the reasons behind a retry policy. In the afternoon you move to an unrelated marketing site. With per-project memory, the agent on the marketing site starts clean and does not surface payment-retry lore that would only confuse the work; come back to the payments service next week and the relevant context is there, scoped to that project, ready to be recalled rather than re-explained.

Recall is intentionally explicit rather than magical. The memory sits behind an MCP tool the agent can call when continuity would help, which keeps the behaviour predictable: you can reason about when prior context is being used, and you are never surprised by an invisible edit to what you typed. Local storage, per-project scope, and tool-based recall are three separate decisions, and 3.0 makes all three the default.

There is a dedicated deep dive on how the memory is built, stored, and recalled. The short version is: local by design, private by default, isolated per project.

Your Obsidian vault, connected live

A lot of people already keep their real knowledge in Obsidian. 3.0 meets them there.

Open Free Max can connect the vault that is currently open in Obsidian directly to your agents, through the MCP server built into the Obsidian Local REST API plugin. Once that plugin is enabled, Claude Code or Codex can search, read, and write notes in the live vault while they work — no copy step, no separate import, no second source of truth to keep in sync.

This is deliberately kept separate from Open Free Max's own project memory. The Obsidian vault stays in Obsidian; the product does not slurp it into memory.db or hold a stale copy. You end up with two clean, distinct knowledge sources: the local project memory that the IDE maintains, and the personal vault that you maintain in Obsidian. The agent can use both, and neither pretends to be the other.

The setup is short. Install and enable the Obsidian Local REST API community plugin, point Open Free Max at it, and the agent gains vault access. The honest limit is that the connection targets the vault Obsidian currently exposes through that plugin; it is not a general filesystem crawler, and it is not a replacement for the product's own memory. It is a bridge to the notes you already trust.

In day-to-day use that looks like asking an agent to check a decision you wrote down weeks ago, to pull the acceptance criteria from a spec note into the code it is writing, or to append a short summary of what it just changed back into the right note. The vault stays the canonical record; the agent reads and writes it in place. For people who have spent years building a second brain in Obsidian, that is the difference between an assistant that knows your context and one that starts from zero every session.

Seven official CLIs, one command center

3.0 rounds out the agent lineup to seven official CLIs.

You can run Claude Code from Anthropic, Codex from OpenAI, the open-source OpenCode, Gemini from Google, Vibe from Mistral, Kimi Code from Moonshot, and Cursor Agent — all inside the same application. Kimi Code joined earlier in the 2.x line, the multi-CLI wiring landed across the app over the summer, and Cursor Agent arrived as the seventh CLI in this release.

CLI	Provider	Status
Claude Code	Anthropic	Supported
Codex	OpenAI	Supported
OpenCode	Open source	Supported
Gemini	Google	Supported
Vibe	Mistral	Supported
Kimi Code	Moonshot	Supported
Cursor Agent	Anysphere	Supported

Each session runs in its own PTY — a real interactive terminal — so you can keep several going at once without them stepping on each other. Settings are handled per provider through a schema-driven panel, which means each CLI exposes its own relevant options instead of a lowest-common-denominator form.

3.0 also adds a multi-CLI resume picker. When you come back, you can reopen prior sessions across the different CLIs, including Codex rollouts, and pick up where each one left off. The point of supporting seven agents was never novelty; it was removing the lock-in. You bring the agent you already pay for, and the IDE adapts to it.

Per-provider settings matter more than they sound. Each agent CLI has its own flags, model options, and behaviours, and flattening them into one generic form loses exactly the controls power users reach for. The schema-driven panel means Codex exposes Codex's options and Gemini exposes Gemini's, without the IDE guessing. The resume picker complements that: a real workday spreads across several agents and several projects, and being able to reopen the exact prior sessions — Codex rollouts included — is what makes multi-agent work continuous instead of a fresh start every morning.

That last phrase carries the billing principle the whole product is built on. Open Free Max drives these CLIs in interactive mode, with a human in the loop, so the work stays on your existing subscription rather than a metered programmatic path. The IDE never handles your keys or your auth. Each official CLI signs in the way it always does, and Open Free Max simply gives it a better place to run.

Plan: hand off the repetitive work

Some jobs are not one prompt. They are the same prompt, fifty times, over fifty inputs. 3.0 has a mode for exactly that, and it is called Plan.

You give Plan one repetitive job — a brief, split into units — and it runs a pool of interactive agent sessions in parallel until the whole batch is done. Each unit writes its own output, a file or a folder, which makes the run idempotent and fully resumable. If a unit already produced its result, it does not need to be redone.

The interesting part is what happens when things go wrong, because at scale they will. Plan survives crashes and reboots. And because it stays on your subscription, it fully expects to hit token and quota limits along the way. Instead of failing the run, it parks and auto-resumes when your plan refreshes. The for-loop that used to be you — babysitting a terminal, restarting after every limit — is now the software's job.

A concrete shape helps. Say you need to migrate two hundred files to a new API, or generate a short document for each of eighty inputs. You write one brief, describe the unit of work, and let Plan fan it out across a pool of sessions. Each unit lands its own file. If forty are done and the machine reboots, the next run skips the forty that already have output and continues with the rest. If you hit a quota ceiling at unit ninety, Plan waits and resumes rather than dropping the last hundred and ten on the floor.

Plan comes with the scaffolding you need to actually use it: onboarding, brief templates, and AI-assisted brief generation to get a first draft of the job quickly. You can edit a campaign by clicking its card and adjusting a pre-filled advanced popup, and deleting a campaign asks for confirmation first so a long run is never lost to a stray click. A split view of the queue, with automatic purge of finished work, keeps a large batch readable. When Plan launches an agent, it even passes the launch instruction in the language your IDE is set to, so an English, French, or Spanish workspace speaks to the agent in kind.

There is a full deep dive on Plan. If your work has a repetitive shape, it is the feature to read about next.

Mission Control: every agent on one screen

Running seven CLIs and a bulk engine only helps if you can see all of it at once. Mission Control is where that happens.

Mission Control is a multi-agent dashboard: a wall where every live session appears as its own tile, across projects and providers, each in its own PTY. You can tell at a glance what is running, what is idle, and what is finished, and click into any tile to take over its prompt. An auto-approval engine handles the routine confirmations so a wall of agents does not turn into a wall of yes/no prompts waiting on you.

Auto-approval is a real time-saver at scale, and it is scoped to be practical: it clears the routine confirmations that would otherwise pile up, so your attention goes to the decisions that actually need a human. The wall is not a passive monitor either — it is the control surface. A tile that needs you is where you click in, steer the agent, and drop back out to the overview while the rest keep moving.

The surrounding UI was flattened in this line into a single top bar — Wall, Plan, IDE, Settings — with contextual, tinted bars so you always know which mode you are in. You can reorder projects by dragging them in the rail, and that order is shared between the wall and the rest of the shell and persisted between launches. Small things, but they are what make a dozen sessions feel like a workspace instead of a mess of windows.

The details that make it usable

A release is also the sum of the smaller things that remove daily friction.

The screenshot bridge remains a signature. Paste with Ctrl+V or drag any number of images straight into a prompt; Open Free Max writes each one to disk, shows a thumbnail chip, and injects the real paths when you send — so you never type a file path, and clipboard paste works on native Windows where the raw CLI often fails silently. On macOS, screenshots taken with Cmd+Shift+4 are auto-imported into the prompt.

On Windows, native WSL2 projects are first class. You can open a project that lives inside a WSL distribution and the agent runs in Linux, with the node, git, and CLI binaries from your distro and the right PATH, without installing an IDE-side extension. The editor gained image and PDF preview, a file search bar in the tree, and visual line wrapping for prose. The terminal gained a multi-tab shell panel and copy-on-select inside TUIs. These are not headline features; they are the reason the headline features are pleasant to use.

None of them arrived at the cost of weight, which is the constraint the product refuses to break. Every panel, preview, and terminal tab runs inside the system WebView and the Rust core, not a second browser engine bolted onto the app. That is why a workspace with several agents, an editor, and a couple of terminals still behaves like a native tool rather than a laptop-fan simulator.

Account security and how the app is built

3.0 also hardens the account layer. Two-factor authentication is now enrolled in-app with TOTP on first sign-in, so protecting your account does not send you out to a separate flow. On Windows, production builds are code-signed.

Under the hood, the product stays honest about weight. The release Rust profile and lazy loading of the Monaco editor keep memory down, which is the entire reason the application exists: a native shell over the official CLIs, not a browser engine pretending to be a desktop app. Product telemetry, where present, is pseudonymous and opt-out; it is about install health and country-level reach, not your conversations, which — as covered above — never leave your machine.

Who should update

3.0 is worth the download if any of these describe your week. You run more than one coding agent and you are tired of them living in separate windows with separate histories. You keep your real knowledge in Obsidian and want your agents to use it without a copy-paste tax. You have a task that is really the same task repeated many times. Or you simply want a coding IDE that does not eat your memory and does not quietly route your work onto a metered API bill.

If none of that is you yet, the release still lowers the cost of trying. It installs as a normal desktop app, it keeps your data on your machine, and it runs the agent you already have. There is little to lose in pointing it at one project and seeing whether a lighter, memory-keeping command center changes how the work feels.

Availability and how to get it

Open Free Max 3.0 is available now as a direct download for Windows and macOS. The Windows build ships as a signed installer; the macOS build is a signed and notarized disk image for Apple Silicon. There is no package manager step and no command line required to install it — download the file for your platform and run it.

The download is a single file per platform, and the first launch is the whole setup. No account is required to start editing and running an agent; the account layer exists only for the Pro features, and even then your projects and local memory stay on disk regardless of sign-in state. If you work offline, the editor, the terminals, and your local memory keep working — what needs the network is the agent talking to its own provider, exactly as the CLI would on its own. That separation is deliberate: the IDE is a place to work, and model access stays where it already lives, on your subscription with your provider.

If you are already on an earlier version, the update is the same download. Your projects, sessions, and local memory remain on your machine throughout; nothing about this release moves your data off-device.

You can get the build from the download section on the site, and the documentation covers setup for memory, the Obsidian connection, and each of the seven CLIs. If you keep your knowledge in Obsidian, if you run more than one agent, or if your work has started to look like the same task repeated many times, 3.0 was built for exactly that.

The deep dives — local memory, the Obsidian connection, the seven-CLI lineup, and Plan — go one level down into each of these. Start with whichever one matches the problem in front of you today.