I Tried Claude Loops. The Luddite Horses Are Retiring Themselves Too Early.

The latest word from the mountain is that we shouldn't be prompting agents at all. What are you, poor? If you have infinite tokens, you are now the bottleneck—get out of Fable 5's way and let that boy cook!

So I decided to derive my wisdom through the ancient technique of solvitur ambulando: it is solved by walking.

What is a Loop?

A loop is a way for an agent to prompt itself. In reality, it's a thin Claude wrapper around a stripped-down cron, packaged as a Skill. Still, if you say anything like I just did, you can make it sound uncool.

I think it is cool.

The API is simple, at least as Anthropic implemented it. It comprises of the slash command, an optional interval token, and a prompt.

It looks like this:

/loop 5s pass the butter

If you omit the interval token, you're giving Claude carte blanche to decide the interval between its calls (which I think is a sensible default).

How Claude parses the loop command is simple:

It checks if there is an interval token — Claude is given a helpful regex command for extracting various ways this token may be represented in natural language (eg: "5s" may be represented as "5 seconds", "five secs", "5secs", etc — this is not even exhaustive).

This interval token is then parsed and formatted as an appropriate value fed into a scheduler — more on this in a sec.

The prompt itself is the command, which Claude must execute on in its first pass, THEN schedule itself with the interval token (again, if absent, Claude decides on its own how to deal with the interval).

Claude also has the option of modifying its prompt between invocations, but that requires a specific LOOP.md file, which Claude can read when it wakes up, perform some work, update the doc, and then go to sleep.

Put together, this is how a loop feels from Claude's perspective:

1. User has asked me to pass the butter on a loop every five seconds. I will do so.
2. Calls tool pass_butter
3. I have passed the butter.
4. Calls tool Schedule(task="pass butter", delayInterval(5000)
5. Sleep

(Returning to the note on omitting the interval token: in the example above, Claude will pass butter every five seconds until you stop the loop and/or the session ends. If you don't pass the interval token, Claude will decide dynamically).

Under the hood, the loop is implemented as a Claude skill and a tool call to a Scheduler.

The skill tells Claude basic things for how to run a loop but I found a little bit of organizational context leaking into this implementation: if you ask Claude to /loop itself for an interval longer than 24 hours, it will tell you that the loop will be flaky because loops require running sessions, and 24 hours all but guarantees your session will be interrupted before then. Might you be interested in Claude Managed Agents? Anthropic will graciously take over your session and safe-guard it for you.

Claude has been saddled with selling Claude Managed Agents. Piqued.

How is a Loop implemented + my thoughts

As I said before, a Loop is a prompt and a tool call to a Scheduler function. The Scheduler is the interesting part. It takes an argument, delayInterval, which is how the scheduler knows when to run and awaken Claude.

This implementation is...less than ideal. Let me explain.

Claude's Loop skill doesn't have native state management between loops, which means from Claude's point of view, it is consistently being spontaneously invoked (no human in the loop), disoriented. It then reorients itself by reading the chat, seeing what's done, what else is to be done, does with it can, then sends a schedules another future call to itself.

Claude 4.8, ever the improviser, works around this by bootstrapping its own state file (eg: loop-state.json, temp.md `— these are often arbitrarily and conveniently named by Claude) . This kind of recurrent need for state necessitates encoding this as a default state tool for the skill—but the skills API is rather rigid, I think. This is part of its beauty, so this isn't strong criticism of its design, although I wonder why Claude (or someone) doesn't intuitively use the LOOP.md file as a free state store.

My real issue, though, is with the philosophy of a Claude loop. We know, today, that LLMs (as powerful as they are, still!) tend towards entropy as their task horizon climbs (due to blowing up the context window and just the diffusion of attention over time). The reasons humans exist in the loop is sorta to reset these entropic intervals with grounding context. Or so I always assumed from personal work.

Now, I admit: Claude Loops are fun, but they are not the future. If they are, then the luddite horses are retiring themselves too early.

I planned to give you a list of experiments I conducted using Claude loops, but unfortunately removing myself from those experiments meant I ended up not caring about what Claude ended up doing. I remember, though, that in a toy example, I asked Claude to add strokes to a p5 canvas every five minutes. I was underwhelmed by the output, but that's because I really wasn't involved or invested at any point in the process.

Now I did find actual use for Claude loops: research. Claude's waking disorientation (the statelessness problem I mentioned) proved useful here: Constraining Claude not to create a state file, I made it always wake up, review its past work, and push the boundaries of a small research endeavor I was conducting. I cannot tell you if this workflow makes the output better. All it did was allow me forget about it—and never return.

I guess I'm one of those old souls who still don't trust spooky action from a distance.