/Tech3h ago

Ghostty creator Mitchell Hashimoto says Fable AI is too slow and expensive for general development but excels at narrow optimization loops

A SwiftUI layout optimization test cost $40 in compute.

491.3K7133872.7K
Original post
Mitchell Hashimoto@mitchellh#1886inTech

Fable is a good model. As with all new models, it is simultaneously excellent and entirely unremarkable (relative to other models). It is slow and expensive, and the "loops are all you need" discourse they are pushing is obvious in the context of someone using Fable-class models

What I've found so far is that for broad scope design (code architecture) tasks, Fable is unremarkable. Or, not better enough to justify its cost and speed.

But in highly targeted goal-oriented loops, it is another beast entirely. It is very slow but produces very good results.

I let it churn on optimizing a SwiftUI-layout resolver in Go I wrote and it was able to bring it down to an order of magnitude I could not reach myself (micro => nanosecond scale). But it took 2 hours and $40 to do it and I had to claw back some changes it overfit to Apple Silicon. Still, very worth it.

In comparison, for "implement this feature/change" iterative work, I ran head-to-head Fable vs GPT5.5 vs. GLM-5.1. They all produced equally acceptable final results, but GPT5/GLM did it in a couple minutes and Fable was churning away for 40 minutes. And GLM cost me less than a dollar, GPT5.5 ~$1.50, and Fable cost $9.

You can see that in this context, interactively working with an agent is nonsense. Its too slow. You need to write loops to keep the agent working and you probably want to highly parallelize the work being done. As with all things, I think a balance makes sense...

My sense is that I'd reserve Fable for targeted, surgical analysis and work. Not for daily driving everyday tasks.

I'm going to keep spending a shitload of money (relatively) and maining Fable for the rest of the week to continue to judge, will report if anything changes. I'll continue to head-to-head as well.

11:16 AM · Jun 10, 2026 · 70.8K Views
Sentiment

Positive users praise the honest analysis of Fable's targeted code optimization strengths, while negative users criticize the model as slow, costly, verbose, and impractical for everyday use.

Pos
35.7%
Neg
64.3%
16 comments with sentiment.
Cluster Engagement
Posts from X
Most Activity
Most Activity
VIEWS2K
Lenny Pruss@lennypruss

@mitchellh Follow the incentive (e.g. benchmark) and you'll see the outcome. The models are getting incredibly good at brute forcing long-context, hard coding problems. But in doing so they're sacrificing speed and elegant abstractions.

3hViews 2KLikes 5
BOOKMARKS4LIKES22

In the increasingly growing discourse around companies wildly spending on tokens and blowing token budgets, I think its really just highlighting the changing modality of models (pun intended).

I feel like a lot of products and companies have moved beyond "use the latest model all the time" a while back. A lot of agents (non-coding) use things like Sonnet and Flash-based and open-weight models. Its good enough.

But for coding I feel like companies have mostly opted to use the latest at all times, for the most part. And I think that should shift with these Mythos-class models. I mean, I think it should've already been shifting with GPT 5.5 xhigh too.

The problem is that I think broadly speaking, a lot of people don't have the skill (a new skill!) to judge when to use what model.

But I think sandbagging, like 18 months from now we'll see a ton of habits change just due to cost (not even capability, but also that).

3hViews 1.7KLikes 22Bookmarks 4
RETWEETS12

Fable is a good model. As with all new models, it is simultaneously excellent and entirely unremarkable (relative to other models). It is slow and expensive, and the "loops are all you need" discourse they are pushing is obvious in the context of someone using Fable-class models

What I've found so far is that for broad scope design (code architecture) tasks, Fable is unremarkable. Or, not better enough to justify its cost and speed.

But in highly targeted goal-oriented loops, it is another beast entirely. It is very slow but produces very good results.

I let it churn on optimizing a SwiftUI-layout resolver in Go I wrote and it was able to bring it down to an order of magnitude I could not reach myself (micro => nanosecond scale). But it took 2 hours and $40 to do it and I had to claw back some changes it overfit to Apple Silicon. Still, very worth it.

In comparison, for "implement this feature/change" iterative work, I ran head-to-head Fable vs GPT5.5 vs. GLM-5.1. They all produced equally acceptable final results, but GPT5/GLM did it in a couple minutes and Fable was churning away for 40 minutes. And GLM cost me less than a dollar, GPT5.5 ~$1.50, and Fable cost $9.

You can see that in this context, interactively working with an agent is nonsense. Its too slow. You need to write loops to keep the agent working and you probably want to highly parallelize the work being done. As with all things, I think a balance makes sense...

My sense is that I'd reserve Fable for targeted, surgical analysis and work. Not for daily driving everyday tasks.

I'm going to keep spending a shitload of money (relatively) and maining Fable for the rest of the week to continue to judge, will report if anything changes. I'll continue to head-to-head as well.

3hViews 70.8KLikes 1.3KBookmarks 343
REPLIES1
Tim Lucas@toolmantim

@mitchellh Have you tried Fable with low or medium reasoning effort for hands-on interactive work? I found that quite a lot better than high/xhigh. Hard to say if it’s better than GPT5.5 medium (deep² in Amp) at this point though.

1hViews 889Likes 2

@bodwinestroll A layout resolver (similar to Flexbox) but modeled after SwiftUI, fully written in Go.

3hViews 1.1KLikes 9Bookmarks 1
Mario Figueiredo@fromdevoid

It is becoming far too obvious that in order to use every new model effectively we need strong technical skills, a good technological understanding, and a lots of time and money to spend on testing them and restructuring the way they should be approached for our own projects.

There is no unified approach to agentic development and it doesn't look like ever will. Not between different company models and not even between different model versions of the same company. It is all largely very experimental, a guessing game and almost entirely based on claims (like yours) that cannot be properly documented and reproduced in different dev/project environments.

Ignoring for now how hard this goes against the promises made of a brighter simpler future accessible to everyone, the real question is how can companies adapt to the rate new models are being churned and how much is all this costing them financially and to the quality of their products.

2hViews 384Likes 3
Olabode Adedoyin@bodwinestroll

@mitchellh Potentially stupid question

> optimizing a SwiftUI-layout resolver in Go

what does this mean? I'm curious, I never though I'd see SwiftUI and Go in the same sentence

3hViews 1.5K

@mitchellh Fable looks like a specialist tool, not an everyday driver. Slow and costly, but that nanosecond optimization shows it shines when you need surgical precision over speed.

3hViews 377
Teeser@Teeserv2

@mitchellh @martin_casado For my purpose opus 4.6 still smashed it

2hViews 76Likes 1

@toolmantim I did, but it falls into the same problems I had with Opus imo. Small sample size, but it seemed over eager to code when it needed to plan a *bit* more.

1hViews 745Likes 2
Adv@advnt0x5

You nailed. I stuck Fable on some pretty rudimentary tasks yesterday to see how it would perform, and, unsurprisingly, it cost $50 to explore a rather simple codebase. On the other hand, it found a few bugs that Opus and 5.5 hadn’t found, and it blew my mind. Surgical work only, maybe a PR review here and there. Other than that, the cost-benefit analysis does not favor using this model for most use cases. Sorry for the blob of text that isn't too interesting, but wanted to share my thoughts anyways.

1hViews 61Likes 1
martin_casado@martin_casado

@Teeserv2 @mitchellh 4.6 is fantastic.

2hViews 22
ben hylak@benhylak

https://benhylak.substack.com/p/accumulated-drift

3hViews 833
DRM HSE@drmhse

@mitchellh When you let it run free it tends to be very verbose….easily churns 1000 loc for something worth 100 loc

3hViews 491
Zygis@zygisSS22

Love this type of content. More grounded and without the unnecessary hype behind a new release.

Similar feelings here. It’s kinda slow, but I think the correctness and direction are always on point. I haven’t had an issue where the model goes into a rabbit hole and I need to refocus it. It’s always on track: slow and steady.

2hViews 398
John Malone@john_malone

@mitchellh Now I can spend money on Claude twice as fast!

3hViews 337
Paweł J Lisowski@PawelJLisowski

@mitchellh Great take and exactly similiar to experience i had so far. Its kinda good at planning if i let it burn tokens like crazy with subagents but most regular tasks or plan executioner theres really no reason to use it

2hViews 323
Olabode Adedoyin@bodwinestroll

@mitchellh Ahh! gotcha. I tried something like this a while back(in Go as well) by defining the "artifact" interface and letting an llm churn on the details with mixed results, more of a flutter style feel. I'll love to see what you came up with interface design wise if you can share.

3hViews 310

@mitchellh Thank God for honest and agenda lacking smart people building real products who take the time to share real assessments from personal experiences to bring balance to this insane discourse around all the AI models like Mitchell. There are not many and we should treasure them. 🙏🏾

3hViews 287
Load more posts