AI agents · A scripted run · Space to play

One loop, three models

How a team of AI models can build a software feature in a loop. The biggest model plans the work and reviews it, a mid-sized one writes the code, and the smallest reads files and clicks through the browser. The checks that decide pass or fail are plain code, not models. Press play to watch one run, failures included.

The task: Add a decade filter to a movie list

0:00 into the run · step 1 of 23

FramePersonClaude Opus 5.5Claude Haiku 5.5BuildClaude Sonnet 5.5GatesVerifyClaude Haiku 5.5GatesReviewClaude Opus 5.5PreviewClaude Haiku 5.5GatesShipPersonClaude Opus 5.5GatesRecordClaude Haiku 5.5
Person
Opus
Sonnet
Haiku
Gates
Frame
Build
V
B
V
R
B
V
R
P
Ship
R

✓ a check passed · ✕ a check failed and the run went back to Build. Tap any block to jump to it.

Frame

Person

Asks for the feature, approves the ship

Asks for a feature

Add a decade filter to the movies page, so I can see just the nineties.

A person: no tokens

Tokens and cost so far

Total $0.00

Calls, tokens and cost per model, up to the current step
ModelInOutCost
Opus 5.50.0k0.0k
$0.00
Sonnet 5.50.0k0.0k
$0.00
Haiku 5.50.0k0.0k
$0.00
Gates (code)––$0

The same tokens all on Opus 5.5 would have cost $0.00. List prices, without prompt caching.

The loop

A loop framework gives an agent a fixed path to follow. First write down what done looks like as checks anyone can run: “picking 1990s shows only films from 1990 to 1999”, not “it looks good”. Then build, and go round until every check passes. Any failure, at any stage, sends the work back to Build with the reason attached. Nothing reaches production until a person says yes.

The run above adds a decade filter to a page of movies. It fails twice, which is normal and the point: a type error caught by the compiler, and a bug the browser check missed but the review caught.

Why three models

The work in a loop is uneven. A little of it is judgment, where a mistake is expensive: deciding what to build and whether the result is right. Much more of it is reading files and clicking through pages, where a mistake is cheap and the next check catches it. So each kind of work gets its own model.

  • Opus, the lead, frames the work and reviews the diff. It uses no more tokens than the others but costs the most, and that is money well spent: these are the moments that decide the outcome.
  • Sonnet, the builder, writes and fixes the code. That needs real skill, and a lot of tokens.
  • Haiku, the scout, reads code and drives the browser. It reads about a third of all the tokens in this run for under two cents.

Each model sees only what its job needs. The scouts hand the lead a short summary, not every file they opened, so the lead's context stays small and sharp.

Why the checks are not models

A model asked whether its own work is finished tends to say yes. The compiler, the linter and the build cannot be talked round, so they hold the gates, and they cost nothing. Where a check needs eyes, such as clicking through a page, a model does it, but against checks written down before any code existed.

The layers catch different things. In this run the compiler caught a type error, and the review caught a bug the browser check had walked straight past, because nobody had told it to click “All”.

What to take with a pinch of salt

  • This run is scripted. It is written to match how these runs really go, but the token counts are representative, not measured. Costs are worked out from them at list prices as of October 2026.
  • Real runs cache. Each call resends much of the same context, and prompt caching makes those repeated tokens far cheaper. Real totals are lower than shown here, and caches are per model, so splitting work across models gives some of that saving back.
  • Three models is not always cheaper. One capable model at a lower effort setting can match a team of smaller ones. The honest measure is cost per finished feature, retries included, not cost per call.

Sources

  • Anthropic 2024 · E. Schluntz and B. Zhang, "Building effective agents", Anthropic (2024): orchestrator–workers and evaluator–optimizer loops
  • Yao et al. 2022 · S. Yao et al., "ReAct: Synergizing Reasoning and Acting in Language Models" (2022): the think, act, observe loop
  • Shinn et al. 2023 · N. Shinn et al., "Reflexion: Language Agents with Verbal Reinforcement Learning" (2023): learning from a failed check in words
  • Anthropic pricing · Claude API list prices per million tokens, as of October 2026