Plan: Open Free Max's Autonomous Bulk-Run Mode, Explained

Open Free Max 3.0 ships with Plan, a mode built for one specific problem: running the same agent task hundreds of times without babysitting it. You describe a repetitive job once, split it into units, and Plan runs a pool of interactive agent sessions in parallel until the whole batch is finished. If your machine reboots or your subscription hits its quota window, Plan parks the work and picks it back up on its own.

This is not a new experiment bolted onto the release. The engine underneath Plan is the bulk continuity engine that first landed in the 1.1.0 line on 8 June 2026, described internally at the time as an agnostic continuity engine for bulk mode. In the public 3.0 release it has a name, a dedicated place in the interface, and a set of supporting features around onboarding, editing, and queue management. This article explains what Plan actually does today, the exact workflow, why it can resume itself, and where its limits are.

What Plan is

Plan is the third of four surfaces in Open Free Max. The application exposes a single top bar with four entries: Wall, Plan, IDE, and Settings. That layout arrived on 9 June 2026 and is what you see in 3.0. Wall is where you watch activity, IDE is the coding surface, Settings holds configuration, and Plan is where you define and launch bulk work.

The short version is simple.

Plan takes one repetitive job and turns it into many small, independent runs.

Think of the difference between asking an agent to do a task once, interactively, and needing that same task performed across a long list of inputs. Doing the second by hand means opening a session, pasting a prompt, waiting, saving the result, and repeating until you lose the will to continue. Plan removes the repetition. You define the shape of the work a single time, hand it the list, and the mode fans the work out across several agent sessions running at once. Each session takes a unit, completes it, writes its output, and moves to the next available unit until the queue is empty.

The design goal is unattended throughput without losing the human-in-the-loop model that keeps the whole thing on your existing subscription. That last point is the part most people miss, and it is the reason Plan behaves the way it does under pressure. We will come back to it.

The workflow: brief, units, agents, output

Plan is organised around a campaign. A campaign is one bulk job, and it has four moving parts you should understand before launching anything.

The brief

Everything starts with a brief. The brief is the instruction that every unit shares: what to produce, in what form, following which rules. You write it once. Because it is reused for every unit, the brief is where you invest your attention. A precise, unambiguous brief produces a consistent batch; a vague one produces a batch that is consistent only in its vagueness.

To lower the cost of getting started, 3.0 includes three supporting capabilities that shipped together on 10 June 2026. The first is Plan onboarding, a guided path for a first campaign so you are not staring at an empty form. The second is brief templates, reusable starting points so common shapes of work do not have to be rewritten from scratch. The third is AI brief generation, which drafts a brief for you from a short description that you then refine. These exist to reduce the friction of the very first step, not to replace your judgement about what the batch should contain.

The units

A campaign is a brief split into units. A unit is one item of work: one entry in the list, one row, one target. If the brief says how to do the job, the units say what to do it against. Ten units means ten runs of the same brief with ten different inputs. Five hundred units means five hundred runs.

The unit is also the atom of resumability, and that is the most important structural fact about Plan. Each unit is tracked on its own. It is either pending, in progress, done, or failed, independently of every other unit in the batch. Nothing about unit 214 depends on unit 213 having finished, so the batch does not have a fragile ordering that a single failure can break.

The agents

Plan runs a pool of interactive agent sessions in parallel. Rather than processing the list one unit at a time, it keeps several sessions busy at once, each pulling the next available unit as it frees up. This is what turns a long list into a bulk run instead of a slow serial loop. The parallelism is the throughput; the per-unit tracking is the safety.

The launch instruction handed to each agent is passed in the language of the IDE. Open Free Max supports English, French, and Spanish for that instruction, a behaviour added on 9 June 2026. If your interface is set to French, the agent is launched with a French instruction; the same applies to English and Spanish. This keeps the model's task framing aligned with the language you are already working in.

The output

Each unit writes its own output. That output is a file or a folder that belongs to that unit and no other. This one-output-per-unit rule is not a cosmetic choice. It is what makes the whole run idempotent and fully resumable, because the presence of a unit's output is the record that the unit is done. There is no separate, easily corrupted ledger that has to stay in sync with reality. The filesystem is the record. If the output exists, the work exists.

Put the four parts together and the workflow reads cleanly. You write a brief once. You split the job into units. Plan runs a pool of agents in parallel across those units. Every unit lands its own file or folder. When every unit has its output, the campaign is finished.

Why Plan is resumable and idempotent

Resumability and idempotency are words that get used loosely, so it is worth being exact about what they mean here and why Plan earns them.

A run is idempotent when doing it again does not double the result. Because each unit maps to one output and Plan treats an existing output as the signal that the unit is complete, re-running a campaign does not reproduce work that already landed. It looks at what is already on disk, sees which units are satisfied, and only picks up the ones that are not. Run the same campaign twice and you do not get two copies of everything; you get the missing pieces filled in.

A run is resumable when you can stop it and start it again without losing your place. This follows directly from the per-unit output model. Plan does not hold the state of a batch only in memory, where a crash would erase it. The completed units are visible on disk as their outputs, and the pending units are simply the ones without outputs yet. Resuming is therefore not a special recovery procedure with its own failure modes. It is the ordinary case: look at what is done, do what is not.

This is the quiet strength of the design. The continuity does not depend on a clever checkpointing scheme that has to be trusted. It depends on the plainest possible fact, whether a file or folder exists, which survives crashes, reboots, and closing the application because it was never in volatile memory to begin with.

Crashes, reboots, and quota windows

Long bulk runs meet reality, and reality includes crashes, restarts, and running out of budget. Plan is built to survive all three, and the way it handles the third is the part that reflects a deliberate architectural choice.

Surviving crashes and reboots

Because the record of progress is the set of per-unit outputs on disk, a crash mid-run costs you at most the units that were in flight at the moment things stopped. Everything already written stays written. When you launch the campaign again, Plan sees the completed outputs, treats those units as done, and continues with the remainder. A reboot is no different from a crash in this respect. The application coming back up does not mean the batch starts over; it means the batch continues from wherever the filesystem says it was.

Parking on quota, and auto-resume

Here is the behaviour that sets Plan apart from a naive automation loop. Plan orchestrates the official command-line tools in interactive mode, which is to say it drives human-in-the-loop sessions rather than a metered programmatic or API path. The consequence is that a Plan run stays on your existing subscription instead of billing against a separate per-call meter.

That choice has a direct and honest cost, and Plan is designed around it rather than pretending it away: because a long bulk run lives on your subscription, it fully expects to reach the token or quota limits of your plan partway through a large batch, and when it does, it does not crash, error out, or throw away the units it has not reached yet.

Instead, Plan parks. It stops issuing new work, holds the position of the batch, and waits. When your plan's quota window refreshes, Plan auto-resumes and keeps going with the units that remain. You do not have to sit and watch for the moment your budget replenishes, restart the run manually, or reconstruct where it stopped. Parking and auto-resuming is expected behaviour under this model, not an error state. It is the price of staying on your subscription, paid automatically.

This is why the continuity engine exists in the first place. If Plan ran against a metered API, hitting a limit would be a billing event rather than a pause, and the whole subscription-only premise would fall apart. Because it runs interactive sessions on your plan, tolerating quota windows and resuming across them is not a bonus feature; it is the requirement that shaped the design.

Managing a campaign

Plan is not only a launch button. The 3.0 release includes the everyday controls you need to run campaigns without dropping into a terminal, and each of these landed with a specific commit in June 2026.

Editing a campaign

You can edit a campaign by clicking its card. Doing so opens an advanced popup that is pre-filled with the campaign's current settings, so you are adjusting an existing definition rather than re-entering it. Under the hood this is handled by the orch_update_campaign path, added on 9 June 2026. The practical effect is that a campaign is a living object you can revise, not a one-shot form you fill in and lose.

Deleting a campaign safely

Deleting a campaign shows a confirmation popup first, a guard added on 9 June 2026. Bulk work represents real accumulated output, so an accidental single click should not throw it away. The confirmation step is a small thing that matters exactly once, on the day you almost deleted the wrong campaign.

Watching the queue

The queue has a split view with automatic purge, which arrived on 16 June 2026. The split view lets you see the state of the batch, and the automatic purge keeps the queue from filling up with stale entries as units complete and cycle through. Together these keep a long-running campaign legible, so that a batch of hundreds of units does not turn its own status display into noise.

Taken as a group, onboarding, brief templates, AI brief generation, click-to-edit, delete confirmation, the language-aware launch instruction, and the split queue with purge are the connective tissue that makes the continuity engine usable day to day. The engine provides the resumable parallel runs; these features make the engine something you can actually operate.

Where Plan fits in Open Free Max

Open Free Max is a lightweight native desktop IDE built on Tauri, Rust, and TypeScript, and it runs on Windows and macOS. Plan lives inside that application as one of the four top-bar surfaces alongside Wall, IDE, and Settings. It is not a separate service, a cloud dashboard, or a hosted queue. It is a mode of the desktop app you already run.

That matters for two reasons. First, the outputs land on your own machine, in your own files and folders, which is the same fact that makes the runs resumable. Second, the whole thing sits behind the same subscription-only model as the rest of the product, driving official CLIs in interactive sessions rather than reaching for a billed API. Plan does not change how Open Free Max is metered; it inherits the model and is engineered to live within it.

If you have used the IDE surface to work on a single task interactively, Plan is the same interaction pattern multiplied. The individual unit is still a human-in-the-loop agent session of the kind you already know. Plan's contribution is to run many of them, track each one by its output, and keep the batch moving across interruptions you would otherwise have to manage by hand.

Honest limits

A product-news article that only lists strengths is a brochure, so here is the candid boundary of what Plan does today.

Plan is a bulk executor, not a planner of intent. It runs the brief you give it across the units you define. It does not decide what your batch should contain, judge whether the brief is a good idea, or verify that the output is correct beyond the fact that a unit produced its file or folder. The presence of an output marks a unit as done; it does not certify that the output is right. Quality control of the results remains your responsibility, and a weak brief will produce a batch that is uniformly weak. The AI brief generation feature drafts a starting point from a short description, but it is a draft to refine, not a guarantee of a well-formed job.

The auto-resume behaviour is a response to quota windows and interruptions, not a way to escape your plan's limits. Plan does not grant more capacity than your subscription provides. On a large batch it will reach your quota and park, and it will resume when the window refreshes, but the total work still fits inside the budget you already have. If a batch is large enough, finishing it may span more than one quota window, with parking in between. That is by design, and it is the honest trade-off of staying on your subscription rather than billing per call.

Language support for the launch instruction covers English, French, and Spanish. Those are the languages the instruction is passed in as of the changes dated 9 June 2026. If you work in another language, the launch instruction itself is not among the supported options today.

The platforms are Windows and macOS, matching the desktop application. Plan is part of that native app; it is not offered as a standalone web service.

One more boundary is worth naming: a unit is only as independent as you make it. Plan runs units in parallel, so a job whose steps depend on each other in strict sequence is a poor fit — the engine works best when each unit can produce its output without waiting on another. Splitting the work into genuinely independent units stays a human decision, and it is what determines whether a batch parallelises cleanly or fights itself.

How to try it

Plan ships in the public Open Free Max 3.0 release, so there is nothing to enable separately. Install or update the desktop application, open the Plan tab in the top bar, and use the onboarding path to define your first campaign. Start small. A short list of units is enough to see the full loop end to end: the shared brief, the parallel agent sessions, one output per unit, and the batch reporting itself finished when every unit has its file or folder.

Once you trust the loop on a small batch, scale the unit count up. On a larger run you will eventually see the behaviour that defines Plan, where it reaches a quota window, parks, and resumes on its own when your plan refreshes, without losing the units already completed.

To download the current release, go to /#download. For the full documentation, including the details of briefs, templates, and campaign management, see /docs. Both are the right starting points; everything in this article reflects what the public 3.0 release does today, drawn from the continuity engine that first shipped in the 1.1.0 line on 8 June 2026 and the supporting features that followed through that month.

Summary

Plan is the answer to a narrow, common frustration: running one agent task across a long list without watching it. You write a brief once, split the job into units, and Plan runs a pool of interactive agent sessions in parallel until the batch is done. Each unit writes its own file or folder, which is what makes the run idempotent and fully resumable, because an output on disk is the record that a unit is complete.

It survives crashes and reboots by reading that record rather than trusting memory. It stays on your subscription by driving official CLIs in interactive sessions, and because of that it expects to hit quota limits, so it parks and auto-resumes when your plan refreshes. Around the engine, 3.0 adds onboarding, brief templates, AI brief generation, click-to-edit campaigns, a delete confirmation, a language-aware launch instruction, and a split queue with automatic purge.

The limits are as clear as the features. Plan executes your brief; it does not judge it, and it does not verify results beyond their existence. Auto-resume manages quota windows; it does not raise your quota. Supported instruction languages are English, French, and Spanish, and the platforms are Windows and macOS. Within those honest boundaries, Plan turns a repetitive job into an unattended, resumable batch, and it does so without stepping outside the subscription you already pay for.