Hermes /loop: Recurring Tasks Inside Your Session

Share this post

Hermes /loop re-runs a prompt on a recurring cadence, and each wakeup is a real agent turn reading fresh state. Here’s how it works, the two cadence modes, every way a loop ends, and when you should be using /goal or cron instead.

Short answer

  • /loop 5m <prompt> re-runs a prompt every 5 minutes inside your current session.
  • Omit the interval and it self-paces — backing off to 15m when nothing changes, snapping back when it does.
  • /loop is timer-driven, /goal is judge-driven, cron runs unattended outside any session.
  • Every tick is a full agent turn, so cost scales with cadence — there’s a 100-tick backstop by default.

What /loop actually does

/loop re-runs a prompt — or a slash command — on a recurring cadence inside your current session.

The important part is that each wakeup is a real agent turn. Hermes reads the current state fresh: the latest CI result, the newest queue depth, the file as it is right now. It does the work, reports back, and goes quiet until the next tick.

It’s Hermes’ take on Claude Code’s /loop, and the /proactive alias works here too.

Getting started is one line:

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

You’ll see the loop accepted, the first wakeup fire in five minutes, and then a repeat every five minutes until something stops it. You can loop a slash command just as easily — /loop 10m /recap.

/loop vs /goal vs cron

Hermes has three ways to make work happen repeatedly, and picking the wrong one is the most common mistake.

/loop/goalcron
TriggerA timer, or self-pacedA judge verdict after each turnA schedule, outside any session
Lives inYour current sessionYour current sessionIts own session per run
Ends whenStop condition, caps, or youGoal achieved, budget, or youYou remove the job
Best forPolling, monitoring, periodic re-runsOne objective, iterate until doneUnattended, long-horizon schedules

In plain terms: /goal is judge-driven — keep working until this objective is achieved. /loop is timer-driven — do this again every N minutes until something says stop.

And when the work should run unattended overnight, on a real schedule, surviving restarts of your terminal, you want a cron job. /loop lives inside a session; cron lives outside all of them.

🔥 Want this set up without the guesswork? Knowing which of /loop, /goal and cron to reach for is the difference between an agent that works while you sleep and one that quietly does nothing. Inside the AI Profit Boardroom you get the Agent OS as a ready-to-install file, a 30-day roadmap, daily tutorials the same day new tools ship, and four live coaching calls a week where you share your screen and get unstuck. → Get access here

The two cadence modes

Fixed interval — you set the clock

Give it an interval — 30s, 5m, 2h, 1h30m — and it fires on that schedule. Use this when the thing you’re watching changes on its own timeline:

/loop 2m poll the build and ping me the moment it finishes

Self-paced — Hermes sets the clock

Omit the interval and the loop paces itself. It starts at the floor (one minute by default) and while the replies stop changing it backs off exponentially — 2m, 4m, 8m — up to a ceiling of fifteen minutes.

The moment a reply differs from the last one, cadence snaps straight back to the floor. Change detection is a local digest comparison with timestamps ignored, so idle waits cost you nothing extra.

/loop keep an eye on the migration and summarise progress

The rule of thumb: fixed interval when an external clock drives the work, self-paced when the work drives the rhythm.

How a loop ends

ConditionHow
The agent decides it’s doneIt ends its reply with LOOP_COMPLETE on its own line when the task is finished or moot
A run cap--times N stops after N wakeups
An evidence-based condition--until <condition> — the same judge that powers /goal checks each reply. It fails open, so a broken judge never wedges the loop
You/loop stop, or /loop pause to keep it around
The backstop budgetloops.max_ticks (default 100) pauses the loop so an unattended session can’t burn tokens forever

Examples: /loop 2m poll CI --times 30 or /loop 5m watch the queue --until queue depth reaches zero.

That backstop matters. Every tick is a full agent turn, so token cost scales directly with cadence — match the interval to how often the state actually changes, and prefer self-pacing for idle waits.

The commands

CommandWhat it does
/loop [interval] <prompt> [--times N] [--until <cond>]Start or replace the loop for this session
/loop or /loop statusShow cadence, ticks fired, and time to next wakeup
/loop pauseStop firing without losing the loop
/loop resumePick it back up
/loop stopEnd the loop
/proactive …Alias for /loop

It works on the CLI, the TUI (hermes --tui), the web dashboard chat, the desktop app and every gateway platform — Telegram, Discord, Slack, WhatsApp. On messaging platforms the gateway fires wakeups even between your messages, and the results arrive as ordinary replies.

Mixing it with /goal

Both features inject synthetic turns at idle boundaries, so they follow one rule: an active goal owns the session.

While a /goal is actively driving — judge saying continue — loop wakeups defer. The loop resumes using idle time as soon as the goal finishes, pauses, or parks itself on a wait barrier.

A parked goal plus a loop is a natural combination: the goal waits on the big asynchronous thing while the loop keeps a heartbeat on something else.

And a real message from you always wins over both. Wakeups only fire while the session is idle and nothing of yours is queued.

Behaviour worth knowing

  • A wakeup is a normal user-role turn — no system-prompt mutation, no toolset swap, so prompt caching stays intact.
  • Loop state survives /resume and context compression, same as /goal.
  • One loop per session. Setting a new one replaces the old. Run several by running several sessions, or use cron for a fleet.
  • Interrupting a wakeup turn with Ctrl+C pauses the loop rather than killing it — recoverable with /loop resume, so cancel actually means cancel.

Configuration lives in ~/.hermes/config.yaml under loops:min_interval_seconds (30), max_ticks (100), self_paced_floor_seconds (60) and self_paced_ceiling_seconds (900). The --until judge routes through the goal_judge auxiliary task, so those overrides apply to loop conditions too.

What to actually use it for

  1. Polling external state. Watch a deploy, a CI run or a queue and tell me when it changes. This is the canonical use.
  2. Iterate until green. Run the tests, fix what fails, repeat until they pass.
  3. Monitoring during a work session. Keep an eye on error rates or a long job’s progress while you do something else in the same conversation.
  4. Periodic housekeeping. Re-run a lint pass or a status summary every N minutes during a long session.

For anything unattended and long-horizon, use cron instead — see how cron jobs travel with your agent and running it inside a dashboard.

Want the whole Hermes automation stack set up? The AI Profit Boardroom has step-by-step tutorials on loops, goals and cron jobs — plus the Agent OS where Hermes runs alongside Claude and OpenClaw with shared memory, four coaching calls a week and a 30-day roadmap. Start free with the free AI course and community.

FAQ

What is /loop in Hermes?

A command that re-runs a prompt or slash command on a recurring cadence inside your session. Each wakeup is a full agent turn reading fresh state.

What’s the difference between /loop and /goal?

/loop is timer-driven — do this again every N minutes. /goal is judge-driven — keep working until this objective is achieved.

When should I use cron instead?

When the work should run unattended, on a real schedule, surviving terminal restarts. /loop lives inside a session; cron lives outside all of them.

What is self-paced mode?

Omit the interval and Hermes paces itself — starting at one minute and backing off to fifteen while replies stop changing, snapping back to the floor the moment something differs.

How do I stop a loop?

/loop stop ends it, /loop pause keeps it for later. It also stops on –times, on an –until condition, when the agent signals completion, or at the max_ticks backstop.

Does a loop burn tokens?

Yes — every tick is a full agent turn, so cost scales with cadence. Match the interval to how often state actually changes and use self-pacing for idle waits.

Does it survive compression or /resume?

Yes. Loop state persists per session and migrates across context-compression boundaries.

Can I run more than one loop?

One per session — a new /loop replaces the old. Run several sessions, or use cron for a fleet of schedules.

The bottom line

Hermes loop is the timer-driven half of Hermes automation: /loop for polling and monitoring inside a session, /goal when there’s one objective to iterate toward, and cron when it needs to run unattended. Use self-pacing for idle waits, keep an eye on cadence because every tick is a real turn, and let the backstop stop you burning tokens overnight.

About Julian Goldie

I run Goldie Agency, a 7-figure SEO agency, and teach this daily on a 400K+ subscriber YouTube channel. 240+ client projects on Upwork at a 100% job-success score, 10+ years through every major Google update. My systems are in the AI Profit Boardroom; my link building book is free here.

Table of contents

Related Articles

How to use the free Hermes Pixel Office to supervise agent work – setup, reading the room, approval flags, and what it deliberately does not do.