Big Model Orchestrates, Cheap Models Execute (And When That Loses)

The pattern everyone is sharing right now is a frontier model plans and delegates while cheaper models do the execution — the source of the viral ~96% of the performance at ~46% of the cost stat. It is real and well-anchored by Anthropic's own research, but the online version conflates three different architectures and stops at Anthropic-family-internal results, where a big Claude orchestrates cheaper Claude workers. This guide does two things that coverage misses. First, it separates the orchestrator, advisor, and plan-then-execute variants cleanly. Second, it makes the cross-vendor case with our own 13-model benchmark: on standard coding tasks quality converges (10 of 13 models scored a perfect 9/9) while cost for identical output spreads 88x — so the executor can be a $0.10 open-weight model from a different vendor entirely. We finish with the honest counter-evidence: mixing does not always beat a solo strong model, and a decision rule for when it wins.

Three patterns people keep conflating

The viral phrase "big model plans, cheap models execute" actually names three different architectures, and mixing them up leads to the wrong build. Before any numbers, get the taxonomy straight — the online discourse collapses all three into one headline.

All three descend from Anthropic's 2025 multi-agent research system. The differences are about who holds the plan and when the expensive model is invoked — which changes both the cost profile and the failure modes.

The orchestrator pattern and the viral stat

In the orchestrator pattern a frontier model plans and delegates to cheaper Sonnet-class workers that execute in parallel — and this is the source of the ~96%/46% headline. Per benchmarks circulated by Anthropic and reported in July 2026, the orchestrator setup reached roughly 96% of full-strength performance at about 46% of the cost: on the BrowseComp benchmark, 86.8% vs 90.8% accuracy and $18.53 vs $40.56 per problem. One honest caveat: that specific figure traces to an X post citing Anthropic benchmarks plus secondary coverage, not a first-party anthropic.com page — so treat it as reported, not officially published.

The lineage is firmer. Anthropic's 2025 multi-agent research system (a Claude Opus 4 lead with Claude Sonnet 4 subagents) outperformed single-agent Claude Opus 4 by 90.2% on their internal research eval. But that uplift came at a cost: multi-agent architectures used about 15x more tokens than chat, and token usage alone explained 80% of the performance variance on BrowseComp (token usage, tool calls, and model choice together explained 95%). The uplift is real; it is also a research/breadth-first result, not a coding one.

The advisor pattern (inverted)

The advisor pattern flips the hierarchy: a cheap model is the lead executor, and it calls a strong model as an advisor tool only when it needs help. Published by Anthropic on April 9, 2026, the reported results are striking. Sonnet plus an Opus advisor scored 74.8% on SWE-bench Multilingual vs 72.1% for Sonnet alone (+2.7 points) while cutting cost per task 11.9%. Even more dramatic: Haiku plus an Opus advisor more than doubled its BrowseComp score, 19.7% to 41.2%, while costing about 85% less per task than Sonnet alone.

The economic logic is the mirror image of the orchestrator: instead of a big brain paying for cheap hands, you have cheap hands that occasionally rent a big brain. This is the same idea we cover in cutting token costs on coding agents — reserve the frontier model for the moments that actually need it. Note that the exact benchmark naming (SWE-bench Multilingual vs Pro) is reported inconsistently across sources and the numbers come from one secondary source attributing Anthropic, so cite them as reported.

Why the cost curve bends: planning is ~20% of tokens

The whole pattern works because planning is a small slice of total token usage — often around 20% — so upgrading the planner to a frontier model is cheap while the bulk runs low-cost. If execution is 80% of your tokens, then swapping the executor from a frontier model to one that is 40x cheaper moves almost your entire bill, while keeping (or upgrading) the planner barely registers. That asymmetry is why the cost curve bends favorably instead of averaging out.

It also explains why the naive intuition — "mixing must cost somewhere in between" — is wrong. You are not averaging two prices; you are applying the expensive price to a thin planning layer and the cheap price to the thick execution layer. The question that decides whether this actually pays off, then, is: how cheap can the executor be without losing quality? That is exactly what a benchmark can answer.

The cross-vendor case: quality converges, cost spreads 88x

Here is what the Claude-family-internal coverage misses: the executor does not have to be a cheaper Claude — it can be a $0.10 open-weight model from a different vendor entirely. We ran a first-party executed coding benchmark in July 2026 — 13 models, 9 generate-code-then-run-hidden-tests tasks (full writeup and method in our 13-model coding cost benchmark). The result that matters for this pattern: 10 of 13 models scored a perfect 9/9. On standard coding tasks, quality converged. What did not converge was cost — the spread for the same 9/9 output was 88x.

Cost is $ per 1,000 tasks (tokens × list price); latency is average seconds per task. Qwen3 Coder Next, Mistral Medium 3.5, and Claude Sonnet 5 posted 0 reasoning tokens — non-reasoning models were often both faster and cheaper than heavy reasoners. Not every model hit 9/9: DeepSeek V4-Pro (8/9, missed a CSV parse), Grok 4.3 (8/9, missed a nested-dict flatten), and StepFun 3.7 Flash (8/9) fell one short. Source: DataLLM Lab first-party benchmark, July 2026.

The takeaway for this article: because a $0.10 executor matches a $4.05 or $8.83 model on standard coding output, the orchestrator pattern turns into a concrete multi-provider routing recipe — frontier plans, third-party-cheap executes. For picking that executor tier specifically, see our best cheap LLM for coding rundown.

A worked cross-vendor cost example

Let us price a real split so you can see where the money goes. Take 1,000 coding tasks. Assume planning is ~20% of total tokens and execution is ~80%, matching the pattern's economic logic. We price the planner at the Claude Opus 4.8 rate from our benchmark ($4.05 per 1k tasks at full workload) and the executor at the Qwen3 Coder Next rate ($0.10 per 1k tasks). Output quality is held at the observed 9/9 both ways. These are illustrative figures built on our measured per-1k costs, not a separate benchmark run.

Solo: full $4.05 workload on Opus, split notionally 20/80 as $0.81 + $3.24. Mixed: keep the $0.81 planning layer on Opus, run the 80% execution layer on Qwen at its $0.10-per-1k rate scaled to the 80% slice ≈ $0.08. Total ≈ $0.89 — about a 4.5x reduction, landing at or below the reported 46%-of-cost mark, but priced across real gateway models from two vendors rather than Claude alone. The catch: this assumes the executor genuinely can carry that 80% at 9/9, which holds for standard tasks and breaks on the hard, non-parallelizable ones — see below.

When mixing loses: the honest counter-evidence

The hype omits that mixing does not always beat a solo strong model — sometimes it is slower AND more expensive. In a practitioner benchmark on a mature coding harness (akitaonrails, April 2026), solo Opus 4.7 scored 97/100 at about $4. A strong planner mixed with a cheap executor (Opus + Kimi K2.6) tied at 97/100 — but cost about $5 to $7 and added 12 to 22 minutes. Worse, once the hidden orchestrator/planner cost (~$11 unlogged) was counted, manual orchestration ran about 3x more expensive than solo. Treat this as one illustrative harness, not a definitive refutation — but it is a real caution.

Anthropic's own caveat points the same way. It warns the multi-agent pattern is a poor fit for tasks where agents must share context or have many inter-agent dependencies, and states plainly that most coding tasks involve fewer truly parallelizable tasks than research. So the 90.2% research uplift does not transfer to a typical coding workflow. Mixing wins on genuinely parallelizable, well-scoped, one-shot work; it loses on tightly coupled tasks where the coordination and hidden orchestrator overhead eat the savings.

A decision rule

Use this as a quick gate before you split a workload. The pattern earns its keep only when a few conditions hold together.

If most rows land in the left column, the cross-vendor split will likely beat solo-frontier on cost at equal quality. If they land right, a single strong model is often cheaper once you count coordination overhead. When in doubt, measure both on your own tasks — which a gateway makes a config change, not a rewrite.

Building it on a gateway

The split is trivial to wire when every step goes through one OpenAI-compatible endpoint: you pick the model per call and the routing happens underneath. Point the planner at a frontier model and the executors at a cheap cross-vendor model, and the "which model for which step" decision becomes config rather than a code rewrite. A gateway also handles failover if one provider is rate-limited, so multi-provider routing does not mean juggling multiple accounts.

from openai import OpenAI

client = OpenAI(
    base_url="https://www.datallmlab.com/v1",
    api_key="YOUR_DATALLMLAB_KEY",
)

# orchestrator: frontier model plans + decomposes
plan = client.chat.completions.create(
    model="anthropic/claude-opus-4.8",
    messages=[{"role": "user", "content": "decompose this feature into independent coding subtasks"}],
)

# executor: cheap cross-vendor model runs each subtask
code = client.chat.completions.create(
    model="qwen/qwen3-coder-next",
    messages=[{"role": "user", "content": "implement subtask 1 against this interface"}],
)

Because the endpoint is OpenAI-compatible, it drops into Cursor, Cline, or any agent that speaks the OpenAI schema — and you can even run a cheap executor inside Claude Code, as in running Claude Code with GLM-5. For how routing and failover are wired, see what an LLM gateway is. One aside on the model landscape: it moves fast — Grok 4.5 shipped from xAI around July 8-9, 2026, described as Opus-class but faster and cheaper (our benchmark tested the earlier Grok 4.3 at 8/9, $1.75), so treat specific model versions and prices as a July 2026 snapshot.

FAQ