Cron Jobs: Schedule Tasks in Natural Language

Hermes brings cron-style scheduling to the agent world, letting you describe when a task should run in everyday language — "every morning at 9am" — instead of translating your intent into cryptic flags. Behind the scenes, scheduled tasks run in fresh agent sessions managed by the gateway daemon, so automation stays isolated from your interactive work. Whether you need a one-off reminder in half an hour or a recurring daily digest, Hermes turns a sentence into a reliable scheduled run.

Creating Scheduled Tasks

There are several comfortable entry points, all converging on a single cronjob tool with action-style operations. You can type /cron add "every 2h" "Check server status" directly in chat, use the standalone CLI with hermes cron create "every 1h" "Summarize new feed items" --skill blogwatcher, or simply ask Hermes in a normal message — for instance, "Every morning at 9am, check Hacker News for AI news and send me a summary on Telegram." The agent reads the request and wires up the job internally.

Jobs can be one-shot or recurring, support pausing, resuming, editing, triggering, and removal without being recreated, and can attach zero, one, or multiple skills so an agent inherits reusable workflows on schedule. Results can be delivered back to the originating chat, written to local files, or routed to configured messaging platform targets.

Picking the Right Model

Every job resolves to a model at fire time using a clear precedence: a per-job pin, then cron.model from config.yaml, then the global default. You can pin a model per job through the dashboard, hermes cron create/edit --model … --provider …, or by editing ~/.hermes/cron/jobs.json. Notably, switching your chat model with hermes model never changes your cron fleet: Hermes snapshots the provider and model at creation time, and that snapshot acts as the job's effective pin. If you set cron.model, every unpinned job follows that fleet-wide default, independent of your chat model.

Jobs can also pin their own reasoning effort — from none to ultra — separate from the model. This lets heavy scheduled analyses run at high thinking while cheap recurring jobs run at minimal, without touching your global defaults. One caveat: cron-run sessions cannot recursively create more cron jobs, which prevents runaway scheduling loops, though you can opt back in with cron.allow_agent_scheduling: true.

No-Agent Mode and Validation

For pure script-on-a-schedule needs, Hermes supports a no-agent mode where a job runs a command and delivers its stdout verbatim — zero LLM involvement. This is ideal for telemetry or operations where you don't need reasoning, just reliable execution.

Before dispatching any job, Hermes runs pre-dispatch configuration validation. It confirms the provider API key resolves, attached skills are ready, and delivery targets have credentials. If validation fails, the job reports blocked_config, delivers a single alert, and never spends tokens on a run that can't succeed. The next healthy run clears the blocked state. You can disable this check with hermes config set cron.preflight false if you prefer the older run-and-fail behavior.

Lifecycle Management

Cron jobs have a fuller lifecycle than simple create and remove:

• pause — keep the job but stop scheduling it
• resume — re-enable it and compute the next future run
• run — trigger it on the next scheduler tick
• edit — modify schedule, prompt, skills, or delivery
• remove — delete it entirely

Every mutating verb accepts a job's name (case-insensitive) in place of its hex ID. Because names aren't unique, ambiguous matches are refused with the list of candidate IDs so you never accidentally mutate the wrong job. You can even create a job already paused as a safe canary: hermes cron create "every 1h" "Post the digest" --paused.

Inside the Scheduler

The gateway daemon handles execution, ticking the scheduler every 60 seconds. On each tick it loads jobs from ~/.hermes/cron/jobs.json, starts a fresh AIAgent session for each due job, optionally injects attached skills, runs the prompt to completion, delivers the response, and updates run metadata. A file lock prevents overlapping ticks from double-running the same batch. Execution history is recorded in ~/.hermes/cron/executions.db, tracking attempts through claimed, running, and terminal completed, failed, or unknown states, inspectable with hermes cron runs.

Failing jobs get a repeated-failure review nudge — once a failure_streak reaches a configurable threshold (default 3), the failure message suggests fixing, pausing, or removing the job. Durable failure incidents, keyed by job plus error signature, let you acknowledge known failures so they stop pinging you while everything else stays tracked.

Key Takeaways

• Schedule tasks with natural language, /cron commands, or the standalone CLI — all backed by one unified cronjob tool.
• Model selection is deliberate: per-job pin, then cron.model, then a creation-time snapshot of the global default.
• Attach skills, pin reasoning effort, or run jobs in no-agent mode for a zero-LLM script on a schedule.
• Manage the full lifecycle with pause, resume, run, edit, and remove — by name or ID — without recreating jobs.
• The gateway scheduler ticks every 60 seconds with pre-dispatch validation, durable execution history, and failure nudging.