Fable: 92% of the Performance at 63% of the Cost, Advisor and Orchestrator Patterns from a Private Anthropic Webinar

At 1 AM Korea time on July 23, 2026, I joined a private webinar hosted by Anthropic. Modern Web Labs was invited to attend, and the session focused on Claude Fable 5. More precisely, the topic was "how to run Fable 5 in production at a cost you can actually sustain."

The conclusion of the one-hour session compresses into a single sentence. Organizations that use Fable 5 well do not use Fable 5 everywhere. They design a structure that deploys Fable 5 only on the hardest segments and delegates the rest to lower-tier models. This post summarizes the two production patterns Anthropic presented directly, along with a cost optimization checklist.

The session was structured as follows.

Fable 5 is a model you reach for only on the hardest work

Fable 5 is Anthropic's top-tier model. Its biggest difference from earlier models is the ability to run long-horizon tasks that stretch from hours to days, making its own judgments and seeing the work through without human intervention. Fable 5 shows its true value when it can close the loop on its own: write code, run tests, look at the results, and revise.

What was interesting in the webinar was not the performance bragging but the failure cases. Many organizations move a workload that was running on Sonnet straight over to Fable 5 and then conclude, "it's not really any better." That is because the difference does not surface on work the existing models were already handling well enough. You only see Fable 5's value when you give it a task that was out of reach for previous models.

The catch is price. As of July 2026, the official pricing is as follows.¹

Fable 5 is twice the price of Opus 4.8 and more than three times the list price of Sonnet 5. Routing every request through Fable 5 leaves you with an inefficient cost structure. That is exactly why Anthropic proposed the two patterns below in the webinar.

The Advisor pattern: pairing a senior with a junior

Here is the analogy used in the webinar. Attach a senior mentor to a junior engineer and the junior's output rises sharply, even when the senior never touches the keyboard. It is enough for the senior to point out how to approach the problem once and to help diagnose the cause when the junior gets stuck.

The Advisor pattern applies this structure to models. Execution is handled by Sonnet 5. Most tasks such as reading code, invoking tools, and running bash are handled by Sonnet 5 at nearly the same quality as the higher-tier model, at a much lower cost. Instead, Sonnet 5 is given a single tool called advisor. Sonnet 5 is fairly accurate at recognizing when it is "stuck." After grasping the full picture of the problem, it asks once "is my understanding correct?", and if tests keep failing, it asks again "why are they failing?" The expensive tokens of the higher-tier model are used only at these moments.

(Image source: https://platform.claude.com/docs/en/agents-and-tools/tool-use/advisor-tool)

On a SWE-bench Pro style evaluation shared in the webinar, this configuration achieved 92% of the score of Fable 5 alone at 63% of the cost. Fable 5 alone does have the top score, but whether it is worth paying an additional 37% in cost (100%-63%) to gain an 8% in score (100%-92%) depends on the type of work. The host emphasized several times that "this is only one evaluation, so you must evaluate on your own workloads."

The Advisor pattern has a low barrier to adoption. That is a real advantage for teams building AI-powered products through the API. No architectural change is needed; you simply add one server-side tool to your existing Messages API call.

const client = new Anthropic(); const response = await client.beta.messages.create({ model: "claude-sonnet-5", max_tokens: 4096, betas: ["advisor-tool-2026-03-01"], tools: [ // add tool { type: "advisor_20260301", name: "advisor", model: "claude-fable-5" } ], messages: [ { role: "user", content: "Build a concurrent worker pool in Go with graceful shutdown." } ] }); console.log(response);

(Code source: https://platform.claude.com/docs/en/agents-and-tools/tool-use/advisor-tool#quick-start)

The webinar included a demo of a configuration using Fable 5 as the advisor. Which execution and advisor model combinations are allowed keeps changing, so check the official docs before using them. You do need some prompt-level tuning to control when the advisor is called. If calls are too frequent the cost benefit shrinks, and if too rare the quality drops, so this is a point you have to dial in by running evaluations.

The Orchestrator pattern: using Fable 5 only as a manager

The second pattern flips the direction. User requests hit Fable 5 first. Fable 5 breaks the problem down into subtasks, and the actual execution is delegated to lower-tier sub-agents like Sonnet or Haiku. Expensive tokens are spent only on the high-level planning and judgment that Fable 5 excels at, while the labor-intensive execution runs at a lower unit price.

For reference, the webinar called this the Orchestrator pattern, but Anthropic's official GitHub Claude Cookbook repository introduces it as the Coordinator pattern. During the webinar the Anthropic team shared the Claude Cookbook repository link in real time.

(Image source: https://github.com/anthropics/claude-cookbooks/blob/main/managed_agents/CMA_plan_big_execute_small.ipynb)

The operational discipline the presenter emphasized was striking. Give the orchestrator no tools (check the "no tools of its own" label at the bottom of the Coordinator component marked in orange). No bash, no MCP. Fable 5, when given tools, has a tendency to just do the work itself. The delegation structure holds only if the orchestrator can do nothing except spin up workers. It is the same logic as deliberately stripping authority from a manager in an organization who cannot let go of hands-on work.

This pattern shines on tasks that can be parallelized. The webinar used BrowseComp-style research benchmarks as an example. A single research report is ultimately a sum of many small investigation tasks, so hundreds of sub-agents can run concurrently, which makes it a good fit for the Coordinator pattern. The webinar also shared numbers from BrowseComp-style research benchmarks: a Fable 5 orchestrator with Sonnet 5 workers reportedly achieved 96% of Fable 5's standalone performance at 46% of the cost. The implementation delegated token-heavy investigation work to Sonnet 5 sub-agents on top of Claude Managed Agents.

As with the Advisor pattern, standalone Fable 5 has the higher absolute score, but the combination wins on cost-efficiency. This structure, splitting one large task into many independent subtasks and processing them concurrently, is called fan-out. Picture a single manager handing out work to multiple assignees at the same time. Some readers will already be familiar with fan-out: Claude Code's dynamic workflows orchestrate hundreds of sub-agents in exactly this way. We covered dynamic workflows in detail in Modern Web Labs' write-up on ultracode and dynamic workflows.

Which pattern should you choose

The webinar offered a single diagnostic question.

"Does the work break down into pieces that don't need each other?"

If it doesn't break down, use advisor. If it does, use orchestrator. Here is the comparison in table form.

Advisor suits sequential work. If most of the job is simple steps punctuated by a few hard stretches, calling the higher-tier model only in those stretches is efficient. Because it is a drop-in addition of a few lines to an existing API call, the cost of experimenting is low.

Orchestrator suits fan-out work that branches into many parallel tasks. When you can run dozens or hundreds of independent subtasks in parallel, putting Fable 5 in the manager seat pays off. The tradeoff is that you have to reroute requests through the orchestrator to the workers, so the adoption effort is higher than advisor.

Four fundamentals to lock down before any pattern

After walking through both patterns, the presenter was blunt: "If you don't have prompt caching in place, forget the patterns and start with caching." Here they are, ordered by cost impact.

• Prompt caching: Input tokens that hit the cache are discounted by 90%.² Since input tokens dominate most customers' bills, caching alone can move Fable 5 from "unaffordable" to "affordable." Top-tier customers who have invested properly in caching reportedly maintain cache hit rates in the 90% range. One practical tip from the session: ask the claude-api skill that ships with Claude Code to optimize your cache hit rate, and it knows the techniques and will fix your code. Where to place caches to get real hit rates, and how much you actually save, is covered in detail in our writeup of the caching design from a Claude Code engineer.

• The effort dial: Before swapping models, adjust output_config.effort (low to max). If Opus 4.8 is too expensive, lower the effort. If it falls short, raise the effort before jumping to Fable 5. A counterintuitive result also came up: Fable 5 at low effort can solve a problem at lower cost than Sonnet at high effort, because the stronger model reaches the answer in fewer attempts.

• Batch API: Work that doesn't need real-time responses gets a 50% discount when run as a batch.³ The batch API stacks with prompt caching, so a well-structured batch multiplies the two discounts. When to use the Batch API and when to avoid it is also covered in detail in our writeup of the caching design from a Claude Code engineer.

• Spend limits and task budgets: Separate your experimental workspace and set a spend limit so you don't wake up to a shocking overnight Fable 5 bill. The task budget feature nudges the model to finish work within a token budget on its own.

The two-week execution plan proposed in the webinar

The action plan shared at the end of the session was concrete enough to pass along verbatim.

1. Pick 3 to 5 tasks to optimize and collect production logs.

2. Read the transcripts yourself. Have Claude read them too and surface anomalous patterns. The presenter was emphatic: if you do not read the transcripts, no improvement follows.

3. Run the same task through Haiku, Sonnet, Fable 5 at low effort, and Opus at high effort to establish per-tier baselines.

4. Wire up an advisor or orchestrator and compare quality against cost.

5. Confirm that the 3 to 5 tasks you chose actually represent real traffic, using shadow traffic or A/B tests.

Modern Web Labs runs on the same principles

Modern Web Labs applies these same principles to the services we operate. We introduced prompt caching to our content translation pipeline and moved work that does not need real-time processing, such as newsletter generation, to batch. Infrastructure costs came down step by step. Many of the tips from the webinar are the kind that change your invoice within a few hours of being applied.

Readers who code with Claude Code are probably wondering how to pull these patterns in. The advisor tool is available in Claude Code via the /advisor command (per the official documentation, it is an experimental feature whose behavior and pricing may change). Fable 5 is not yet on the advisor list in Claude Code, so for now you can only pair it with Opus as the advisor. The core strategy of when to escalate to a higher model can be reproduced with CLAUDE.md rules and read-only subagents. We cover the actual setup in the follow-up post.

We send a biweekly newsletter with material like this webinar that rarely reaches public channels, along with what we learned from applying it ourselves. If this post was useful, drop your email in the subscription form below. You will be the first to receive the notes from the next webinar too.

1. For official per-model pricing, see the Anthropic model documentation. The temporary discount pricing for Sonnet 5 applies through August 31, 2026.

   ↩

2. More precisely, cache reads run at roughly 0.1x the base input rate. Cache writes are billed at 1.25x on a 5-minute TTL, so caching only pays off on prefixes that will be reused at least twice. See the prompt caching documentation.

   ↩

3. See the batch processing documentation. You can send up to 100,000 requests in a single batch, and most complete within an hour.

   ↩