Script-Only Cron Jobs Without LLM Cost

Not every scheduled task needs a model. If a script can determine the exact message, Hermes no-agent mode runs the script on schedule and routes non-empty output without making an inference call.

Official documentation: https://hermes-agent.nousresearch.com/docs/guides/cron-script-only

Good no-agent jobs

Disk, memory, certificate, or endpoint threshold checks.
Backup completion markers.
Deterministic counts and status summaries.
Fixed reminders whose wording never changes.
File-arrival or process-health watchdogs.

Use an agent-driven cron job when the output requires judgment: selecting important items, summarizing prose, combining sources, or drafting an audience-aware response.

Script contract checklist

[ ] Put the script under ~/.hermes/scripts/.
[ ] Use a supported script type and explicit dependencies.
[ ] Exit zero with empty stdout when nothing needs attention.
[ ] Print only the message that should be delivered.
[ ] Return non-zero on genuine script failure so it does not fail silently.
[ ] Set a timeout appropriate to the check.
[ ] Avoid credentials and private payloads in stdout or stderr.
[ ] Test once manually before enabling the recurring schedule.

Choose the scheduler boundary

Hermes no-agent cron is appropriate when the Hermes scheduler is healthy and the monitored system is external. For a watchdog whose purpose is to detect that Hermes itself is down, use an independent OS scheduler that can call an external alert endpoint or signed webhook. A monitor should not depend entirely on the component it is meant to monitor.

Quiet-channel design

A healthy watchdog should usually say nothing. Empty stdout creates a silent tick, while non-empty stdout is delivered. This supports frequent checks without flooding a channel. Include enough context in alerts to act: what failed, where, when, and which verification command or URL should be checked next.

Pitfalls

Paying for an LLM every minute to evaluate a numeric threshold.
Printing routine success messages that create alert fatigue.
Swallowing non-zero errors and making a broken monitor appear healthy.
Depending on an in-gateway scheduler to detect gateway failure.
Writing scripts outside the allowed scripts directory.
Including unstable host details or secrets in delivered output.

Verification steps

Run the script in a healthy state and confirm stdout is empty.
Simulate the threshold and confirm one concise alert is printed.
Simulate a script error and confirm the job reports failure.
Trigger the cron job manually.
Verify the destination receives the alert once.
Restore the healthy state and confirm the next run stays silent.