DOCS · SCHEDULING & RECURRING RUNS
Work that runs on a schedule.
Some jobs should repeat without being asked twice — the same brief every morning, the same check every Monday. A scheduled run is a recurring job you set up once and SynthOS runs on a clock. It registers with macOS, so the work happens on time even when the app window is closed — as long as your Mac is awake. This page documents exactly how that works, where the honest limits are, which plan unlocks it, and how to start, change, or stop a schedule.
THE BASICS
What a scheduled run is.
A scheduled run is a job you describe once and attach to a recurrence — every morning at 7, every weekday, the first of each month. From then on SynthOS runs it on that clock without you opening it each time.
When you save a recurring job, SynthOS registers it with macOS as a scheduled task on your Mac. The operating system keeps the clock; at the appointed time it wakes SynthOS to run the job, then the job finishes and steps aside until the next occurrence. Because the schedule lives with macOS rather than inside an open window, the app window does not have to be open for the run to happen — you can close it and the next run still fires.
A run is the same work the app does in front of you — an agent (or a crew of them) carrying out the job you described, running real tools on your Mac, with a receipt for every action. The only difference is who started it: a clock, instead of you typing. Everything a scheduled run produces files into your vault exactly as a run you kicked off by hand would, so you can read it back when you return.
Scheduling does not give an agent any new power. A scheduled run can do exactly what the same job could do if you ran it live, under the same guardrails — it simply runs it on time, on its own.
WHAT IT IS NOT
The honest limits: app closed, Mac awake.
Two things are true at once, and it matters that you hold both: the app window can be closed, but the Mac itself has to be awake. A scheduled run is not a promise that work happens while your machine sleeps.
The app window can be closed. The schedule is held by macOS, not by an open SynthOS window. You can quit back to the desktop, switch to other work, or close the app entirely and the next run still fires when its time comes.
The Mac must be awake. A scheduled run executes on your machine, so your machine has to be running and awake at the scheduled time. If the Mac is asleep, shut down, or out of power when a run is due, that run does not happen in its place — there is no remote server quietly doing it for you.
No “while you sleep” promise. We don’t claim work gets done while your computer is off or asleep, because it doesn’t. What scheduled runs give you is work that happens while you’re away from the keyboard on an awake Mac — finished and waiting when you come back — not work that happens on a sleeping one.
Keeping the Mac awake is your call. If you want an early-morning run to fire while you’re still asleep, that’s a matter of keeping the machine awake and powered — plugged in, with macOS energy settings that don’t put it to sleep. SynthOS runs on the schedule; it does not override your Mac’s power state to wake a sleeping machine for you.
Closed app, awake Mac. Scheduled runs do the work while you step away — not while your computer sleeps.
PLANS
Which tier unlocks it.
Scheduled and recurring runs are part of the Orchestrate tier — $99/mo — and the tiers above it. Lower plans run the same agents, the same tools, and the same guardrails; what Orchestrate adds is the ability to put that work on a clock and let it run on its own.
Full hands-on work: agents edit your files and run your tools while you watch. No scheduling — runs are the ones you start yourself.
Everything in Build, with the brakes off and priority dispatch so a crew starts sooner. Still no scheduled, app-closed runs — that begins at the next tier.
Where scheduling unlocks. Set recurring jobs that register with macOS and run on schedule with the app window closed (the Mac awake), plus the morning brief of what got done while you were away. Everything in Run is included.
The tiers above Orchestrate keep scheduled runs and turn every limit up — a wider fleet and top priority — for operators whose schedule carries more work. See the pricing page for what each adds.
SETUP
Setting up a recurring job.
You set a schedule the same way you start any other job: describe what you want, then attach a recurrence. SynthOS turns that into a task registered with macOS.
Describe the job
Write the recurring job in plain language, the way you’d ask for it live — “each weekday morning, pull my inbox, calendar, and open issues, and write me a brief.” This is the instruction every run will follow.
Choose the recurrence
Pick how often it should run and when — daily at a set time, on chosen weekdays, weekly, or monthly — in your Mac’s timezone. This is the clock macOS will keep. You can change it later.
Set its guardrails
Confirm the limits the run inherits — a spend ceiling through your own provider key, and what it may do versus what it must pause and ask about. A job that runs unattended leans harder on these, so they’re part of setup, not an afterthought.
Save — it registers
Saving registers the job with macOS as a scheduled task. From then on it runs on its clock whether or not the app window is open, as long as the Mac is awake. Each run files its work and receipts into your vault, and rolls up into the brief.
# a schedule is a job + a recurrence, registered with macOS. # times are in your mac’s timezone. a run that’s due # while the mac is asleep or off does not fire — it is skipped, # not queued forever. nothing about scheduling widens what an # agent is allowed to do; it only sets when it runs.
WHAT YOU COME BACK TO
The morning brief.
When scheduled runs happen while you’re away, you don’t have to reconstruct what occurred. SynthOS rolls them into a single summary — a brief of what got done — so you can catch up in one read.
The brief is a plain account of the runs that fired while you were away: what each one did, what it produced, and anything it paused to ask about. It’s a summary for reading, not a replacement for the record — every run still keeps its full receipts in your vault, so the brief is the headline and the receipts are the detail you can open underneath it.
The brief above is an illustration of the surface, not a real run. In the app it reflects the actual scheduled runs that fired since you last looked.
Because the brief is honest about what happened, it shows the things that didn’t finish too — a run that hit an error, or one that stopped to ask a question only you can answer. Nothing waits silently: if a scheduled run needs a decision, the brief is where you’ll see it, and the run holds until you make the call.
GUARDRAILS
Guardrails on scheduled runs.
A run that fires while you’re away is held to the same rules as one you watch — and in some cases held tighter. The guardrails don’t relax just because no one is looking.
Ask-first still applies. Anything destructive, irreversible, or that spends money pauses for your approval — it does not auto-approve itself because it’s running on a schedule. A run that reaches one of these stops at that point and waits; you’ll find it flagged in the brief when you return.
A receipt for every action. Every command a scheduled run executes and every result it gets is recorded, the same as a live run. An unattended job leaves the same readable audit trail, so “what did it do at 7am” always has an exact answer.
A spend ceiling holds. The limit you set on what a run can cost through your own provider key applies to scheduled runs too. When a run approaches the ceiling it stops and records why rather than quietly running up a bill while you’re away.
It stays on its own piece. A scheduled job runs its instruction and the work that follows from it — not a wider mandate. It has no more reach unattended than it would with you watching; the schedule sets when, never what.
The point is simple: leaving a job to run on its own should feel as safe as starting it by hand. Receipts, the spend ceiling, and ask-first are what make that true, and they ship in every tier — they are never something scheduling switches off.
MANAGING A SCHEDULE
Stopping, editing, or pausing a schedule.
A schedule is yours to change at any time. You can edit what a job does or when it runs, pause it without losing it, or remove it entirely — and you can stop a run that’s in progress.
Change the instruction, the recurrence, or the guardrails on an existing schedule. The change re-registers the job with macOS and takes effect from the next run — a run already in flight finishes on its old terms.
Pause a schedule to stop future runs without deleting it. The job and its settings are kept; nothing fires while it’s paused. Resume it later and it picks up its clock again from the next scheduled time.
Stop a run that’s currently executing. As with any run, the kill-switch halts the work in flight and keeps the receipts of everything that already ran, so you can see exactly where it ended.
Delete a schedule to remove it for good. SynthOS unregisters the task with macOS so it never fires again. The work and receipts from past runs stay in your vault — removing the schedule doesn’t erase what it already did.
Edit it, pause it, or remove it — the schedule answers to you, and stopping it never loses the record of what it already did.
KEEP READING
Put the recurring work on a clock.
Scheduled runs are part of Orchestrate in SynthOS — the AI operating system for a company of one. Get the app and set your first recurring job, or read how the agents that carry it out actually work.
App window can be closed · Mac must be awake · Receipts & spend ceiling · Ask-first on risk.