Créer des tâches planifiées avec Hermes Agent
Cette page fait partie du guide pratique francophone consacré à Hermes Agent. Elle répond à l'intention de recherche : planifier une automatisation.
Le contenu s'appuie sur la documentation officielle Hermes Agent associée à cette page. L'objectif n'est pas de remplacer la documentation de Nous Research, mais de fournir une lecture claire en français, structurée pour aller vite, avec un maillage logique vers les pages complémentaires du même site.
À retenir
- Sujet principal : hermes agent cron.
- Type de page : spoke.
- Cluster : automatisation.
- Source canonique : documentation officielle Hermes Agent.
- Aucun lien vers l'autre domaine n'est utilisé dans cette page.
Quand utiliser cette page
Utilisez cette page quand vous voulez planifier une automatisation. Elle part du principe que Hermes Agent est déjà identifié comme l'outil à mettre en place ou à comprendre, puis détaille les points importants issus de la documentation officielle.
Si vous découvrez seulement l'outil, revenez d'abord au hub parent puis suivez les liens internes proposés en fin de page.
Base officielle
Schedule tasks to run automatically with natural language or cron expressions. Hermes exposes cron management through a single cronjob tool with action-style operations instead of separate schedule/list/remove tools.
What cron can do now
Cron jobs can:
- schedule one-shot or recurring tasks
- pause, resume, edit, trigger, and remove jobs
- attach zero, one, or multiple skills to a job
- deliver results back to the origin chat, local files, or configured platform targets
- run in fresh agent sessions with the normal static tool list
- run in no-agent mode — a script on a schedule, its stdout delivered verbatim, zero LLM involvement (see the no-agent mode section below)
All of this is available to Hermes itself through the cronjob tool, so you can create, pause, edit, and remove jobs by asking in plain language — no CLI required.
At creation, an unpinned job (one you don't give an explicit provider/model) follows the global default selected by hermes model — and Hermes snapshots that provider and model on the job. If the global default later changes, the job fails closed: it skips the run, makes no inference call, and sends an alert telling you to pin the provider/model explicitly (cronjob action=update job_id=… provider=… model=…) to proceed. This prevents an unattended job from silently inheriting a switch to a paid provider/model and spending money you didn't intend (#44585). To make a job deliberately track your global default, pin it to the new values after changing them. hermes setup --portal is the lowest-friction option for unattended runs since OAuth refresh is automatic. See Nous Portal.
Cron-run sessions cannot recursively create more cron jobs. Hermes disables cron management tools inside cron executions to prevent runaway scheduling loops.
Creating scheduled tasks
In chat with /cron
/cron add 30m "Remind me to check the build"
/cron add "every 2h" "Check server status"
/cron add "every 1h" "Summarize new feed items" --skill blogwatcher
/cron add "every 1h" "Use both skills and combine the result" --skill blogwatcher --skill maps
From the standalone CLI
hermes cron create "every 2h" "Check server status"
hermes cron create "every 1h" "Summarize new feed items" --skill blogwatcher
hermes cron create "every 1h" "Use both skills and combine the result" \
--skill blogwatcher \
--skill maps \
--name "Skill combo"
Through natural conversation
Ask Hermes normally:
Every morning at 9am, check Hacker News for AI news and send me a summary on Telegram.
Hermes will use the unified cronjob tool internally.
Skill-backed cron jobs
A cron job can load one or more skills before it runs the prompt.
Single skill
cronjob(
action="create",
skill="blogwatcher",
prompt="Check the configured feeds and summarize anything new.",
schedule="0 9 * * *",
name="Morning feeds",
)
Multiple skills
Skills are loaded in order. The prompt becomes the task instruction layered on top of those 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",
)
This is useful when you want a scheduled agent to inherit reusable workflows without stuffing the full skill text into the cron prompt itself.
Running a job inside a project directory
Cron jobs default to running detached from any repo — no AGENTS.md, CLAUDE.md, or .cursorrules is loaded, and the terminal / file / code-exec tools run from whatever working directory the gateway started in. Pass --workdir (CLI) or workdir= (tool call) to change that:
hermes cron create "every 1d at 09:00" \
"Audit open PRs, summarize CI health, and post to #eng" \
--workdir /home/me/projects/acme
cronjob(
action="create",
schedule="every 1d at 09:00",
workdir="/home/me/projects/acme",
prompt="Audit open PRs, summarize CI health, and post to #eng",
)
When workdir is set:
AGENTS.md,CLAUDE.md, and.cursorrulesfrom that directory are injected into the system prompt (same discovery order as the interactive CLI)terminal,read_file,write_file,patch,search_files, andexecute_codeall use that directory as their working directory- The path must be an absolute directory that exists — relative paths and missing directories are rejected at create / update time
- Pass
--workdir ""(orworkdir=""via the tool) on edit to clear it and restore the old behaviour
Jobs with a workdir run sequentially on the scheduler tick, not in the parallel pool. This is deliberate: the cron worker applies the job workdir through process-global terminal state, so two workdir jobs running at the same time would corrupt each other's cwd. Workdir-less jobs still run in parallel as before.
Editing jobs
You do not need to delete and recreate jobs just to change them.
The <job_id> placeholder below (and in Lifecycle actions) also accepts the job's name (case-insensitive) — handy when you remember morning-digest but not the hex ID. An exact job ID takes precedence over name matches; if the reference is not an ID and a name matches more than one job, the command refuses and prints the candidate IDs so you can disambiguate.
Chat
/cron edit <job_id> --schedule "every 4h"
/cron edit <job_id> --prompt "Use the revised task"
/cron edit <job_id> --skill blogwatcher --skill maps
/cron edit <job_id> --remove-skill blogwatcher
/cron edit <job_id> --clear-skills
Standalone CLI
hermes cron edit <job_id> --schedule "every 4h"
hermes cron edit <job_id> --prompt "Use the revised task"
hermes cron edit <job_id> --skill blogwatcher --skill maps
hermes cron edit <job_id> --add-skill maps
hermes cron edit <job_id> --remove-skill blogwatcher
hermes cron edit <job_id> --clear-skills
Notes:
- repeated
--skillreplaces the job's attached skill list --add-skillappends to the existing list without replacing it--remove-skillremoves specific attached skills--clear-skillsremoves all attached skills
Lifecycle actions
Cron jobs now have a fuller lifecycle than just create/remove.
Chat
/cron list
/cron pause <job_id>
/cron resume <job_id>
/cron run <job_id>
/cron remove <job_id>
Standalone CLI
hermes cron list
hermes cron pause <job_id_or_name>
hermes cron resume <job_id_or_name>
hermes cron run <job_id_or_name>
hermes cron remove <job_id_or_name>
hermes cron edit <job_id_or_name> [...flags]
hermes cron status
hermes cron tick
What they do:
pause— keep the job but stop scheduling itresume— re-enable the job and compute the next future runrun— trigger the job on the next scheduler tickremove— delete it entirelyedit— modify schedule, prompt, delivery, etc.
Name-based lookup. All four mutating verbs (pause, resume, run, remove, edit) plus the agent's cronjob tool now accept a job name (case-insensitive) in place of the hex ID. The agent and CLI both prefer an exact ID match if one exists; ambiguous name matches (multiple jobs sharing the same name) are refused with the full list of candidate IDs so you can pick one explicitly. Names are not unique, so this guard is load-bearing — it prevents silently mutating the wrong job when two share a name.
How it works
Cron execution is handled by the gateway daemon. The gateway ticks the scheduler every 60 seconds, running any due jobs in isolated agent sessions.
hermes gateway install # Install as a user service
sudo hermes gateway install --system # Linux: boot-time system service for servers
hermes gateway # Or run in foreground
hermes cron list
hermes cron status
Gateway scheduler behavior
On each tick Hermes:
- loads jobs from
~/.hermes/cron/jobs.json - checks
next_run_atagainst the current time - starts a fresh
AIAgentsession for each due job - optionally injects one or more attached skills into that fresh session
- runs the prompt to completion
- delivers the final response
- updates run metadata and the next scheduled time
A file lock at ~/.hermes/cron/.tick.lock prevents overlapping scheduler ticks from double-running the same job batch.
Delivery options
When scheduling jobs, you specify where the output goes:
- Option — Description — Example
"origin"— Back to where the job was created — Default on messaging platforms"local"— Save to local files only (~/.hermes/cron/output/) — Default on CLI"telegram"— Telegram home channel — Uses `TELEGRAM
Points de vigilance
- Vérifiez toujours la version active de Hermes Agent avant d'appliquer une commande ou une configuration.
- Ne collez pas de clé API dans un chat public ou dans une page visible.
- Gardez les secrets dans les fichiers ou gestionnaires prévus pour cela.
- Si une fonctionnalité dépend d'un provider, d'un plugin ou d'une plateforme de messagerie, vérifiez que le composant est bien activé dans votre profil.
- Pour une installation de production, testez d'abord le flux complet sur une machine ou un profil isolé.
Exemple de parcours logique
- Lire la page courante pour comprendre hermes agent cron.
- Ouvrir le hub parent du cluster automatisation.
- Passer ensuite aux pages complémentaires proposées dans « À lire ensuite ».
- Revenir à la documentation officielle si vous avez besoin du détail exact ou d'une commande récemment modifiée.
FAQ rapide
Cette page remplace-t-elle la documentation officielle ?
Non. Elle sert de guide francophone structuré. Le lien vers la source officielle est disponible en bas de page.
Les commandes sont-elles garanties à jour ?
Elles sont basées sur la documentation officielle récupérée au moment de la génération. Pour un usage critique, vérifiez toujours la page officielle liée en bas.
Pourquoi autant de liens internes ?
Hermes Agent est un système modulaire. L'installation, les providers, les outils, la mémoire, les skills, la sécurité et les plateformes se répondent. Le maillage interne aide à suivre ce chemin sans tomber sur des pages orphelines.