How to schedule recurring tasks for an AI coding agent

Summary

• To schedule a coding agent, something has to start a fresh session on a recurrence with a stored prompt and record whether the run worked. Some agents ship a scheduler; Omnigent adds one across many agents.
• Claude Code documents Routines (cloud), Desktop scheduled tasks (your machine) and /loop (repeat a prompt in a CLI session). Hermes Agent has a built-in cron scheduler.
• Omnigent's Automations fire a real session on an RFC 5545 RRULE, not cron, from the web UI, POST /v1/scheduled-tasks or the sys_scheduled_task_* agent tools. There is no automatic retry and no replay of missed fires.
• The open-source Omnigent project lists "Status: alpha". On Databricks, "Omnigent is in Beta", with a managed server, Foundation Model APIs and Unity Gateway, and Databricks Sandbox hosts.

How to schedule recurring tasks for an AI coding agent

Give the agent a stored prompt and a recurrence, and let a scheduler start a fresh session each time the rule fires. You can use the scheduler an agent ships with, call the agent's non-interactive mode from a scheduler you already run, or use a meta-harness such as Omnigent, whose Automations work across the agents it launches. Whichever you pick, make sure every run leaves a record: an unattended agent that fails quietly is worse than none.

Which coding agents can run on a schedule?

Option	How you schedule it	What to know
Claude Code Routines	The web, the Desktop app, or /schedule in the CLI	Run in the cloud, so they keep going when your computer is off; can also trigger on API calls or GitHub events
Claude Code Desktop scheduled tasks	The Claude Code desktop app	Run on your machine, with access to local files and tools
Hermes Agent	Its built-in cron scheduler	Tasks are written in natural language and run unattended
A print-mode CLI	claude -p, Cursor's agent -p or pi --print, called from cron or CI	You own retries and logs; Cursor only proposes file changes unless you pass --force
Omnigent Automations	Web UI, REST API or agent tools, with an RRULE	Each schedule binds to an Omnigent agent

How do Omnigent Automations work?

"Automations" is the web UI's name; the REST paths and agent tools call the same feature a scheduled task. Each firing creates a real session, bound to an agent, that runs the stored prompt. You can create one on the Automations page (/tasks), with POST /v1/scheduled-tasks, or from an agent with sys_scheduled_task_create, so an agent can schedule its own follow-up work. The REST API requires name, prompt, rrule and agent_id and rejects unknown fields:

{
  "name": "weekday triage",
  "prompt": "Triage issues opened since yesterday and post a summary.",
  "rrule": "FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=9;BYMINUTE=0",
  "agent_id": "ag_...",
  "timezone": "UTC",
  "execution_target": "connected_host"
}

timezone defaults to UTC and execution_target to connected_host. Other optional fields are model_override, reasoning_effort, permission_mode, max_cost_usd, workspace and host_id.

How do you write the schedule?

Schedules are RFC 5545 recurrence rules evaluated in the task's IANA timezone. The guide's examples are FREQ=HOURLY for every hour and FREQ=DAILY;BYHOUR=9;BYMINUTE=0 for daily at 09:00 local time. Create and update reject a rule whose sampled occurrences sit less than an hour apart, a rule that never fires, and a rule that fires only once. Passing that check puts no bound on cost, so set a budget too.

What controls apply to each run?

Control	What it does	Watch out for
max_cost_usd	Gives each fired session its own cost-budget policy, which blocks later requests and tool calls once spend reaches the cap	It can't interrupt a model turn in progress, so spend can overshoot
permission_mode	Sets the Claude Code mode: default, auto, acceptEdits, plan, dontAsk or bypassPermissions	Only for claude-native agents; default and plan can leave a run waiting for approval
execution_target	connected_host uses a pinned host or the owner's most recently active live host; managed_sandbox provisions a fresh sandbox per firing	An offline host records a failed run, such as host_offline; existing managed sandboxes can't be pinned

Server, agent and session policies still apply to the sessions an automation creates.

What happens when a run fails?

GET /v1/scheduled-tasks/{id}/runs returns history with a status (running, succeeded, failed or skipped), timestamps, the conversation_id and an error_code. The guide is plain about current limits: there's no automatic retry, and the next occurrence fires normally. Fires missed while the server was down aren't replayed, an overlapping fire of the same task is dropped, and a late tick is skipped. To test a new automation, POST /v1/scheduled-tasks/{id}/run fires it immediately without disturbing the schedule.

How Databricks approaches scheduled coding agents

On Databricks, "Omnigent is in Beta". Databricks runs a managed Omnigent server that integrates with your workspace's identity provider, provides model access through the Foundation Model APIs and Unity Gateway, and offers Databricks Sandbox hosts, which Databricks provisions in the cloud and which keep running when your laptop is off. Two documented limits: Omnigent on Databricks supports built-in contextual policies and custom policies written in Common Expression Language (CEL), not custom Python policies, and a Databricks Sandbox host routes model access through Unity Gateway, so you can't bring your own model API keys to it. Databricks Sandbox is in Beta in select AWS regions.

FAQs

Can I use a cron expression for an Omnigent automation?

No. The automations guide says it in a heading: "Schedules are RRULEs, not cron".

Does a failed automation retry automatically?

No. Omnigent records the failed run with an error_code and fires the next occurrence on schedule.

How do I keep a scheduled agent from running up costs?

Set max_cost_usd on the automation, knowing it can't stop a model turn that's already running. For a cap across sessions, Omnigent's policy guide documents user_daily_cost_budget, a per-user daily budget an admin can apply server-wide.