If you run either OpenClaw or Hermes Agent long enough, you eventually stop chatting with it and start scheduling it. The point of having a daemon sitting on your machine isn’t to answer questions faster. It’s to get work done while you’re asleep. Daily briefings at 7am. Hourly log checks. A Friday digest posted to Slack. Both projects built a cron system for exactly this, and from the outside they look near-identical: jobs persist in jobs.json, survive restarts, tick inside the Gateway process (not inside the model), take cron expressions or intervals, and push results to a chat channel or webhook.
Look under the hood and the family resemblance evaporates. OpenClaw’s cron is a gateway-first orchestrator that treats the scheduler as one more surface on a large platform. Hermes’s cron is an agent-loop-first dispatcher that treats every scheduled run as a clean, isolated, skill-backed turn. The same problem, two very different answers.
This matters more than a spec-sheet comparison suggests. The choices each project made about sessions, skills, isolation, and scanning bleed into the kinds of workflows you’ll actually feel comfortable leaving unattended. I’ve been running both for the past several weeks against real schedules (morning standups, market monitors, inbox triage), and the day-to-day feel is not the same.
Here’s what’s actually different, starting with the scheduler itself and ending with the security trade-off that most comparisons skip.
The scheduler: staggering vs. ticking
OpenClaw’s cron lives inside the Gateway process and parses expressions with the croner library. Its most distinctive behavior is staggering: any recurring expression that lands on a top-of-hour boundary gets jittered by up to five minutes to avoid load spikes. If you schedule four jobs for 0 9 * * *, they won’t all fire at 09:00:00. You can opt out with --exact, narrow the window with --stagger 30s, or set timezones with --tz America/New_York. The Gateway keeps a background-task ledger and gives any run a five-minute grace period before it counts as lost.
Hermes takes the opposite tack: predictability over load smoothing. The gateway daemon wakes on a 60-second tick, reads ~/.hermes/cron/jobs.json, checks every job’s next_run_at, and spawns isolated sessions for anything that’s due. A file lock (~/.hermes/cron/.tick.lock) guarantees no overlapping ticks, and writes to the job store are atomic. Every job lives in one of four explicit states (scheduled, paused, running, completed), which makes “why didn’t this run?” debuggable without spelunking through logs.
Neither is strictly better. If you’re scheduling dozens of jobs at round hours, OpenClaw’s staggering prevents the “ten agents fighting for the same API credits” problem you’ll eventually hit on a Hermes box. If you want to be able to look at a single job and know precisely what state it’s in, Hermes’s explicit state machine is kinder to operators. OpenClaw optimizes for load distribution; Hermes optimizes for introspection.
The session model: flexibility vs. isolation
This is the biggest philosophical split and the one that will likely decide the tool for you.
OpenClaw gives you four session styles per job. A main job enqueues a system event on the next heartbeat turn, which is the right shape for reminders and nudges. An isolated job spawns a dedicated cron:<jobId> session, runs your prompt, cleans up any browser state, and exits. That’s the right pattern for reports and one-shot work. current binds the session at creation time so a recurring job inherits today’s context. And the interesting one: session:<custom-id> points at a persistent named session that builds real history across runs. A daily standup prompt in a custom session can remember yesterday’s blockers without you re-pasting them.
Hermes refuses to play that game. Every cron job runs in a fresh isolated AIAgent session, full stop. No conversation history carries over. If a prompt needs context, that context has to be in the prompt or in a skill loaded with the job. The justification is straightforward: cross-session isolation is how you keep a scheduled run from leaking (or stomping on) your interactive work.
The trade-off is real. A persistent-session cron on OpenClaw can do things a Hermes cron structurally cannot: compound knowledge over weeks, develop a working memory of a recurring project, converge on a better prompt through repeated turns. Hermes makes that harder to do badly, and harder to do at all. If you’ve ever watched an agent quietly pick up a bad habit over 50 iterations and then realized you had no idea when it started, you’ll understand why Hermes made this call.
Skills: prompt-driven vs. skill-backed
OpenClaw has a skills ecosystem (ClawHub is enormous), but its cron is overwhelmingly prompt-driven. You write a --message, optionally override the model with --model, tighten tools with --tools exec,read, shave startup cost with --light-context, and maybe pick a thinking level. Skills exist alongside cron rather than inside it.
Hermes inverts that. The unit of reuse in a Hermes cron job is the skill, not the prompt. You attach zero or more skills to a job; at tick time each skill’s SKILL.md is loaded in order and your prompt layers on top as the task instruction. Because Hermes agents also write their own skills after complex tasks (the self-improvement loop that everyone debates), cron becomes the natural home for work the agent has already learned how to do. “Run the ai-report skill at 9am every weekday” is a one-line job.
Hermes jobs can also run an optional pre-run Python script before the LLM turn, with a configurable 120-second timeout (HERMES_CRON_SCRIPT_TIMEOUT). That lets the expensive, deterministic part of a workflow (fetching data, normalizing JSON, dropping a file on disk) happen in cheap Python before a single token is spent on the model. OpenClaw handles the same problem by letting cron hit arbitrary tools, which is more general but also more token-hungry.
The management surface: many knobs vs. one tool
OpenClaw’s cron command surface is a traditional Unix CLI that has grown a lot of flags. openclaw cron add|edit|remove|list|run|runs|status, plus per-job flags for model, thinking level, tools, light context, announce channel, webhook, failure destination, stagger, timezone, wake mode, and more. In a multi-agent setup you can also pin a job to a specific agent with --agent ops. The power is real; so is the sprawl. Some agent authors have complained that they regularly forget to set "enabled": true when writing job objects programmatically.
Hermes consolidates everything into a single cronjob tool with an action parameter: create, list, update, pause, resume, run, remove. The chat-side equivalents are /cron add, /cron edit, and so on. Because there’s only one tool, there’s only one place for the recursion guard to live. More on that in a moment. The cost is less expressive per-job configuration than OpenClaw offers; the benefit is a smaller, safer surface to reason about.
Delivery: webhooks vs. platforms
The two systems split on output the same way they split on input.
OpenClaw offers three delivery modes: announce (post a summary to a target channel), webhook (POST a finished event to a URL), and none (internal only). The channel targeting is granular: Telegram topic IDs, Slack/Discord/Mattermost prefixes, and per-job failure destinations that fall back to a global cron.failureDestination. The webhook infrastructure is first-class: /hooks/wake, /hooks/agent, and user-defined /hooks/<name> mappings, all authenticated with a bearer token (query-string tokens are explicitly rejected). There’s also a Gmail PubSub integration that turns inbound email into cron-adjacent triggers with optional per-hook model overrides. This is clearly built for teams wiring the agent into an existing stack.
Hermes pushes in a different direction: more platforms, less plumbing. Delivery targets look like telegram:<chat_id>, discord:<channel_id>, local, origin, and so on across 15+ messaging integrations. The framework automatically wraps output and honors a [SILENT] prefix; the cron run can choose not to deliver at all, except in failure cases, which always notify. Outputs get persisted per-run at ~/.hermes/cron/output/{job_id}/{timestamp}.md, which makes “show me everything that happened last Tuesday at 3pm” a file-system walk rather than a log grep. There’s no first-class webhook story, though. If you need to push to a generic HTTP endpoint, you’ll be writing a skill.
The rough rule: OpenClaw wins if your cron is a node in a wider pipeline with external systems listening. Hermes wins if your cron’s job is mostly “run the thing and tell a human about it.”
Observability: log pruning vs. per-run artifacts
Neither project leaves you blind when a job misbehaves, but they record history differently enough that the debugging experience diverges.
OpenClaw treats run history as an append-only log with size and line caps (defaults are 2MB or 2,000 lines, auto-pruned). You inspect it through commands like openclaw cron runs --id <jobId> --limit 50 and openclaw cron status. That’s the right design for long-lived recurring jobs where you mostly want recent state, not archaeology.
Hermes writes every single run to its own file: ~/.hermes/cron/output/{job_id}/{timestamp}.md. Nothing gets pruned by default. That makes forensic questions (“what did the 3am job say last Tuesday when the alerts went off?”) a cat away, but it also means disk usage grows with fire-and-forget jobs. If you’re running a chatty five-minute schedule, you’ll be writing a cleanup cron for your cron.
Which is a decent segue to the part both projects most want you to think about, and most users don’t until something bites them.
Safety: operator diligence vs. automated scanning (that isn’t perfect)
The lazy summary is “Hermes is safer by default, OpenClaw is safer if you do the work.” That’s broadly true, but the April 2026 story is messier than it looks.
Hermes’s posture on paper is excellent. Prompts are scanned for prompt injection and credential exfiltration patterns at both job creation and pre-execution. Destructive root-path commands, invisible-Unicode payloads, and SSH-backdoor patterns are blocked. The Tirith pre-execution scanner adds another layer for homograph attacks, pipe-to-shell, and ANSI injection in under a millisecond. Cron management tools are disabled inside cron sessions, which gives Hermes something OpenClaw doesn’t have: a hard recursion guard. A compromised cron run cannot, by construction, spawn more cron jobs. Session storage paths are hardened against traversal. Sessions can’t read each other’s state.
Then comes issue #3968, reported March 30, 2026: the cron prompt-injection scanner (_scan_cron_prompt in tools/cronjob_tools.py) only scans the user-supplied prompt. The skill content loaded at execution time via _build_job_prompt in cron/scheduler.py is never re-scanned. Combined with cron jobs running non-interactively, which auto-approves commands, a malicious local skill turns into a clean execution path that bypasses Tirith entirely. The proposed fix is obvious in hindsight (scan the fully assembled prompt, move to a whitelist for cron toolsets), but the bug is a useful reminder: “scans prompts” is not the same thing as “scans what the model is going to see.” Hermes’s own skill-first design is what made skills the easiest bypass to miss.
OpenClaw’s cron doesn’t ship with anything like this scanning. It leans on the broader platform: the global openclaw security audit command, exec approvals, allowlists, and a documented pre-enable checklist that OpenClaw’s own docs call out as the “highest-risk configuration.” When the project missed a big one, it missed it loudly. CVE-2026-25253, the one-click RCE that exfiltrated WebSocket auth tokens to a malicious gatewayUrl, was patched in 2026.1.29 but not before making the rounds. OpenClaw has accumulated nine-plus CVEs in its first couple of months of real popularity. None were cron-specific, but cron’s unattended nature is exactly where a token-exfiltration vulnerability hurts most.
The honest read: Hermes gets you further out of the box without explicit security labor, and its recursion guard is a genuinely nice design choice. But “automated scanning” isn’t a substitute for threat modeling, and the skill-bypass bug shows why. OpenClaw requires more operator diligence but gives you more operator levers: per-job tool restrictions, approval policies, failure destinations, audit tooling. On a hardened OpenClaw box with a reviewed job catalog, I’d trust the cron surface more than I’d trust a default Hermes install running skills I didn’t write. On an unhardened box with a busy user, it’s the reverse.
Cost is the other quiet axis. An OpenClaw heartbeat cron pulls the full session context on every wakeup. Reports of around 120,000 tokens per tick, roughly $0.75 each compound quickly on a */5 schedule. Hermes’s fresh-session-per-job design sidesteps this almost by accident: there’s no conversation to reload, only the prompt plus any attached skills. For continuous monitoring workloads, the monthly bill between the two can differ by an order of magnitude.
How to choose
A rough decision rule, after using both.
If you want recurring work that compounds context over time (a daily journal agent, a weekly research pipeline that builds on prior runs, a standup that remembers yesterday’s blockers), use OpenClaw with a custom named session. Hermes’s isolation will fight you every step.
If you want set-and-forget with a short audit surface (a morning briefing, a silent monitor that pages you on anomalies, a “tell me when X happens” trigger), use Hermes. The fresh-session-per-job model, explicit states, and recursion guard will save you from yourself.
If you’re embedding cron into a bigger system with webhooks, Gmail triggers, and multi-channel routing, OpenClaw’s delivery plumbing is a generation ahead and the platform-level integrations already exist.
If you’re investing in skills the agent writes and rewrites over time, Hermes is the obvious pick. Cron is where the self-improvement loop pays off; in OpenClaw, skills and cron live next to each other rather than inside each other.
And if you’re running on a shared or exposed box, default to Hermes. Pick OpenClaw only after you’ve walked the pre-enable checklist and restricted tools per job. In either case, update. The CVE pipeline in this space is active.
Both systems are production-capable for proactive agents. They’re not interchangeable. OpenClaw’s cron is the one you’d build if you’d spent a decade writing infrastructure. Hermes’s cron is the one you’d build if you’d spent the last year trying to stop agents from hurting themselves. The right answer for your agent depends heavily on which of those problems you think you actually have.
Based on OpenClaw 2026.3.23 and Hermes v0.2.x. Both projects ship fast; check the current docs before committing to a design.
