A timer keeps paying you back with no further effort, and keeps billing you with no further
attention. cron has done the paying-back half for forty years, for nothing. An agent session
doing the same job is not nothing. The numbers below come from one machine’s dispatch records: an
anecdote with a receipt.
A timer is nearly free. What the timer starts is not.
cron and launchd fire something at nine every morning for approximately nothing, open app or
not. What costs money is what wakes up. If your chore is “fetch a JSON document and send a
notification”, the answer is a shell script, and it is free.
A recurring chore does not have to be an agent at all. The question is not how often the job runs, but whether the run has to decide anything. A script executes; it cannot decide. It cannot read the repository, work out which of three things broke this morning and write the fix. That capability is the whole reason to pay more than nothing. So: which of your chores actually needs judgement?
Work out what fraction of one run is the thing you wanted
Before you put something on an agent timer, work out what fraction of one run is the thing you actually wanted. If the answer is a few percent, you are not automating a chore. You are buying a session every morning and using one corner of it.
We ran it on ourselves on 28 August 2026, starting with a daily weather push. It reads no project file, writes to no repository, fetches one JSON document and sends one notification.
It costs about 700,000 tokens a run, spent in under a minute. The clock is the giveaway: almost none of it is work. It is standing context, read once per turn, exactly as a four-hour task would read it.
Across five recorded runs of three daily chores the total was about 9.4 million tokens and $8.52 — 4.0% of every task that machine had ever dispatched. Between them they produced 51,000 output tokens.
Two of those three chores had no judgement in them. The number does not say schedules are bad; it says two shell scripts had been put inside two assistants.
The ratio you measure today is the best it will ever be. A loop feels cheap because software made it cheap: a program’s second run is nearly free. Agent work inverts that, because the expensive part is the reading. Every instruction file, skill and tool is standing context: useful to real work, and billed in full to a job that fetches one JSON document.
What a schedule buys when the chore needs judgement
For the chores that survive that test, a Clawdline schedule is not a separate, weaker code path. It is an ordinary dispatch with a clock in front of it.
It goes through the same gate as everything else. The same declared write paths that stop two sessions committing each other’s work, the same capacity limit and one-level dispatch ceiling, the same permission and trust checks, the same task record at the end.
A schedule can also be a single named date rather than a set of weekdays. Think of a maintenance window at half past one on the sixth, which then retires itself. And a paired phone can create, retime and delete schedules, behind a remote-settings switch that is off until you turn it on. Read that both ways. A phone can remove work that would otherwise run unattended, and a wrongly timed schedule need not wait for you to reach the Mac. Stopping a run already going is a different write behind the same switch, with its own post.
When the Mac was asleep, or the last run is still going
Three questions actually arrive.
| When this happens | The schedule does this |
|---|---|
| An occurrence was missed, and the app opens again inside the catch-up window | It runs, once, late |
| An occurrence was missed and the window has passed | It is recorded as missed and notified, not run late |
| A firing arrives while the previous run of the same schedule is still going | That occurrence is skipped and audited, rather than stacked on top of the first |
| Clawdline is not open | Nothing fires at all |
The catch-up window is per schedule, from nothing at all to a week, six hours unless you change it. The third row is the one worth having: a chore that occasionally runs long cannot quietly become two of itself.
The last row is the honest boundary. This is not a launch daemon and it will not wake a Mac that is
off; cron wins that outright.
Batch the ones that need judgement into one session
Three chores on three schedules pay three start-ups. One session that does all three pays one, and on the measurement above the start-up is nearly the whole bill.
The cheap version needs only a text editor: one schedule, one time. The instructions list the chores separately, so the report can say what happened to each. The fuller version keeps a session open between jobs and sends each chore in as its own task, with its own id, write paths, timeout and result file. One failure then cannot take the others with it.
What would fix the weather push is a schedule that runs a plain command and opens a session only
when the command fails. Clawdline has no such thing yet. Until it does, those chores go on cron.
Write down what would make you turn it off
A schedule is decided once and executed forever, which makes it the shape most likely to outlive its own reason. It never asks whether you still want it; it just keeps arriving, correctly, at nine.
So give every schedule a field saying what would have to happen for you to reconsider it. How long it has sat there without that happening is the best deletion signal there is. If you cannot answer it the day you create it, you have not automated anything. You have moved a habit somewhere you will stop noticing it.
Put every chore on the cheapest thing that can actually do it. cron for the ones that only
execute; a schedule, batched into one session, for the ones that have to look and decide.
New to the app? What it actually is is the place to start, and the workflows guide covers project rows, dispatch, schedules and delivery in order.