Fable 5 vs Opus 4.8: Three One-Shot App Builds and the Real Cost

Pat Simmons gave Claude Opus 4.8 and Claude Fable 5 the same three application briefs: a 30-product candle store, an interactive 3D art-history museum, and an Age of Empires-style browser game. Each model received one build pass, the results were deployed, and Pat reviewed what actually worked.

Fable 5 won all three in Pat's evaluation. The useful conclusion is not simply "Fable is better." It is that Fable produced more complete first-pass outcomes on exactly the kind of visual, ambiguous, long-running tasks Anthropic built it to handle. The premium was real too.

Video, prompts, build runs, tracker figures, and hands-on verdict credit: Pat Simmons. Connect with Pat on LinkedIn.

Source Note

Pat's supplied transcript is the source for the prompts, timings, token readouts, tracker estimates, interactions, and qualitative judgments in the three builds. The numbers are creator-reported session estimates from Pat's tracker, not audited Anthropic invoices. The transcript collapses the decimal in the first Opus estimate; the spoken figure is treated here as approximately $21.41, alongside Pat's clearly stated $36.84 Fable estimate.

Official Anthropic documentation is the factual source for model pricing, context, output limits, data retention, adaptive thinking, safety refusals, and the behavioral differences between Fable 5 and Opus 4.8. Current standard API pricing is $10 input and $50 output per million tokens for Fable 5, versus $5 input and $25 output for regular Opus 4.8.

"One-shot" needs a qualifier. Pat did not run repair prompts after seeing the deployed results, but both models asked design-direction questions and received matching answers. The museum build also included a copyright discussion about modern artworks. These are valuable one-pass creator tests, not sealed laboratory benchmarks.

Link Map

Raw Scoreboard

Build 1: A 30-Product E-Commerce Store

The fictional brand was Slowburn, a small-batch candle company. The brief asked for a production-quality Shopify-style experience with 30 distinct products, visually different product imagery, readable text, clear labels, and working commerce interactions. Both models were also asked to propose design directions.

What Opus 4.8 produced

Opus improved on Pat's earlier dynamic-workflow test. Product labels were readable, the catalog had multiple categories, product pages opened, the cart drawer worked, and basic hover motion was present. The weaknesses were product-level UX and art direction: text overlapped the hero image, the category treatment felt scattered, the navigation behavior was confusing, and the generated imagery felt less coherent.

What Fable 5 produced

Fable created a more convincing store on the first pass. Pat highlighted the announcement strip, cleaner hero hierarchy, rotating product notes, stronger calls to action, more coherent image prompts, better product filters, polished product cards, a three-step usage section, and a stronger footer. It was not only prettier; the information architecture felt more like a familiar commerce product.

Pat estimated about 35 minutes for Fable and roughly 50 minutes for Opus. His tracker showed approximately $36.84 for Fable and $21.41 for Opus. Fable cost more, but Pat considered the difference in completeness decisive.

Build 2: An Interactive 3D Art Museum

This was the strongest architecture test. The app needed an infinite art-history timeline, periods and artists, Wikipedia data, a Neon database, hundreds of public-domain paintings, and realistic Three.js galleries with lighting, navigation, placards, zoom, and interaction.

Copyright became part of the run. Opus correctly raised a public-domain constraint for modern artists such as Picasso and Dali. Pat pushed back, then accepted the restriction and continued with public-domain material. That was a useful result: a model that refuses an unsupported asset source may be protecting the product from a future rights problem.

Opus had a good map and a broken doorway

Opus produced Pat's best art-history timeline from a model up to that point. The color-coded periods and zoom behavior were promising. But the canvas movement and click behavior conflicted, so Pat could not enter artist galleries. The central user path failed despite a visually plausible overview.

Fable completed the actual journey

Fable assembled 16 periods, 69 artists, and 767 paintings in the database. It found data edge cases such as the Wikipedia title for Francis Bacon the artist, delegated work across agents, tested zoom and movement, noticed its own dark floor and lighting issue, and continued correcting the experience. Pat could enter a gallery, inspect art, and navigate the space.

The Fable run took about 30 minutes; Opus was still working around 43 minutes. Pat's tracker reported 51,000 input and 437,000 output tokens for Opus, with an estimated cost around $46. For Fable it showed 54,000 input and 280,000 output tokens, with an estimated cost around $64. Fable used fewer reported output tokens but still cost about 37 percent more in the tracker.

That is cost per token versus cost per completed path in one table. Opus was cheaper but failed the core gallery interaction. Fable was more expensive but delivered the journey Pat asked to test.

Build 3: An Age of Empires-Style Strategy Game

The final prompt asked for a fully playable real-time strategy game in a realistic 3D browser world: a town center, resources, units, building, enemies, attacks, map movement, lighting, and a core civilization loop.

Both runs were similar in duration: about 33 minutes for Opus and 30 minutes for Fable. The outcome was not similar.

Opus rendered a world and controls, but Pat could not move around the map, zoom correctly, place buildings reliably, or reach a functioning game loop. He judged the app broken. Fable delivered a navigable map with a civilization, selectable units, buildings, farms, resources, enemies, and working placement interactions. Pat did not exhaustively validate balance or combat, but the prototype behaved like a game rather than a scene.

This is the clearest example of why visual quality alone is a poor agent benchmark. The winning signal was not a cinematic screenshot. It was whether movement, selection, building, and resource constraints formed a usable loop.

The Cost Question

Fable is exactly twice the regular Opus token price. That does not automatically make it twice as expensive per finished task. If Opus requires two repair passes, an hour of human debugging, or a second model review, Fable can be cheaper in practice. The opposite is also true: paying Fable rates for a task Sonnet completes cleanly is waste.

Track the whole unit of work:

• model and effort setting;
• input, output, cache writes, and cache reads;
• tool and image-generation costs;
• elapsed time and retries;
• human review and repair minutes;
• accepted or rejected outcome.

Why Fable Won This Particular Test

Anthropic's official prompting guide describes the same behaviors Pat observed. Compared with Opus 4.8, Anthropic says Fable improves long-horizon autonomy, first-shot correctness on complex specified problems, vision, ambiguity handling, code review, and delegation across parallel subagents.

Pat's tasks combined all of them:

• the store required visual taste, image prompting, product structure, and many repeated assets;
• the museum required API research, data cleaning, rights constraints, database design, 3D interaction, and testing;
• the game required a coherent world, input handling, entity state, resources, enemies, rendering, and a playable loop.

The comparison therefore tells us something useful but narrow: when the task is broad enough to need planning, parallel work, visual inspection, and persistent self-correction, Fable's premium can buy a materially better first pass.

What This Test Does Not Prove

• No repeated runs: one result per model cannot measure variance or reliability.
• No blind scoring: Pat knew which model built each version and reviewed visual taste subjectively.
• Harness effects: tool availability, Cursor integration, subagents, browser testing, image generation, and model effort all affect the outcome.
• Clarification turns: both models asked design questions, so this was not a sealed single-message test.
• Third-party model effects: GPT Image 2 contributed much of the store's product imagery.
• Incomplete QA: no shared automated test suite checked checkout, data integrity, every museum route, or the full strategy-game loop.
• Tracker estimates: subscription telemetry and an estimated API equivalent are not the same as a final API bill.

A Better Production Test

Keep the same-prompt idea, but define acceptance before either model starts. A stronger harness would look like this:

Build the application from the attached specification.

Before finishing:
1. Map every required user path to an automated browser test.
2. Test keyboard, pointer, mobile, empty, loading, and error states.
3. Verify every progress claim against a tool result from this run.
4. Save screenshots and logs for each accepted path.
5. Do not call the task complete while any required test fails.
6. Report elapsed time, model usage, tool costs, unresolved defects,
   and any requirement you skipped or changed.

Run each model three times in clean repositories. Use the same tools, effort, context, timeout, and credentials. Ask a reviewer who does not know the model identity to score functional completion, visual quality, defects, maintainability, accessibility, latency, cost, and repair time.

That test is less entertaining than a reveal video. It is much better for deciding what belongs in a production route.

How Builders Should Route the Models

1. Start with Sonnet 5 when the task is routine, bounded, and easy to verify.
2. Move to Opus 4.8 when architecture, difficult debugging, review, or higher judgment is the bottleneck.
3. Use Fable 5 when the task combines ambiguity, long duration, visual understanding, many tools, and parallel subagents.
4. Escalate by evidence: route upward after a cheaper model fails an acceptance test, not because the project sounds important.
5. Keep fallback logic: Fable can return a refusal for safeguarded domains; applications need a documented Opus fallback and user-visible status.
6. Check retention: do not send zero-retention workloads to Fable, which requires 30-day data retention.

Bottom Line

Fable 5 dominated Pat Simmons' three raw app builds. It produced the stronger store, the museum with a working gallery path, and the only strategy-game prototype that Pat could meaningfully navigate and use. It was usually faster in these runs and more complete on the first pass.

It also cost more, and the experiment leaned directly into Fable's strongest territory. The practical conclusion is disciplined rather than dramatic: keep cheaper models for ordinary work, reserve Fable for the builds where visual judgment, orchestration, and long-horizon completion decide whether the task succeeds at all, and verify every result with a test suite before calling it production-ready.

Sources

• Pat Simmons: I Made Opus 4.8 and Fable 5 Build the Same App - Raw Results
• Pat Simmons on YouTube and LinkedIn
• Anthropic: Introducing Claude Fable 5 and Claude Mythos 5
• Anthropic: Introducing Claude Opus 4.8
• Claude Platform pricing
• Anthropic: Prompting Claude Fable 5
• Anthropic: Migrating from Opus 4.8 to Fable 5