First notes after one day of testing Anthropic's new Fable 5, and why I think it belongs above Opus in the orchestration stack — not buried inside a flat subscription.

I've spent one day with Fable 5. This is a field note, not a benchmark. But sometimes a single day is enough to see the shape of a tool, and the shape of this one surprised me.

The headline, for me, is counterintuitive: Fable is not a better conversationalist. It is a better translator. Where it pulls ahead isn't the back-and-forth with a human — it's what it produces for other machines to act on. Hand it a fuzzy intent and it gives you a plan, a specification, an architecture that a downstream model can execute almost verbatim. It speaks "machine" with unusual fluency.

That single observation reframes where this model belongs.

We've been here before — with Opus

It's worth remembering a quieter turning point in this space. When teams first started using Opus as a coordinator over Sonnet workers — rather than asking one model to do everything — the gains were not subtle. The jump didn't come from a smarter single model. It came from structure: decompose the problem, isolate each piece, hand each worker a clean, bounded task, and let the coordinator hold the whole picture.

That was the moment an orchestration tier was born. The model stopped being a soloist and became a section of an orchestra.

Fable, to me, looks like the next layer up.

A new tier above Opus

If Opus-over-Sonnet gave us a coordinator and workers, Fable adds the role that was implicitly missing: the architect. The one who takes a half-formed idea, gives it a structure, decides the shape of the technical solution, and translates all of that into instructions clean enough for a coordinator to run with.

In practice, the stack I'm now reaching for looks like three tiers:

• Fable — the architect. Ideation, technical architecture, giving structure to vague ideas, producing the high-level plan, and acting as the first-pass reviewer of what comes back. It owns the front of the work and the first quality gate.
• Opus — the orchestrator. Takes Fable's plan, decomposes it into isolated, well-bounded tasks, and coordinates a team of subagents. It holds the picture while the work fans out.
• Sonnet — the workers. Detailed, isolated, narrowly-scoped execution. Each one gets a clean task and does it well, without needing the whole context in its head.

The interesting part is that each tier speaks to the one below it, not to me. Fable's job isn't to charm a human — it's to write something Opus can consume. Opus's job is to write something Sonnet can consume. The human sits at the top, talking to the architect; the rest is machine-to-machine.

That's why "talks to machines better than to people" isn't a weakness. It's the whole point of the layer.

Where it sits in the RPI / RPIQ loop

For anyone who follows the Research → Plan → Implement workflow I've been building my agent teams around, this maps cleanly. Fable strengthens the front of the loop — the Research and Plan stages, plus the architectural framing that usually leaks out across both. And in the RPIQ version, where Quality is a first-class stage, Fable naturally owns the first Q: the initial review of whether a plan or a design is even worth implementing, before a single Opus subagent spins up.

In other words, it doesn't replace anything below it. It sharpens the part of the loop that most determines whether everything downstream succeeds.

Why token-based pricing is the right call — not a tax

Here's the take I expect some pushback on.

Anthropic positioning Fable outside the flat subscription, as a token-based model, strikes me as correct — and not for billing reasons. It's correct because of what it does to behaviour.

Fable is heavy. It consumes real tokens and real resources. A flat subscription invites you to treat every problem as a Fable problem — to reach for the most expensive cognition you have for tasks that a Sonnet worker would finish in seconds. That's the classic sledgehammer-and-nail failure mode, and at scale it produces overengineered solutions to simple problems: three-tier architectures for a config change, elaborate plans for a one-line fix.

Token-based pricing acts as a forcing function for discipline. It nudges you to use Fable where its leverage is highest — building technical architecture, structuring ambiguous ideas, designing the approach, reviewing the first draft of a plan — and then hand off the execution to cheaper, faster models that are perfectly capable of it. The cost isn't a tax on the model; it's a reminder of where the model belongs in the stack.

Put bluntly: I don't want Fable doing my dishes. I want it designing the kitchen and then handing the dishes to someone faster.

The honest caveats

This is one day. I've tested it inside my own workflows — primarily the agent orchestration I run for BowSmith — not against a benchmark suite, and not at the volume I'd need before I'd call any of this settled. The economic argument above is a hypothesis about behaviour, not a measured result. And as someone whose day job is trust in software quality, I'd rather flag that early than oversell a one-day impression.

But the shape is clear enough that I'm comfortable saying it out loud: Fable is not a chatbot upgrade. It's a coordination layer. Treat it like one and the rest of your stack gets cheaper, faster, and — I suspect — better.

What's next

I'll be putting this to the test properly over the coming weeks: Fable as the architect and first reviewer, Opus coordinating isolated tasks, Sonnet executing them, all inside the RPI loop I already trust. If the early signal holds, this changes how I scope the front of every agent run.

If you've started testing Fable too, I'd like to hear where it landed for you — especially whether you're seeing the same machine-to-machine fluency, or something different.

This continues a thread from my 2025 talk, "Is AI the Future of Software Delivery?", and the orchestration work behind BowSmith. More on the RPI / RPIQ workflow and the four-surface orchestration model in upcoming posts.