Expensive Models Don't Write Code: A New Paradigm for Multi-Agent Orchestration

Over the past year, most developers have used coding agents in almost exactly the same way: pick a model, open a chat window, and watch it write line by line. Powerful models come with terrifying bills; cheap models require constant supervision to keep them on track.

The author of Orchestro proposes a radically different approach. He runs multiple projects simultaneously, and the most expensive model in the entire system doesn't write a single line of code. Over 14 days, his sessions consumed roughly $2,100 worth of tokens at API prices, yet he only paid $100 in subscription fees. Behind that number is a multi-agent orchestration architecture that completely separates "thinking" from "typing."

Three Roles, Each With a Single Job

The architecture splits work into three layers, with each role responsible for exactly one thing.

The Strategist, powered by Claude Code running at high reasoning effort, checks every 5 minutes (via /loop 5m) on what the orchestrator is doing: which task it picked, what it delivered, where it's stuck. It doesn't write code — it only judges whether the direction is right.

The Orchestrator holds the backlog queue, picks the next task, hands it to an executor, and records the result.

The Executor is a cheap coding agent running on a fixed subscription, such as Muse. It does the actual work: pulls branches, changes code, runs tests, opens PRs, merges only when verification passes, and finally confirms the change is live.

The key point is that the orchestrator doesn't care which model the executor uses. Projects declare their own choice of Claude, Codex, Grok, or Muse — which means when one vendor's quota runs out, tasks don't get stuck. They stay in the queue with their evidence, and switch to another executor to keep going.

What is the /loop command? In some coding agent CLIs (such as community extensions for Claude Code or similar tools), /loop is an instruction that makes the agent automatically repeat a task at fixed intervals. /loop 5m means triggering once every 5 minutes. Its value lies in turning "supervision" from a manual operation into an automated heartbeat: the strategist doesn't need to be constantly online — it just reads the orchestrator's current state each time it wakes up and judges whether the direction needs adjusting. This "scheduled agent" pattern differs from the traditional "event-driven" approach: costs are predictable and the logic is simpler, but it also means the strategist spends most of its time checking a quiet system and may miss transient failures that occur between two checks.

What is model cascade / mixed models? Model cascade refers to combining models of different capabilities and price points within the same workflow, letting expensive models make high-value decisions and cheap models handle batch execution. The core assumption is that different stages of a task have vastly different reasoning-depth requirements. In this architecture, the strategist uses a high-reasoning-effort Claude for directional judgment, while the executor uses a cheap model within the subscription to handle long-chain operations like pulling branches, changing code, and running tests. This avoids using expensive models for mechanical labor and anchors costs to a fixed subscription rather than a token-billed API.

One Rule That Keeps the Whole System Running: Distinguish Two Kinds of Problems

When the strategist finds a problem, the first question is: whose problem is this?

Project problem (a bug, a priority misordering, a missing backlog item): the strategist directly fixes the backlog queue, and the executor picks it up in the next round.

Framework problem (the orchestrator picks the wrong task, gets stuck, never closes out work): the strategist doesn't patch around it, but reports the issue to another session — one whose sole responsibility is maintaining the orchestrator. It fixes the core logic and pushes the new version to all projects.

The author gives a real case: on October 14, the strategist found that the blog content pipeline hadn't had anything verified for an entire day after switching to a lightweight orchestrator. Work was delivered as usual, but the orchestrator only recorded "delivered," never "verified," so the verifier never saw these changes at all. This wasn't a blog problem — it was a framework problem — and it got sent to the framework session rather than papered over with a local temporary patch.

Every project tests the framework, and every framework fix benefits all projects. The author doesn't plan orchestrator improvements in advance — "real projects find them on their own."

What are the "orchestrator" and "backlog queue"? The orchestrator is the scheduling hub in this system. It doesn't write code itself; instead, it maintains a backlog queue, picks the next task from it, assigns it to an executor, and records the execution result (success, failure, evidence) back into the queue. The backlog queue decouples tasks from executors: when one vendor's quota runs out, tasks aren't lost — they stay in the queue with their existing evidence, waiting for the next available executor to continue. Recording results rather than just "dispatched" is the precondition for this architecture to detect the "merged ≠ verified" problem, because the evidence chain lets an independent verifier re-examine every change after the fact.

What is the divide between "framework problems" and "project problems"? This is the attribution principle the author repeatedly emphasizes. A project problem refers to a defect or priority error in a specific project, and the fix is confined to that project's backlog queue; a framework problem refers to a logic defect in the orchestrator itself, such as picking the wrong task, getting stuck, or never closing out work. The point of distinguishing them is to avoid "local patching" that masks systemic defects. Framework problems get reported to a dedicated session — whose sole responsibility is maintaining the orchestrator's core logic — which fixes them and pushes to all projects. This "ownership routing" amplifies the benefit of a single fix across all projects, and lets the framework evolve passively through real project usage rather than by advance planning.

The Real Reason for Mixed Models: Cost and Resilience

Why mix models? The answer has two layers.

The cost logic is clear: thinking is expensive, typing is cheap. The expensive model reads the state once every 5 minutes; the cheap model runs long continuous tasks. All calls go through official CLIs, using native subscription quotas rather than token-billed API keys.

From the 3rd to the 16th, the author's Claude Code sessions consumed roughly 17 million output tokens and 7 billion cached input tokens. At public API prices, that's about $2,100 to $2,250, or roughly $4,500 per month. What he actually pays is a €100 monthly subscription — and that's only Claude's cost, with executor usage not yet counted.

But the author is very honest about the precondition: a loop that re-reads context every 5 minutes is cheap under a subscription and expensive under API billing — 65% of the API-equivalent bill would be cache reads. This pattern works precisely because it uses a fixed subscription and operates within its limits. If a vendor changes how it bills automated usage, these numbers change.

Resilience is the other layer of value. When one vendor's quota runs out (that week it was Codex), work doesn't stop. Tasks stay in the queue with their evidence and continue with another executor.

Why would cache reads make up 65% of the API-equivalent bill? Modern LLM APIs typically price input tokens in two tiers: cache hits and misses. Cache hits (i.e., context sent previously being reused) cost far less than misses. In this architecture, the strategist re-reads the orchestrator's state and history every 5 minutes, so the vast majority of input is repeated old context, generating enormous volumes of "cache read" tokens (the author reports 7 billion cached input tokens), while genuinely new content is minimal. Under API billing, these cache reads, though cheap per unit, accumulate into the bulk of the bill due to their sheer volume. Under a fixed subscription, this cost is absorbed by the subscription fee — which is exactly the key precondition for the pattern to work. Once a vendor changes billing for automated usage, the economics could flip instantly.

The Current Data, Including the Ugly Parts

The author published data across three dimensions:

• Blog content pipeline, the 3rd–14th: the independent verifier issued 95 verdicts, 87 passed, 7 failed, 1 inconclusive.
• The orchestrator's own repository, same period: 63 merges, 0 independent verification passes (8 failures, 13 inconclusive).
• After switching to the lightweight orchestrator on the 13th: the blog had no verification records on the first day, until the strategist caught the bug.

The lesson the author keeps learning is: "merged" does not equal "verified." A system that only counts merges will look beautiful, but it lies to you.

Unsolved Problems

The architecture isn't without weaknesses, and the author lists three:

The executor still says "done" when it isn't. That's why the strategist reads state rather than messages.

A strategist checking every 5 minutes spends most of its time inspecting a quiet system — and the ratio of "how many checks per effective fix" is something he hasn't measured yet.

Two heavy builds on the same machine fight each other. Currently a shared lock serializes them, but the author admits this is a stopgap, not a design.

This Isn't Entirely New, But the Combination Is

The author openly acknowledges that planner/executor splits, supervisor agents, and model cascades have all existed for a while. What he hasn't seen is this combination: a cheap supervisor running on a fixed clock, routing problems by "ownership" (project problem vs. framework problem), and a separate session dedicated to improving the orchestrator from failures surfaced by real projects.

If you're already working in a similar way, or have solved the same problem differently, the author poses three questions: how often does your supervisor check, and what exactly does it look at? How do you decide whether a problem is a project problem or a tooling problem? And what is your true cost per "verified" change, rather than per merge?

Orchestro is currently in a very small private testing phase, used mainly on the author's own projects.