Devin’s team said replacing Opus 4.8 with Fable 5 on FrontierCode 1.1 lowered the bill instead of raising it. That happened even though Fable 5 carries roughly double the per-token price of Opus 4.8. Under the company’s Fusion architecture, the Fable-led runs also scored better.
The report, published by BlockTempo and based on a post on X by Joon Lee, breaks down the cost structure behind 3,000 evaluation sessions. The comparison covered four configurations: Fable and Opus each serving as the lead model, and each running either with or without the same lower-cost helper model.
How the four setups compared
In pure runs without a helper, the outcome matched the expected pattern. Fable scored higher than Opus, but it also cost more. Fable posted a score of 60.8, compared with 55.4 for Opus, while average cost per run came in at $4.03 versus $3.06.
The picture changed once the helper model was added. With the same helper attached, Fable + helper averaged $1.86 per run, below the $2.04 logged by Opus + helper, while also producing a higher score at 60.7 versus 54.6. Relative to pure Fable, the Fable + helper setup cut cost by 54% with almost no change in score.
- Fable 5 (low) + helper: score 60.7, average cost $1.86
- Opus 4.8 (medium) + helper: score 54.6, average cost $2.04
- Fable 5 (low): score 60.8, average cost $4.03
- Opus 4.8 (medium): score 55.4, average cost $3.06
The article says “2x per token” turned out to be the wrong number to focus on. In these agent runs, total cost was shaped mainly by how many turns the lead model took, how much context it dragged along, and, most of all, which tasks it chose not to handle itself.
What Fusion changes in the workflow
According to the write-up, the lead agent in Fusion owns the whole session. It talks to the user, plans the job, reviews the work, and commits changes. A persistent helper sub-agent is available for delegated tasks. The lead model writes a plain-language handoff brief, a much cheaper model executes the task in its own context, and the lead model then reviews the result and decides what happens next.
To trace where money was going, the team did two things. First, it parsed every LLM call across all 3,000 sessions, tracking which model was speaking, what tools were called, how many tokens were read and written, and how much each call cost. Second, it selected 40 tasks for closer inspection, including cases where Fable was clearly cheaper, cases where Opus was clearly cheaper, and a random sample from the middle. For each task, the team compared the Fable-led and Opus-led trajectories side by side.
Where the spending sat between the lead and the helper
The published breakdown shows that Fable spent more on the helper than Opus did, but that increase was more than offset by lower spending on the lead model itself.
| Configuration | Lead $ | Helper $ | Total per run $ | Lead turns per run | Lead input tokens (cumulative) |
|---|---|---|---|---|---|
| Fable + helper | $1.28 | $0.58 | $1.86 | 11.5 | 545k tok |
| Opus + helper | $1.73 | $0.31 | $2.04 | 26.5 | 1,679k tok |
On average, Fable spent $0.27 more than Opus on the helper per run, but it spent $0.45 less on the lead model. The Fable lead averaged 11.5 turns per run, against 26.5 for Opus. Its output token count was about one-third of Opus at 6.1k versus 19.0k, and its input token usage was also around one-third.
The team said those token savings came from simply staying out of the work more often. In 81% of Fable-led runs, the lead model never made a single code edit from start to finish. The comparable figure for Opus was 24%. In 13% of Fable-led runs, the lead model never even read a repo file itself.
Two management styles
The article frames the gap as one between a micromanager working with interns and a manager working with senior engineers. The number of delegations was roughly the same in both cases, about three handoffs per run, so the difference was not that Fable simply delegated more. It was when delegation happened, and what got delegated.
Fable tended to hand work off early. A typical Fable-led run would do a few reconnaissance actions on the repo, write a spec-level brief, and delegate the full implementation, testing, and linting loop in one shot. After that, it would inspect the diff with something like a git show and commit the result.
Opus often delegated much later. Before that point, it would spend a long stretch exploring, designing, and implementing on its own, usually across 20 to 45 turns. By the time the handoff happened, the design decisions had already been made, the important files had already been loaded into context, and much of the expensive work had already been done by the lead model.
The article says Fable sometimes began a session by delegating immediately. It also argues that simply forcing Opus to delegate earlier is not a clean fix, because knowing what can be safely delegated and what must be handled directly is itself a form of judgment. A model pushed into delegation does not automatically gain that judgment.
Handoffs changed quality, not just cost
The write-up says Opus tended to issue instructions when it delegated implementation work, while Fable produced something closer to a design document. That mattered for quality as well as spending.
One example involved a hashing task. The specification required a hash function whose complexity on pointer length had to be O(1). Opus implemented the task itself, but never wrote that requirement down. At one point it lost track of the constraint and shipped a linear-time implementation, scoring 25. Fable delegated the work through high-level constraints instead. Its brief stated that “operator() must be O(1) in pointer length: no full token scan,” and the helper delivered an implementation that met the requirement and scored 94.
The article says the same pattern appeared across tasks. Fable’s handoff briefs tended to enumerate constraints, edge cases, and a definition of done. That reduced the amount of work the lead model needed to do and gave the helper a clearer path to finish the implementation cheaply and correctly.
What happened after the helper returned work
Both lead models often ran the same low-cost checks on the helper’s output, typically two or three git diff or git show calls. Opus, however, often went further.
According to the team, Opus pulled helper-generated files back into the lead-model context twice as often as Fable and made up to four times as many corrective edits at lead-model pricing. In the most extreme case described in the article, Opus reverted the helper’s output entirely and rewrote it by hand.
The report says that extra distrust did not translate into higher correctness. In some benchmark tasks, Fable caught a real bug with a single diff review and chose to send out another cheap handoff rather than escalate to a lead-model rewrite, which Opus reportedly did more often.
Where delegation stopped helping
The article also says Fable’s delegation strategy did not work everywhere. It broke down when the task had no meaningful component that could be split off and handed to another model.
- Short tasks with only a few lead-model turns left little to delegate between the decision and the delivery.
- Serial debugging tasks required a long chain of continuous judgment calls, and the accumulated context was itself part of the work.
On those tasks, the report says Fable hardly delegated at all. The same judgment that helps it write a strong brief also tells it when not to write one. If there is nothing worth handing off, delegation has little leverage over cost.
In production, the article says Fusion handles this at another level: delegation decides which work stays with the expensive model, while routing decides whether the expensive model needs to be involved at all.
The pricing argument pointed to judgment
The team said it began the experiment expecting to measure how much Fable’s 2x premium would raise cost. Instead, it found that effective delegation reduced the total bill. The article closes by arguing that as helper models become cheaper and better, more work can move to them. What will still justify frontier-model pricing, in this view, is judgment: deciding what to do, what constraints matter, and who should write the code.