Claude Architect in Practice: How Fable 5 Runs the Four Loop Types in Claude Code
Anthropic's four loop types — turn based, goal based, time based, and proactive — map directly onto the Claude Architect model. Here's the mechanism behind letting Fable 5 direct while cheaper models build.
In our last post, Claude Architect Model with Fable 5, we made the case for treating your top tier model as a planner, not a typist. Fable 5 designs the system and writes the specification. Smaller models handle the actual code. That argument was conceptual. This post is the mechanism.
Anthropic's Claude Code team recently published their own answer to a question a lot of people have been asking on X lately: what actually counts as a loop. Their definition is simple. A loop is an agent repeating cycles of work until a stop condition is met. They split loops into four types, based on how they start and how they stop. It maps onto the architect model almost exactly, which made it worth a second post.
Turn based loops: the architect at the keyboard
This is the loop most people already run every day. You send a prompt, Claude gathers context, takes an action, checks its own work, and hands back a result. You read it, and you write the next prompt.
This is Fable 5 acting as architect in the most literal sense, one exchange at a time. It suits exploratory work, the kind where you are still deciding what the system should look like. It is not the loop to use once the shape of the work is settled, because every turn still needs a human to judge whether it is done.
Goal based loops: the reviewer built in
This is where the architect model gets its teeth. Instead of judging each turn yourself, you define what done looks like up front with a goal command, and an evaluator model checks the work against that goal every time Fable 5 tries to stop. If the goal is not met, it goes back to work. This continues until the goal is hit or a turn limit you set is reached.
A goal for a client migration project might read something like this. Migrate the legacy invoicing module to the new schema, stop after eight tries once every integration test passes. Notice what happened there. The architect did not have to sit and watch. It stated a deterministic finish line, and the system enforced it.
/goal migrate the legacy invoicing module to the new schema.
Stop after 8 tries once every integration test passes and the staging deploy succeeds.
This is the same reviewer role we described in the first post, except now it is a named, repeatable primitive instead of a habit you have to remember to practice.
Time based loops: where delegation earns its keep
This is the loop type that makes the cost argument from our last post concrete. Recurring, narrowly scoped work, the kind that does not need a strategist, gets triggered on an interval instead of a prompt. Checking a staging deploy every five minutes, or triaging new client tickets every morning, is exactly the kind of task that never needed Fable 5's reasoning in the first place. It needed a cheap, fast model that shows up on schedule.
One version of this runs locally and stops the moment you turn your machine off. Another version moves the same loop to the cloud, so it survives without you present at all. That second version is still labelled research preview by Anthropic, so treat it as something to pilot on a small, low risk task before you hand it a client's production pipeline.
Proactive loops: the whole pipeline, unattended
This is the full architect model running exactly as we described it in the first post, minus the human. A schedule triggers the check. A goal defines what finished means. Skills tell the system how to verify its own work. And for anything that needs more than one agent, dynamic workflows, also still research preview, orchestrate several agents at once, triaging, fixing, and reviewing in parallel, with a separate judge model checking the fix before it ships.
Anthropic's own guidance for this loop type is blunt about the economics. Route the routine work to smaller, faster models. Save the most capable model for the calls that actually require judgment. That is not us reading delegation into their framework. That is the framework.
Mapping loops to the architect tiers
| Loop type | Architect tier equivalent | What it hands off |
|---|---|---|
| Turn based | Architect, manual | The check itself |
| Goal based | Reviewer | The decision to stop |
| Time based | Implementer, scheduled | The trigger |
| Proactive | The full pipeline | The prompt itself |
What is still research preview
Two of the pieces above, cloud based scheduling and dynamic workflows, are not yet stable features. Anthropic flags both as research preview. That is not a reason to avoid them, but it is a reason to pilot before you build a client deliverable on top of one. Run a small, low stakes version first, watch where it stalls, and only then wire it into anything that has a deadline attached.
The takeaway
The first post argued that your best model should direct, not do. This one shows the actual controls for making that true. Turn based loops are the architect thinking out loud. Goal based loops give the architect a reviewer that never gets tired. Time based loops hand recurring work to a model that never needed a strategist in the first place. And proactive loops chain all three together into a system that runs the way Fable 5 designed it, without Fable 5 having to watch.