Loop Engineering AI Playbook: Stop Conditions That Save Cost

Loop engineering AI is the craft of writing agent jobs so a coding assistant repeats work until a clear stop fires: verify success, early abort, or turn cap with escalate. This playbook owns cost control through stop conditions. You leave with a stop taxonomy, verify ladders ordered cheap to expensive, cap ranges by job class, escalate templates that turn failure into a ticket, and honest limits: PromptMake at https://promptmake.net/loop-prompt-generator writes command text only. It does not run loops or bill model tokens. The sibling loop-engineering-explained article defines goals, verify, and caps as a design discipline. Stay here for the cost playbook you run on real tickets.

Who this loop engineering AI playbook is for

You need this playbook when agents keep spending after the useful work ended: flaky tests thrashing, missing secrets, or a goal that was two epics wide. Stop conditions convert those failure modes into bounded spend. Without them, "keep going until it works" becomes an open invoice.

Strong fit: teams using Claude Code /goal-style loops, SDK runners with max_turns, and leads who review agent transcripts for waste. Weak fit: one-shot chat questions, or readers who still need vocabulary only. Send those readers to loop-engineering-explained first.

As of mid-2026, pair written stop clauses with host ceilings when available: Claude Agent SDK max_turns, dollar budgets such as max_budget_usd, and account usage controls. Prompt text teaches behavior. Runner options enforce the wall when the model ignores soft language.

PromptMake drafts recommended goal, verify, turn cap, and stop guidance as text. You paste into Claude Code or Codex and supervise on a branch. Soft entry: https://promptmake.net/loop-prompt-generator.

Stop condition taxonomy that protects cost

Three stop families matter. Success stop fires when proof appears: tests exit 0, build green, forbidden paths untouched. Early abort fires when progress is impossible: missing secret, identical error fingerprint three times, out-of-scope schema change required. Turn-cap stop fires when attempts run out regardless of proof, then escalate must run.

Write all three into the same brief. Success alone leaves impossible jobs looping. Cap alone stops work without teaching what done meant. Abort alone without a cap still lets slow thrash burn tokens until a human notices.

Order the brief so stops sit next to verify: Goal, Scope fences, Verify ladder, Abort rules, Turn cap, Escalate script. Agents and humans share one contract. Put the cap number in natural language ("or stop after 12 turns") and mirror it in host options for unattended runs.

Cost rises in late turns because context grows. Early aborts save the expensive half of the curve. Teach abort with the same care you teach success. A loop that only knows how to win will fake progress when blocked.

Success stop lines you can paste

"Stop with success when: npm test --workspace packages/api exits 0; lint clean on touched files; no files outside Allow changed. Print the verify command outputs in the final message."

Early abort lines you can paste

"Abort early when: required env var missing; same error fingerprint on three consecutive turns; fix requires Deny paths; upstream service 5xx for ten minutes. On abort: no further edits; run Escalate."

Verify ladders and turn caps that save money

A verify ladder lists checks from cheap to expensive. Lint or typecheck on touched files before full integration suites. One failing unit file before the monorepo test script. Read one config before grepping the tree. Cheap checks fail fast and leave budget for real fixes.

Turn caps bound how many tool-use rounds you buy. Size by job class, not luck. Single-package test fix: 8-12. Contained refactor: 12-20. Migration batches: 6-10 per batch, not one mega-cap of 40. Unattended CI babysitting: cap identical red statuses before cancel, even when interval language dominates.

Align the number with the host counter. As of mid-2026, SDK max_turns counts tool-use rounds. Chat narration without tools may not consume that counter the same way. Write one definition in the brief and the runner config.

Log outcomes. If the same job class hits the cap with half the ladder green three times, split the goal or nudge the cap by 3-5 after you fix verify. If caps never fire and successes land mid-range, leave the number alone. Raising caps on vague goals buys more of the same failure.

Deeper sizing tables live in turn-cap-agent-prompts. Deeper verify wording lives in verify-criteria-prompt-patterns. This playbook stitches them into a cost stop system.

Cap ranges cheat sheet

Docs sync path-fenced: 8-12. API bug in one package: 10-15. Cross-package refactor with fences: 15-20. Call-site migration batch of five: 8-10. Never start at 40 for a vague "improve reliability" goal.

Dollar ceilings beside turn caps

When the runner supports max_budget_usd or similar, set it for overnight jobs. Turns control behavior. Dollars protect the invoice when late turns get fat. Interactive sessions may lack per-run dollar flags; still write a turn clause and use account limits.

Escalate scripts that turn stops into tickets

A stop without escalate wastes the money you already spent. The agent must convert failure into a skimable report: blocker summary, checks passed, checks failed with command excerpt, recommended human next step. Forbid further edits after escalate.

Require escalate on turn-cap, early abort, and repeated verify fail after N attempts if you use that rule. Paste the same four-line script everywhere so transcripts look alike in review.

After escalate, humans choose: fix the environment, split the goal, tighten fences, or raise the cap by a small step. Do not auto-relaunch the same brief at 40 turns. Read the blocker first.

Store winning stop packs in docs/agent-loops/ with last-tested Claude Code version and date. Retest after CLI upgrades because evaluator defaults and slash behavior can shift.

Escalate block (paste-ready)

"On turn-cap or abort: (1) one-paragraph blocker, (2) passed verify lines, (3) failed verify lines with last command excerpt, (4) next human action. Do not edit more files. Do not start a new goal unless the human says continue."

What to change after repeated cap hits

Split the goal, fence directories tighter, move expensive checks later, or switch to turn-based approval between batches. Only then nudge the number up. Soft redraft of the command text: https://promptmake.net/loop-prompt-generator.

Step-by-step: apply the playbook to one ticket

Pick a real failing test or a five-call-site batch. Write Goal, Allow/Deny, Verify ladder, Abort rules, Turn cap, Escalate. Draft on paper first. Optionally polish at https://promptmake.net/loop-prompt-generator. Run on a clean branch. Log which stop fired.

Success metric: stop fired for the right reason with a useful escalate, or success with proof printed. A green diff that ignored Deny is a failed run even if tests pass.

Guest free use on PromptMake loop generation is about three per day; free registered accounts about five as of mid-2026. Anthropic or OpenAI spend is separate.

Step 1: Write stops before tools run

Fill Success, Abort, Cap, Escalate while offline. If you cannot name Success in one paragraph, split the ticket before you open Claude Code.

Step 2: Mirror caps in the host

Paste the brief. Set max_turns (and dollar budget if available) to match the written number for unattended jobs. Interactive sessions still keep the written clause.

Step 3: Review the stop, not only the diff

Read whether success, abort, or cap fired. File the escalate text. Adjust fences or verify before you touch the number. Save the winning pack for that job class.

Common mistakes that burn loop budget

Mistake 1: Goal without success proof.

Mistake 2: Cap of 40 on a mega-goal.

Mistake 3: Cap without escalate.

Mistake 4: Expensive full-suite verify on every turn before cheap lint.

Mistake 5: Treating PromptMake as a runtime that enforces stops.

Mistake 6: Confusing this playbook with loop-engineering-explained. That page owns definitions. This page owns cost stop conditions.

Mistake 7: Raising caps instead of splitting scope when escalate shows no progress.

Model routing and host notes (mid-2026)

Route mechanical edits and log summarization to cheaper tiers when your host allows model routing. Reserve Claude Opus 5 or GPT-5.6 Sol class judgment for planning and hard fixes inside the fence. Caps bound waste; model choice sets the price per turn. A high cap on a vague goal with a flagship model is the expensive failure mode this playbook exists to prevent.

Claude Code slash spellings and evaluator defaults can shift. Treat /goal and /loop as patterns: structured brief plus bounded iteration. Read Anthropic release notes when field names move. SDK options such as max_turns and max_budget_usd remain the unattended safety net as of mid-2026; confirm exact option names in current docs before overnight jobs.

PromptMake at https://promptmake.net/loop-prompt-generator remains text-only. It suggests turn caps and stop language. It does not enforce runtime limits, schedule CI, or watch your branch. Pair every serious brief with host ceilings when you leave the session unattended.

Risky work still needs a human gate even with perfect stops: production deploys, payment code, permission changes, data deletes. Use turn-based skeletons and require an explicit continue after each escalate report. Cost savings never outrank blast-radius control.

Soft next steps on the loop prompt generator

Take one recurring red test. Write the six-part stop pack. Generate a draft at https://promptmake.net/loop-prompt-generator. Run once. Log the stop reason. Promote the pack into your team docs when it wins three times. For Skill-shaped standing jobs, use the Claude skill generator instead. For turn-cap math tables, read turn-cap-agent-prompts.

FAQ

What is loop engineering AI in this playbook?

Loop engineering AI means designing agent loops with explicit stop conditions so cost and scope stay bounded. You combine success verify, early abort, turn caps, and escalate reporting. The playbook focuses on those stops as a cost system, not on inventing new slash command brands.

Which stop conditions save the most cost?

Early abort on missing secrets and repeated identical errors often saves more than shaving two turns off a healthy run. Cheap-first verify ladders cut waste inside each turn. Caps stop open-ended thrash. You want all three written.

How do turn caps and verify criteria work together?

Verify defines success. Turn caps define when to stop without success. Abort defines when to stop before the cap because progress is impossible. Complementary posts on this blog go deep on verify patterns and cap sizing. This playbook shows how they combine for cost.

Does PromptMake run my loops?

No. https://promptmake.net/loop-prompt-generator generates command text: goal, verify, caps, stop guidance. You paste into Claude Code or another host. PromptMake does not access repos, schedule jobs, or pay model invoices. Guests get about three generations per day; free registered accounts about five.

How is this different from loop-engineering-explained?

Loop-engineering-explained teaches the discipline: what goals, verify criteria, and turn caps are. This loop engineering AI playbook focuses on stop conditions that save cost: abort rules, escalate scripts, ladders, and operational ranges. Read definitions first if you are new; stay here to cut spend.

What turn number should I start with?

Start about 8-12 for single-package fixes, 12-20 for contained refactors, and 6-10 per migration batch. Raise only when escalate shows real progress near the wall. Prefer splitting goals over jumping to 40.

Should I set SDK max_turns if the prompt already has a cap?

Yes for unattended runs. Written caps teach summarize-and-stop behavior. Host max_turns and optional dollar ceilings enforce the wall when soft language fails. Keep the numbers aligned so humans and machines share one definition.