Wenn du Hermes Agent betreibst und den Cron-Scheduler noch nie angerührt hast, lässt du eines seiner mächtigsten Features ungenutzt. Cron in Hermes ist kein einfaches „führe dieses Skript jede Stunde aus“-Werkzeug — es ist ein vollwertiges Automatisierungs-Framework, das Planung in natürlicher Sprache, Skill-gestützte Agents, Multi-Job-Pipelines und Zero-Token-Script-Watchdogs umfasst.

In diesem Leitfaden lernst du:

• Wiederkehrende und einmalige Aufgaben mit einfachem Englisch oder Cron-Ausdrücken zu planen
• Skills an einen Job anzuhängen, sodass er Experten-Workflows erbt
• Mehrere Jobs zu verketten, sodass einer den nächsten speist (das Pipeline-Muster)
• Script-Only-Watcher auszuführen, die null LLM-Token verbrauchen
• Produktionsreife tägliche Briefings, GitHub-Monitore und Website-Gesundheitschecks einzurichten

Fangen wir von Grund auf an.

Was macht Hermes Cron anders?

Die meisten Cron-Implementierungen führen ein einzelnes Skript nach einem Timer aus. Hermes Cron führt eine vollständige Agent-Sitzung nach einem Timer aus — dein Prompt wird zur Aufgabe, der Agent hat Zugriff auf alle seine Werkzeuge (Terminal, Datei, Web, Browser, Delegation), und das Ergebnis wird an die Chat-Plattform deiner Wahl geliefert.

Die Kernidee: Ein Cron-Job in Hermes ist „eine geplante Hermes-Sitzung“. Was auch immer du Hermes im Chat fragen kannst, kannst du auch autonom planen.

Darüber hinaus bietet Hermes Cron:

• Skill-Injection — lade eine oder mehrere Skills in die Sitzung, bevor der Prompt ausgeführt wird
• Pipeline-Verkettung — die Ausgabe eines Jobs wird zum Kontext des nächsten Jobs
• No-Agent-Modus — führe ein einfaches Skript nach Zeitplan aus, null LLM-Token, stdout wird wortgetreu zugestellt
• Multi-Plattform-Zustellung — sende Ergebnisse an Telegram, Discord, Slack, E-Mail, SMS, Feishu oder eine beliebige konfigurierte Plattform
• Vollständiges Lebenszyklus-Management — pausieren, fortsetzen, bearbeiten, bei Bedarf auslösen, alles aus dem Chat oder CLI

Der Scheduler läuft im Hermes-Gateway-Daemon und tickt alle 60 Sekunden. Jobs werden in ~/.hermes/cron/jobs.json gespeichert und verwenden einen Datei-Lock (~/.hermes/cron/.tick.lock), um überlappende Ticks zu verhindern.

Grundlegende Planung: Drei Wege, einen Job zu erstellen

Du kannst einen Cron-Job auf drei Arten erstellen. Alle Wege führen zum selben Scheduler.

1. Aus dem Chat mit /cron

Der schnellste Weg — gib den /cron-Slash-Befehl während einer Chat-Sitzung ein:

/cron add "every 2h" "Check server status and report any issues"
/cron add "0 9 * * *" "Summarize yesterday's commits from the project repo"
/cron add "30m" "Remind me to stand up and stretch"

Mit einem angehängten Skill:

/cron add "every 1h" "Check feeds for new posts" --skill blogwatcher

2. Von der eigenständigen CLI

Die CLI-Version funktioniert identisch und ist skriptfähig:

hermes cron create "every 2h" "Check server status"
hermes cron create "0 9 * * *" "Summarize yesterday's commits" --name "daily-summary"

Mit mehreren Skills:

hermes cron create "every 1h" "Monitor feeds and maps" \
  --skill blogwatcher \
  --skill maps \
  --name "Multi-skill watcher"

3. Durch natürliche Konversation

Sag Hermes einfach, was du willst:

“Every morning at 9am, check Hacker News for AI news and send me a summary on Telegram.”

Hermes verwendet intern das cronjob-Tool, um es einzurichten — keine CLI, keine Syntax zum Merken.

Zeitplanformat-Referenz

Hermes akzeptiert vier Zeitplanformate:

Format	Beispiel	Verhalten
Relative Verzögerung	30m, 2h, 1d	Einmalig, läuft einmal nach der Verzögerung
Intervall	every 30m, every 2h, every 1d	Wiederkehrend bis zum Entfernen
Cron-Ausdruck	0 9 * * * (täglich), 0 9 * * 1-5 (Wochentage), 0 */6 * * * (alle 6h)	Wiederkehrend nach festem Zeitplan
ISO-Zeitstempel	2026-12-25T09:00:00	Einmalig zu einem bestimmten zukünftigen Zeitpunkt

Du kannst die Standard-Wiederholungsanzahl überschreiben:

cronjob(
    action="create",
    prompt="Check mailbox for urgent messages",
    schedule="every 2h",
    repeat=5,        # nur 5 Mal ausführen, dann automatisch entfernen
)

Skill-gestützte Cron-Jobs

Die wahre Stärke zeigt sich, wenn du Skills anhängst. Ein Skill kapselt einen wiederverwendbaren Workflow — wenn ein Cron-Job ihn lädt, erbt der Agent dieses Fachwissen, ohne dass du Anweisungen in den Prompt stopfen musst.

Einzelner Skill

cronjob(
    action="create",
    skill="blogwatcher",
    prompt="Check the configured feeds and summarize anything new.",
    schedule="0 9 * * *",
    name="Morning feeds",
)

Mehrere Skills

Skills werden in Reihenfolge geladen. Der Prompt wird zur letzten Anweisung über allen geladenen Skills:

cronjob(
    action="create",
    skills=["blogwatcher", "maps"],
    prompt="Look for new local events and interesting nearby places, then combine them into one short brief.",
    schedule="every 6h",
    name="Local brief",
)

Praktischer Tipp: Verwende Skills zur Trennung von Zuständigkeiten. Ein „Datensammler“-Skill holt Rohdaten; ein „Formatierer“-Skill verschönert sie; ein „Zustellungs“-Skill leitet sie weiter. Kombiniere sie in verschiedenen Jobs.

In einem Projektverzeichnis ausführen

Standardmäßig laufen Cron-Jobs detached — es wird kein CLAUDE.md oder AGENTS.md geladen. Übergib --workdir (CLI) oder workdir= (Tool-Aufruf), um den Job in einem bestimmten Repository laufen zu lassen:

hermes cron create "every 1d at 09:00" \
  "Audit open PRs, summarize CI health, and post to #eng" \
  --workdir /home/me/projects/acme

Wenn workdir gesetzt ist, werden Projekt-Kontextdateien aus diesem Verzeichnis in den System-Prompt eingefügt, und alle Datei-/Terminal-Tools verwenden dieses Verzeichnis als Arbeitsbasis.

Serialisierungshinweis: Jobs mit workdir laufen sequentiell (nicht im parallelen Pool), da sie den prozessglobalen Terminal-Zustand ändern. Workdir-lose Jobs laufen weiterhin parallel.

Fortgeschritten: Multi-Job-Pipelines mit context_from

Cron-Jobs laufen in isolierten Sitzungen ohne Erinnerung an vorherige Läufe. Aber manchmal ist die Ausgabe eines Jobs genau das, was der nächste Job braucht. Der context_from-Parameter stellt diese Verbindung automatisch her.

Das Pipeline-Muster

Hier ist eine 3-stufige KI-Nachrichten-Pipeline — Sammlung, Triage und Zustellung:

# Schritt 1: Finde die ID des Collector-Jobs
cronjob(action="list")

# Schritt 2: Erstelle einen Triage-Job, der die Ausgabe des Collectors erhält
cronjob(
    action="create",
    prompt="Read ~/.hermes/data/briefs/raw.md. Score each story 1-10 for engagement and novelty. Output top 5 to ~/.hermes/data/briefs/ranked.md.",
    schedule="30 7 * * *",
    context_from="<collector_job_id>",
    name="AI News Triage",
)

# Schritt 3: Erstelle einen Versender, der die Triage-Ausgabe erhält
cronjob(
    action="create",
    prompt="Read ~/.hermes/data/briefs/ranked.md. Write 3 tweet drafts (hook + body + hashtags).",
    schedule="0 8 * * *",
    context_from="<triage_job_id>",
    deliver="telegram:7976161601",
    name="AI News Brief",
)

Wie context_from funktioniert:

• Wenn Job B ausgelöst wird, liest Hermes die letzte Ausgabe von Job A aus ~/.hermes/cron/output/{job_a_id}/*.md
• Diese Ausgabe wird automatisch dem Prompt von Job B vorangestellt
• Die Kette kann beliebig lang sein: A → B → C → …
• Du kannst eine einzelne ID (String) oder eine Liste von IDs für Fan-In-Muster übergeben

Wann Pipelines verwenden:

• Mehrstufige Verarbeitung (sammeln → filtern → formatieren → zustellen)
• Abhängige Aufgaben, bei denen Schritt N die Ergebnisse von Schritt N−1 benötigt
• Fan-Out/Fan-In: Ein Aggregator-Job sammelt Ergebnisse von mehreren Collectors

No-Agent-Modus: Script-Only-Watchdogs

Für wiederkehrende Aufgaben, die kein LLM benötigen — klassische System-Watchdogs, Festplatten-/Speicher-Alarme, Heartbeats, CI-Pings — übergib no_agent=True. Der Scheduler führt dein Skript nach Zeitplan aus und liefert stdout direkt, null Token, null Inference-Aufrufe.

CLI-Setup

hermes cron create "every 5m" \
  --no-agent \
  --script memory-watchdog.sh \
  --deliver telegram \
  --name "memory-watchdog"

Agent-gesteuertes Setup

Sag Hermes einfach im Chat:

“Ping me on Telegram if RAM is over 85%, every 5 minutes.”

Hermes schreibt das Prüfskript nach ~/.hermes/scripts/ und richtet den Cron-Job automatisch ein.

Semantik des No-Agent-Modus

Bedingung	Verhalten
Script stdout (nicht leer)	Wird wortgetreu als Nachricht zugestellt
Leeres stdout	Stiller Tick — nichts wird gesendet (das Watchdog-Muster)
Nicht-Null-Exit oder Timeout	Fehleralarm wird zugestellt (damit defekte Watchdogs nicht still ausfallen können)
Letzte Zeile {"wakeAgent": false}	Stiller Tick (dasselbe Gate, das LLM-Jobs verwenden)

Skriptdateien:

• .sh / .bash → läuft unter /bin/bash
• Alles andere → läuft unter dem aktuellen Python-Interpreter (sys.executable)
• Müssen in ~/.hermes/scripts/ liegen

Praxisbeispiel — ein Speicher-Watchdog-Skript:

#!/bin/bash
# ~/.hermes/scripts/memory-watchdog.sh
THRESHOLD=85
USAGE=$(free | awk '/^Mem:/ {printf "%.0f", $3/$2 * 100}')
if [ "$USAGE" -gt "$THRESHOLD" ]; then
    echo "⚠️  RAM alert: ${USAGE}% used (threshold: ${THRESHOLD}%)"
    echo "Top processes:"
    ps aux --sort=-%mem | head -6
fi
# Wenn unter dem Schwellenwert, erzeugt das Skript kein stdout → stiller Tick

Dieses Skript erzeugt nur dann Ausgabe, wenn der Speicher 85% überschreitet. An ruhigen Tagen sendet es nichts — kein Spam, keine verschwendete Aufmerksamkeit.

Lebenszyklus-Management

Jeder Cron-Job hat einen vollständigen Lebenszyklus. Du verwaltest alles über CLI oder Chat.

CLI-Befehle

hermes cron list              # Alle Jobs auflisten (--all für deaktivierte)
hermes cron pause my-digest   # Nach Name oder ID pausieren
hermes cron resume my-digest  # Wieder aktivieren
hermes cron run my-digest     # Beim nächsten Scheduler-Tick auslösen
hermes cron edit my-digest --schedule "every 4h"  # Zeitplan ändern
hermes cron edit my-digest --prompt "Revised task"
hermes cron edit my-digest --add-skill maps       # Skill hinzufügen
hermes cron edit my-digest --remove-skill maps    # Skill entfernen
hermes cron edit my-digest --clear-skills          # Alle Skills entfernen
hermes cron remove my-digest  # Vollständig löschen
hermes cron status            # Scheduler-Status
hermes cron runs my-digest --limit 20  # Ausführungsverlauf

Aus dem Chat

/cron list
/cron pause <job_id>
/cron resume <job_id>
/cron run <job_id>
/cron edit <job_id> --schedule "every 4h"
/cron remove <job_id>

Namensbasierte Suche: Alle Befehle akzeptieren entweder die hexadezimale Job-ID oder den Job-Namen (Groß-/Kleinschreibung wird ignoriert). Wenn ein Name mit mehreren Jobs übereinstimmt, gibt der Befehl die Kandidaten aus, damit du unterscheiden kannst.

Ausführungsverlauf

Hermes zeichnet jeden Cron-Lauf in ~/.hermes/cron/executions.db auf. Jeder Versuch durchläuft claimed → running → einen der Status completed, failed oder unknown (nach Prozessneustart). Mit hermes cron runs [job-id] --limit 20 einsehen.

Provider-Wiederherstellung und Modell-Fixierung

Cron-Jobs erben deine konfigurierten Fallback-Provider und die Rotation des Credential-Pools. Wenn der primäre API-Key ratenlimitiert ist, fällt der Job automatisch auf einen alternativen Provider zurück oder rotiert zum nächsten Credential im Pool.

Wichtig — Modell-Fixierungsverhalten: Wenn du einen Cron-Job ohne Angabe von Provider/Modell erstellst, speichert Hermes einen Snapshot deiner aktuellen globalen Voreinstellung im Job. Wenn du später die globale Voreinstellung änderst, scheitert der Job sicher — er überspringt den Lauf und benachrichtigt dich, Provider/Modell explizit zu fixieren. Dies verhindert, dass unbeaufsichtigte Jobs stillschweigend zu einem kostenpflichtigen Provider oder einem anderen Modell wechseln:

# Ein bestimmtes Modell für einen Job fixieren
cronjob(
    action="update",
    job_id="<job_id>",
    provider="openrouter",
    model="anthropic/claude-sonnet-4",
)

Für unbeaufsichtigte Läufe ist hermes setup --portal (Nous Portal OAuth) die reibungsärmste Option — OAuth-Refresh erfolgt automatisch.

Sicherheitsregel: Cron-ausgeführte Sitzungen können keine neuen Cron-Jobs erstellen. Hermes deaktiviert Cron-Management-Tools innerhalb von Cron-Ausführungen, um außer Kontrolle geratene Planungsschleifen zu verhindern.

Zustellungskonfiguration

Plattform-Zielauswahl

Gib beim Planen eines Jobs über den deliver-Parameter an, wohin das Ergebnis geht:

# An Telegram zustellen
cronjob(action="create", ..., deliver="telegram")

# An einen bestimmten Discord-Kanal zustellen
cronjob(action="create", ..., deliver="discord:#engineering")

# An mehrere Plattformen zustellen
cronjob(action="create", ..., deliver="telegram,discord")

# An alle verbundenen Home-Kanäle verteilen
cronjob(action="create", ..., deliver="all")

# An Ursprung plus alle Kanäle zustellen
cronjob(action="create", ..., deliver="origin,all")

Unterstützte Ziele sind Telegram, Discord, Slack, WhatsApp, Signal, SMS, E-Mail, Feishu, DingTalk, WeCom, Matrix und andere.

Das Silent-Muster

Wenn die endgültige Antwort des Agenten [SILENT] enthält, wird die Zustellung vollständig unterdrückt. Die Ausgabe wird lokal für Audit-Zwecke gespeichert, aber keine Nachricht gesendet:

# Prompt-Text:
"Check if nginx is running. If everything is healthy, respond with only [SILENT]. Otherwise, report the issue."

Fehlgeschlagene Jobs werden immer zugestellt, unabhängig vom Silencer — nur erfolgreiche Läufe können stummgeschaltet werden.

Antwort-Wrapping

Standardmäßig wird die zugestellte Cron-Ausgabe mit einem Header/Footer umschlossen:

Cronjob Response: Morning feeds
-------------

<Agent-Ausgabe hier>

Note: The agent cannot see this message, and therefore cannot respond to it.

Um Rohausgabe ohne Wrapper zuzustellen:

# ~/.hermes/config.yaml
cron:
  wrap_response: false

Fortsetzbare Jobs (Auf einen Cron antworten)

Standardmäßig ist eine Cron-Zustellung Fire-and-Forget. Setze einen Job fortsetzbar (über attach_to_session=True) und du kannst darauf antworten — das Briefing wird zur Konversation:

# ~/.hermes/config.yaml
cron:
  mirror_delivery: true

Oder pro Job über das Tool:

cronjob(
    action="create",
    ...,
    attach_to_session=True,
)

Auf thread-fähigen Plattformen (Telegram Topics, Discord Threads) eröffnet jede Zustellung einen dedizierten Thread. Auf DM-only-Plattformen (WhatsApp, Signal) wird das Briefing in die DM-Sitzung gespiegelt.

Produktions-Playbook: Drei kampferprobte Setups

1. Persönliches tägliches Briefing

Ein Morgenbriefing, das GitHub-Aktivitäten, Wetter und Kalendereinträge sammelt:

hermes cron create "0 8 * * 1-5" \
  "1. Check my GitHub notifications for any PRs requesting my review
   2. Check the weather forecast for today
   3. Summarize anything from my calendar that needs attention
   4. Format everything into a clean morning brief" \
  --deliver telegram \
  --name "daily-briefing"

Warum das funktioniert: Es läuft nur an Wochentagen (1-5), verwendet Hermes’ integrierte Websuche und Dateitools und liefert direkt an Telegram, wo du es beim Kaffee lesen kannst.

2. GitHub-Repository-Watchdog

Ein No-Agent-Skript, das dich benachrichtigt, wenn sich das neueste Release eines Repos ändert:

#!/bin/bash
# ~/.hermes/scripts/github-watchdog.sh
REPO="NousResearch/hermes-agent"
CACHE_FILE="$HOME/.hermes/cron/output/latest_release.txt"
LATEST=$(curl -s "https://api.github.com/repos/$REPO/releases/latest" | grep -o '"tag_name": *"[^"]*"' | head -1)

if [ ! -f "$CACHE_FILE" ]; then
    echo "$LATEST" > "$CACHE_FILE"
    echo "📦 Initialized watcher for $REPO — latest: $LATEST"
    exit 0
fi

PREVIOUS=$(cat "$CACHE_FILE")
if [ "$LATEST" != "$PREVIOUS" ]; then
    echo "$LATEST" > "$CACHE_FILE"
    echo "🚀 New release detected for $REPO!"
    echo "   Previous: $PREVIOUS"
    echo "   Latest:   $LATEST"
    echo "   View: https://github.com/$REPO/releases/tag/$LATEST"
fi

Einrichten:

hermes cron create "every 6h" \
  --no-agent \
  --script github-watchdog.sh \
  --deliver telegram \
  --name "github-release-watchdog"

Null Token-Kosten. Das Skript läuft alle 6 Stunden und sendet nur dann eine Nachricht, wenn sich ein Release tatsächlich ändert.

3. Website-Gesundheitschecker

Eine mehrstufige Pipeline: Website-Check → Protokollanalyse → Alarmzustellung.

Stufe 1 — Collector (No-Agent-Skript):

#!/bin/bash
# ~/.hermes/scripts/health-check.sh
URL="https://hermes-agent-lab.com"
STATUS=$(curl -s -o /dev/null -w "%{http_code}" --max-time 10 "$URL")
TIME=$(curl -s -o /dev/null -w "%{time_total}" --max-time 10 "$URL")
TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')
echo "[$TIMESTAMP] $URL → HTTP $STATUS (${TIME}s)"

hermes cron create "every 30m" \
  --no-agent \
  --script health-check.sh \
  --name "site-health-collector"

Stufe 2 — Analyse (LLM-gestützt, vom Collector verkettet):

hermes cron create "0 */2 * * *" \
  "Review the last 4 health checks for hermes-agent-lab.com.
   Are any failures or slow responses apparent?
   If everything is healthy, respond with only [SILENT].
   If there is an issue, write a summary of the problem and deliver it." \
  --context_from "<collector_job_id>" \
  --name "site-health-analyst"

Der Collector läuft alle 30 Minuten (kostenlos, keine Token). Der Analyst läuft alle 2 Stunden, erhält die Ausgabe des Collectors als Kontext und sendet nur dann eine Nachricht, wenn etwas nicht stimmt.

Häufige Fallstricke und wie man sie vermeidet

1. Vergessen, dass das Gateway laufen muss

Die Cron-Ausführung wird vom Gateway-Daemon übernommen. Wenn das Gateway nicht läuft, werden deine Jobs nicht ausgelöst:

hermes gateway install     # Als Benutzerdienst installieren
hermes gateway status      # Überprüfen, ob es läuft
hermes gateway run         # Oder im Vordergrund zum Testen ausführen

2. Relative Verzögerung vs. Intervall-Verwechslung

• 30m = einmalig in 30 Minuten
• every 30m = wiederkehrend alle 30 Minuten

Dies ist ein häufiger Fehler. Verwende every explizit, wenn du Wiederholung möchtest.

3. Stille Jobs, die nie sprechen

Wenn dein Job läuft, aber du nie eine Ausgabe siehst, hat der Agent wahrscheinlich mit [SILENT] geantwortet (Erfolgsfall) oder das Skript hat kein stdout erzeugt (No-Agent-Fall). Überprüfe die lokale Ausgabe:

ls ~/.hermes/cron/output/
cat ~/.hermes/cron/output/<job_id>/*.md

4. Modell/Provider funktioniert plötzlich nicht mehr

Nicht fixierte Jobs speichern einen Snapshot der aktuellen Voreinstellung bei der Erstellung. Wenn du den Provider geändert hast (hermes model), benachrichtigt dich der Job, explizit zu fixieren. Fixiere immer Produktions-Jobs:

hermes cron edit my-job --provider openrouter --model anthropic/claude-sonnet-4

5. Überlappende Pipeline-Zeitpläne

Wenn du Jobs mit context_from verkettest, stelle sicher, dass der Upstream-Job beendet ist, bevor der Downstream-Job startet. Wenn Job A um 0 7 * * * (7:00) läuft und Job B um 0 7 * * * (ebenfalls 7:00) läuft, erhält Job B die Ausgabe von Job A vom Vortag — oder eine leere Datei beim ersten Lauf. Versetze sie um mindestens 15–30 Minuten.

6. Workdir-Jobs blockieren sich gegenseitig

Jobs mit gesetztem workdir laufen sequentiell. Gestalte deine Pipelines so, dass Workdir-Jobs nicht zum Engpass werden — halte sie kurz oder verwende Workdir-lose Zwischen-Jobs für schwere Verarbeitung.

Zusammenfassung

Hermes Cron verwandelt dich vom manuellen Bediener zu jemandem, der einstellt und vergisst. Hier der Spickzettel:

Aufgabe	Ansatz	LLM-Kosten
Persönliches tägliches Briefing	Einzelner LLM-Job mit Websuche	Niedrig
GitHub-Release-Monitor	No-Agent-Skript	Null
Website-Gesundheitscheck + Alarm	Pipeline: No-Agent-Collector → LLM-Analyst	Niedrig (2-stündlich)
KI-Nachrichten-Pipeline	Multi-Job-Kette mit context_from	Mittel
Festplatten-/Speicher-Watchdog	No-Agent-Skript	Null
Multi-Plattform-Broadcast	Einzelner Job mit deliver="all"	Niedrig

Die Kombination aus vollständigen Agent-Sitzungen, Skill-Injection, No-Agent-Script-Modus und Multi-Job-Pipelines macht Hermes Cron zu einem der vielseitigsten Automatisierungstools in jedem KI-Agent-Framework.

Schnellstart-Befehle

# 1-Minuten-Onboarding: Plane deinen ersten Job
hermes cron create "every 1d at 09:00" "Give me a 3-sentence summary of what happened on GitHub with NousResearch/hermes-agent since yesterday" --deliver telegram

# Auflisten und überprüfen
hermes cron list
hermes cron status

# In Echtzeit beim Laufen zusehen
hermes cron run my-job-name

Für mehr über Hermes-Automatisierung siehe die offizielle Cron-Dokumentation, unseren Installationsleitfaden und die Funktionsübersicht.