Hermes Agent Background Tasks: The Seven Ways To Run Them, And The Models Worth Paying For

Hermes Agent background tasks are jobs the agent runs while you aren't typing to it, and Hermes has seven built-in ways to run them.

The seven are scheduled cron jobs, the gateway running as a service, /bg background sessions, background terminal processes, delegated subagents, kanban workers and the /loop command.

Hermes Agent is the free, open-source agent from Nous Research, and all seven features are included.

I checked every command below against the official Hermes docs and the read-only help output of my own install, which is v0.21.4, on 12 October 2026.

You'll get what each mode is, the real command, when to use it, how to see and stop it, the safety and cost settings, and then a late section on which models suit background work.

Hermes Agent background tasks at a glance

What "background" means in Hermes Agent

People use the word for three different things.

The first is a job that runs on a schedule with no chat open, which is cron.

The second is the agent process staying alive after you close the terminal, which is the gateway service.

The third is work that runs beside your current chat, which covers /bg, background processes, subagents and /loop.

Kanban sits across all three, because its workers are separate processes that the gateway dispatches.

Knowing which one you need is most of the setup.

The gateway service: keeping Hermes alive

The gateway is the long-running Hermes process that answers chat apps, runs the cron scheduler and dispatches kanban workers.

You install it as a service once.

hermes gateway install

hermes gateway start

hermes gateway status

The docs describe a launchd agent on macOS, a systemd user service on Linux and a Scheduled Task on Windows.

On a Linux server you should run sudo loginctl enable-linger $USER, so the service keeps running after you log out.

The docs also describe sudo hermes gateway install --system for headless hosts that should come back at boot.

hermes gateway run is the foreground version, and the help text recommends it for WSL and Docker.

You follow the service's log with hermes logs gateway -f.

Cron jobs: Hermes Agent background work on a schedule

A cron job is a prompt on a schedule, and each run starts a fresh agent session with no chat attached.

hermes cron create "0 6 * * *" "Read my to-do file and write a short recap of today's priorities." --name "Daily 6AM To-Do Recap"

You can also type /cron add "every 2h" "Check server status" in a chat, or ask Hermes in plain English.

The schedule accepts cron expressions, intervals like every 2h, delays like in 30m and natural forms like weekdays at 9am.

The official cron docs say execution is handled by the gateway daemon, which ticks the scheduler every 60 seconds.

That means no job fires while the gateway is down, and a recurring job that missed its slot catches up once when the scheduler returns.

A cron prompt must be self-contained, because the run has no memory of the chat where you created it.

The --deliver flag sends the result to Telegram, Discord, Slack, email or another target.

The --skill flag attaches a skill, and the --workdir flag runs the job inside a project folder.

The --model flag pins one job to its own model, which matters for the model section further down.

Output from every run is saved under ~/.hermes/cron/output/.

My real scheduled jobs

I ran hermes cron status on my Mac on 12 October 2026, and it reported the gateway running with five active jobs.

The first is my Daily 6AM To-Do Recap on the schedule 0 6 * * *, and the list showed it finishing at 06:01 that morning with the status ok.

The others are a 7am inbox summary, an 8am inbox triage, a 6pm wrap-up and a 9pm job that writes a summary into my notes vault.

In my Herald OS video I also showed a daily Japanese learning job in the same automations list.

My trend radar wakes at 6am as well, and it reads the live X feed through Grok and returns six ranked AI stories.

I documented that build in my Hermes Oracle Radar guide.

/bg sessions and background terminal processes

The /bg command runs one prompt in a separate session while your main chat stays free.

/bg Analyse the logs in /var/log and summarise any errors from today

The background session knows nothing about your current conversation, so the prompt has to be complete.

The result appears as a panel in the terminal, or it is sent back to the same chat on a messaging platform.

Background terminal processes are different, because the agent starts a long shell command and keeps talking to you.

You ask for one in plain words, such as "run the build in the background and tell me when it finishes".

The agent's process tool can then list, poll, wait for, read the log of and kill that command.

A process belongs to the agent that started it, so a subagent's processes end when the subagent finishes.

Delegated subagents and background agents

Hermes can split a task and hand the pieces to child agents with its delegate_task tool.

The delegation docs say the agent delegates automatically when a task is complex enough.

Each child gets a fresh conversation and its own terminal, and only its final summary returns to the parent.

Top-level delegations run in the background automatically, so Hermes returns a handle and the conversation continues.

The defaults are 10 parallel children per batch, 250 iterations per child and flat delegation with no grandchildren.

The TUI's /agents overlay shows a live tree of subagents with per-branch cost and tokens.

Children can't ask you questions, write shared memory, send messages or create cron jobs.

A Hermes restart does not resume a running child, so the docs point to cron for work that must survive one.

Herald OS, the free desktop shell built on Hermes, exposes a setting for the number of background agents, which I showed in the video above.

My Herald OS breakdown covers that settings screen.

Kanban workers

Kanban is the durable version of delegation.

hermes kanban create "Draft the weekly SEO report" --assignee researcher --max-runtime 30m

Every task is a row in ~/.hermes/kanban.db, and every worker is a full operating system process with its own profile.

The dispatcher runs inside the gateway, so nothing extra needs installing once the service is running.

A task is blocked after two consecutive failed attempts by default, which stops a broken task from retrying forever.

A kanban task can also carry its own model with the --model flag, which plain delegation can't do per task.

/loop, /heartbeat and /goal

The /loop command re-runs a prompt on a timer inside your current session.

/loop 5m check the deploy status and tell me if it's live yet

Each wakeup is a real agent turn that reads the current state fresh.

If you leave out the interval, the loop paces itself from one minute up to a 15 minute ceiling while nothing changes.

You can cap it with --times 30, end it on a condition with --until, or stop it by hand with /loop stop.

/heartbeat every 10m <prompt> keeps one recurring instruction in a session, and /goal <text> keeps working until a judge model says the objective is done.

The docs say unattended overnight work should use cron, because all three live inside a session.

My Hermes /loop guide shows real sessions, and you may need hermes update on an older version.

How to see what's running and stop it

hermes cron pause followed by a job name or ID stops one job.

/stop inside a session ends that session's background processes and subagents.

hermes pause is the global emergency stop, and it halts new cron dispatch, kanban dispatch and new gateway turns until you run hermes resume.

The help text says it never kills work that is already in flight.

Herald OS adds an activity history screen, which shows background work you forgot you started.

Approvals and safety for unattended runs

Nobody is there to click approve at 6am, so Hermes decides in advance.

The setting approvals.cron_mode defaults to deny, so a cron job that hits a dangerous command is blocked.

Webhook and API sessions get the same default through approvals.unattended_mode.

An approval prompt that nobody answers is denied after 300 seconds.

A hardline blocklist of destructive commands sits below every setting, and the docs say --yolo does not bypass it.

Hermes scans cron prompts for prompt-injection and secret-exfiltration patterns when a job is created or edited.

You can narrow the tools cron gets by running hermes tools and choosing the cron platform.

Herald OS has an auto-approve switch with an "ask before sending messages" option, and I'd leave the asking on.

Cost control for background tasks

Every scheduled run and every loop tick is a real agent turn, so frequency and model choice decide the bill.

The scheduler validates a job's setup before each run, and a misconfigured job is blocked without making a model call.

My /loop guide works through the backoff maths, where a fixed two-minute loop fires 240 times overnight and a self-paced one fires about 35 times.

Mac, VPS or Hermes Cloud

A background job only runs while its machine is awake.

On a Mac, the Hermes docs recommend the built-in caffeinate tool.

caffeinate -i -w $(cat ~/.hermes/gateway.pid) &

The docs warn that closing a MacBook lid still puts it to sleep.

A VPS removes the sleep problem, and my best Hermes Agent VPS ranking covers the options.

Docker is another supported route, and the official image restarts the gateway automatically if it crashes.

You can run hermes gateway run in tmux or under nohup for a test, but nothing restarts it after a reboot.

Hermes Cloud's Standard size cost $0.51 a day while running when I checked on 10 October 2026, with inference billed separately.

Which models are worth running Hermes Agent background tasks on?

This is the part where GoldieBench can add something.

Hermes Agent doesn't ship its own model, so a background job is only as good as the model you point it at.

GoldieBench is my leaderboard, and it gives every model the same one-shot prompt to build a game, a page, a simulation or a visual, then scores the result from 0 to 10.

It doesn't measure scheduled jobs, inbox triage, tool calling over a long run or how reliably a model follows a cron prompt at 6am.

What it does show is how well a model follows a detailed brief and ships working output first time, with nobody there to correct it.

That is close to the situation a background job is in, which is why I think the scores are a fair first filter.

Hermes MoA is Hermes Agent's own Mixture of Agents mode, where a panel of models answers and a chair merges the result.

It scores 8.17 on the board, but every run makes several model calls, so I wouldn't put it on a job that fires every few minutes.

MiniMax M3 is the one I'd look at first for scheduled work, because 7.97 sits close to the top at a small price per token.

Hy3's 6.76 comes from only 7 scored tasks, so I treat it as an early signal and not a settled score.

Laguna XS 2.1 is free, and its 3.93 tells me to use it for testing a job and not for the job's real output.

The planner and worker split

The Hermes delegation docs describe a cost strategy with a frontier planner and inexpensive workers.

The idea is that splitting a problem takes a strong model, while carrying out a well-specified piece usually doesn't.

You set it up by leaving your main model on a strong brain and setting delegation.model to a cheaper one.

On the numbers above, that could be Claude Opus 5 at 8.27 as the planner and MiniMax M3 at 7.97 as the worker.

For scheduled jobs the same split is cron.model, which moves every unpinned job to a cheaper model without touching your chat.

I haven't benchmarked that pairing as a pair, so treat it as a reasoned starting point and measure it on your own jobs.

Local models for background work

A local model makes a background job free to run, because your own machine does the thinking.

Both scores came from a Mac with Apple silicon, so they don't tell you how those models behave on a rented CPU server.

A local model also ties up the machine while it works, which matters if five jobs fire in the same hour.

The local models board has the full list, and my best local model for Hermes Agent breakdown goes deeper.

For API brains, my best LLMs for Hermes Agent post is the place to start.

What to read next

My Hermes Agent bot post covers the chat apps that deliver background results to your phone.

My Hermes Agent backend post covers where the agent's commands execute and which model backends it supports.

My best Hermes Agent use cases ranking has more jobs worth scheduling.

Also On Our Network

• Agent Operatorsthe seven-step setup walkthrough for background Hermes agents
• AI Income Deskseven real business uses for background Hermes jobs
• AI Tool Verdictevery Hermes background mode explained and scored
• agentos.guidethe background quick-start and how it fits an Agent OS
• agentos.guideMy Hermes /loop guide on agentos.guide

Install the gateway, schedule one small job on a model that scores well for its price, and you'll have your first Hermes Agent background tasks running by tomorrow morning.