We ran GPT-5.6 Sol vs Fable 5 through the same build tasks this week: identical prompts, identical scope, two different engines producing two different outputs. This is not a benchmark exercise for us. We build software and AI systems for operators who pay by the outcome, so which model does the work changes what a project costs and how long it takes to ship.
What we actually tested
We gave both models the same brief: build a working feature from a single prompt, then judge the result on functionality, polish, and how much it cost to produce. We ran this three times with different briefs: an interactive browser build, a marketing site with animation and sound, and a set of five smaller creative builds from an intentionally vague prompt. Same rules for both models. Same creative freedom. No hand-holding mid-build.
The pattern held across all three runs. Sol finishes faster and burns far fewer output tokens for the same brief, which is the direct reason it costs a fraction of what Fable costs on the identical job. Fable takes longer and spends more, and on subjective creative and design output, it produced the result we would ship more often than not.
Where the cheaper model wins
Sol is the model to reach for when the task is scoped, technical, and has a clear right answer. Refactor this function. Write this data pipeline. Extract this field. Fix this bug. Extend this existing pattern. Tasks where correct is a testable outcome, not a subjective one. For that category of work, a model that spends fewer tokens and finishes faster is simply better, because you are not paying a premium for creative judgment the task does not need.
This matters more than it sounds like it should. Most of what a 10 to 50 person operator needs built is exactly this kind of work: connect this system to that one, route this lead to that inbox, log this call to that CRM. Scoped, testable, repeatable. That is the bulk of what we ship inside our automation builds, and it is where a cheaper, faster model is the obvious default.
Where quality still costs more
Fable earns its higher price on the ambiguous end of the spectrum: greenfield product design, anything customer-facing where first impression matters, and creative direction with no single correct answer. When we gave both models total creative freedom and asked for the most impressive result they could produce, Fable's output was not marginally better. It was different in kind: better spatial reasoning, more considered pacing, fewer visible seams.
That gap is worth paying for on specific work. A client-facing landing page. A demo build that has to land in one shot in front of a buyer. The first version of a new product surface, before a pattern exists for a cheaper model to follow. Anywhere the output is customer-facing and first impressions carry real weight, we default to the model that gets the judgment calls right, not the one that gets there fastest.
The token efficiency gap is the real story
The interesting number in our testing was not the sticker price difference. It was output tokens. On identical briefs, Sol consistently produced roughly a third of the raw output that Fable did to reach a working result. That token gap is the mechanism behind the entire cost difference, and it tells you something about how each model approaches a problem: Sol converges fast and stops, Fable keeps iterating on the details. Neither approach is wrong. They suit different jobs.
Current list pricing for both model families is public and changes often enough that we check it before every client quote rather than working from memory. OpenAI publishes its API pricing here, and Anthropic publishes Claude pricing here. If you are routing spend between model families for client work, check both before you build the routing logic, not after.
The mistake: picking a favorite
The operator mistake we see most often is treating this as a loyalty decision. Someone tries one model, likes the output, and defaults to it for everything going forward regardless of task. That is expensive in one direction and slow in the other. Running Fable on a scoped data extraction job burns budget it did not need to spend. Running Sol on a customer-facing landing page ships something that reads as slightly off, and slightly off is the kind of thing a buyer notices even when they cannot say why.
The fix is not picking a winner. It is building a routing layer that sends each task to the model suited to it, the same way you would not send every support ticket to your most senior person. We treat this exactly like task routing in any operations system: classify the job, route by type, track the outcome. Our AI Operations Agent is built around this pattern already, sitting between the client's tools and whichever model is doing the work underneath, so the client never has to make this decision manually on every task.
How we route tasks now
Here is the routing logic we are running internally and building into client systems this quarter.
| Task type | Default model class | Why |
|---|---|---|
| Scoped technical build, existing pattern to follow | Fast, low-cost model | Correct answer is testable. Speed and cost win. |
| Data extraction, routing, classification | Fast, low-cost model | High volume, repeatable, no creative judgment needed. |
| Client-facing landing page or demo | Higher-cost model | First impression risk outweighs the cost delta. |
| Greenfield product design, no existing pattern | Higher-cost model | No pattern to converge on yet. Judgment matters more than speed. |
| High-volume background agent work | Fast, low-cost model | Running 24/7, cost compounds fast at volume. |
That last row matters more than it looks. An agent that works 24/7 on a low-cost model beats a human on a payroll clock before you even account for raw capability, and it beats a high-cost model running the same volume of scoped work by a wide margin. Volume is where model choice compounds, for better or worse.
What we are building this quarter
We are rebuilding the model-routing layer inside every active AI Chief of Staff and AI Operations Agent deployment so it is not a manual choice per task. The client should never need to know which model handled a given job. They should just see the output, the cost, and the turnaround.
For new clients, this starts at the €999 assessment, credited straight to the build if you move forward. We map the workflows eating the most hours, typically 10 or more hours a week of admin work per operator we assess, and we decide task by task which model class each workflow should run on before we write a line of the build. That decision gets baked into the system, not left to whoever happens to be prompting it that day.
If you are already running voice agents or automations and have not looked at model routing since your last build, this is worth revisiting. Pricing and capability shift fast enough that a routing decision made two quarters ago is probably costing you money today. We cover the same logic across voice agent deployments, where response latency and cost per call make the model choice even more visible on the monthly bill.
Want to see where this shows up in your own numbers? Our revenue leak heatmap flags the workflows worth automating first, and our case studies show what the routed version of this looks like once it is live. Read more operator breakdowns like this one on the luup blog. For the technical detail on how each vendor structures models within a family, OpenAI's model documentation and Anthropic's model documentation are the primary references we check before every routing decision, and we would rather you check them too than take our word for a number that changed last week.
The takeaway is not that one model beat the other. It is that asking which model is better is the wrong question for an operator to ask. The right question is which task you are routing, and whether your system is smart enough to make that call without you.