The Sport Bike and the Dirt Track

Like a lot of people, I was disappointed when Fable was pulled almost as quickly as it appeared. I spent every moment of the few days I had it building out client and personal products, and going back to Opus 4.8 afterward felt like handing back the keys. Now Fable is back, along with all the pricing changes and politics that came with it, and the field keeps widening. Kimi K3 is out. Serious new models are landing every few weeks. If you don’t track releases closely, the shape of the lineup matters more than the specific names. For me it’s Fable and Sol at the top, Opus 4.8 as the everyday workhorse, and cheaper models below that.

All of that abundance has surfaced a skill I didn’t know I’d need, which is recognizing when a specific model is much better than the others at a particular kind of work and building my tooling and budget around that.

Not prompt technique. Not which model is smartest. Which model, for which task, at what price.

Overkill is a price judgment

Never in a million years would I have thought the models would get advanced enough that Fable and Sol would be overkill for most backend code.

That’s not a knock on the models. If they cost what the lower models cost, they wouldn’t be overkill at all. They would be the only thing any of us ever used. Overkill is a price judgment, not a capability judgment. At current prices, you can burn through a week of credits shockingly fast, and most backend and logic work simply doesn’t return the difference. A CRUD endpoint written by a frontier model is not meaningfully better than one written by a model a tier down. It’s just more expensive.

So the grunt work goes to the less sophisticated models. Migrations, endpoints, straightforward business logic, and test scaffolding are all workhorse tasks that get workhorse models, and the quality holds. That single routing decision is what stretches a budget across an actual week of production instead of three impressive days.

You don’t take the sport bike on the dirt track. The ride doesn’t get better. It just gets more expensive.

The front end is where the expensive models earn

The common instinct is that hard logic deserves the big model and UI work is the easy part you can hand to anything. My experience is the opposite.

If I could figure out a way to afford it, I would only ever use Fable or Sol on the front end. Combine them with tools like Impeccable and the quality of execution is far above what I get from Opus 4.8. When I run frontend work through Opus, I spend real time fighting weird choices and inconsistencies in the UI and UX. When I run the same work through Fable or Sol, those fights mostly don’t happen. Fewer mistakes, less correction, and the time savings are larger than on any backend task, because UX work is notoriously hard to review and even harder to un-bake once it’s wrong.

The allocation logic is to spend the frontier capability where the models are actually differentiated, which for me is design thinking and frontend execution, the work where judgment shows.

Opus’s verbosity is a real cost. Getting it to stop talking and just do the work feels like a regression of about a year, back to chasing hallucinations and fixing things it was specifically asked not to do. Navigating that is easier now than it has ever been, but I factor it in as part of Opus’s price. And Claude Design doesn’t seem to care which model runs underneath it. I’ve tested both, and I haven’t noticed a significant difference between Fable and Opus there. Claude Design already uses a ton of tokens on its own, so Opus 4.8 is what stays. For now.

Quality comes from models arguing

The second thing the multi-model world gave me is cheap disagreement.

I swap models back and forth on purpose now. I’ll do design and thinking work in Fable, then have Sol critique it, and go back and forth between the two. Or I’ll design in Fable, let Opus carry the build, and then have Sol go through the finished work to evaluate and critique it. That last pass has caught a bunch of things I would have otherwise missed, and the quality of the backend and logic work in my applications has gone way up because of it.

A single model doing a single pass is one perspective, and it’s confident whether or not it’s right. Confidence isn’t information. Disagreement is. The critiques don’t apply themselves, though. I read what the critic finds and decide what’s real. The models argue; I adjudicate.

I run that two-model build-and-review loop on top of goal mode, and this is the same principle applied at every scale, not just overnight builds but design documents, individual features, anything where a second set of judgment is cheaper than a missed flaw. That loop was already running me about $320 a month before Fable came back, which is exactly why the routing question matters. Every task you hand a frontier model is either a task something cheaper could have done, or a task nothing cheaper could touch. The skill is knowing which is which.

Trusting the overnight run

Most of my weekday capacity goes to client and training work, so product building has moved to a different shift. Long goal and loop sessions run in the background while I’m having dinner with my family.

For the first time, I really trust these runs to do what they were asked to do. That trust isn’t coming from the models getting smarter. It comes from process. The runs are connected to spec-driven and test-driven development, with real tooling linking the spec through development, through testing, and through release into staging or production. Because I can run scans, have models critique each other’s work across the pieces, and trace what was built back to what was specified, I can see into the quality instead of hoping about it.

The trade is that my own review time has grown, not shrunk. Reading specs, and making sure I understand exactly what’s being put together and how it works, takes up more of my day than it ever has. That’s the deal. The models do more of the building, and I do more of the understanding. I’ll take it.

The week has a shape now

The other change this summer is that my week finally has a structure that matches how these tools actually work.

Mondays are intake, when everything new comes in and gets captured. Then production planning, where intake becomes specs and scheduled work. Then the production flow itself, much of it running in those background sessions. Then a testing pass, then a revision pass. Intake, plan, produce, test, revise. Every week, same rhythm.

Around that cadence I’ve automated the connective tissue, the daily briefs generated each morning and the status updates drafted automatically from the conversations and work that actually happened during the week. A couple of weeks in, the workflow feels great. For the first time, I feel like I have the lay of the land for how these tools work inside a company of one or a small business.

The boundaries held. I’m still not working weekends, and the laptop still closes at six, though I do find myself starting earlier because I want to. The overnight runs took the night shift so I didn’t have to. And the sheer volume of work is the reason I haven’t been publishing as much lately. This new production cycle is what should bring the writing back.

The part you can’t delegate

If I could leave you with one encouragement from all of this, it’s not about model choice.

Take the time to methodically think through what you’re actually trying to accomplish, and write your specs against that thinking. In my view, doing that will be far more beneficial than any scaffolding or harness you set up around the work. The mechanics are well covered in Claude’s own best practices documentation, right down to having Claude interview you and draft the spec itself, but the mechanics aren’t the hard part. The hard part is that thinking is the easiest step to skip, and the one we most want to believe the AI will do for us.

It won’t. Every time a delivery has caught me off guard, a build that makes no sense, a piece missing an important interface or content or strategic analysis that should obviously be there, I can trace it back to the same cause. I didn’t think completely through what I was doing. Not the model’s failure. Mine.

So that’s the July report. If you want to try any of it, here’s what I’d do over the next thirty days:

• Route the grunt work down. Pick one project and send its backend and boilerplate work a tier down, then spend the savings running your frontend or design work through the best model you can afford.
• Add a critic. Put a second model in the loop on one real deliverable, have it critique the first model’s work, and read what it catches.
• Shape one week. Give a single week the intake, plan, produce, test, revise rhythm and see if it holds.
• Write the spec first. Before your next build, write down what you’re actually trying to accomplish, slowly, until it says what you mean.

Best of luck out there. I hope you’re enjoying the new tools as much as I am, and give me a shout if your experience is different than mine.