Advisor and Executor: Using Fable 5 Without the Fable 5 Bill

On July 7, 2026, Anthropic's ClaudeDevs account shared a pattern they use often with Fable 5, and it is worth more than the tweet it came in: don't make Fable 5 do everything. Make it the advisor.

A cheaper executor — typically Sonnet 5 — runs the main loop. It reads files, gathers context, edits code, drafts, runs tests, handles retries, and spends the token budget. When it hits a decision that genuinely benefits from frontier reasoning, it calls Fable 5 for guidance. Fable 5 is not the worker. It is the expensive judgment layer. Their line: most tokens are billed at the lower executor rate.

That reframes orchestration as an economic control surface, not just a quality trick. You are not only routing for the best answer. You are routing for cost, latency, and reasoning depth at the same time.

Who does what

The executor owns the workflow: inspecting inputs, summarizing local context, drafting steps, making changes, validating outputs, keeping state — and, crucially, deciding when it is stuck. The advisor owns high-leverage judgment: the calls where being wrong compounds. Architecture. Decomposition. Ambiguous requirements. Debugging strategy. Security and migration risk. The moments where the executor is holding conflicting evidence.

The whole system lives or dies on the escalation rule. The executor should call up not when it needs the next line filled in, but when the answer changes the shape of the work — two plausible plans with different risk, a change that crosses service or data boundaries, a validation loop it has failed more than once, a decision that determines whether the next few thousand tokens of work are even useful. Ask Fable 5 to rubber-stamp every edit and you have just built an expensive single-model system with extra latency.

The economics

The core is simple: because the advisor only ever sees a compact decision context — not the whole working loop — most tokens run through the cheap executor, so the blended cost stays close to the executor's rate while decision quality climbs toward the advisor's.

The numbers below are illustrative — not from the ClaudeDevs post — and assume the advisor costs 10× the executor per token. Say a task burns 100,000 model tokens across planning, reading, editing, and validation:

The advisor/executor run costs a bit more than Sonnet-only and a fraction of Fable-only. The exact ratio is not the point — the shape is. If 95% of tokens go through the cheaper model, the blended cost mostly follows the cheaper model. Frontier reasoning is most valuable at decision points and least valuable while walking files, applying mechanical edits, or retrying a known command.

When it wins, and when it doesn't

It wins when a task has both cheap work and expensive judgment — which most real engineering-agent tasks do. Reading a repo is token-heavy but rarely frontier-hard. Editing boilerplate is token-heavy but rarely frontier-hard. A validation loop is operational, not philosophical. But deciding which subsystem should own a behavior, or whether a migration is safe, is exactly where the stronger model earns its price. It shines on long coding tasks with a few architectural forks, debugging where repeated failure is expensive, and planning-heavy work followed by mechanical execution.

It is not free. There are four ways to break it. Latency: the advisor is an extra hop, so on small or latency-sensitive tasks the handoff can cost more than it saves. Coordination: if the executor ships messy transcripts and undifferentiated dumps, the advisor call gets expensive and unreliable. Over-consulting: the common one — teams adopt an advisor and then call it for everything because it feels safer, which nukes the whole cost advantage. Under-consulting: an overconfident executor grinds thousands of cheap tokens in the wrong direction, and cheap failure is still failure. The real design problem was never "use two models." It is "define the escalation boundary."

The pattern also rewards an executor that can compress. The advisor does not need the whole transcript — it needs the distilled problem, the evidence, the options considered, and the decision being asked for. "What should I do?" is a low-signal consultation. "I'm on task X, constraints A/B/C, two paths with these risks, tests show Y — which path, and what do I watch for?" is a high-signal one, and it is what keeps the economics intact.

It isn't a Claude thing

Fable 5 and Sonnet 5 are just a clean instance of the archetypes: frontier advisor, fast workhorse executor. The structure holds for any strong-advisor plus cheap-executor pair — a reasoning model as reviewer over a general-purpose implementer, a high-context model consulted only when broad context actually matters. The properties that make it work: the advisor is meaningfully better at the decisions it receives, the executor can run without constant supervision, context is compressed before escalation, the routing policy is explicit, and the advisor's output is actionable rather than merely thoughtful. It is related to model routing, but more opinionated. Routing asks "which model should answer this request?" Advisor/executor asks "which parts of this workflow deserve expensive reasoning?" — the better question for agents, because agents are not single calls. They are loops.

Three takes

The takeaway

The lesson from the ClaudeDevs pattern is not that every system needs two Anthropic models. It is that frontier reasoning should be placed where it has leverage. Let the workhorse spend the tokens. Let the advisor make the calls that matter. Compress before you escalate. Track how often the expensive model gets invoked, and watch both failure modes — the reflexive over-consulting and the stubborn under-consulting. That is how you get most of the benefit of Fable 5 without turning every file read, edit loop, and retry into a Fable 5 bill.