Fable 5.1 vs Fable 5: Which One Actually Builds Better Apps?
A head-to-head test has Fable 5.1 and Fable 5 build the same app, comparing cost, build time, token use, and final UI quality.
What happened when Fable 5 and Fable 5.1 built the same app?
A builder ran an identical prompt through Fable 5 and Fable 5.1, asking each to orchestrate a team of sub-agents (rather than write code directly) to build the same app: a local-first visual tool for designing and simulating incident response workflows. The results diverged sharply. Fable 5 finished in about half a day for roughly $500. Fable 5.1 took about a day and a half and cost around $1,200. Both apps worked, but they looked, felt, and were built completely differently, despite starting from the exact same instructions.
TL;DR
- Fable 5 finished the build in about half a day and cost roughly $500, while Fable 5.1 took about a day and a half and cost around $1,200, more than double.
- Both agents were told to delegate almost all engineering work to sub-agents (mostly Opus for architecture and design decisions, Sonnet for implementation and testing) rather than write code themselves.
- Fable 5 leaned heavily on Sonnet workers (about 80% of the work), which likely explains its lower cost and faster turnaround.
- Fable 5.1 split its work more evenly across Opus (about 57%) and Sonnet (about 40%), with the orchestrator itself accounting for only a small slice of total tokens.
- An independent Codex review scored Fable 5.1’s app slightly higher overall (9.1 vs 8.4), citing better information hierarchy and clearer run summaries, while Fable 5 scored well on deeper authoring controls and more accurate run-state reporting.
- Context window usage told a clear efficiency story: Fable 5.1 used about 40% of its available context over 36 hours, while Fable 5 used about 26% in roughly half the time.
- Judged purely on cost versus quality gap, the builder concluded Fable 5 won this test, since the extra $700 spent on Fable 5.1 didn’t buy a proportionally better app.
Everyone else built a construction worker.
We built the contractor.
One file at a time.
UI, API, database, deploy.
How was the test set up?
The builder gave both agents a single, detailed prompt with one difference: which model it was told to act as. Everything else, including the goal, scope, and constraints, was identical word for word.
The prompt explicitly told each agent to act as an orchestrator, not an implementer. It was instructed to own strategy, planning, delegation, sequencing, quality standards, and final acceptance, but not to personally perform coding, debugging, testing, or design work. Instead, it was told to delegate execution to worker agents: Opus models for architecture, product direction, and hard problem-solving, and Sonnet models for implementation, research, testing, and iteration. The agent was also told not to stop at a “plausible” implementation, but to keep orchestrating until it had objective evidence the product actually worked and was presentation-ready.
The target app was “Ops Flow,” a local-first visual automation studio for designing and rehearsing incident response workflows. It’s not a general workflow automation platform. It’s meant to let someone visually draw out an emergency response plan as a flowchart, then simulate how that plan plays out step by step, including triggers, conditions, actions, approvals, and resolutions.
What did the two apps actually look like?
Both builds produced a working node-based canvas where users could drag in blocks (trigger, condition, action, approval, resolution), connect them, and run a live simulation showing which paths executed, which were skipped, and how the incident resolved.
The two implementations differed in small but telling ways:
- Connection rules. In one version, a single trigger could only feed into one downstream node before throwing a “connection refused” error. The other allowed more flexible branching without that restriction.
- Visual style. One build used rounded, color-blocked cards that read as distinctly AI-generated in style. The other had a cleaner, flatter look that the builder preferred at first glance.
- Zoom behavior. One version kept node labels at a consistent size when zooming in or out. The other let text grow as you zoomed in, which the builder felt looked “cheap” compared to the more consistent version, though he noted this is partly a matter of taste.
- Run feedback. One version handled a rejected approval step by correctly failing the run. The other, in at least one test, kept progressing down the “true” path even after a rejection, a meaningful logic gap for an app whose entire purpose is accurately simulating incident response.
- Import compatibility. The two apps used different JSON schemas for importing workflows. A file that loaded fine in one version produced an empty canvas in the other, even though both were built from the same spec.
After testing blind, it turned out the cleaner-looking, more consistent-zoom version was Fable 5, and the version with growing text and the rejection-handling bug was Fable 5.1.
How did an independent review score the two apps?
Plans first. Then code.
Remy writes the spec, manages the build, and ships the app.
To reduce personal bias, the builder had Codex test both apps without knowing which model built which, referring to them only by local port numbers. Codex scored Fable 5.1’s build at 9.1 and Fable 5’s build at 8.4, a gap of 0.7 points.
Codex favored Fable 5.1 for visual design and hierarchy, first-run ease of use, workflow authoring, dry-run experience, and validation and safety, though several categories were rated as very close. On the other hand, Fable 5 was praised for deeper authoring controls, a clear autosave timestamp, useful negative test presets (like a “missing severity” case), and an accurate live preview tied to the current payload. Fable 5.1 also got credit for stronger run summaries, downloadable run logs, and clear visual states for succeeded, failed, skipped, and waiting nodes, though it was flagged for the rejection-handling issue where a declined approval didn’t properly fail the run.
Was the cost difference worth it?
This is where the test gets interesting for anyone budgeting agentic builds. Fable 5.1 cost a little over double what Fable 5 cost and took roughly three times as long to finish, a gap the builder said he wasn’t expecting going in.
The token and model-usage breakdown helps explain both the cost and the time difference. Fable 5.1 routed about 57% of its work through Opus workers, about 40% through Sonnet, and only about 3% through the orchestrator itself. Fable 5, by contrast, sent about 80% of its work to Sonnet workers, with Opus and the orchestrator splitting the remainder. Since Opus is the more expensive, slower model in this setup, Fable 5.1’s heavier reliance on it lines up directly with its higher bill and longer runtime.
Context window data reinforced the efficiency gap. Fable 5.1’s session used about 404,000 tokens of context (roughly 40% of what was available) over about 36 hours. Fable 5’s session used about 260,000 tokens (about 26% of context) in roughly half a day.
The builder’s conclusion: Fable 5’s app was close enough in quality that spending an extra $700 to get Fable 5.1’s version didn’t seem justified. He was careful to frame this as a result specific to this build and delegation setup, not a blanket claim that Fable 5 is the stronger model. In fact, he noted that for general day-to-day work, he’s found Fable 5.1 to feel more efficient and better at understanding intent. But for this particular orchestration-heavy app build, cost and time favored Fable 5, and the quality difference wasn’t large enough to offset that gap.
Frequently Asked Questions
What app did Fable 5 and Fable 5.1 build in this test?
Both agents built “Ops Flow,” a local-first visual automation studio for designing and simulating incident response workflows, essentially a flowchart tool that lets users visually plan and rehearse what happens when a system goes down.
Why did Fable 5.1 cost more than Fable 5?
Fable 5.1 routed a much larger share of its work through Opus workers (about 57%, versus roughly 12% or less for Fable 5), while Fable 5 relied on the cheaper Sonnet model for about 80% of its tasks. That model mix is the main driver behind Fable 5.1’s higher cost and longer runtime.
Which app had better UI quality?
Remy is new. The platform isn't.
Remy is the latest expression of years of platform work. Not a hastily wrapped LLM.
It was close, and partly a matter of taste. The build that turned out to be Fable 5 had a cleaner visual style and kept node labels a consistent size when zooming. The Fable 5.1 build had stronger run summaries and clearer visual run states, but its text grew when zoomed in, which the builder found less polished.
Did either version have bugs?
Yes. The Fable 5.1 build had an issue where rejecting an approval step didn’t properly fail the simulated run, instead continuing down the “true” path in at least one test. The Fable 5 build was noted for having useful negative test presets and more accurate live previews.
Which model won the test overall?
Based on cost, build time, and the final quality gap, the builder concluded Fable 5 was the better value in this specific scenario, since Fable 5.1’s app wasn’t meaningfully better despite costing roughly $700 more and taking about three times as long to build.
