I tried using `/goal` when it just came out, but back then they used Haiku for it. And if your main model is a 1M model, Haiku can't even read that much. So my /goal always failed. (I instead went for an elaborate /loop-scheduled message)
I think the improvement on how it codes is pretty much represented correctly by the benchmarks (a nice bump, but not some crazy leap)
But where it really shines is in how NOT lazy it is. Fable requires less hand-holding. And I can understand how someone who uses Claude-Code sparingly and with very focused prompts would not see a lot of improvement there.
But simple example: if you ask Opus to do a review of the codebase (with a short prompt and not too much guidance), I've had it basically read the `git log` output, do a simple `ls` and have it declare "Everything looks great! No problems found!", when Fable really does what you would expect it to do.
And you might think: "oh, so it's just capable of handling crap prompts?", well sure. But even if you make THE PERFECT Opus plan (a plan that would take many turns/hours to finish), Opus will fake out, say everything is done, and then you see that half of the plan was deferred, half of the functions are ridiculous stubs, ...
If you give the same plan to Fable, it'll just DO IT. And it WILL get it done. And in the end it'll tell you "Oh, I also found 30 other bugs and I fixed all of them properly" (where Opus would have started crying, or WORSE, worked around the bugs)
That's not true, but it's their own fault for being so utterly terrible at communication. It only drops back to Opus for some prompts, just like before. The longer blogpost was a bit less vague about this.
Before Fable got pulled, they claimed their goal really was to keep it around in the subscriptions in some way, they just didn't know when it would return. This time there isn't even a single mention of this. It's just "This is a promotion, and it's going away". Like how the hell can this corporation be so fucking bad at communication?
I just don't really understand the entire strategy behind this. Or their horrible, horrible communication.
Because right now it's as if Fable/Mythos 5 is "the end of the line". It's as if this is the best their models are ever going to be. So what the hell are we going to get next? All of their models will forever inch closer to Fable, but never reach it? That doesn't make any sense.
It all seems so dramatic. Instead of just saying honestly "Look, this model is a beast to run, but we're striving to reach the same quality in a cheaper model down the line" all we get is "Oh my god, it's so big and scary, and it costs so much to run, woe is me!"
But LLMs aren't just shuffling words around. Words (tokens) are the "human interface" at the edges. Text input gets embedded, then there's this huge latent-space computation in the middle, and only at the tail end does that get converted back into word/token probabilities. So just saying that "words are the source" isn't entirely correct and feels misleading.
Was this not the case earlier? I've had it stuck in loops from day 1, even when Gemini 3 came out. I've never been able to actually use it for anything because it goes absolutely mental after a handful of turns.
I've been working on something like this too, for quite a while! Though I'm trying to get a non-quadratic-attention LLM (or SLM) up and running.
And anyway, I think the most important thing is dataset quality. Dumping in whatever dataset you find on Huggingface is a recipe for mediocrity, so I'm also spending a lot of time on that.
I've seen Opus do some incredibly token-costly things before too. In fact after most sessions I ask it about which tools it used often, which tools could be simplified/made less verbose, could be "combined" into one, ... So for each project I mostly create a few little scripts that do a bunch of things in one go that it would normally do in multiple tool calls.
For example: one thing Opus was really bad at was re-running the test suite followed by a bunch of `| grep` suffixes. So it would often re-run 5+ minute test suites just to grep the output a bit differently
The solution was to wire up a little script that ran the test suite, save the output to a file, and then inform it where that file is and to NOT re-run the suite just so it can grep the output differently. This saved me a bunch of time & tokens.