Fable 5 came back. It didn't get its job back

My favourite model came back and I didn't give it the architect seat. Not because it got worse — because the seat got measured. What happens to a stack when the tool you were attached to returns.

I promised you the CAST26 recap this week. It's coming. But something happened that jumps the queue.

Fable 5 came back. And I didn't give it the architect seat.

The test I didn't plan to run

Two weeks ago I wrote that the architect tier is a role, not a product — a job description and an interface contract, not a favourite model. That's an easy thing to claim while your favourite is unavailable. It costs nothing. The tier had a vacancy and I filled it, and calling that "designing the seat" is a bit generous when the alternative was not working at all.

The real test was always going to be this: what happens when the favourite comes back and you have a genuine choice?

I expected the test to be "would I switch back?" — a yes/no. That framing turned out to be wrong, which is the interesting part.

What actually happened

Fable 5 is back in my stack. It just isn't in the delivery pipeline.

Architecture and coordination sit with Opus 5. Turning fuzzy intent into a structured plan, holding boundaries, deciding whether a plan is worth building at all, and decomposing it into work — that's one seat now, and Opus 5 holds it.

Fable 5 does ideation and brainstorming. Upstream of the loop entirely. The messy, divergent, "what are the five shapes this could take" thinking that happens before there's anything to plan.

That's not a demotion and it isn't a consolation prize. It's the job Fable is genuinely best at in my workflow. The thing that made it frustrating as a delivery-tier model — that it wants to explore, reframe, and hand you three options when you asked for one — is exactly what you want at the front of the funnel, before anything is committed.

Why it didn't get the seat back

Not capability. Let me be clear about that, because "I moved off my favourite model" invites the assumption that it got worse. It didn't.

Cost per unit of leverage. The architect seat gets invoked constantly — every task, every re-plan, every gate. A model that's meaningfully more expensive per call is a bad fit for the highest-frequency seat in the stack, regardless of how good it is. This is the same argument I made when I took the architect tier out of my delivery work on purpose — I just didn't expect to be applying it to Fable.

Tighter rate limits. A seat that gets hit dozens of times a day cannot be held by something you have to ration. Rationing the architect tier means either batching decisions that shouldn't be batched, or quietly skipping the quality gate when you're near a limit. Both are worse than using a slightly less preferred model freely.

Ideation is the opposite shape of usage: low frequency, high value per call, no urgency if you have to wait. Which is precisely where an expensive, rate-limited, exploratory model earns its keep.

The thesis held, but not the way I expected

I thought "design the seat, not a favourite" meant any competent model can hold any seat, so don't get attached. That's not quite it.

What it actually means is: once you've written down what a seat requires, you can notice when your favourite no longer fits it — and you can notice where it fits better instead. The job description isn't just a hiring filter. It's what lets you reorganise rather than just substitute.

If I'd never written the three jobs down, the return of Fable would have had exactly one possible outcome: put it back where it was. That's what you do with a tool you're attached to. Instead the question became "which seat does this fit now?", and the answer wasn't the one it used to hold.

Tools don't come back to their old roles. Systems reorganise around what each part is actually good at — if you've done enough work to know what that is.

What I'd do differently

Write the job description before the outage, not during it. I got the seat definition out of Post 8 because I was forced to — losing Fable made me articulate what the tier was for. That clarity is what made this week's decision easy, and I'd rather have had it while everything was still working.

If you're running a multi-model stack right now with everything available and no crisis: that's the cheapest possible moment to write down what each seat requires. You'll never have better conditions for it, and you'll be glad of it the first time something changes underneath you.

Next week — the CAST26 recap, properly

Now the deck. Next week I'm writing up CAST26 — what landed, what didn't, and the questions from the room I didn't have good answers for. Slides included, as promised.

If you're testing Fable 5 / Opus 5 too, where did they land for you? And the sharper version: has a tool ever come back to your stack and not got its old job back — or did you put it straight back where it was without asking?

Series: Post 1 — Fable 5 talks to machines better than to people · Show me the receipts · Show, don't tell · Why I took the architect tier out · The RPIQ loop · Where the stack was overkill · BowSmith case study · I lost my favourite tool · Opus Max as architect