Loop engineering without the cloud bill

A coursebook on Claude Code loops landed in my inbox this week — a genuinely good one, thirteen chapters on the shift from prompting a coding agent to designing the loop it runs inside. I agree with almost all of it. The one place I'd push back is the part it treats as settled: where the loop runs, and who pays for it.

The book's mental model is clean, and I'm going to borrow its vocabulary because it's the right one. A "loop" is three separable things:

• Goal loops — run until a condition you can prove holds, then stop. Bounded.
• Interval loops — re-run on a clock, or fire on an event. Continuous.
• The execution surface — where the loop physically runs. This is the one that decides whether your machine stays awake and whose account gets billed.

That third one is where the book and I part ways. Its interval examples reach, by default, for a hosted scheduler — cloud Routines, metered runs, a -p billing caveat you're told to mind before you wire anything up. And that's a reasonable default for a lot of people.

It just isn't mine. I run a persistent agent over my whole operation — capital, engineering, health, the books, the job pipeline — and it's run for months on a flat Max subscription and a Mac that won't go to sleep. No cloud loop surface. No per-run meter. So this post is the other half of that coursebook: the same six primitives, mapped onto the surfaces you already own.

The claim

Of the six things a production loop needs, exactly one has a cloud-shaped answer in the popular telling — the interval scheduler. The other five are already free, local, and in your session today. And that one exception has a local substitute that predates all of this by about forty years.

Here's the whole map, and where each piece actually lives on my machine.

1. Goal-conditioned execution — already local, already free

The heart of the book is the goal loop: give the agent a finish line it can verify, and stop pressing enter. The trick that makes it honest is that a separate, smaller model grades the transcript — the model deciding "done" is not the model doing the work, so the agent can't quietly grade its own homework.

This runs in your terminal. It costs what any interactive turn costs. There is nothing cloud about it. The craft is entirely in writing a condition with something concrete to check: not "clean up this file" but "npm test exits 0 with no failures in test/auth and npm run lint is clean." If you can't name the command whose output flips from no to yes, the loop has nothing to stand on — it'll spin, or hallucinate that it's finished.

I'll be honest about my own boundary here, once: I don't drive this through the built-in goal command yet. My verification is home-rolled — every agent action writes a pass/fail trace into a graph store, and a separate check reads that. Same architecture, different plumbing. The lesson is identical: an unattended loop without an independent verifier is a machine that ships bugs with high confidence.

2. The interval scheduler — the one exception, and its local answer

This is the piece the cloud telling actually owns. You want something to fire nightly, or every ten seconds, without a human in the chair.

The vendor answer is a hosted Routine. The answer that's been on your machine since 1975 is a scheduler daemon — launchd on a Mac, cron everywhere else. I have launchd agents that keep a local model server up, keep the machine caffeinated so overnight work doesn't die when the screen sleeps, and run shell daemons that poll on a fixed interval — one of them wakes every ten seconds. None of that phones home. None of it meters.

The composition the book teaches still holds perfectly: a scheduled loop (surface + interval) whose body, each time it fires, is a goal-bounded task. I just supply the "scheduled" half with a plist instead of a cloud subscription. The interval decides when; the goal decides when each run is done.

3. Verification — a second opinion, not a second bill

Covered above, but it's worth pulling out as its own primitive because it's the one people skip and the one that bites hardest. The verifier doesn't need to be expensive or remote. It needs to be independent — a different model, or at minimum a different process reading only what the worker surfaced. I run the small-model half of this on a local Ollama instance. The second opinion costs electricity, not tokens.

4. Memory and state — the thing that turns a favor into compounding

A single agent run is a favor: you delegate, you get it back, you move on. A loop compounds: each cycle resumes from recorded state and builds on the last. That only works if state actually persists between runs — and that's a database, which you already know how to run locally.

Mine is a graph store holding three layers: canonical current-state nodes (the truth for any given thread), an append-only episodic log (what happened, in order), and behavior nodes (corrections that should never have to be made twice). Every loop that fires reads that state on the way in and writes to it on the way out. The compounding the book promises is real — but it lives in your store, not the vendor's.

5. Parallelism and isolation — worktrees, not fleets

Running several agents at once only ends well if they can't collide. The book's answer is git worktrees, and it's correct — it's already a hard rule in my own engineering standards: no code work happens in the shared checkout. Every task gets its own worktree off the base branch, so two loops editing the same repo overnight can't clobber each other's uncommitted work. This post was written in one. Free, local, git.

6. Circuit breakers — the discipline an unattended loop demands

A loop cuts both ways. An interval loop with a vague goal and no cap can run for hours burning turns on nothing. So every loop needs a brake: a turn cap written into the condition itself, scoped permissions, and — the one I lean on hardest — a spend gate. Nothing in my system reaches for a paid surface without an explicit yes. That single rule is why the "cloud bill" in this post's title is zero, and it's a circuit breaker as much as any turn cap is.

What's actually cloud, then?

Add it up. Goal execution: local. Verification: local model. Memory: local database. Parallelism: git. Circuit breakers: policy. The scheduler: a daemon that predates the web. Five of six were never cloud-shaped, and the sixth has a substitute older than the problem.

I'm not claiming the hosted surfaces are worthless — they buy you a machine you don't have to keep awake and a scheduler you don't have to babysit, and for plenty of people that's worth the meter. I'm claiming the architecture is portable, and that "you need the cloud to run agent loops overnight" is a story about convenience wearing the costume of a requirement.

The commitment

Talk is cheap, so here's the deliverable with a clock on it. By July 11 I'll publish the exact recipe as a resource on this site. The launchd plist, the wrapper that runs a goal-bounded task on a fixed interval, the caffeinate trick that keeps it alive overnight, and the local-verifier hookup — copyable, with the token-and-electricity cost from a full week of it running against one of my own agents. The mental model is the durable part; the plumbing should be something you can lift.

The loop architecture is worth stealing. The bill attached to it in most of the writing is optional.