Fable 5 Plans and Reviews. Opus 4.8 Builds.

Claude Fable 5 is back on the runtime menu in Sprint Engine. It's Anthropic's most capable model, and you can now assign it to any role on your team — architect, developer, any of the reviewer gates.

The obvious instinct is to run it everywhere. Best model, best results. But Fable 5 is priced like the most capable model, and a completed task burns a lot of tokens — most of them on implementation. Putting Fable on every role means paying its premium on the part of the work where a cheaper strong model already does the job.

The better move is to spend intelligence where it compounds. Run Fable 5 on the architect and the review gates — the two places a single decision shapes everything downstream — and let Opus 4.8 do the high-volume building underneath it. That's the roster Sprint Engine ships as a starting point, and it's the one worth understanding.

Fable 5 is the most capable model — and priced like it

There's no cost sleight-of-hand to pretend otherwise. Fable 5 lists at exactly twice Opus 4.8, per token, on both input and output:

Because Fable is exactly 2× Opus on both input and output, the ratio holds no matter how a task's tokens split between prompt and completion. Fable costs double, everywhere. So the only lever that changes your bill is which roles you run it on.

Spend intelligence where it compounds

Not every role carries the same leverage. The architect writes the plan and owns the dependency graph — every task built downstream inherits its judgment. The reviewer gates decide what actually ships. A weak plan or a missed review doesn't cost you tokens; it costs you a rebuild, or a bug in production. Those are the roles where the most capable model pays for itself.

Implementation is different work. Once the plan is good and the gates are strict, building it is high-volume, well-specified labor — read the files, write the code, run the tests, iterate. Opus 4.8 is very good at exactly that, at half the price. And it's where the token count lives: developers and testers re-read context on every turn, so the build roles dominate a task's spend.

So the roster splits along that seam. The default team — the one in the screenshot below — puts Fable 5 on the four judgment roles and Opus 4.8 on the three build roles.

What that costs

Here's the arithmetic, kept honest. The numbers below are illustrative — built from published list prices and a representative task profile, not measured telemetry — so treat them as a shape, not a quote. Take a completed task that consumes roughly 100k tokens across its Claude-run roles, split about 15% planning, 65% implementation, 20% review. Price each role's slice at that model's blended rate.

The hybrid is about 32% cheaper than all-Fable and only about a third more than all-Opus — and for that small premium you put the most capable model on the plan every task inherits and on the gates that decide what ships. At a thousand completed tasks, that's roughly $2,200 all-Fable versus $1,485 hybrid: a little over $700 saved, with Fable still running the architecture and the reviews.

Set it up in the roster

This isn't a config file you hand-edit — it's the team step you already pass through when you start work. Each role has a runtime dropdown; the split takes about a minute to set once and save as a named team.

• Set Architect to Claude Code · Fable 5. This is the plan every task inherits — it's the highest-leverage seat on the team.
• Set the reviewer gates — Code Reviewer, Nuclear Reviewer, UI/UX Reviewer — to Fable 5. These decide what ships; you want the sharpest read here.
• Set the build roles — Developer, Frontend, Tester — to Claude Code · Opus 4.8, and staff them with the agent count your work needs. This is where the tokens go, so this is where the cheaper model earns its place.
• Save it as a team so the split is one click next time. The rest of the roster stays free to mix — Sprint Engine runs any CLI, so Performance, Security, and other roles can sit on Codex, Z.AI, or whatever you prefer.

What this is, and what it isn't

Worth being precise about the edges, because a cost claim that over-reaches helps no one:

• The dollar figures are illustrative. They come from published list prices and a representative 15/65/20 task profile — not from measured Sprint Engine telemetry. Your split will differ; the structure of the saving won't.
• It's a cost claim, not a token claim. A 100k-token task is 100k tokens on any model. What changes is the price per token, and therefore the bill — not the token count.
• Prompt caching lowers every bar. Re-read context is cached, so real per-task costs run below list. Caching shrinks the absolute numbers roughly in proportion, so the hybrid stays ahead of all-Fable by about the same margin.
• Other runtimes are priced separately. A real team often mixes Codex, Z.AI, and others across roles; those roles sit outside this Fable-vs-Opus comparison and carry their own costs.
• Fable is not the cheap option. If your task is genuinely hard enough that Fable-grade implementation changes the outcome, run it on Fable and pay for it. The hybrid is the default because most implementation, under a good plan and strict gates, doesn't need it.

The point isn't that one model beats another. It's that a roster lets you place each model where it earns its price — the most capable one on the decisions that echo through the whole task, the strong cheaper one on the volume. Fable 5 is back; put it where it counts.

Run the best model where a single decision shapes everything downstream. Run the cheaper strong model everywhere the work is high-volume and already well-specified. The roster is how you say which is which.