Claude Fable 5, Part 2: Loop Engineering

In part 1 I made the case that Fable 5 punishes step-by-step prompting and rewards goals, boundaries, and verification.

Part 2 is the endpoint of that logic. A few days in, most of my Fable 5 tokens are no longer spent on prompts I type. They're spent inside loops: systems with a trigger, an executor, a grader, a memory file, and a stop rule, that run whether or not I'm at the keyboard. The people getting the most out of this model have made the same move, and this post is a field guide to how they build.

One sentence of philosophy and then we get concrete. A prompt is a request; a loop is a policy. Requests need you present. Policies work at 3am, survive your vacation, and get better each cycle because they write down what they learned.

Here's the split for this post. The free half covers the anatomy of a production loop, the one rule that separates loops that converge from loops that flatter themselves (the maker is never the grader), cost routing across models, and stop rules. The paid half is the loop cookbook: paste-ready templates for a nightly verifier loop, the rubric-driven outcome loop with working API code, the orchestrator pattern, scheduled deployments for production, verified GitHub repos that run these loops today (deep research agents and an agentic SOC), and a weekend build project.

From prompts to loops

The idea has a source, and I checked it the same way I fact-checked part 1. Boris Cherny, who created Claude Code and still runs it at Anthropic, said this on stage at Sequoia's AI Ascent in May: "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." The punchier one-liner going around X ("loops that prompt Claude for me") is a paraphrase, and the tagline "Loops are the future" that gets pinned on him appears in no transcript I could find. But the substance is his, repeated at a WorkOS event with Acquired in June and at Fortune Brainstorm Tech, where he described managing "maybe a few hundred" agents that morning, some days "thousands, or tens of thousands," and added the line that explains this whole post: "It's actually another Claude that does the prompting."

The tooling caught up to the idea, and it's in official docs now. Claude Code ships `/loop` (v2.1.72+) for recurring or self-paced runs of a prompt or slash command, `/goal` (v2.1.139+) which sets a completion condition and keeps working toward it, and cloud Routines via /schedule that run on Anthropic-managed infrastructure with your laptop closed. The Managed Agents API adds outcome-graded sessions that iterate against a rubric without you in the room. June even gave the practice a name: "loop engineering" got a New Stack feature and an Addy Osmani post. None of this requires exotic infrastructure. A loop can be a scheduled task on a laptop that invokes an agent with the same three-paragraph instruction every night.

One honesty note before the anatomy. Several loop patterns circulate on X attributed to specific handles: a six-component loop stack, a plugin that watches failures and auto-writes CLAUDE.md, a quote about "a few thousand agents doing deeper work every night." I ran the same deep-research pass I used for part 1 and could not locate those posts, that plugin, or that quote; the closest real thing to the last one is Cherny's Fortune remark above. Every component of the patterns is independently documented, so I'll teach the patterns. I won't put names on posts I can't find, and you shouldn't either when you share this material.

Fable 5 fits this work because of the combination from part 1: it holds a goal over long horizons, it uses file-based memory instead of ignoring it, and parallel subagents are dependable enough to delegate to. Older models needed you in the loop as the error corrector. Fable 5 needs you in the loop as the policy author.

The six parts of a loop that won't embarrass you

Every loop I've seen work, mine and other people's, has the same six parts. Every loop I've seen fail is missing one of them.

The trigger starts a cycle: a cron schedule, a CI failure, a webhook, or /loop self-pacing. The rules load pulls in the frozen project knowledge (CLAUDE.md) and the accumulated memory, so cycle forty knows what cycle three learned. The executor does one bounded unit of work, not "make progress" but "fix the next failing test" or "process the next ten files." The verifier grades the output in a fresh context. The memory write records progress and lessons. The stop check decides: done, escalate, park, or go again.

Here is the whole thing as an instruction block you can hand to a scheduled agent, sized to fit in a system prompt:

Each cycle: (1) read memory/INDEX.md and any lesson files it flags
as relevant; (2) do ONE bounded unit of work toward the goal below;
(3) spawn a fresh-context verifier subagent to audit what you claim
you did against test output and diffs; (4) append progress and any
new lesson to memory; (5) stop if the success condition is met, if
you have failed the same step 3 times, or if this cycle's token
budget is spent. Otherwise end the cycle cleanly for the next run.

The load-bearing words are "ONE bounded unit." A loop that tries to finish everything in each cycle is a long prompt with extra steps, and it fails the same way: scope creep in the middle, fabricated status at the end. Small cycles keep each verification cheap and each failure recoverable, and the memory file is what turns forty small cycles into one coherent project.

The maker is never the grader

This is the rule that decides whether your loop converges or spirals. The phrase itself is community coinage, but the pattern has two named sources. Anthropic's Fable 5 prompting guide says separate fresh-context verifier subagents "tend to outperform self-critique," and recommends running them on a set cadence during long work. And Lance Martin, who joined Anthropic this spring to lead model launches, published "Designing loops with Fable 5" in June with numbers attached: in his experiments, verifiers in independent context windows caught around 73 percent of seeded issues, against 7 to 33 percent for self-critique in the same context. His framing of the mechanism is the cleanest I've seen: the maker sees its own reasoning trail; the verifier sees only the artifact and the rubric.

The mechanism is worth understanding, because it explains the design. A model reviewing its own transcript inherits its own framing. If it misread the spec at step 3, the misreading is sitting right there in context at step 30, coloring the review. The fresh-context grader gets none of that: only the claims, the diff, and the raw test output. It answers one question per claim, does the evidence support it, and it has no stake in the answer. In my experiment of running these, the graders caught things the worker had narrated past: a skipped migration file, a test suite that "passed" because it never ran, a benchmark number copied from the wrong run.

Two implementation notes. Run graders at effort: low; judging evidence is cheaper than producing it, and a low-effort Fable 5 grader (or even a Sonnet 5 grader for mechanical checks) is plenty. And feed the grader artifacts, never the worker's summary. If the grader reads the story instead of the evidence, you've rebuilt self-review with more steps.

Route by cost: plan, act, verify

At $10/$50 per million tokens, running Fable 5 for every keystroke of implementation is how you turn a $30 night into a $300 one. The pattern that keeps showing up in cost-conscious setups splits the work by what each stage needs:

Plan on Fable 5 at xhigh, because a plan error is the most expensive error you can make and this is the model that catches spec contradictions. Gate the plan with a human read, five minutes that saves hours. Implement on Sonnet 5 at medium, because typing out a well-specified plan is not capability-sensitive work. Review the diff on Fable 5 at xhigh in a fresh context, which is the maker-grader rule applied across models. Gate the merge.

plan = fable(task, effort="xhigh")           # expensive, once
approve(plan)                                 # human gate
diff = sonnet(implement(plan), effort="medium")  # cheap, bulk
verdict = fable(review(diff, plan), effort="xhigh", fresh=True)
approve(verdict)                              # human gate

That pseudocode is the entire economics of the pattern: Fable 5 appears exactly twice, at the two points where intelligence compounds (deciding what to build, deciding whether it was built), and the token-heavy middle runs at a third of the price. On my week-one numbers this routing cut the cost of a comparable feature by a bit more than half, and the diff-review stage rejected one Sonnet implementation that would have shipped a subtle API misuse. The two human gates are optional once you trust the loop; keep them while you're calibrating.

Stop rules, or your loop will run until your card declines

An unbounded loop is not autonomy, it's a liability. The discipline that separates production loops from demos is that every exit is explicit:

Three exits, in priority order. A success condition, stated as something checkable ("all tests green and the verifier confirms the migration list is empty"), stops the loop with an evidence-backed report. A retry ceiling (the same step failing three times) stops it with an escalation to a human, because cycle four of the same failure is never the one that works; it's the one that starts "fixing" things that weren't broken. A budget ceiling, in tokens or dollars, parks the work cleanly for the next window.

The API gives you a native lever for the last one. Task budgets tell the model how many tokens it has for the whole agentic loop, and it sees a live countdown and paces itself instead of getting cut off mid-file:

response = client.beta.messages.stream(
    model="claude-fable-5",
    max_tokens=128000,
    output_config={"effort": "high",
                   "task_budget": {"type": "tokens", "total": 60000}},
    betas=["task-budgets-2026-03-13"],
    messages=[...], tools=[...],
)

The budget is advisory to the model but visible to it, which changes behavior: it prioritizes, wraps up, and reports what's left rather than sprinting into a wall. The floor is 20,000 tokens, and max_tokens stays the hard per-response cap underneath. In a nightly loop I set the task budget per cycle, so a confused run burns one cycle's allowance and not the night's.

That's the free half. Behind the paywall: the paste-ready templates for all of this, the rubric-driven outcome loop that grades itself, the orchestrator setup, production scheduling with the failure modes, memory poisoning and how to not do it to yourself, and the weekend project.

For paid subscribers — the loop cookbook starts below.

Everything up to this point is free. The Going Deeper section that follows is for paid subscribers. It contains the paste-ready nightly verifier loop and memory scaffold, the rubric-driven outcome loop with working Managed Agents code, the orchestrator pattern for routing Fable 5, Sonnet 5, and Haiku by cost, production scheduling with the failure modes that bite, the memory-poisoning countermeasures nobody else is writing about, verified GitHub repos running these loops today (deep research agents and an agentic SOC, with a triage-loop template), a dedicated companion repo with the templates and both loops as working Fable 5 code, and a weekend project to ship your first loop.

You can unlock it with 50% discount— and every paid deep-dive on this publication — here: https://kenhuangus.substack.com/subscribe?coupon=302342d9.