Open Free Max 3.5 introduces recurring work with the heartbeat

Open Free Max 3.5 adds recurring work, a new way to ask an official CLI agent to revisit a local project on a schedule.

The feature is called the heartbeat because it is designed to keep a project checked without turning every check into an interruption. You define a checklist, choose when the work should run, select the local provider and project, and decide what should happen when the agent finds something. If the checklist finds nothing that needs attention, the turn can end with a quiet acknowledgement. If it finds a meaningful change, it writes a report you can open. If the decision is genuinely ambiguous, it waits for you.

This is scheduled work inside Open Free Max, not a remote automation service. The agent CLI still runs locally through the same interactive PTY path used by the rest of the application. The heartbeat does not handle provider credentials, call an SDK, or switch a subscription session into a hidden API workflow.

What is shipping

Recurring work is built around a small unit called a schedule. A schedule belongs to a project and has a label, a provider, an optional agent or skill, a checklist, a prompt template, a cadence, and an output directory. Its purpose is explicit: ask an agent to perform the same kind of review repeatedly, then make the result visible only when there is something worth reading or deciding.

There are two cadence options in the first release:

• Run at an interval, such as every 30 minutes or every six hours.
• Run at fixed local times, such as 08:00 and 18:00.

An optional active-hours window can restrict a job to a range in the machine's local time. Without that window, recurring work is available at any hour. This is a 24/7 scheduling model in the practical local sense: the schedule has no default night boundary, but it only fires while the computer and Open Free Max are running.

The interface shows each schedule's next run, status, last acknowledgement, last report, daily turn count, and any missed slots. A report is an actual link to the file produced by the turn. An acknowledgement is a successful « nothing to do » result, so it updates state without creating a new report to read.

A checklist is the centre of the job

A recurring job does not begin with a vague instruction to « keep an eye on things ». It begins with a checklist.

The checklist is the durable responsibility that the agent receives each time. It can ask the agent to inspect dependency notices, review a folder of notes, look for stale documentation, compare a local project against a set of release conditions, or perform another repeatable check. The more concrete the checklist, the easier it is for a user to understand why a turn ran and whether its result is useful.

A job also has a prompt template. The template gives the turn its output convention and can refer to the checklist, the report path, the acknowledgement path, the selected agent, the configured skill, and the current unit. This makes the result predictable across turns. The job is not asked to invent a new reporting format every time it runs.

The default output directory is '.ofm/heartbeat' inside the project. Reports and acknowledgements are stored below that directory. The convention keeps recurring output next to the work it describes and makes the local file boundary clear. Reports can be opened from the interface, while acknowledgements remain available as execution evidence without becoming a stream of prose.

A checklist can also be empty. In that case, the heartbeat skips the turn without consuming a daily run. This is useful when a schedule is being prepared or temporarily left in place while its responsibility is being rewritten.

Silence is an intentional result

The most common successful outcome for a monitoring job is that nothing requires action. Open Free Max treats that outcome as a feature.

A turn that finds no meaningful change writes an acknowledgement. The job's status and timestamps still move forward, but no report is added to the user's reading queue. This keeps the notification surface meaningful. A person does not have to dismiss the same « all clear » message several times a day in order to discover the one report that matters.

A turn that finds something worth sharing writes a report. The report can describe what changed, what was checked, what was repaired, or what needs a decision. The distinction between report and acknowledgement is not a model of success versus failure. Both are successful completions. The difference is whether the result carries information that deserves the user's attention.

This gives recurring work a different rhythm from a conventional alert system. The heartbeat checks often. It speaks selectively.

Human approval remains part of the loop

Recurring work can act when the checklist and project context make the next step clear. It does not get to turn uncertainty into an irreversible decision.

When a turn reaches a question that needs human judgement, the work is marked as coming from a recurring job and sent to the approval queue. Open Free Max also raises a system notification for that blocked turn. The user can then inspect the situation and decide how to proceed.

This behaviour matters for two reasons. First, an agent can be capable of editing a file while still lacking the context to know whether that edit is wanted. Second, the absence of a person at the keyboard should not be treated as permission to guess. The heartbeat is meant to remove repeated checking, not to remove ownership of consequential decisions.

The approval path is part of the same orchestration surface as other work. It is not hidden in a separate automation dashboard. A user can see that the request came from a recurring schedule, inspect its project and provider, and handle it in the same place as the rest of the local workflow.

Provider settings are scoped to the schedule

Official CLI providers do not all expose approval behaviour in the same way. A setting that is comfortable for a human-led session may stop an unattended recurring turn at its first confirmation.

To address that without weakening every manual session, each schedule can carry provider settings overrides. The override applies to the turn from that schedule only. It does not rewrite the user's global interactive configuration.

The available format follows the provider's own settings, such as:

• Claude: 'permissionMode=bypassPermissions'
• Codex uses 'askForApproval=never'
• Antigravity: 'mode=accept-edits'
• Mistral Vibe: 'agent=auto-approve'
• Kimi Code: 'auto=true'
• OpenCode: 'dangerous=true'

These settings are powerful and should be chosen deliberately. They describe how a scheduled job is allowed to proceed, not what Open Free Max believes every job should do.

The heartbeat also rejects flags that would turn the work into a programmatic or headless path. Options such as '-p', '--print', 'exec', or output-format switches that bypass the interactive session model are not accepted for recurring work. The feature launches the official CLI through a local interactive PTY. It does not create an API meter behind the user's back and does not provide a shortcut around provider authentication or subscription rules.

Local execution and local boundaries

The heartbeat runs on the machine that contains the project and the official CLI. The scheduler is part of the local Open Free Max engine. It does not require a remote worker to stay available while the computer is offline.

If the machine sleeps, no recurring turn fires. Open Free Max can request that the machine stay awake while an active schedule asks for it, but it cannot wake a sleeping laptop, and a closed lid still causes sleep on most portable computers. This is a straightforward limitation of local work, and it is important when choosing a cadence.

Missed slots are never replayed at boot. Suppose a job runs every hour and the computer is off for two days. When the application starts again, it does not launch 48 stale turns. It records the missed slots and calculates the next run from the current time. This avoids a sudden burst of work, protects the user's quota from surprising catch-up behaviour, and keeps a periodic check focused on the current state of the project.

Recurring work is therefore a scheduler for observations, not a durable event queue. If a workflow must account for every event that occurred while a machine was offline, it needs a different design.

Manual sessions always start

The heartbeat is designed to work alongside sessions that a user opens by hand.

A manual session should start immediately even if recurring workers are using the orchestrator's available slots. The concurrency limit applies to the heartbeat worker pool, not to the direct path for a human-led session. This preserves the central interaction model of Open Free Max: the user can open a project and drive an official CLI agent without waiting for automation to finish.

Within the recurring worker pool, schedules can have a priority. Lower priority values run after higher priority values, which provides a simple way to let human-oriented recurring checks take precedence over less urgent work. A global option can also reserve the final available worker slot instead of allowing heartbeat work to consume it.

These rules are intentionally visible in the product. Automation should not feel like it has taken possession of the workspace.

Quota and consumption controls

Recurring turns consume the user's subscription quota in the same way as other agent sessions. They are not free background calls, and the heartbeat does not make a provider's usage accounting disappear.

Open Free Max provides controls so the user can decide how much recurring work is appropriate. The global heartbeat settings include:

• A default maximum number of turns per day.
• A minimum interval between turns.
• A default priority.
• A maximum checklist size.
• A retention count for failed turns.
• An option to reserve the last worker slot.
• A global pause for the orchestrator.

A schedule can inherit the global daily turn limit, override it, or set zero to choose an unlimited value. The product does not impose a hidden high-water mark beyond the technical scheduling floor. The user decides whether a job should run occasionally, frequently, or without a daily cap.

The interface displays each schedule's turns for the current day. This makes the cost of a schedule part of the same surface as its state. A user can pause the engine, pause one schedule, reduce its cadence, or lower its daily limit without deleting the job.

The minimum interval is a technical safeguard. The scheduler cannot fire a job more quickly than the engine can evaluate its state. It is not presented as a judgement about how much a user should spend.

Memory and Obsidian options

Recurring work can use the local knowledge features already available in Open Free Max, but those behaviours are explicit per schedule.

A schedule can ask the agent to recall the project's memory before acting. This gives the turn access to relevant decisions and context from earlier work instead of starting every check with only the current file snapshot.

A schedule can also feed a completed report into the project's local memory. This ingestion is deterministic and does not depend on a model deciding whether the report is worth remembering. An acknowledgement is not ingested because « nothing to do » does not add useful project knowledge.

There is a separate option for maintaining one note in an Obsidian vault. The note is written through the vault's MCP server by the agent, so it is an instruction in the turn rather than a hidden direct write from the heartbeat engine. The one-note convention avoids producing a new vault note for every run of a job.

These switches let a user choose the amount of continuity that fits the project. A lightweight dependency check might need no memory. A recurring project review might benefit from recalling earlier decisions and recording reports. The schedule makes that difference visible.

Projects do not need Git

Recurring work can be useful outside software repositories.

A project can be a codebase, a book, a research folder, a set of documents, or an Obsidian vault. The heartbeat does not require Git, a build system, or a test command. It runs the checklist against the local project context that the user selected.

When a project contains Git, Open Free Max can add guidance that keeps the agent on the current branch and avoids an unintended push. That guidance is a CLI instruction, not a new technical sandbox. A recurring schedule does not create a branch automatically.

When a project has no version control, the user needs to understand the different recovery boundary. Files written by an agent may not be reversible through Git because there is no Git history. Open Free Max does not pretend that a schedule is a backup. For a first job in an unversioned folder, a read-only report is the safest starting point.

This is one reason the heartbeat is built around a checklist and an output convention. The user can begin with observation before allowing edits.

A simple first schedule

A useful first recurring job is a report-only review. For example, a user might create a schedule named « Dependency and security sweep », attach it to a project, choose a six-hour interval, and write a checklist such as:

• Inspect the dependency manifests and lockfiles.
• Look for advisories or suspicious changes already visible locally.
• Do not upgrade packages automatically.
• Write a report only when there is a concrete finding.
• Write an acknowledgement when there is nothing to report.
• Ask for approval if a decision requires changing a version or configuration.

The exact checklist will depend on the project. The important part is the shape: it defines the inspection, separates findings from actions, and states what the agent should do when it reaches a boundary.

After the job runs, the status line will show whether the latest turn is idle, running, deferred, skipped, or waiting. A report appears only when the turn has information to share. The user can then decide whether the next version of the job should remain read-only or receive a narrowly scoped write permission.

This staged approach makes it easier to evaluate a schedule against real work instead of assuming that a general autonomous prompt will behave predictably.

Where to find it

Recurring work is available from the workspace interface. The heartbeat panel lists schedules for the current project and provides actions to create, edit, pause, resume, run immediately, or remove a job. The panel shows the job's cadence, provider, current state, run count, last report, and next run.

« Run now » ignores the schedule time, active-hours window, and daily cap, but it will not start a second live turn for the same schedule. That exception is deliberate: testing a job should be easy, while launching overlapping turns that can edit the same project would be surprising.

The recurring work guide in the documentation covers the full set of states, provider-specific approval flags, quota settings, machine sleep behaviour, and output files:

/docs/recurring-work/overview/

The feature is also described on the Open Free Max homepage under recurring work, where the report, acknowledgement, approval, and local-execution model are shown together.

What the heartbeat is not

Recurring work does not make an agent smarter. It gives the agent another opportunity to inspect a project using a checklist and the context available to that turn.

It is not a full cron replacement. It does not wake a sleeping machine, replay every missed slot, or provide a five-field schedule language.

It is not a remote job runner. The project, engine, PTY, provider CLI, output files, and approval path remain local.

It is not a guarantee that an agent will understand an ambiguous request. When the next step is unclear or requires a human decision, the correct result is to stop and ask.

It is not a reason to remove backups or version control. A schedule can write into the current working tree, and the user remains responsible for the recovery strategy around that project.

These limits are part of the release. A recurring feature becomes easier to trust when its edges are explicit.

Available in Open Free Max 3.5

Open Free Max 3.5 brings recurring work into the same local, subscription-oriented workflow as manual agent sessions. It gives users a way to keep repeatable project checks moving while preserving the controls that make local work understandable: visible schedules, quiet acknowledgements, human approval, provider-scoped settings, quota controls, and an output file that belongs to the project.

The heartbeat is useful precisely because it does not speak all the time. It checks on the schedule you choose, reports when something matters, and leaves the workspace available for the work you choose to do yourself.

The release also makes the state of that background work inspectable. A user can see whether a schedule is waiting for its next slot, already running, deferred because a worker is busy, skipped because a window or limit applies, or paused by configuration. That vocabulary is part of the feature's reliability story. It lets a person distinguish a healthy quiet job from a job that could not run, without opening a terminal or guessing from the absence of a report.

For teams evaluating the feature, this means the first deployment can stay deliberately small. Create one schedule, attach it to one project, keep it report-only, and use Run now to observe the first result. The schedule can remain paused while its checklist is refined. Once the output is clear, its cadence, approval settings, and memory options can be adjusted independently from the rest of the workspace. Recurring work is ready to grow, but it does not require a large automation commitment on day one.

WHAT TO KNOW

• Recurring work runs official CLI agents locally through an interactive PTY.
• A checklist can produce a report or a quiet acknowledgement.
• Ambiguous work goes to the human approval queue.
• Sleeping machines do not run turns, and missed slots are not replayed.
• Daily limits, priority, cadence, and memory options are visible controls.

THE RECOMMENDED START

Create one report-only schedule for one project, use a generous interval, and run it manually once before enabling the cadence. Read the first few reports, adjust the checklist, and only then consider allowing the job to edit files.