The model that looks too expensive until you build with it
Claude Opus is the most expensive output token on the market. On a per-token basis it’s 5–8x what worker-tier models cost and 30–50x what fast-tier models cost. Most cost-conscious teams reflexively avoid it. Most teams that have shipped a real multi-agent system have stopped reflexively avoiding it.
The reason is simple: Opus is the right model for the orchestrator role, and the orchestrator is a small fraction of total tokens in a well-designed system. Paying premium price for a small fraction of calls produces dramatically better results than paying mid-tier price for all calls. The math works.
This post is the case for that math, and the architecture that makes it pay off.
The orchestrator role
In a WAT-shaped system, the orchestrator’s job is narrow: read the workflow, look at the current state, decide which tool to call next. It does not draft responses. It does not write code. It does not summarize documents. It makes a sequence of small decisions about what to do next.
The orchestrator’s tokens are small. Input is the current state + the workflow + the toolset description. Output is usually a single tool call with arguments. A well-designed orchestrator burns maybe 2–8% of a system’s total tokens.
But every decision the orchestrator makes determines what happens next. A wrong tool call cascades. A right tool call propagates correctness through the entire workflow. The orchestrator’s leverage is enormous and its volume is small. This is exactly the shape of work where you want the best possible reasoning, regardless of price.
Where Opus wins decisively
Five capabilities where Opus measurably beats lower tiers in orchestrator work:
Instruction following under ambiguity. When the workflow describes a complex sequence and the state is partially novel, Opus follows the workflow more reliably than Sonnet or GPT-4-class models. We’ve measured this. The gap is small on clean states (90% vs 88%) and large on novel states (85% vs 60%).
Tool selection from large toolsets. When the agent has 15+ tools available, Opus picks the right one more often. Sonnet starts making “close but wrong” selections that look right but break the workflow.
Recovery from upstream errors. When a tool fails or returns unexpected results, Opus more often reasons productively about what to do next. Lower-tier models more often retry blindly or give up.
Stable reasoning across long sessions. Multi-step agent workflows drift more on smaller models. Opus stays coherent over 20-30 step workflows that other models lose track of around step 10–15.
Honest uncertainty. When the right answer is “I don’t know enough; ask for clarification,” Opus says that. Smaller models more often guess. The asymmetry matters in production — a wrong guess is much worse than asking.
The cost math
Here’s a worked example from a recent build. The system has:
- An orchestrator agent that makes ~8 decisions per user task.
- ~6 tool calls per task, each consuming ~3000 input tokens and ~200 output tokens (some are model-backed, some are pure code).
- A typical workload of 4,000 tasks per day.
Option A: Sonnet for everything.
- 8 orchestrator decisions × 4,000 tasks × (avg 5000 input + 800 output tokens at Sonnet pricing) ≈ $192/day on orchestrator alone.
- Worker tool calls (model-backed): 6 × 4,000 × Sonnet pricing ≈ $384/day.
- Total: $576/day. ~$17,300/month.
Option B: Opus for orchestrator, Sonnet for workers.
- Opus orchestrator: 8 × 4,000 × (5000 input + 800 output at Opus pricing) ≈ $960/day.
- Sonnet workers: $384/day (unchanged).
- Total: $1,344/day. ~$40,300/month.
The Opus option is 2.3x more expensive. That’s the headline cost number.
Now the quality number. In the same build, with the same workflow:
- Sonnet-only: agent successfully completed the workflow on first try 78% of the time. Retries pushed that to 92%. The remaining 8% required human intervention.
- Opus-for-orchestrator: first-try success 94%. Retries pushed to 99.2%. Human intervention <1%.
The cost of human intervention is the dominant factor. Each intervention requires 5–15 minutes of an internal operator’s time, fully loaded at $80/hour. Across 4,000 tasks/day:
- Sonnet-only: 320 interventions/day × 10 min × $80/hour = $4,267/day in operator cost.
- Opus-orchestrator: 40 interventions/day × 10 min × $80/hour = $533/day in operator cost.
Adding it up:
- Sonnet-only total: $576 inference + $4,267 ops = $4,843/day.
- Opus-orchestrator total: $1,344 inference + $533 ops = $1,877/day.
The Opus configuration is 61% cheaper because the inference savings of Sonnet are swamped by the operations cost of more frequent failures. This is the math that makes Opus worth the price.
Where the math doesn’t work
This argument has boundaries. Opus is not always the right call.
For pure worker tasks, Sonnet is the right model. The work is bounded, the failure cost is small, and Opus is overkill. We’ve never built a system where Opus made sense for the worker tier.
For high-volume short-response classification, Opus is the wrong model. Haiku, GPT-mini, or self-hosted Qwen will do the job for 1/30th the cost with quality that’s indistinguishable on bounded tasks.
For very short workflows (1–2 steps), the orchestrator role barely exists. Putting Opus there doesn’t move the needle. Sonnet or GPT-4-class is fine.
The pattern: Opus pays off when the orchestrator’s decisions cascade and when human-intervention cost is meaningful. It doesn’t pay off otherwise.
The architecture that makes Opus economics work
Three architectural moves make the Opus-for-orchestrator pattern sustainable:
1. Prompt caching aggressively. Opus has prompt caching that cuts the cost of repeated prefixes (workflow doc, toolset description) by ~90%. In a real orchestrator, most of the input tokens are cacheable. Done right, the effective cost of an Opus orchestrator call is closer to the Sonnet uncached cost.
2. Cap the orchestrator’s per-task budget. The orchestrator should have a hard ceiling on tokens per task. If it goes over, abort. This catches degenerate loops before they become expensive incidents.
3. Route confidently within the orchestrator. When the orchestrator’s job is well-bounded for a known workflow shape, you can sometimes drop to Sonnet for the orchestrator on the known cases and reserve Opus for the unknown ones. This is more architectural complexity, and only worth it at high volume.
The honest counterargument
The argument against using Opus is real: it’s a bet that the capability gap is large enough to justify the price gap. The capability gap is closing. In 12–18 months, Sonnet-class models may be good enough for the orchestrator role at meaningful cost savings.
If you believe the gap will close fast enough, the Sonnet bet is reasonable. If you believe it will close slowly, the Opus bet wins through the period it remains true.
Our practice is to default to Opus for the orchestrator and re-evaluate quarterly. We have not yet found a quarter where the Opus bet wasn’t the right one for non-trivial orchestrator work. That may change. It hasn’t yet.
What to do with the savings
If switching to Opus-for-orchestrator reduces your total operating cost (which it does in the math above), the natural question is what to do with the savings. Three good options:
- Buy more sophistication. Higher per-tenant cost ceilings, more aggressive eval suites, more workflows in production. The unlocked operational capacity is meaningful.
- Pass cost to customers as quality. Better outcomes per task means better retention, better reviews, more word-of-mouth. Reinvest into the product surface.
- Build the next system. The freed-up operator hours can be spent on the next agent rather than baby-sitting the current one.
The take
Claude Opus looks expensive on a per-token basis and is the right call for orchestrator agents in most multi-agent systems. The total system cost is lower because operator intervention cost dominates inference cost when the agent fails. Build the system to match this cost shape — Opus for orchestration, Sonnet for workers, fast tier for classification — and the math works out. Default to cheapest-everywhere and you’ll spend the savings on operators cleaning up after the agent.
Multi-provider routing with Opus orchestrators is the default in our Custom AI Builds. If your current agent stack is single-tier and you want a re-architecture conversation, schedule a call.
