Loop Engineering: Your Claude Code /loop and /goal Setup Guide (Without Budget Surprises)

Stop prompting every single step. Build loops that check their own work, fix their own mistakes, and stop on a ceiling you set.

This is the guide I promised: what a loop actually is, the two commands that ship inside Claude Code today, your first loop in five minutes, and the one billing setting that stops a runaway loop from eating your budget while you sleep.

Let's get you running.

What is loop engineering?

Loop engineering is the practice of designing a small system that prompts an AI agent for you, checks the result, and decides the next step, instead of you typing every prompt by hand. As Addy Osmani puts it, "loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead." A loop is a recursive goal: you set the purpose once, and the agent iterates until the work is done.

💡 Key Insight: A prompt is one turn you babysit. A loop is a goal you set once that runs, checks itself, and corrects until it hits the finish line you defined.

At a glance

How to read this guide

If you only have two minutes, read "The two loop commands" and "The billing guardrail." Those two sections are the working setup. The rest gives you the why, the deeper verification design, and the tools beyond Claude Code so you understand what you are building, not just the commands to paste.

The shift: from prompting to designing loops

For two years, getting work out of an AI agent meant one thing: write a good prompt, read what came back, write the next prompt. You were holding the tool the entire time, one turn after another.

That part is ending. Two people closest to the work said so within a week of each other.

Boris Cherny, the creator of Claude Code at Anthropic, said in a recent interview: "I don't prompt Claude anymore. I have loops that are running. They're the ones that are prompting Claude and figuring out what to do. My job is to write loops."

Five days later, Peter Steinberger, who stewards the OpenClaw project, posted a line that spread fast across tech Twitter: "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."

Two million-ish impressions later, plenty of people were sharing it and almost nobody was explaining what a "loop" actually is. So here is the plain-English version.

Think of an airplane on autopilot. The pilot knows the destination. The pilot does not press every button by hand. They set the route and the altitude, and the autopilot flies it: adjusting, correcting, holding the line until the plane lands. Until now, you were the pilot and the co-pilot, sitting on every control. A loop moves you out of the cockpit. Your job becomes writing the flight plan.

The 4 ingredients of every loop: Goal, Context, Evaluation, Agent

Whatever tool you use, a loop is built from four parts. Get these right and the loop runs. Get them vague and it wanders.

1. Goal. The finish line or the thing to watch. "All tests in the auth folder pass." "Every product description is under 150 words." "Tell me the moment the deploy goes green." Write it as something the agent's own output can prove.
2. Context. What the agent needs to know to do the work: the project, the relevant files, a skill that holds your standards, and a memory file on disk that survives between runs. The agent forgets between runs. The file does not.
3. Evaluation. The check that decides pass or fail after each pass. This is the part people skip, and it is the part that decides whether the loop is trustworthy. A passing test or a clean build is a fact. A model saying "looks done" is an opinion. Prefer facts.
4. Agent. The model doing the work. In Claude Code that is a current model like Claude Opus 4.8 or Sonnet 4.6 doing the building, with the fast, cheap Claude Haiku 4.5 acting as the checker.

💡 Key Insight: The "Evaluation" ingredient is the whole ballgame. A loop is only as good as the check that tells it whether it is done.

The two loop commands in Claude Code: /goal vs /loop

Here is the part most people get wrong. There are two commands, and they do different jobs. Both keep Claude working without you re-prompting. The difference is what starts the next turn.

/goal: run until it's actually done

/goal sets a completion condition and Claude keeps working toward it across turns. After every turn, a small fast model reads the conversation and answers one question: is the condition met? A "no" comes back with a reason, and that reason becomes the instruction for the next turn. A "yes" clears the goal.

/goal all tests in test/auth pass and the lint step is clean

This is the self-correcting behavior from the reel: set the goal once, it checks the result, and if there is an error it keeps going until the finish line is real. One caution from the docs: the checker only judges what Claude has actually shown in the conversation. It does not run commands on its own. So write the finish line as something Claude's own output can prove, like "the test command exits clean."

Non-coders, this works for you too:

/goal rewrite all 40 product descriptions until each is under 150 words and matches the brand checklist

/loop: run on a schedule to watch and react

/loop re-runs a prompt on a clock. You give it an interval and a prompt, and it fires on that schedule until you press Esc.

/loop 5m check if the deployment finished and tell me what happened

Give it just a prompt and no interval, and Claude picks the gap itself each round, anywhere from one minute to an hour, based on whether anything is happening. This is the right command for the "babysit my work" example:

/loop babysit all my PRs. Auto-fix build issues, and when comments come in, fix them.

💡 Key Insight: Pushing work to a finish line is a /goal. Watching for a change and reacting is a /loop. Point one at the other's job and you either burn turns on finished work or spin forever on something the agent cannot move.

Your first loop in 5 minutes

1. Update Claude Code so you have both commands (you need v2.1.139 or later for /goal).
2. Open Claude Code in the folder you want to work in. The folder is your "context."
3. Pick one job with a clear finish line. Start small: a single file, a single list, a single test folder.
4. Type /goal followed by your finish line, written as something the output can prove. Add a stop clause (next section).
5. Watch the ◎ /goal active indicator. After each turn you will see a short reason explaining why the condition is or is not met yet.
6. When the condition is true, the goal clears itself. Run /goal with no argument any time to see the turns and tokens spent so far.

That is the whole loop. You wrote the flight plan. Claude flew it.

The billing guardrail: stop a loop before it drains your budget

This is the setting I promised in the reel, and it is the one most people miss. A loop without a ceiling is an expensive way to discover you left it running. Set two ceilings, every time.

1. A turn ceiling, inside the goal. Add a stop clause to the condition itself so a goal that can never be satisfied does not run forever:

/goal every row has a verified email, or stop after 20 turns

1. A dollar ceiling, at the account level. Set a spend limit in your Anthropic Console usage settings so no single loop can run past a dollar amount, no matter what. This is your hard backstop.

Three more habits that keep the bill sane:

• Check the meter. Run /goal with no argument to see turns and tokens spent at any point.
• Use a cheap checker. The evaluator defaults to the fast, low-cost Haiku model, so the checking does not cost what the building costs. Keep it that way.
• Prefer factual evals. A loop that exits the instant a test passes stops paying for extra turns. A loop that waits for a model to "feel done" can keep going.

💡 Key Insight: Two ceilings, always: a turn cap inside the goal, and a dollar cap on the account. The first stops a confused loop. The second stops a catastrophe.

Verification is where loops live or die

If you want loops you can actually trust to run unattended, this is the section to re-read.

The canonical loop has five steps: Sense, Plan, Act, Verify, repeat. Cutler SG's analysis makes a sharp point: step 4, Verify, is where agents fail. His test for whether you have a real verify step is worth memorizing: "If your Verify call shares context with the Act call, you have not added a Verify step. You have added a louder version of Act." The agent checking its own work is not a check.

Three patterns fix this:

1. The maker-checker split. One agent produces the work. A second agent, with its own fresh context, checks it. The checker's only job is to find reasons to say no. Because it did not produce the work, it has no ego invested in calling it finished. The Loop Library calls this "the single most useful structural upgrade" you can make.
2. Deterministic gates over opinions. A unit test passing is a fact. A clean build is a fact. A model saying "yes, complete" is an opinion, and the weakest of the three. Match how much you trust a loop to how faithfully its check measures the real goal.
3. Verify at every transition, not just the end. The common mistake is checking only at the finish. If the final review misses a failure, the failure ships. The stage-gate approach puts a pass-or-fail gate after each step. Any gate fails, the loop stops, logs the exact output that broke it, and retries from that stage, not from the beginning. Work downstream of the failure never runs, so you do not pay for doomed turns.

Loops beyond Claude Code

This is not a single-tool idea, and you should not treat it as one. The pieces now ship inside the products.

• The Codex app has an Automations tab where you pick a project, a prompt, a cadence, and whether it runs on your checkout or a background copy. Runs that find something land in a triage inbox.
• Claude Code gives you /goal, /loop, scheduled tasks, hooks, and GitHub Actions.
• The Loop Library, a community catalog from Matthew Berman published in June 2026, is a cookbook of copy-paste loop prompts with built-in checks and stop conditions. Start there if you want patterns other people already tested.

Once you see that the shape is the same across tools, you stop arguing about which app and just design a loop that works wherever you are sitting.

How it all works together

Picture one loop running your week. An automation fires every morning. Its prompt reads yesterday's failures, the open tasks, and the recent changes, then writes what it found into a single file or board. For each item worth doing, the loop opens an isolated workspace and sends one agent to draft the fix. A second agent reviews that draft against your standards and your tests. What passes moves forward. What fails goes back with the exact reason. You read a short summary and make the calls that need taste. The agents handle the rest.

You are not in the cockpit pressing buttons anymore. You are writing the flight plan and reading the instruments.

Getting started: what you need and what it costs

• Claude Code, updated to v2.1.139 or later, on a paid Claude plan. This is the fastest way to use both commands today.
• One folder and one small job with a clear finish line. Resist starting big.
• A spend limit set in your Anthropic Console before you run anything unattended.
• Optional: a memory file (a simple markdown file in your project) so the loop remembers what is done between runs.

Cost depends on how much work the loop does and which model does it. The point of the turn cap and the dollar cap is that you decide the ceiling in advance, not after.

Resources

• Boris Cherny on writing loops instead of prompts (interview write-up): officechai.com
• Addy Osmani, "Loop Engineering": addyosmani.com/blog/loop-engineering
• Claude Code docs, "Keep Claude working toward a goal" (/goal and /loop): code.claude.com/docs/en/goal
• Matthew Berman's Loop Library: signals.forwardfuture.ai/loop-library

FAQ

What is loop engineering?

Loop engineering is designing a small system that prompts an AI agent, checks the result, and decides the next step, so you stop typing every prompt by hand. A loop is a recursive goal: you set the purpose once and the agent iterates until the work meets a condition you defined. The term was popularized in June 2026 by Boris Cherny, who built Claude Code, and Peter Steinberger of the OpenClaw project.

What is the difference between /goal and /loop in Claude Code?

/goal keeps Claude working until a finish condition is true, with a fast model checking after each turn whether the condition is met. /loop re-runs a prompt on a timer to watch for changes and react. Use /goal to push work to done, like fixing tests or rewriting a list. Use /loop to watch something on its own schedule, like a deploy status or incoming PR comments. /goal shipped in Claude Code v2.1.139, /loop in v2.1.72.

Do you need to be a coder to use loops?

No. If you can write a clear instruction with a checkable finish line, you can write a loop. The same /goal command that fixes a test folder can rewrite forty product descriptions until each is under 150 words and matches your brand checklist. The skill is writing a goal the agent's own output can prove, not writing code.

How do you stop an AI agent loop from burning your API budget?

Set two ceilings. First, a turn cap inside the goal itself, written as a stop clause like "or stop after 20 turns," so a goal that can never be met does not run forever. Second, a dollar limit in your Anthropic Console usage settings, so no single loop can spend past a hard amount. Also use the cheap fast model as the checker and prefer factual checks like passing tests, which let the loop exit the moment the work is truly done.

What are the four ingredients of a loop?

Goal, Context, Evaluation, and Agent. Goal is the finish line or the thing to watch. Context is what the agent needs to know, including a memory file on disk that survives between runs. Evaluation is the pass-or-fail check after each pass, where a passing test beats a model's opinion. Agent is the model doing the work, with a cheaper, faster model acting as the checker.

Is prompt engineering dead?

Not dead, but no longer the top layer. Writing a single good prompt still matters inside a loop. The shift is that the highest-value skill is now designing the system that prompts the agent and checks its work, rather than typing each prompt yourself. As Boris Cherny put it, "my job is to write loops." Prompting is one ingredient of a loop, not the whole job.

How is loop engineering different from prompt engineering?

Prompt engineering is crafting one instruction for one turn that you supervise. Loop engineering is designing the system around the agent: the goal, the context it can read, the check that decides pass or fail, and the schedule or condition that drives the next turn. Prompting holds the tool the whole time. A loop hands the tool a flight plan and a set of instruments, then runs on its own until the condition you set is met.

What tools support loops besides Claude Code?

The Codex app supports loops through its Automations tab, where you set a project, prompt, cadence, and environment, with results landing in a triage inbox. Beyond the built-in commands, the Loop Library from Matthew Berman is a community catalog of copy-paste loop prompts with built-in checks and stop conditions. The underlying parts (automations, isolated workspaces, skills, connectors, and reviewer sub-agents) now ship inside multiple tools, so a well-designed loop carries across them.

If this helped, here is the ask:

→ Share it with one person who is still prompting every step by hand.

→ Tell me which loop you set up first. I read every reply.

Loops are the upgrade. Just remember the two ceilings before you walk away from one.

Keep building.