The /loop Pattern: When Self-Pacing Helps vs Burns Tokens

It was 11 PM on a Saturday when I noticed the agent had been running for nine hours and had spent forty dollars. The job itself was unsexy: a content drift babysitter, watching a small set of pages for changes, with a self-paced loop the runtime allowed to pick its own interval. The agent had picked thirty seconds.

I had not told it to pick thirty seconds. I had told it, in the prompt, “self-pace, and check back when it seems appropriate.” Thirty seconds seemed appropriate to the agent. The prompt cache window is 270 seconds. Every wake-up was a fresh full-input charge on a system prompt that was, by the standards of these things, big. By morning I had a charming little ASCII chart of identical no-op checkpoints and an invoice that made me close the laptop.

That was the night the /loop pattern stopped being an interesting toy in the Maestro Section 10 docs and became a discipline I apply to every long-running agent I ship. The pattern is not complicated. It is concrete. Once you understand the cache breakpoint it lives or dies on, you stop writing self-pacing loops by default and start choosing them deliberately.

This post is the practitioner version of what Maestro S10 specifies and what I learned the expensive way. What /loop actually is. Where the 270-second window sits in the math. When self-pacing wins. When it loses badly. And the concrete recipes I now use for deploy babysitters, content drift checks, and the long-running patterns in between.

What Is the /loop Pattern?

/loop is the Maestro Section 10 mapping for “this agent needs to wake on a cadence rather than run once and exit.” The S10 spec breaks the long-running surface into three primitives, worth naming precisely because the choice between them is where the cost lives.

/loop <interval>. You tell the agent the exact wake cycle in advance. Every five minutes, every ten, every hour. The interval is fixed by you, not by the agent, which means the cost shape is predictable. You can do the cache math up front.

/schedule. The durable cloud version: the routine survives process restarts, runs on cron-style cadence, persists state through an external scheduler. Use this when you want the loop to survive your laptop closing.

The omitted-interval case, the one that burned me. No interval given. The agent is told to self-pace using ScheduleWakeup, which lets it choose its own wake time. The Maestro rule is precise: polling under 270 seconds is allowed when cache locality matters, otherwise the next wake should be 1,200 seconds or more. Not advisory. The difference between an inexpensive loop and one that bills four dollars an hour for doing nothing.

One rule sits above all three: never poll work the harness already notifies you about. If the runtime tells you when a tool returns, when a build finishes, when a process exits, do not write a loop to ask. Use the persistent Monitor primary and let the loop pattern be a fallback heartbeat at most. The cheapest poll is the one you do not run.

That last rule is the one most people violate first. The rest of this post covers the rest.

Why Does the 270-Second Prompt Cache Window Matter?

Claude (and several other frontier APIs) supports prompt caching. The system stores the long prefix, system instructions, tool definitions, conversation history, in a cache keyed to your account. If the next request arrives inside the TTL with a matching prefix, the cached portion is billed at roughly an order of magnitude below full input. Cache hit: small read fee. Cache miss: full input rate.

The standard TTL is 270 seconds at the time of writing. There is an extended-cache tier with a longer window at additional storage cost. The 270-second number governs default self-pacing, and it is what Maestro S10 anchors its rule to.

The cost shape is sharper than people intuit. A 240-second wake on a 30,000-token system prompt pays cache-read rates on 30,000 tokens plus full input on the small delta. A 300-second wake misses by 30 seconds and pays full input rate on the entire 30,000-token prefix. Over an eight-hour overnight run, 240 vs 300 seconds is the difference between a couple of dollars and a couple of hundred.

This is why “five minutes feels safe” is the dangerous intuition. Five minutes is 300 seconds, exactly the interval that misses the cache by the smallest margin. Poll inside the window, or stretch the interval enough that the miss is amortized over real work instead of over wakeups.

When Does Self-Pacing Win?

The honest answer is: less often than I used to think. There are three specific cases, and they share a structural property worth naming.

Self-pacing wins when the work is event-driven and the agent has more context than you about when events are likely. If the agent is watching a long build for the next log signature it cares about, or holding a research thread open while a downstream tool slowly returns chunks of source material, it often knows whether the next interesting moment is thirty seconds away or thirty minutes away. A fixed interval cannot capture that judgment.

The pattern that works here is: persistent Monitor for the actual event stream, self-paced loop as a fallback heartbeat. The Monitor tells you when a tool finishes, when a new log line arrives, when a tracked file changes. The loop tells you “the Monitor should have fired by now, let me check the world.” Combined right, the Monitor handles most of the work for almost no token cost, and the self-paced loop only wakes when the agent’s expectation diverges from reality.

The second case is reasoning, not polling. If the loop body is “think for a while, then sleep, then keep thinking,” and the thinking benefits from incubation gaps, then the agent’s own judgment about sleep duration matches the rhythm of the work better than a fixed interval. This is rarer than people pretend; most tasks billed as “needs incubation” just need a smaller agent and a shorter run. But genuine long-horizon planning across multiple sessions does benefit from variable spacing.

The third case is recovery work. An agent retrying after a downstream failure should back off, judge whether the failure cause is likely to have cleared, and pick the next attempt accordingly. Self-paced fits, as long as the agent is told the floor for non-polling waits is 1,200 seconds and that polling under 270 is reserved for cache-locality cases.

In all three the agent has information you do not. That is the structural property. If you have the information, set the interval yourself and stop paying the model to make a decision you could have made with a number.

When Does Self-Pacing Burn Tokens?

The losing case is the one I lived. It is also the most common shape I see in the wild.

Self-pacing loses when the work is fundamentally polling and the agent has no information to choose an interval beyond what you gave it in the prompt. “Check if anything changed” is the dominant example. Nothing in the agent’s context tells it whether thirty seconds is too aggressive or ten minutes too slow. It picks a number. If the number lands in the 300-to-1,200-second dead zone, you pay full input rate on every wake. If it lands under 270, you pay cache-read rate but probably poll more often than the work needs. Either way, cost is set by a model decision that had no signal driving it.

The worse version is polling a tool whose runtime already notifies on completion. This is the rule at the top of every Maestro S10 loop spec, and it is the first one violated. If a long-running tool emits a completion event, the harness routes that event to the agent for free. Polling on top is pure waste: full input rate on every wake to ask a question the runtime will answer without being asked.

There is a subtler losing case: self-pacing burns tokens when the agent’s wake-up logic depends on state the agent does not remember. If the loop reasons every iteration about “should I check again in thirty seconds or three minutes,” and that reasoning regenerates from scratch each wake because nothing in the cached prefix records the previous decision, the agent oscillates. 30 seconds, then 90, then 300, then 30 again. Fixed intervals do not have this failure mode. They are dumber by design, and the dumbness is the saving.

The shape of the losing pattern: an agent asked to make a decision it has no information for, in a loop, with no anchor between iterations. Almost any self-paced loop not designed around the Monitor primitive degenerates into this. The fix is not better prompting. The fix is to write the interval as a number.

A Recipe for the Deploy Babysitter

The deploy babysitter is the case that taught me to write intervals as numbers. The work is: a build runs, the agent watches for completion, surfaces success or failure cleanly, optionally kicks off the next step. The instinct is “check every five minutes.” Five minutes is 300 seconds. Five minutes is the worst possible interval.

The right answer, when the platform does not emit a completion webhook the harness can route, is a fixed /loop 240s. Two hundred and forty seconds keeps the cache hot. The cache-read cost on the system prompt is small. The fresh-context delta is a single line about the previous check’s status. Over an hour: roughly fifteen wakes at cache-read rate plus fifteen small deltas. Well under a dollar on any orchestration-tier model.

If the platform does emit completion events, do not use /loop at all. Monitor is the primary; the loop is a long-interval fallback at most. Set the fallback to /loop 1800s. Its job is to notice “the Monitor has been silent for thirty minutes when it should have fired,” not to ask “did the build finish yet.”

The deploy babysitter does not benefit from agent judgment on interval. The work is pure polling. The right shape is /loop 240s if you must poll, Monitor primary with /loop 1800s fallback if you can. Self-pacing is wrong here because the agent cannot improve on “240 seconds, every time.”

A Recipe for the Content Drift Check

The drift check is the case that taught me about the 1,200-second floor. The work is: every so often, look at a set of tracked pages, see if anything has materially changed, write a short note if it has. Most days nothing of interest happens. The cache is irrelevant because by the time we wake again, the prefix has long expired.

The right answer is /loop 1800s or /loop 3600s, depending on staleness tolerance. Both are past the cache window, so every wake pays full input rate. That sounds bad until you do the arithmetic. Forty-eight wakes a day at full input rate on a thirty-thousand-token system prompt is a smaller bill than a 240-second interval would generate even with cache hits, because the 240-second loop does 360 wakes a day. Cache savings do not catch up. Long intervals win on wake count alone.

The Maestro S10 floor of 1,200 seconds is the lower bound for “not polling-locality.” Below 1,200 you should be inside the cache window or you are paying full input for no reason. At or above 1,200 the regime flips: wake count dominates, and the right strategy is to wake less often, not chase the cache.

Self-pacing is mostly wrong here too, with one exception. If the drift check is genuinely event-driven, say, a feed of upstream change signals through a Monitor channel, then a self-paced loop pegged to “wake when the Monitor has been quiet for an hour, otherwise let the Monitor drive” is the right shape. The Monitor handles the live signal at near-zero cost. The loop is a heartbeat, and the agent’s judgment on heartbeat interval is fine because the floor is high enough that the cache math stops mattering.

A Recipe for the Long-Horizon Reasoner

This is where self-pacing earns its keep. An agent doing genuinely long-horizon work, planning across sessions, accumulating findings, distilling rules into a checkpoint as Maestro S10 specifies, benefits from variable spacing because the work has variable rhythm. After a productive burst, sit and let downstream artifacts settle. After a quiet stretch, wake more aggressively.

The pattern: self-paced loop with an explicit floor of 1,200 seconds, a ceiling around 7,200, and a hard rule that wake intervals are recorded in the checkpoint file so the next iteration can reason about the previous decision. Checkpoint anchoring stops the oscillation problem. Without it the agent re-derives pacing every wake and burns tokens drifting. With it, the agent reads its previous decision, considers whether to extend or shorten, and writes the new interval back.

This is also where the extended-cache tier earns its keep. Storing the stable prefix at the extended-TTL rate means a four-hour gap still gets cache-read pricing. Worth it for long-horizon work; not for a deploy babysitter, where the savings do not justify the cache-storage spend at deploy-loop frequency.

What I Tell Other People About This Pattern

Four rules, in priority order.

Never poll work the harness already notifies you about. If the runtime emits a completion event, use the Monitor. Polling on top of notification is the single most expensive mistake in this whole pattern.

If you must poll, stay under 270 seconds or jump to 1,200 or more. The 300-to-1,200-second range is the dead zone. It misses the cache without buying you latency benefit. If five minutes feels right, ask whether four or twenty would do the job, and pick one of those instead.

Write the interval as a number unless the agent genuinely knows something you do not. You know how often the build completes, how often the page changes, how often the metric drifts. /loop 240s is cheaper than letting the model decide, because the model has no signal driving the decision and will burn tokens making it.

Use checkpoints to anchor self-paced decisions. When you do let the agent self-pace, the checkpoint file prevents oscillation. The previous wake interval should be readable in the next iteration. Maestro S10 specifies the checkpoint shape; the relevant property is durability across wakes.

I have applied these rules across most of the long-running agent work I have shipped since the night the drift check ate forty dollars. Most loops should be fixed-interval. Most fixed intervals should be either 240 seconds (cache hot) or 1,800 and up (accepted miss). Self-pacing is reserved for cases where the agent has genuine signal the operator does not. Monitor is primary for event-driven work. The loop is a fallback heartbeat at most.

The deeper point, which I have written about from a different angle in The Automation Paradox, is that cost discipline on agent systems is engineering work, not vendor work. The cache window is a number. The dead zone is a number. The interval is a number. None of this needs a smarter model. All of it needs the operator to know the numbers and write them down.

What I Am Still Wrong About

The 270-second cache TTL is a current artifact. The extended-cache tier already exists at a longer window with a storage cost, and there is no reason to assume the standard TTL stays at 270. If providers shift the window, the specific numbers in this post move with it. The structural advice will still hold: do not poll harness-tracked work, do not loop in the dead zone, anchor self-paced decisions in checkpoints.

I am probably underweighting how much the model itself improves at picking intervals. I default to fixed today because the model’s pacing judgment is no better than mine, and mine is grounded in the cache math. A future model that genuinely reasons about cost shape and cache TTL might outperform a fixed-interval loop where the rhythm varies. I have not seen that yet.

I am also uncertain how much generalizes beyond the Claude/Maestro setup I run on. Other providers have different cache architectures, different TTLs, sometimes no prompt cache at all. The rule “stay inside the window or jump past the dead zone” is provider-specific in numbers, structural in shape. On a stack without prompt caching, fixed short intervals lose their advantage and self-pacing with a high floor becomes the default. Do not import these specific intervals into a different stack without rechecking the math.

I have written more broadly about this kind of operational discipline in What 18 Months of Production AI Agents Actually Taught Me and about why structural enforcement beats prompt reminders in Why I Stopped Using Multi-Agent Frameworks. Those are the longer companions to the narrow pattern here.

The night the drift check ran for nine hours and spent forty dollars was the cheapest tuition I have paid on this stack. The numbers in this post are what I bought with it. If your loops feel a little too clever, write the interval as a number, check whether it lands in the dead zone, and move toward an edge. Both edges are cheap. The middle is where the money goes.