How to Make Fable Cheaper Than Opus: Redesigning an Agent’s Cost Structure Using Delegation

Fable is like a seasoned engineering manager who pushes work out early, writes the specs clearly, and does less hands-on work; Opus is like a micro-manager with an intern. This article is based on a Joon Lee X piece, breaking down the cost structure behind the scenes using 3,000 evaluation runs.
(Background: Anthropic launched “Claude for Small Business”: targeting AI automation for small and mid-sized businesses—helping you chase invoices, calculate payroll.. )
(Additional context: Anthropic requires real-name KYC verification! Some Claude features will require uploading ID documents, increasing compliance pressure)

Table of contents

Toggle

• Introduction
• Experimental setup
• The cost of an agent
• Micro-manager with an intern vs manager with a senior engineer
• After handoff
• When delegation can’t help
• Conclusion

We swapped Opus 4.8 to Fable 5, and Devin’s bill actually went down.

Fable 5 costs twice as much per token as Opus 4.8. But when we run both models simultaneously on FrontierCode 1.1 using the brand-new Fusion architecture, Fable is actually cheaper. Not surprisingly, its scores are higher too. This article explains why, and what it means for pricing “agentic work.”

Introduction

Everyone who runs code-using agents knows: a stronger model gives better results, but you have to swallow the cost.

When we launched Devin Fusion, we showed an escape route: let a frontier model sit at the helm and delegate the work to a cheaper, faster sidekick—so you can get frontier-level performance at 35% lower cost.

But once the lead model delegates most of the work, does its per-token price still dominate the whole bill? Fable 5’s per-token cost is twice that of Opus 4.8, so an agent led by Fable should, in theory, be more expensive. To find the answer, we ran 3,000 evaluation job runs on FrontierCode 1.1, spanning four configurations: Fable and Opus each taking the lead, and each either with or without the same cheap sidekick.

With pure execution (pure runs), the results match intuition exactly: Fable’s score beats Opus (60.8 vs 55.4), and its cost is higher too. Better model, bigger bill.

The interesting part is what happens when you add a sidekick.

With the same sidekick, the cost ordering flips: Fable + sidekick is cheaper than Opus + sidekick ($1.86 vs $2.04), but the score is higher too (60.7 vs 54.6). Compared with pure Fable, Fable + sidekick cuts cost by 54%, while the score barely changes.

| Configuration | | --- | Score | Average cost per run | | --- | --- | | Fable 5(low) + sidekick | 60.7 | $1.86 | | Opus 4.8(medium) + sidekick | 54.6 | $2.04 | | Fable 5(low) | 60.8 | $4.03 | | Opus 4.8(medium) | 55.4 | $3.06 |

The results prove that “twice the cost per token” was the wrong assumption. The cost of an agent mainly depends on how many rounds the lead model goes through, how much context it drags along together, and—most importantly—what it decides “not” to do itself. The difference comes down to management style: Opus acts like a micro-manager with an intern; Fable acts like a manager with capable engineers.

Experimental setup

Quick recap: how the sidekick architecture in Fusion works. The lead agent owns the entire run session: it talks with the user, plans, reviews the work, and commits. It also has a persistent sidekick sub-agent that delegates tasks. The lead model writes a handoff briefing in plain language; then a much cheaper sub-agent driven by another model executes within its own context and reports back the results. The lead model reviews the results and decides what to do next.

To see where the money flows, we did two things. First, we decomposed every single LLM call across all 3,000 job runs: which model was speaking, what tools it called, how many tokens it read/wrote, and how much each call cost. Second, we selected 40 tasks for closer observation: ones where Fable was clearly cheaper, ones where Opus was clearly cheaper, and another batch of random samples from the middle. For each, we analyzed Fable-led execution and Opus-led execution side by side, examining their trajectories and observing where the spending went.

The cost of an agent

Below is how cost is distributed between the lead model and the sidekick in our experiments:

| | | --- | Lead $ | Sidekick $ | Total cost per run $ | Lead number of rounds per run | Cumulative lead input tokens | | --- | --- | --- | --- | --- | | Fable + sidekick | $1.28 | $0.58 | $1.86 | 11.5 | 545k tok | | Opus + sidekick | $1.73 | $0.31 | $2.04 | 26.5 | 1,679k tok |

Fable spends more money on the sidekick than Opus—$0.27 more per run. But it spends $0.45 less on itself. Fable’s lead model averages 11.5 rounds per run, versus Opus’s 26.5 rounds; its output tokens are only about a third (6.1k vs 19.0k), and its input tokens are also only about a third. Fable’s cost per token is clearly higher, yet it wins on context management and number of rounds.

Fable’s token savings come from simply avoiding work. Interestingly, in 81% of Fable-led runs, the lead model never makes any code edits from start to finish. For Opus, only 24% of runs are like that. In 13% of Fable-led runs, the lead model never even personally reads any repo files.

Micro-manager with an intern vs manager with a senior engineer

What makes this gap interesting is: the number of delegations made by the two lead models is the same—each run has roughly 3 handoffs. The call-by-call logs overturn the simple explanation “Fable just delegates more.” The real difference is “when” they delegate, and “what” they delegate. Fable’s first handoff comes very early.

Opus, on the other hand, often delegates very late—after a long stretch of solo exploration and implementation. By then, design decisions are already made, important files are already in its context, and the expensive work has already been done.

A typical Fable-led run first does a few reconnaissance actions on the repo, then writes a spec-level briefing that delegates the entire loop of “implementation + testing + lint” in one go. Then a git show reviews the diff, and it commits.

A typical Opus-led run goes through 20 to 45 rounds of solo exploration, design, and implementation, plus a handoff that happens late and delegates only a mechanical wrap-up.

Sometimes, the first action in a Fable-led run on a given session is handoff. On the same task, the openings of the two lead models look like this:

The obvious fix—forcing Opus to delegate more exploration—usually hurts performance. Knowing when an investigation can be safely delegated versus when you must do it yourself is itself a kind of judgment. A model that’s forced to delegate won’t gain that judgment; it will just delegate things that should not be delegated.

Each model’s management style is also clearly visible in the handoff briefing itself. When Opus delegates implementation, it’s issuing instructions; when Fable delegates, it’s writing a design document:

Delegation isn’t just shifting costs around—it also changes the quality of the work. The hashing task above is a clear example. The task specification requires that a hash function must be O(1) with respect to pointer length. Opus implemented it by hand, but never wrote that requirement down anywhere. At some step, it forgot this constraint, delivered a linear-time implementation, and got a score of 25. By contrast, Fable delegated using higher-level constraints. Its briefing says: “operator() must be O(1) in pointer length: do not do a full token scan.” The sidekick implemented it successfully and scored 94.

We found this pattern generalizes across tasks. Fable’s handoffs enumerate constraints, edge cases, and a definition of what “done” means—saving itself effort while allowing the sidekick to implement cheaply and correctly.

After the handoff

The other half is what the lead agent does with the sidekick’s returned results. Both lead models often run the same cheap checks: two or three git diff / git show calls. But Opus doesn’t stop there. It pulls the sidekick’s files back into its own context twice as often, and makes up to four times as many corrective edits at the lead model’s prices. In the most extreme case, it fully reverts the sidekick’s output and rewrites it itself:

And Opus’s lack of trust didn’t improve correctness. In some evaluation tasks, a single diff review by Fable caught the sidekick’s real bug and chose to do another cheap handoff, rather than resorting as often to lead-model-level rewrites like Opus.

When delegation can’t help

Fable’s delegation strategy isn’t universally applicable; it fails when the task has no delegable components. The following types of tasks seem hard to break down:

• Short tasks with only a few lead-model rounds, where there’s nothing between “deciding” and “delivering” that can be delegated.
• Sequential debugging tasks whose root-cause chase is a long chain of consecutive judgments—here, the accumulated context itself is the work.

Notably, for these tasks, Fable delegates almost nothing. The same judgment ability that can write good briefings also knows when not to. But when a task has nothing worth delegating, delegation has no leverage on cost.

In a real production environment, Fusion handles this at another layer: delegation decides which work stays with the expensive model, while routing decides whether the expensive model actually needs to be brought into the process.

Conclusion

When we started this experiment, we expected that the 2x premium of Fable would increase costs by how much. What surprised us was that Fable’s effective delegation actually decreased overall cost. It points to constraints and outcomes rather than hard-coding steps of implementation; it gives feedback rather than fixing things itself; and in most cases it never touches code. These are all habits of a good manager.

As sidekick models become cheaper and better, more work can be given to them. And in the future, what’s still worth paying frontier prices for will be judgment: what to do, what to constrain, and what should be written by whom.