Cron Task Creator

Create and manage octo cron tasks

octo runs an agent prompt on a schedule. Each task is a JSON file in ~/.octo/tasks/, loaded by the scheduler inside octo serve. When a task fires, the scheduler runs one agent turn with the task's prompt in a fresh session — a run never sees an earlier run's transcript. What's worth keeping across runs goes in long-term memory: each task has its own project, and with it its own working directory and memory directory, so a note one run saves is in the next run's memory block. Each run is bounded by a 30-minute wall-clock timeout (the only hard cap on a run).

Task schema

id, created_at, last_run, session_id, session_group_id are server-managed — never set them by hand except id in the file-write fallback below.

Every run creates a fresh session (titled by the run's local date and time) and files it under a per-task session group named after the task, so a task's runs cluster together in the sidebar. The group is created with the task and renamed/deleted along with it. Runs never share a session — each starts from a clean transcript.

Cron expression — 6 fields, seconds first

The scheduler uses robfig/cron with a seconds field. A standard 5-field crontab line is invalid — always prepend a seconds field:

seconds minutes hours day-of-month month day-of-week

Descriptors also work: @hourly, @daily, @weekly, @every 90m. Times are in the server's local timezone.

Minimum interval is 1 hour. The scheduler rejects any expression whose consecutive fires are closer together than that (e.g. 0 */30 * * * * or @every 10m) — the seconds/minutes fields exist for picking a precise time of day, not for sub-hourly polling. If the user wants faster iteration, use /loop in a live session instead of a cron task.

Workflow

1. Gather the schedule, the prompt, and any optional fields. If the schedule is vague ("every morning"), pick a concrete time and confirm.
2. Translate to a 6-field expression and echo it back in plain words ("every weekday at 18:30") before creating anything.
3. Write a self-contained prompt. The task session has no access to this conversation — the prompt must carry all context: what to do, where, and what the output should look like. When a run depends on what earlier runs found ("only report issues I haven't seen"), have the prompt say what to save to memory at the end of each run and to check it at the start.
4. Give the prompt an explicit stop condition. An open-ended prompt makes the model keep re-verifying until the 30-minute timeout instead of finishing. Spell out when the task is done, especially the empty case:
   • Bad: "Check the repository for any new open issues that need attention."
   • Good: "List open issues created in the last 24h via one gh issue list call. If there are none, reply exactly 'no new issues' and stop. Otherwise summarize each in one line and stop — do not re-check."
5. Create, then verify by listing. To smoke-test it, point the user to the scheduler panel and have them click Run on the task — do not call the run endpoint yourself from this session. A run is a full agent turn (up to 30 minutes) in the task's own session; firing it from here just blocks this conversation and the output lands in a session the user isn't watching. The panel runs it where they can see it.

Editing a task

The Web UI's edit button opens a session with the skill arguments edit <id> "<name>". There is no single-task GET — find the task in GET /api/tasks by id.

In that session (or whenever the user is clearly in the Web UI), open with an edit form instead of asking what to change. Elsewhere (TUI, IM), list the current fields as text and ask.