Cost-effective orchestration with Fable 5

Hey friends, I’m excited to share another deep dive with you today. I’m going to show you how to use Fable 5 as an orchestrator in Claude Code.

Why an orchestrator?

Because Fable is EXPENSIVE. If you have Fable do planning and orchestration, it can delegate implementation to cheaper models.

I’ll walk you through this concept, then show you how I used it to add a pretty significant feature to a Next.js web app.

Subscribed

Why Fable requires special strategy on our part

Fable is an incredibly capable model, but it’s too expensive for practical daily driving.

We’re seeing this pattern emerge where frontier labs are releasing parallel models of varying size. Fable is Anthropic’s most useful model, but it’s also it’s slowest and most expensive.

But smaller models (even Sonnet 5!) are useful to the point that you can use them for a huge percentage of software engineering.

Anthropic themselves is pushing the orchestrator pattern:

In fact, they shared that this pattern gives remarkable cost savings at minimal performance cost:

The Fable 5 orchestrator achieves 96% of Fable 5 performance at 46% of the price.

The change we’re making with Fable

I recently built a landing page for an info product using Claude Code, but the site only had a waitlist signup.

The AI-Augmented Intelligence report is a monthly report for software engineering leaders to keep them up to date on AI.

AI is moving quickly, and keeping up to date with trends, risks, and workflows can be a full-time job. If you resonated with that, I think you’d love the product.

Try Reports

I didn’t want to overengineer a product that didn’t have demand, so I just shipped it with a waitlist signup.

Well, the waitlist is overflowing. I’m only opening 25 spots and there were multiples of that that signed up for access.

So it’s time to actually open the product for signup!

The core of Reports is information. We need to let users sign up, pay, view an index of past reports, and get emails for new reports.

For today’s article, we’re going to add signup and billing.

How to use Fable as an orchestrator to make this change

I want this change done correctly and quickly, but with minimal input from me. I’m going to start by running plan mode. You can enter plan mode with SHIFT + TAB.

Here’s my starting prompt:

We need to move away from waitlist signup and towards active use! Remove waitlist signup and only allow signup or sign in. Use Clerk for
  auth, make it look great. Use Stripe checkout and stripe billing for authentication. Allow only monthly plans (no annual,yet) at $200 and
  $300 /mo. For database, use supabase. Authenticated users who haven't paid only have an option to pay. Authenticated and paid users get
  sent to the index page of reports. Since there are no reports, show a great empty state page that says the first report drops August 1.

  Don't implement this, just plan these changes now and get back to me for approval.

I’ve made some architecture decisions upfront based on tradeoffs I find wise. I’m deferring a lot of things to providers because I want to focus my time on this product on creating incredbly high-signal reports, not maintaining a backend. So you’ll see auth and DB being delegated to great third-party services.

The first thing Fable did was spin off investigation into a subagent. You can view any running subagents with /agent and then dig into them if you like:

After Fable gave me it’s first plan, I gave it a few things to change and an instruction that during implementation it should spin off subagents using Opus 4.8 and for simple things Sonnet 5.

It included this instruction in the plan.

Once I approved this plan, Claude started to work, using subagents!

After it was done, it gave me a nice SETUP.md file that showed me exactly what I needed to do to setup Clerk, Stripe, and Supabase and get them working with my app. I always ask for this when I’m connecting with third party stuff using AI, because this ends up being the most laborious part of the process.

But still, a proper auth + Stripe integration used to take me HOURS, and this compresses it into <30 minutes.

Now I don’t recommend you “vibe code” authentication OR billing. These are critical parts of your application. I’ve implemented auth in various ways ranging from “from scratch” to something like “Clerk”, so I used my experience to carefully check the work the model was doing.

One thing that makes this easy is that I did all this work on a branch and opened a pull request. Then, I reviewed it as if someone else wrote it.

Still, an incredible speed improvement!

Leave a comment