Mise à niveau du cron de Hermes Agent : monitor-mode, notepad et validation preflight

Les tâches planifiées sont l’une des fonctions d’automatisation les plus pratiques de Hermes Agent : récupérer la page d’accueil de Hacker News à 9h, vérifier le build toutes les 30 minutes, résumer votre flux chaque heure. Mais plus vous lancez de tâches, plus les problèmes deviennent évidents — la plupart des ticks brûlent des tokens en pure répétition, une tâche mal configurée gaspille un appel LLM entier avant d’échouer, et transmettre de l’état entre deux exécutions (« où en étais-je la dernière fois ? ») oblige à bricoler des fichiers externes.

Le lot arrivé sur main début août 2026 dote le cron de trois équipements essentiels :

  1. monitor-mode — un script ou une URL bon marché s’exécute en premier à chaque tick ; si le hash de sa sortie est inchangé, l’exécution complète de l’agent est supprimée, pour un coût LLM de zéro ;
  2. notepad — un bloc-notes persistant clé/valeur par tâche, qui survit d’une exécution planifiée à l’autre (curseurs, watermarks, watchlists) ;
  3. preflight — valide la configuration de la tâche avant que toute mécanique d’agent ne soit construite ; une tâche cassée est marquée blocked_config, prévient une seule fois et ne dépense jamais un token.

Plus un journaliseur usage_audit.jsonl qui enregistre honnêtement la dépense en tokens de chaque exécution de cron. Cet article couvre les quatre, avec de vrais exemples CLI et des clés de configuration.

1. monitor-mode : renifler d’abord, exécuter seulement quand quelque chose a changé

Pourquoi ça existe

La tâche de surveillance canonique ressemble à : « toutes les 5 minutes, vérifier si le flux contient de nouveaux éléments, et les résumer le cas échéant. » Sans monitor-mode, Hermes construit l’agent complet et appelle le LLM à chaque tick — vous payez donc pour un résultat « rien ne s’est passé » à chaque fois que le flux est calme.

monitor-mode sort la détection de changement de l’agent : à chaque tick, un script bon marché (ou une requête GET bornée) récupère la sortie de la source surveillée, qui est hachée en octets exacts :

  • Hash inchangé → l’exécution complète de l’agent est supprimée, enregistrée comme un tick silencieux no_change (aucune dépense LLM, aucune livraison) ;
  • Hash modifié → un bloc MONITOR CHANGE DETECTED (un diff unifié plafonné + la nouvelle sortie) est injecté dans le prompt et l’agent s’exécute normalement ;
  • Le premier tick s’exécute toujours (il établit la baseline) ;
  • Une source de surveillance en échec est traitée comme une erreur de configuration — la tâche n’est jamais silencieusement ignorée.

Utilisation

Création depuis le CLI :

# Monitor source = a script (resolved relative to ~/.hermes/scripts/, or absolute path)
hermes cron create "every 5m" \
  "Summarize any new items on the page" \
  --monitor-script feed_watch.sh

# Monitor source = a URL (one bounded GET per tick)
hermes cron create "every 5m" \
  "Summarize changes on the status page" \
  --monitor-url https://status.example.com/api/health

# Update an existing job
hermes cron edit <job_id> --monitor-script feeds.sh

Depuis le chat, via l’outil cronjob :

cronjob(
    action="create",
    schedule="every 5m",
    prompt="Summarize any new items on the page",
    monitor_script="feed_watch.sh",
)

Trois contraintes (imposées à la création, dans le code source)

  • monitor_script et monitor_url sont mutuellement exclusifs — une seule source de surveillance par tâche ;
  • le mode monitor est incompatible avec no_agent=True — tout l’intérêt est de supprimer ou de réveiller l’agent ; les tâches purement script doivent utiliser le mode script normal ;
  • le script de surveillance doit produire une sortie stable (pas d’horodatages), sinon chaque hash diffère et la tâche se déclenche à chaque tick.

--monitor-script suit les mêmes règles de résolution que script : les chemins relatifs se résolvent sous ~/.hermes/scripts/, les fichiers .sh/.bash s’exécutent via bash, tout le reste tourne en Python. L’implémentation vit dans create_job, et le chemin de suppression par hash du planificateur se trouve dans cron/jobs.py.

2. notepad : un état durable entre les exécutions, sans fichiers externes

Pourquoi ça existe

Les tâches avec état ont un point de friction classique : la tâche A ingère des données à 2h du matin, la tâche B traite « uniquement ce qui est nouveau » à 8h — où vit le curseur « dernière fois vu » ? Historiquement, vous l’écriviez dans un fichier local et gériez vous-même la concurrence et le nettoyage. notepad en fait un citoyen de première classe : un bloc-notes clé/valeur durable par tâche, stocké dans sa propre base SQLite (~/.hermes/cron/notepad.db). À chaque exécution, le planificateur rend un notepad non vide dans le prompt de la tâche — l’agent voit l’état laissé par les exécutions précédentes et le met à jour via le CLI pendant l’exécution.

Utilisation

# List the job's notepad (default action)
hermes cron notepad <job_id>

# Read one key
hermes cron notepad <job_id> get cursor

# Write one key
hermes cron notepad <job_id> set cursor 128

# Delete one key
hermes cron notepad <job_id> delete cursor

Un complément naturel à monitor-mode : après un changement détecté, la tâche écrit « traité jusqu’à l’élément N » dans son notepad, si bien que le prochain tick sait exactement où reprendre. Des plafonds de capacité — une écriture trop volumineuse échoue bruyamment au lieu d’être tronquée silencieusement :

  • 16 Ko par valeur ;
  • clés jusqu’à 128 caractères ;
  • 64 Ko au total par tâche.

Le chemin de lecture injecte le contenu du notepad dans le prompt de la tâche au même endroit que la sortie de context_from ; le chemin d’écriture est l’agent en cours d’exécution qui appelle hermes cron notepad ... set. Les détails d’implémentation sont dans cron/notepad.py, qui suit le même modèle de connexion/pragma que cron/executions.py.

3. preflight : une tâche cassée prévient une fois et ne dépense jamais un token

Pourquoi ça existe

La façon la plus courante dont les tâches cron se cassent n’est pas un mauvais code — c’est la dérive de l’environnement : une clé API de fournisseur a expiré, une skill attachée manque d’une variable d’environnement, les identifiants de livraison sont périmés. L’ancien comportement : le tick s’exécute, l’agent est construit, le LLM est appelé, et ce n’est qu’alors que ça échoue — de l’argent dépensé, et l’erreur est souvent opaque.

preflight valide la configuration de la tâche avant que toute mécanique d’agent ne soit construite (selon la source et la doc officielle cron.md) :

  • la clé API du fournisseur se résout (vérification ignorée quand une chaîne fallback_providers est configurée, car le chemin de secours peut sauver une clé primaire manquante) ;
  • les skills attachées sont prêtes (aucune variable d’environnement, commande ou fichier d’identifiants requis ne manque) ;
  • les cibles de plateforme de livraison sont connues et disposent d’identifiants de passerelle (les cibles local/origin ne sont jamais vérifiées).

En cas d’échec :

  • le last_status de la tâche devient blocked_config ;
  • exactement une alerte est livrée (un marqueur de déduplication preflight_alerted — pas de bombardement à chaque tick), effacée lors du rétablissement pour qu’une future panne alerte à nouveau ;
  • zéro appel LLM — une tâche mal configurée ne dépense jamais de tokens.

Activé par défaut via cron.preflight: true. Pour restaurer l’ancien comportement :

# config.yaml
cron:
  preflight: false

# or on the command line
hermes config set cron.preflight false

Toutes les vérifications échouent ouvertement (fail open) — un problème de preflight ne bloque jamais une exécution, donc une tâche saine n’est pas tuée par accident.

4. usage_audit : un registre de tokens pour le cron

Le même lot a aussi livré une partie de l’atténuation des fuites de tokens du cron : les sessions cron ne lancent plus de revue en arrière-plan (skip_background_review), et un journal d’audit de la dépense en tokens par déclenchement vit désormais dans ~/.hermes/cron/usage_audit.jsonl — une ligne JSONL par exécution. Si vous voulez quantifier combien monitor-mode vous a réellement fait économiser, ce fichier est la réponse.

5. Tout assembler : une tâche de surveillance bon marché et sensible aux changements

Câbler les trois pièces dans une tâche typique de « surveillance de site + résumé incrémental » :

# 1) Monitor script: stable output (e.g. the feed's item titles)
cat > ~/.hermes/scripts/feed_watch.sh <<'EOF'
#!/bin/bash
curl -s https://example.com/feed.xml | grep -o '<title>[^<]*</title>'
EOF
chmod +x ~/.hermes/scripts/feed_watch.sh

# 2) Create the monitor job: unchanged hash → silent skip
hermes cron create "every 5m" \
  "Summarize new feed items and remember the last seen count in the notepad" \
  --monitor-script feed_watch.sh \
  --deliver telegram

À partir de là : flux inchangé → tick no_change silencieux, zéro token ; flux modifié → l’agent se réveille, lit le curseur depuis son notepad, résume les nouveaux éléments, met à jour le curseur, livre sur Telegram. Les utilisateurs soucieux de leur budget peuvent recouper usage_audit.jsonl à la fin du mois.

6. Quand NE PAS utiliser ces outils

  • Les tâches qui doivent s’exécuter à chaque tick (carillons horaires, keep-alive de heartbeat) n’ont pas besoin de monitor-mode — cela n’ajoute qu’une vérification de changement inutile ;
  • notepad est par tâche, pas un magasin inter-tâches — enchaînez les tâches avec context_from ou un stockage externe quand des données doivent circuler entre les tâches ;
  • les tâches purement script qui doivent sauter complètement l’agent : utilisez l’existant no_agent=True + script, ne leur imposez pas le mode monitor.

Résumé

Ces trois pièces transforment le cron d’un « brûleur d’argent planifié » en un « réveil à la demande » : monitor-mode économise (coût nul quand rien n’a changé), notepad se souvient (l’état survit entre les exécutions), preflight stabilise (aucune brûlure de tokens sur une config cassée, un seul avertissement). Pour quiconque gère une flotte de tâches planifiées, c’est une vraie réduction de facture et un gain opérationnel.

Vous découvrez le cron ? Commencez par notre guide complet de l’automatisation cron avec Hermes Agent ; évitez que vos tâches de fond de longue durée ne restent bloquées avec le guide de configuration des longues tâches ; d’autres astuces d’efficacité quotidienne dans notre collection de conseils de productivité Hermes Agent. Pas encore installé ? Le guide d’installation vous fait démarrer en cinq minutes.