Fable 5, One Month In

On day one I gave it everything.

Access was unrestricted. The model ran my whole agent fleet. Every task, every machine, every hour of the night. I wrote field notes that evening and they read like a person who had just been handed a bigger engine.

A month later the setup looks nothing like that. Nothing broke. The model is still excellent. What changed is the job I give it.

The cost cliff

Some background first. Fable 5 went dark on June 14, suspended for export-control reasons. It came back on July 1 and I verified it live the same day, still inside my normal plan.

The plan-included window was originally supposed to end a week later. It didn't, not exactly. The provider extended it a few days past the date I'd already planned around, which meant I spent most of a week bracing for a cliff that moved under me before I actually went over it. When the extension ran out, every call started costing real money. Not a fortune. A small usage-credit budget, which is a very different thing from unlimited.

That single line item rearranged everything downstream, and the moved deadline taught me something adjacent to the cost lesson: don't build your whole posture around a date a provider hasn't committed to in writing. I had already restructured the fleet for the original date. The extension was a bonus few days, not a reason to undo the restructuring.

You cannot run a frontier model as a general-purpose executor on a metered budget. Or you can, briefly, and then you look at the balance. So I stopped.

The demotion that wasn't one

The new pattern is simple. A cheaper Sonnet-tier model does the building. Fable gets consulted.

I call it the Advisor role. It is invoked for high-stakes judgment calls and for second opinions on work that already exists. Should we take this approach. Is this migration safe. What did the other model miss.

Fable went from doing the work to reviewing the work.

That sounds like a demotion. It is a demotion in role. It is not a demotion in respect, and after four weeks I think it is the better fit.

Here is why. Reviewing is where the expensive model earns its price. A build task has a thousand acceptable outputs and most competent models find one. A review task has one right answer, and finding it requires holding the whole problem in your head and being unhappy about small things.

The bake-off said something similar, with caveats

I did not want to trust my own impression on this. Impressions about model quality are almost always vibes with a confidence interval of zero.

So I built a small benchmark sidecar. Nothing elaborate. It runs the same real production tasks through several models side by side and logs cost, time, and test results for each.

Over a handful of runs, cheaper models kept winning on raw build quality for production coding, by the sidecar's own scoring. One run had a fast, inexpensive model shipping the most passing tests at a fraction of the cost. Another had a different cheaper model win because its output was the only one that actually matched its own stated notes. Fable was rarely the cheapest way to get code written, and it wasn't consistently the best either.

Where Fable earned its keep was review. Across a run of adversarial passes on real designs and plans that week, it caught things that mattered: a fail-open default that should have failed closed, a missing chargeback path in a checkout flow, a revenue number in a plan that turned out to be wrong once checked against the ledger, a merge-order bug that would have silently dropped user data. None of those showed up in a benchmark score. They showed up in what got fixed before it shipped.

I want to be honest about how much weight the sidecar itself can carry. One head-to-head run where a newer model beat Fable on test count came with its own logged caveat: single nondeterministic run, small sample, not yet a general claim. That is exactly right, and it should stay true when I write about it too. The sidecar is a handful of data points, not a verdict. What it gave me was a rough shape (build quality was not where Fable was pulling ahead), and the review wave gave me the specific, repeatable evidence for the other half of the claim.

So the budget forced a specialization, and the available evidence points the same direction without fully proving it. I would like to claim I designed that. I didn't. The cost cliff pushed me somewhere I should have gone by reasoning, and I'm still collecting the data that would let me say it with more confidence than "somewhere in this direction."

The lesson I take, held loosely: the frontier model is not obviously the best at everything I ship. It looks like it is the best at one particular thing so far. Noticing what is wrong.

The failure that had nothing to do with the model

Around week six, one of my overnight machines went quiet. Not crashed — quiet. The process was still there, still nominally alive, and it was producing nothing.

I assumed model quality first. That was wrong.

The login had expired. The tool was sitting at a prompt asking to sign back in, and nothing downstream noticed, because the process itself looked fine — a process existed, so every automated health check that only asks "is something running" said yes. Days went by like that before a human actually read the output instead of the exit code. I pulled the machine out of the rotation until it was reauthenticated.

Pure configuration. Zero to do with the model.

I mention it because I nearly filed it as a model regression, and I doubt I am the only person who does that. A multi-machine setup has its own failure surface: expired logins, health checks that confirm a process exists without confirming it's doing anything, silence mistaken for idling instead of failure. None of it is intelligence and all of it looks like intelligence failing when you are reading output at seven in the morning. The fix afterward wasn't a smarter model — it was a check that measures whether the work is actually advancing, not just whether something is technically running.

Fleet reliability and model quality are two different problems. Conflating them makes you distrust a model that is working fine, and it hides the boring config bug that is actually costing you the night.

The question I have not answered

There is one decision still open.

I run a council-of-models pattern. Several models hold seats, they argue, I read the disagreement. One of those seats has been running on Fable since the start, on the logic that the most opinionated seat should go to the frontier model.

I am no longer sure that logic holds.

That allocation was made when Fable was my generalist. It is now my reviewer. A council seat is a generative role. It proposes, it advocates, it takes positions. If the model's real edge is catching what is wrong, maybe it belongs at the end of the council process, not inside it.

Maybe the seat should go to whichever cheaper model is winning build quality that month, and Fable should read the transcript afterward.

I have not made the call. I keep drafting the swap and then leaving it.

The honest answer is that I do not yet know whether the seat is about opinion or about correctness. Until I do, moving it would just be motion.