How the advisor model and worker model split the labor

Advisor mode isn't something the team cobbled together on its own — it's a formal beta feature of the Anthropic API, the advisor tool. The executor model, Claude Sonnet 5, takes the task and works through it on its own, only consulting the advisor model, Claude Fable 5, once at a point where a judgment call is needed — then, armed with that judgment, finishes the task.

This isn't something you cobble together yourself by firing off two manual requests: you declare a tool of type advisor_20260301 in tools, specify which model the advisor uses, and the rest is handled entirely server-side by Anthropic. The executor decides when to ask for advice the same way it would call any ordinary tool; the server spins up a separate inference pass on the advisor model, which sees the executor's full conversation so far (system prompt, tool results, content already written), returns its judgment, and that judgment is fed straight back into the executor's conversation for it to continue writing with. The whole thing happens within a single API request:

response = client.beta.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=4096,
    betas=["advisor-tool-2026-03-01"],
    tools=[
        {
            "type": "advisor_20260301",
            "name": "advisor",
            "model": "claude-opus-4-8",
        }
    ],
    messages=[{"role": "user", "content": "Build a concurrent worker pool in Go with graceful shutdown."}],
)

There's a hard rule for pairing models: the advisor must be at least as capable as the executor, never the other way around. The docs give two typical setups: if you're already running Sonnet on complex tasks, pair it with Fable 5/Opus as the advisor for a quality bump; if you're on Haiku but want a bit more smarts, pair it with an Opus advisor — cheaper than swapping the executor itself for a bigger model.

From the original post: Sonnet 5 executor + Fable 5 advisor score and cost comparison on SWE-bench Pro. Source: X / @ClaudeDevs

Why it's cheaper: the advisor's output is typically only 400 to 700 text tokens (1,400 to 1,800 including its reasoning), since it's only responsible for one key piece of advice, not writing the final answer start to finish. On the bill, advisor calls are billed separately at the advisor model's rate and logged under usage.iterations[] — they don't get folded into the executor's totals. The original post's line that "Fable 5 is called only rarely (about once) per task" is exactly this cost-saving mechanism playing out in practice.

The official best practice is to call the advisor before writing, not after the fact. For Haiku executors, which tend to "not ask when they should," Anthropic provides a system prompt template (reminding the model to proactively consult the advisor when writing files, making judgment calls, or getting stuck) that raised the pass rate on Anthropic's internal coding benchmark by about 7.5 percentage points for Haiku — a concrete, measured number, not a vague suggestion.

The other split: skip the consulting, delegate the task directly

In advisor mode, Fable 5 never touches the work itself — it only ever says a single line when asked. Orchestration mode is different: Fable 5 starts out as the "coordinator," breaks the task into pieces, and dispatches them to multiple Sonnet 5 "worker" sub-agents to run in parallel, while it only handles planning and aggregating results, never doing the work itself.

From the original post: diagram of the Fable 5 coordinator + Sonnet 5 worker sub-agent split. Source: X / @ClaudeDevs

This orchestration capability also has formal official backing — Claude Managed Agents' multi-agent sessions feature. When you define a "coordinator" agent, you declare its dispatchable roster with the multiagent field (up to 20 agents, delegation goes only one level deep, no infinite nesting):

coordinator = client.beta.agents.create(
    name="coordinator",
    model="claude-opus-4-8",
    tools=[{"type": "agent_toolset_20260401"}],
    multiagent={
        "type": "coordinator",
        "agents": [{"type": "agent", "id": research_agent.id}],
    },
)
session = client.beta.sessions.create(agent=coordinator.id, environment_id=environment.id)

Each worker sub-agent runs in its own independent "session thread," with its own model, system prompt, and tool config, fully isolated from the others (up to 25 concurrent threads supported). The official docs summarize three scenarios well suited to delegation: parallel decomposition (looking up multiple sources or analyzing multiple files at once, with the coordinator aggregating at the end), delegation by specialty (handing off work like security review or documentation to a domain-specialized agent, instead of having one agent do everything), and capability escalation (escalating only the small handful of especially hard sub-tasks to a more capable agent).

Anthropic's official cookbook has a concrete, runnable example called the "coordinator pattern" (CMA_plan_big_execute_small.ipynb): the task is verifying 20 facts across 10 national parks against official sources. It compares having a top-tier model read through every webpage on its own to verify facts, versus having the top-tier model only handle breaking down the task while dispatching the page-reading grunt work to multiple cheaper worker sub-agents running in parallel:

The official result: the delegated team was about 2.5x cheaper and about 3x faster than going solo. But the notebook also candidly lays out four hard-won lessons — all measured, not just talking points:

The notebook also gives guidance on when not to use this split: if the task itself is low on information — not much to look up — splitting it into coordinator + workers just wastes an extra coordinator round-trip; if the coordinator never actually delegates and just answers from memory, that's a top-tier model fee spent for nothing; and if the task requires a top-tier model to personally grasp subtle nuance in the source material (not just simple fact-checking), cheaper worker sub-agents may lose key information when summarizing.

From the original post: Fable 5 coordinator + Sonnet 5 worker score and cost comparison on BrowseComp. Source: X / @ClaudeDevs

Why repeated calls don't mean paying full price again

The original post's line that "every sub-agent keeps its own cache" maps to two distinct mechanisms underneath — one for each mode.

On the orchestration side: every worker sub-agent runs in its own session thread, and the thread itself is persistent. When the coordinator comes back later with a follow-up question for the same worker, that worker remembers what it did and said before — no need to re-feed the entire history just to keep the conversation going.

On the advisor side, there's a more specific switch: the advisor tool supports independent prompt caching. Because the advisor, when consulted multiple times within the same conversation, sees a stable prefix of the transcript each time (the Nth consultation = the (N-1)th's content plus a bit more appended), turning on caching means the repeated portion is billed only at the cache-hit rate. The official guidance: if the advisor is consulted fewer than two times in a conversation, turning on caching isn't worth it (the cost of writing to the cache outweighs the savings) — it only starts paying off around the third call, and is worth it mainly for long conversations with multiple rounds of consultation.

Advisor mode or orchestration mode — what to look for

Both modes follow the same principle — "let the stronger model do less, and hand the grunt work to a cheaper model" — the difference is whether the stronger model touches the work itself at all.

Want to try it — where to start

The minimal implementation for both modes takes just three steps — pick whichever matches your own scenario and give it a try.

@ClaudeDevs is Anthropic's official account for developers (Anthropic makes Claude). On July 7, 2026, they shared a fix: the pricey model only steps in when a decision is needed, while the cheaper Claude Sonnet 5 does the heavy lifting of writing out the content.

Officially there are two concrete setups — the difference is whether the pricey model touches the work itself at all. One diagram makes it clear.

Both setups make the pricey model do less. Advisor mode: the cheap model works through the task on its own, only asking the pricey model a question at a critical judgment point. Orchestration mode: the pricey model splits the task into pieces up front, hands them to several cheap models to work on at the same time, and only handles the breakdown and the wrap-up itself.

The official numbers are measured against two public benchmarks. Treat "use the strongest model for everything" as costing 100 units, and see how much each split spends and how much score it gives up:

All of the above numbers are Anthropic's own internal testing, with no independent third-party reproduction.