Schedules

Cmdop schedules work by conversation rather than by a cron entry: you ask, in an ordinary request, for something to happen later or on a cadence. The machine stores that instruction durably and runs it as a fresh turn in the original session, so a program can schedule work, disconnect, and read the result later.

There is no scheduler to wire up and no cron entry to point at a machine. The phrasing of the request is the schedule, and the machine keeps it.

await client.machines.ask(
    machine_id,
    "Every weekday at 09:00, check the open release blockers "
    "and give me a short status.",
).collect()

The call returns immediately. The schedule outlives it.

One-shot and recurring

The phrasing decides which you get. “In five minutes” is a one-shot; “every five minutes” is recurring.

In 30 minutes, check whether the deployment finished and summarize the result.

At 2026-07-22 09:00, remind me to review the release checklist.

An absolute time without an offset is read in the machine’s own timezone, so give an RFC3339 timestamp with an explicit offset when your program runs somewhere else.

What to expect when one fires

A fired schedule comes back into its original session as a new turn, with the tools and permissions that apply at that moment. The result is written into the session’s history, so a program can pick it up later:

history = await client.machines.messages(machine_id, session="2", limit=20)

That is the intended shape — schedule the work, disconnect, read the outcome out of the session afterwards. See Sessions.

Limits worth designing around

• The machine’s agent must be running for a schedule to fire.
• A missed one-shot is dropped rather than replayed. A recurring schedule advances to its next future occurrence instead of catching up.
• Recurring schedules expire after seven days unless renewed, and a fleet-wide cadence is jittered so every machine does not wake at the same instant.
• A session holds a bounded number of active schedules — a few dozen, not thousands. Schedules are per session, not a global queue.

Inspecting and cancelling

Ask in the same conversation to list or cancel them — schedules belong to the session that created them.

Show my scheduled tasks.

For a view across the fleet, the web console shows every armed schedule with its last and next fire time, and lets you delete one. See Armed schedules.

Related

• Sessions
• Armed schedules
• Programmatic access

Common questions

How do I schedule work from code?

Ask the machine in ordinary language to do something later or on a cadence. The machine stores that instruction in the session and runs it as a future turn.

Does Cmdop create cron entries?

No. Schedules are conversation-owned instructions on the machine, not cron entries or a global queue. Inspect or cancel them through the original conversation or the web console’s armed schedules view.

What happens if a schedule fires while my program is disconnected?

The result is written into the original session history. Reconnect later and read the session messages instead of keeping a process attached for the whole delay.