TL;DR: Three days ago I wrote that task difficulty should be treated as a constant and model capability as a variable. I still believe that. But I missed something: it’s not just models that change; the collaboration patterns between them change too. Anthropic’s advisor strategy fills in exactly that layer. A cheap model drives the whole task; the expensive model appears only at critical decision points. Official benchmarks show it approaches top-tier quality at roughly 60% of the cost. This post adds the second variable I left out last time.
Yesterday I came across an Anthropic post on X. One diagram stood out: a cheap model handles the main loop, and only when a critical judgment is needed does it call a stronger, more expensive model for a recommendation. The majority of tokens still run at the cheap model’s rate.
I looked at it for a moment, because it landed directly on a post I had published three days earlier.
That post was called “Difficulty as a Constant”. My argument was that model dispatchers shouldn’t hardcode model names into routing rules, because model capability is the most volatile thing in the whole system. Keep the difficulty tiers as the stable layer, pull “which role uses which model” into a dated binding table, and when a model is updated you only update the table.
I still believe that argument.
But the diagram made me see that I had made the same mistake in that post, just one layer higher. The error wasn’t in the model bindings. It was in the collaboration pattern above them.
The Advisor Strategy: Let the Cheap Model Drive, Bring in the Expensive One Only at the Intersection
Let me start with what that diagram was pointing at.
Anthropic launched something called the advisor tool in April, and recently added Fable 5 as an available advisor. The setup works like this: a cheap, fast model (Sonnet or Haiku) acts as the executor, running the entire task from beginning to end. It calls tools, reads results, and closes in on an answer step by step.
When the executor hits a decision it can’t handle, it consults a stronger advisor.
The advisor sees the full context but doesn’t take over the task. It returns a plan, a correction, or a signal to stop. Then the executor keeps going.
The advisor never touches tools and never produces the final answer the user sees. It only provides direction at critical moments.
The cost savings come down to one detail: the advisor returns roughly 400 to 700 tokens per consultation and is typically called only once across an entire task. Everything else runs at the executor’s cheaper rate.
Most tokens accumulate at the cheap rate. The genuinely expensive judgment appears only where it matters.
The Second Collaboration Pattern I Missed: Decompose, or Ask Up?
There’s a fork here I didn’t see at the time.
The fork isn’t about which model to use. It’s about whether a task should be broken downward or escalated upward.
When I wrote “Difficulty as a Constant,” I had exactly one collaboration pattern in mind: a coordinator decomposes a large task into smaller pieces, dispatches them by difficulty to different models, then validates and integrates the results.
That’s top-down orchestrator-workers. Anthropic describes it clearly in their guide to building effective agents, and I cited it in that post.
The advisor strategy runs in the opposite direction.
Anthropic’s own framing is that it “inverts the common sub-agent pattern where a larger orchestrator breaks down work and delegates to smaller workers.” In the advisor pattern, a cheap model does the driving, and a stronger model is consulted on the way up only when needed.
There’s no upfront decomposition. No worker pool, no dispatch logic.
Orchestrator-workers puts the expensive model at the top giving orders. The advisor pattern lets the cheap model run on its own, borrowing top-tier reasoning only when the situation calls for it.
Both are correct. The difference is the shape of the task.
Some tasks can be cut into parallel pieces with uneven difficulty across them, needing a strong model to pull the results together at the end. Top-down decomposition fits those.
Other tasks are a single long thread: most steps routine, with just a few decision points that determine whether everything succeeds or fails. For those, a cheap model driving with an occasional consult upward makes more sense.
I had framed “multi-model routing” as though it were synonymous with the first kind.
The Official Numbers: Why a Second Opinion Can Cut Costs and Raise Scores at the Same Time
The intuitive assumption is that bringing in a stronger model must cost more.
For certain task shapes, the numbers say otherwise.
Key data
- Sonnet with Opus advisor: +2.7 points on SWE-bench Multilingual vs. Sonnet alone, with per-task cost down 11.9%.
- Sonnet 5 with Fable 5 advisor: roughly 92% of Fable 5’s solo score at roughly 63% of the cost.
- Haiku with Opus advisor: BrowseComp accuracy jumps from 19.7% to 41.2%, nearly doubled.
Why does a second opinion improve both cost and quality?
Because a well-placed outside view prevents the cheap model from going around in circles. Taking a wrong turn, or retrying the same mistake, burns tool calls on a dead end. Quality and tokens both get wasted together.
The savings are two-sided.
Anthropic’s practical recommendation is direct: run your own evaluation set across three configurations. Cheap model alone. Cheap model with advisor. Top-tier model alone. Measure where the actual boundaries are for your work. Don’t choose by instinct.
The Real Mistake: I Also Treated Collaboration Patterns as Constants
Back to my own error.
The core discipline in that post was one sentence: don’t weld things that change into rules that rarely get updated.
I pulled model names out of the routing rules and put them in a dated binding table. That step was right.
But one layer higher, I did exactly the same thing I was warning against. I treated the collaboration pattern as a given, never to be questioned, and it sits upstream of the models themselves.
I handled model capability seriously as a variable. The collaboration pattern I quietly hardcoded, and it sits above everything else in the system.
The whole post assumed that “multi-model routing” meant one expensive model orchestrating from the top down, and then worked out which role should bind to which model within that assumption.
I thought carefully about the binding layer. The pattern layer, I didn’t think about at all. Different problems call for different collaboration patterns: that much is obvious in retrospect, and I missed it entirely.
That blind spot also left a cost landmine in my v1 binding table.
I had placed Fable 5 (then the most expensive available model) in the “overall coordinator” role, meaning it ran on every single iteration. If you believe expensive models belong at the top giving direction, that binding makes sense.
Once you see the advisor pattern, it’s the most expensive possible configuration. The most costly model shouldn’t be in the position called most often.
I changed it. Fable 5 moved from a permanent coordinator to an advisor called once at critical points.
What I thought I needed to guard against was models getting better. What I actually failed to anticipate was that a new collaboration pattern would appear.
Check the Collaboration Pattern, Not Just the Model Bindings
In “Difficulty as a Constant,” the thing I designed most carefully was a periodic review mechanism: when a new model is released, rerun a representative task set and check whether any role can be handed down to a cheaper model.
That mechanism checks whether models have changed. Looking back, it’s missing a second question: has the collaboration pattern changed?
The original mechanism watched for one thing: which model should this role bind to now? It never asked the more upstream question: is the collaboration pattern I assumed still the only one available?
When a model improves, it leaves a trace in benchmark results: you can catch it. But a more efficient way of structuring the work doesn’t announce itself in a binding table. You have to go looking.
The advisor strategy went live in April. I noticed it in July because of a diagram. For those three months, my dispatcher hadn’t bound any model incorrectly.
It had simply never considered a second collaboration pattern, and I had no mechanism to notice.
So now I run the review in two layers.
The bottom layer stays the same: when a new model is released, recalibrate the bindings.
The top layer asks once per cycle: has a new collaboration pattern appeared that would require redrawing the assumptions underneath my whole dispatcher?
What belongs in the rules isn’t a model name. It’s this sentence:
Choose the collaboration pattern before choosing the models.
Tasks that can be decomposed, parallelized, and have uneven difficulty across subtasks suit orchestrator-workers. Long single-threaded tasks with a small number of make-or-break decision points suit executor-advisor.
That sentence was the first step I should have written in the previous post, and I left it out entirely.
It’s the same question I keep returning to on the Intelligence & Order thread: when capability changes quickly, how do you design structures that hold?
I ended “Difficulty as a Constant” with a line about building the emergency exit into the house while you’re still building the house.
Three days later I found out that what actually needed checking wasn’t the model table. It was my assumption about the collaboration pattern.
I treated task difficulty as a constant. I forgot to ask: what else am I temporarily mistaking for one?
Sources
The mechanisms and data referenced in this post come from Anthropic’s official materials:
- Anthropic Developers (X post): the advisor-strategy diagram that prompted this post, referenced at the top.
- Anthropic, The advisor strategy: definition of the advisor strategy, the original “inverts orchestrator-workers” framing, and the SWE-bench Multilingual and BrowseComp benchmark figures for Sonnet with Opus advisor.
- Anthropic, Advisor tool (Claude Platform Docs) and Claude Code Docs: how the advisor tool works, model pairing rules, and version and platform constraints.
- Anthropic, Building Effective Agents: the orchestrator-workers top-down decomposition workflow pattern.
- Anthropic, Claude Fable 5 and Platform Pricing: Fable 5’s positioning and its price differential relative to Opus.
💬 Comments
Loading...