Fable set the default standard for how I code. Expensive, sure, but it's still the one running my actual production stack (Convex, Clerk, Next.js), not a demo I forgot to kill after the screenshot. Then Sol showed up 2 days ago, and for 48 hours the entire AI sphere lost it over one-shot 3D simulations and instant demo apps. Cool trick. A real app never ships off a single prompt though, and maybe my barely broken-in default is already cracking again.
The contrast interests me for a specific reason. I'm not comparing 2 models on a fresh, clean task, which is what most vendor benchmarks do. I'm comparing months of Fable running my own codebase against what independent testers, Every.to first among them, found when they handed Sol something messier: an existing collaboration codebase, a "rewrite this the way a senior engineer would" instruction, and no script to follow. The gap between those 2 stories is not subtle.
Sol costs half what Fable charges per token. On an actual codebase, that discount bought 4 cooperating systems for a problem that needed 1 fix.
Why the Benchmark and the Codebase Disagree
Start with the headline numbers, because they tell 2 completely different stories depending which one you read first. On Terminal-Bench 2.1, the benchmark OpenAI led its launch with, Sol scores 88.8 percent in standard mode and 91.9 in ultra. Fable sits somewhere between 83.4 and 84.3 percent, depending which secondary source you trust, since OpenAI and independent trackers don't fully agree on the exact figure. Sol wins that one clean.
Now flip to SWE-Bench Pro, which grades models on resolving real GitHub issues instead of a scripted terminal task. Fable scores 80.3 percent. OpenAI has not published a Sol number on that benchmark at all. Not "lower," not published. And on Every.to's Senior Engineer benchmark, which hands a model a genuinely messy collaboration codebase and asks it to rewrite the thing the way a senior engineer would, Fable scores 90 out of 100. Sol scores 56.
The reason those 2 headlines fight each other isn't noise. Terminal-Bench measures how a model handles a scoped task inside a terminal: a defined command, a defined success state, no history to carry. That's a real skill and Sol is legitimately excellent at it. But shipping software on a codebase that already exists is a different job entirely. It means reading code you didn't write, figuring out what's load-bearing and what's dead weight, and deciding what not to touch. That second job is what SWE-Bench Pro and Every.to's benchmark actually test, and it's exactly where the 2 models stop agreeing with each other.
There's a pricing angle worth mentioning too, since OpenAI leans on it hard. Sol runs at $5 input and $30 output per million tokens against Fable's $10 and $50. OpenAI also cites a figure from Lovable, a launch partner, claiming 25 percent fewer steps and 35 to 48 percent fewer tool calls on production workflows. Worth noting that's a partner quote in a launch deck, not an independent measurement, and partners in launch decks tend to sound thrilled regardless of what's actually happening under the hood.
YC's CEO shared his own Claude Code prompt not long ago, and the issue with it landed on the exact same fault line: a prompt that solves a task cleanly on paper while missing what the task was actually for. Sol has that same tell.
The Rewrite That Built 4 Systems
Here's the part that made me sit up. Every.to gave Sol a real, messy collaboration codebase and 1 instruction: rewrite this like a senior engineer would. Sol delivered. It produced a complete, technically defensible rewrite that actually ran. The problem is what "complete" turned into: roughly 12,900 lines of new code, split across 4 cooperating processes, to solve something a simpler architecture would have handled on its own (picture Sol clearing the main quest, then farming 3 side quests nobody put on the board). Every.to's own read on it was blunt: you could trace exactly why each addition got added, but stacked together the whole thing recreated the complexity a rewrite was supposed to remove.
Fable, on the same test, scored 90 out of 100. The gap wasn't about capability. It was about restraint, the willingness to stop building once the problem is actually solved instead of once the model runs out of ideas for what else it could add.
I want to be fair to Sol here, because the honest picture isn't "Sol bad." On a separate test, Every.to had both models rebuild their internal editor, Proof, from a single prompt each. Sol delivered a running version in about a third of the time Fable took, even if the reviewer preferred Fable's design. Sol also finished a one-prompt audio workstation build that the previous GPT generation couldn't complete at all. When the target is clear and the scope is fixed, Sol is genuinely fast and genuinely good. The trouble starts exactly where the assignment gets vague enough that the model has to decide, on its own, what belongs in the final product and what doesn't.
Sol executes with real persistence. It just doesn't have Fable's restraint about when persistence should stop.
My Fallback Rate Beats Their Number
Now the part I can only back with my own sessions, not a citation. Fable automatically routes certain prompts to Opus 4.8 when it judges them risky enough to need a stronger model underneath. Anthropic reports that over 95 percent of Fable sessions never trigger that fallback, meaning fewer than 5 percent do. In my daily use, on prompts that are about as harmless as coding prompts get, that number feels a lot higher than 5 percent, and it's been consistent for months, not a one-week fluke. Watching Fable quietly swap itself out for Opus mid-session has a mild HAL 9000 energy to it: it makes the call, it just doesn't explain the call.
I run Fable every day, still trust it on anything that isn't a scoped task, and the fallback itself usually produces a fine result once it kicks in. What bugs me is the wait, and the fact that I still can't predict which prompt triggers it. I'll ask for something almost identical to a request from the day before, get flagged this time, and have zero idea what changed on my end to cause it. Maybe I'm reading too much into a handful of sessions and this evens out over a bigger sample, but the pattern has held long enough that I've started half-expecting it before I even hit send.
Unrelated tangent, but it happened the same week so it's stuck to this article in my head now: my Stripe test mode decided "test" meant "silently drop half the webhooks" for exactly 2 days, no logs, no error, nothing to grep for. I burned a Saturday morning on it before finding a Stripe status update buried 3 clicks deep in a changelog nobody reads. Nothing to do with Sol or Fable. Just a reminder that "no error thrown" and "nothing is wrong" are not the same sentence, in this industry or any other. 🤷♂️
None of this shows up in a benchmark chart, and that's kind of the point. Terminal-Bench doesn't measure how long you sit there wondering if your prompt just got quietly escalated to a different model without asking you first. Neither does SWE-Bench Pro. The friction that actually shapes a workday (waiting on an unpredictable fallback, re-reading a prompt to guess what tripped it, deciding whether to just start over) lives entirely outside what any of these published numbers capture. You only find it by running the thing for months and paying attention to your own irritation, which is a worse methodology than a benchmark and also the only one that catches this particular problem.
Which One Can You Leave Alone
So here's the actual decision, stripped of vendor framing. Use Sol when the task is scoped: a defined ticket, a tight budget, fast iteration on something you can describe in 1 sentence, early prototyping where speed beats judgment. It's fast, it's resourceful, and at half the price it's hard to argue with for that kind of work. Leave it alone for 2 hours on a task like that and it's usually still fine when you get back. No "you died" screen waiting for you.
Use Fable when the codebase already exists and has to keep existing for months, when the task is ambiguous enough that the real work is deciding what to build rather than building it, when getting it wrong costs more than the extra tokens ever would. That's the entire premise behind the Blueprint method in Vibe Coding, For Real: the model that matters isn't the one that nails a clean, well-specified prompt. It's the one that still makes good calls once the spec gets fuzzy, which on a real project happens by around step 3.
I already went deeper on this exact judgment problem in the piece where prompt contracts replaced vibe coding, and Sol's 4-process rewrite is basically that argument playing out on someone else's codebase instead of mine.
Anyway, the question was never which model wins. It's which one you can walk away from for 2 hours without coming back to a surprise.
Sol goes fast and costs less as long as you hand it a fence. Take the fence away and it keeps building anyway, it just doesn't know when to stop. Fable is slower and costs more, fallback detours included, but it tends to stop where the problem actually ends.
The model that costs less on paper doesn't always cost less to run. 💸
Sources
- Every.to, Vibe Check: GPT-5.6 Sol Is Our Favorite Model to Collaborate With
- TechTimes, GPT-5.6 Sol Review: Faster Coding, Half Fable 5 Cost, and a Benchmark Problem
- Layer3labs, GPT-5.6 Sol vs Claude Fable 5: Flagship Tier Compared
- OpenAI, GPT-5.6: Frontier intelligence that scales with your ambition
- Nate Herk, YouTube comparison video and associated post (manager/worker framing)
This post may contain affiliate links. If you click them, I might earn a small commission (costs you nothing, and helps me keep shipping quality articles every day for your reading pleasure).
Top comments (1)
I was particularly intrigued by the contrast between Sol's performance on scripted terminal tasks, such as Terminal-Bench 2.1, and its performance on real-world codebases, like the one tested by Every.to. The fact that Sol costs half what Fable charges per token, yet produced a rewrite with 12,900 lines of new code split across 4 cooperating processes, highlights the potential trade-offs between cost and complexity. In my experience, overly complex architectures can lead to increased maintenance and debugging costs down the line. Have you considered exploring the long-term maintainability implications of Sol's rewrites, and whether the cost savings outweigh the potential added complexity?