Claude Plans, DeepSeek Works: Is a Tiered Agent Actually Cheaper?

Hello builders,

The llm orchestrator worker pattern lets one person run a plan-and-verify team: Claude doing the judgment at both ends, cheap DeepSeek workers carrying the volume in the middle, and a bill you can price per role instead of guessing which tier to tune. You have almost certainly met it as a slogan rather than as an architecture. 96% of the performance for 46% of the cost. It went round every forum for a week and gets quoted as though it were a property of the universe.

Ask the person quoting it where it came from and the answers get vague fast. So I went and looked.

That figure is one company’s benchmark on one browsing task: the orchestrated version scored 86.8% against the single frontier model’s 90.8%, at roughly 46% of the cost. Divide 86.8 by 90.8 and you get 0.955, which is where the 96% comes from. A real measurement by a serious team, on their eval. Your changelog job is not their browsing benchmark.

Here’s the part that makes the point better than a lecture. The same organisation publishes a cookbook notebook for this exact pattern, and it reports its own run as roughly 2.5x cheaper and 3x faster, with 84 to 98% of input tokens billed at the worker rate.

Same org, same idea, two different numbers, because they measured two different things. That gap isn’t a scandal, it’s what honest measurement looks like, and it’s the receipt: if one company gets 46% of cost on one workload and 2.5x cheaper on another, then “how much does tiering save?” has no answer until somebody names a workload.

The expensive model stops reading

Let’s follow one job through and notice which model is holding what.

A request arrives: summarise this week’s work across four repositories into release notes. A single-model agent takes the whole thing and spends ninety seconds reading, deciding, fetching and writing, at one per-token price.

Now we split it. The expensive model goes first and its job is deliberately small: read the brief, decompose the task, assign a slice to each worker, define what done means. That planning step is where judgment lives, and it’s short. Maybe six hundred tokens of output, and it has done almost all the thinking the job requires.

Then the plan fans out. Four cheap workers each get one repository’s commits and one instruction, and none needs to know about the other three. Each holds only its own slice, so each context stays small, and small contexts are cheap. Finally the work comes back and the expensive model does the last piece of judgment: does this hang together, is anything missing, is any of it wrong.

Here’s what actually happened to the token accounting, and it isn’t what people say happened. In the single-model version, the context of all four repositories accumulated in one conversation and every turn resent it at the frontier’s input price. In the tiered version that bulk sits in four disposable worker contexts. The saving isn’t really “we used a cheaper model.” It’s that the expensive model stopped reading things.

Which turns the architecture into one question to ask of any agent you own: which parts of this job are decisions, and which parts are typing? Decisions are worth paying for. Typing is not.

We put the role assignment in roles.json rather than in code, because we are about to change it repeatedly:

{
  "changelog-agent": {
    "planner":  {"model": "claude-opus-4-8", "max_tokens": 1500},
    "worker":   {"model": "ds-flash",        "max_tokens": 2000},
    "verifier": {"model": "claude-opus-4-8", "max_tokens": 1000}
  }
}

We keep our tier vocabulary small and boring: planner, worker, verifier. Then tag every logged call as agent:role so your rollup breaks the agent down by tier with no new tooling. If you can’t say which role’s tokens dominated, you’ve built something you can’t tune.

When this costs you more

Tiering is not automatically cheaper. It is sometimes dramatically more expensive, and we should understand why before refactoring anything.

The same company’s engineering writeup on a multi-agent research system reports a big win and its price in the same post:

“We found that a multi-agent system with Claude Opus 4 as the lead agent and Claude Sonnet 4 subagents outperformed single-agent Claude Opus 4 by 90.2% on our internal research eval.”

“In our data, agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats.”

— How we built our multi-agent research system

Fifteen times the tokens. Move that volume onto models twenty times cheaper and you win. Move it onto models three times cheaper and what exactly have you built? A slower, more complicated way to spend more money. Their own conclusion names the shape of task it pays for: “valuable tasks that involve heavy parallelization, information that exceeds single context windows, and interfacing with numerous complex tools.” That is their advice, in their own post about their own architecture, and I promise I didn’t plant it there. Note the model generation, though: that post runs on an older lead-and-subagent pair, so read it for the mechanism rather than the model names.

So my honest test is two questions. Does this job have parts that are genuinely mechanical, and is the price gap between your tiers wide enough to survive the coordination overhead? If either answer is no, a well-routed single model beats a tiered architecture and is easier to debug.

One last thing, because it’s the failure that will bite you. Worker three hits a rate limit and returns an empty string. Your verifier gets three good summaries and one blank, and cannot tell “repository three had no commits” from “repository three’s worker died.” So it writes confident release notes covering three repositories out of four, nothing errors, and your logger records a completed job.

The fix is structural rather than clever. Workers return a labelled status, never a bare string, and the join refuses to proceed on silence:

# fanout.py
class IncompleteFanOut(RuntimeError):
    """Yours to define. The point is that the join raises instead of proceeding."""

def join(results, plan):
    """Never hand the verifier a hole it cannot see."""
    missing = [r for r in results if r["status"] != "ok"]
    absent = [s for s in plan["slices"] if s not in {r["slice"] for r in results}]
    if missing or absent:
        raise IncompleteFanOut(missing, absent)
    return "\n\n".join(r["text"] for r in sorted(results, key=lambda r: r["slice"]))

An empty response counts as a failure, not as an empty answer, because a worker that returned nothing has told you nothing. And the absent check catches slices that never came back at all, which is exactly what a try/except around each worker will happily miss.

Now go build something this weekend!

John Cook