Let it run on its own

The three kinds of automatic

Work mode (run to completion)

For work that won't finish in a single reply. It only resumes when the response ended mid-task; if it needs a decision from you, it stops and waits.

Auto-continued messages are labelled 🏁 Continuing the work (automatic), so they're never confused with your own instructions. When it stops, the reason is stated (details).

Autonomous runs (laps)

This mode cycles through executing, verifying and correcting. While it runs you see a meter showing laps completed, usage and elapsed time.

The stopping conditions are spelled out in the app:

Stops on: completion, a dangerous operation, no progress, or {n} laps. Other threads stay usable while it runs.

To end it early, press Stop or Esc.

Loops (scheduled runs)

A loop is how you hand over “please do this every week”. Create one from Loops in the sidebar.

Build it, run it, look at what came back, fix it — keeping that circuit turning is what we call loop engineering. No cron, no YAML. There is a short definition in the glossary.

Built through conversation

You don't fill in a form — you settle the conditions by talking, and each answer fills in the “what's decided” panel on the right. There are five core questions:

1. What you want done — the job itself

2. When — Daily, Weekdays, Weekly or Manual only, plus a time

3. What “done” looks like — how it knows to stop

4. What to check with you — where it should pause and ask

5. What happens afterwards — what to do with the result

The loop can't run while anything is still undecided. You can also add your own items — target sites, what to look at, where to record, what to exclude — as the work requires.

Anything you pick under Reference material while building the loop stays on as a named chip. Drop one with ✕; + Add material lets you pick several at once, and whatever you've already chosen disappears from the list of candidates.

Creating one from a thread

The job doesn't have to be pinned down before you start — explore it in a thread first. Once the direction is clear, press ⋮ beside the send button → Turn this thread into a loop.

Only what was explicitly settled in the conversation is carried over into the request, and the Create a loop screen opens already partly filled in. Anything still vague is never filled in on a guess — it comes back to you as “only these two points are left”. The knowledge and connections the thread had equipped are carried over too, and the finished loop keeps a link back to the original thread.

Run research loops on a cheaper model

For scheduled research, the web-research saving applies to loops too. Whether a loop involves research is judged automatically from the request, and every turn of the run — the first one as well as the laps — goes through Claude→Haiku 4.5 or ChatGPT→Luna. You can also switch it by hand under Research economy in the loop's detail view.

Choosing the AI it runs on

Each loop picks its own AI for the run — Claude, ChatGPT, Kimi or Antigravity — and its model. Set it under AI to use in The request, and it applies to that loop's runs.

To vary it by step, say so in the request — “research with Claude, images with GPT” — and it switches as it runs.

Connections used when running

A loop can carry external connections (SSH or an outside service). Both the Create a loop screen and the loop's own detail view have a Connections used when running (SSH, external services) picker, and whatever you choose there is attached to every run thread automatically. That's what lets you hand over a job like “SSH into the server and post an announcement on our own site”. Setting the connections up in the first place is covered under Connect (servers, MCP, APIs, email).

How much to delegate

You also decide how many times it may stumble on the same point, and how many retries before it asks you.

Try it before you schedule it

Don't jump straight to a schedule. Use Try it now once and read the result. There's also a review feature that flags gaps such as “what ‘done’ looks like is empty” or “your documents contain zero rules”.

Running on schedule

Switch on Run on schedule and it fires at the time you set. The next run is displayed on screen (Next: {date and time}).

For a late-night schedule, a sleeping Mac means it won't fire on time. Keep it plugged in if the timing matters.

Catching up a run you slept through

A slot that was missed because the Mac was asleep at the scheduled time is run retroactively the next time the app starts. It looks back over the last eight days. A daily loop no longer vanishes when the date rolls over, and a “every Tuesday” loop no longer skips to the following week just because you slept through Tuesday.

• A caught-up run is marked Ran late, and the time it was originally due is shown
• Missed slots are never fired off all at once — only the most recent one runs
• Slots that passed before you switched Run on schedule on are still not caught up

Reviewing what it did

Each loop has exactly one thread, and every run lands inside it as a child thread. Loop threads are prefixed with 🔁 and are easy to spot in the list.

• What it did — a weekly timeline showing when, the result, the duration, the number of laps, and a closing line
• Things to watch — observations from the runs
• Run status — Finished / Something to check with you / Stopped partway / Working

Only the most recent runs stay in the list; older ones are archived automatically. View opens them again.

Reading a run at a glance

Every entry in the record carries a one-line summary of that run (for example, “All three held their prices; B launched free shipping”). Scanning the list alone tells you which runs actually found something.

Open Details and the substance is laid out as bullets, with any files the run produced — a spreadsheet, a log file — openable right there. If there's something a person needs to do next, exactly one item is shown. Most of the time you never need to go into the thread itself.

The summary is written under instructions to skip empty sentences like “task completed” and to state the figures, the names and whether anything changed. The file list isn't the AI's own account of its work — it's the files that were actually created or updated.

Continuing a run that stopped

Every entry under What it did has a Continue button, so a run that stopped partway — or one sitting and waiting on a decision from you — can be restarted from where it left off. Runs whose record had already closed, and were previously out of reach, can be picked up too.

Pressing it puts that run's record back into a working state, re-applies the automatic-run setting, and opens the thread so the work carries on. The AI is told this is the continuation of unfinished work rather than a new request, and that the parts already done are not to be redone. When it ends, the automatic setting is released as usual.

Changing it afterwards

Edit lets you rewrite each item. You can also just say it in the chat below — “add a third site”, “change where it records”, “make it Tuesdays” — and it updates. Changes take effect from the next run. Edits appear on the same timeline as the results, so you can trace why the output changed.

Getting smarter every lap

Each time a loop completes a lap, your digital twin reads that run's exchange and proposes what to add to the rules so the same question doesn't come up next time.

Nothing enters the rules until you press Adopt — it never rewrites the loop on its own. What you adopt is logged on the timeline as an edit (Edited …), so you can trace when each rule was added.

Getting the result by email

With SMTP configured, the outcome is emailed when the loop finishes. Subject, body and recipient are assembled by the app, so the AI is never handed a way to send mail itself. Setup is under SMTP email.

Deleting a loop

Deleting a loop leaves the threads it produced intact, so you can tidy up without losing the record.

Where to go next

• Skills — settle the procedure before you automate it
• Knowledge — the rules it should read every time
• Approval mode — the safety catch on all of this