GPT-5.6 Sol vs Fable 5: Three Identical App Briefs and the Raw Results

Pat Simmons gave GPT-5.6 Sol and Claude Fable 5 the same three ambitious briefs: reconstruct a sophisticated mockup tool, invent an original viral product drop, and build an interactive New York City learning platform.

Sol won Pat's overall comparison. The important result is more specific: Sol showed stronger interface fidelity, interaction design, and instruction following. Fable remained competitive when the task rewarded information density and when it received direct feedback about the experience.

Video, prompts, build runs, deployed demos, timing notes, session-cost estimates, and qualitative verdict credit: Pat Simmons. Follow Pat on X, LinkedIn, or visit PerSimmons Studio.

Source Note

The observed outputs, runtimes, failures, revisions, and winner come from Pat's supplied transcript. Official model positioning and token prices come from OpenAI and Anthropic. The description of the reference product comes from Shots. This article does not reproduce proprietary code or assets and does not endorse deploying a competing clone.

Link Map

How the Comparison Worked

Pat ran Sol at high reasoning in the new ChatGPT/Codex app and Fable at high effort in Claude Code. Both received the same top-level brief and access to Pat's app-cloning skill where relevant. The intended rules were one build pass, no repairs, and a live deployment.

The execution drifted from a strict one-shot test. During the Shots run, Sol requested explicit continuation to move from extraction into later phases. In the NYC test, Pat gave both models a second prompt asking for a more immersive 3D experience. That revision is still valuable, because it tests response to feedback, but it should be scored separately from first-pass performance.

• What was controlled: top-level task, broad intent, reviewer, and output format.
• What was not controlled: harness, tool behavior, hidden system instructions, token budget, continuation behavior, deployment environment, and cost instrumentation.
• What was subjective: visual taste, creativity, usefulness, and the final winner.
• What was directly observable: runtime, visible features, broken interactions, information coverage, and whether the deployed app worked during review.

The Raw Scorecard

Build 1: Reconstructing the Shots Experience

Shots is a mature mockup editor, not a simple landing page. It includes device frames, media upload, animated mockups, video zoom, layouts, styles, shadows, lighting, watermarks, backgrounds, effects, custom sizes, and export controls. That makes it a demanding test of reconnaissance, visual hierarchy, state, interactions, and rendering.

Fable finished in roughly 30 minutes. Its app could upload an image, change backgrounds, adjust some radius and tilt settings, and switch canvas dimensions. Pat found the result usable but far from feature parity, especially around realistic device mockups and the breadth of the control panel.

Sol took roughly 2 hours and 51 minutes. It spent much longer on extraction, design specification, architecture, QA, and polish. The result was visibly much closer to the reference and included a far broader control surface: upload, device presets, layout grids, lighting, shadows, backgrounds, effects, watermark text, and even an animation timeline.

The fidelity was not complete. Some presets did nothing, device assets were missing or malformed, text could not be positioned properly, watermark and stage controls were inconsistent, and the animation editor was only partly functional. Sol won the build, but "nearly identical" applied more to the visible shell than to every behavior.

The Pixel-for-Pixel Cloning Boundary

This section matters. Shots' terms state that its software, designs, trademarks, and service content are protected intellectual property. The terms also prohibit reverse engineering, attempting to extract source code, scraping, bulk downloading, and infringing commercial use.

The responsible exercise is reference-based interface analysis: inventory public states, identify interaction patterns, and build an original implementation with your own brand, assets, code, and product decisions. Do not copy source code, private endpoints, copyrighted assets, trademarks, or a confusingly similar commercial presentation.

Build 2: Inventing a Viral Drop

The second brief tested invention rather than copying. Each model had to study the pattern behind MSCHF's catalog, generate at least ten concepts, choose one, and build the full drop experience.

Sol: Human Resources

Sol built a satirical labor-and-CAPTCHA concept: users repeatedly prove they are human while producing labels that help machines automate future work. The experience included clocking in, selection tasks, fairness controls, consent text, a conveyor-belt visual, a completion certificate, and rejected concepts.

Pat found the idea difficult to explain, but the confusion also fit the strange institutional satire. The strength was the interaction density and consistency of the visual world. It behaved like a drop, not merely a page describing one.

Fable: The Free Shirt

Fable's concept made a shirt free while charging layers of fees. Removing a fee created another fee. The joke was legible and the receipt interactions worked, but the broader experience was mostly static and less surprising.

This round exposes an important tradeoff: clarity is not always the same as creative force. Fable communicated its idea faster; Sol built the more memorable and complete experience. Pat gave the round to Sol.

Build 3: A New York City Learning Platform

The third brief deliberately left the solution open. It asked for an interactive way to explore New York City from boroughs and neighborhoods down to buildings and landmarks, with facts drawn from Wikipedia and media from Wikimedia Commons. Every fact should pass the "I did not know that" test.

First pass

Fable produced the stronger content layer. It surfaced historical facts, borough and neighborhood paths, landmark pages, images, and a knowledge-graph-like structure. The user experience forced too many clicks and the interface looked generic, but there was more to learn.

Sol produced the more attractive first impression, with stronger motion and visual hierarchy. It covered fewer neighborhoods and landmarks, had awkward navigation, and did not resolve the core need for a deep learning environment. Pat preferred Sol's design but found both results disappointing.

Feedback pass

Pat then told both models the experience was too static and asked them to keep working until it became visual, immersive, and interactive. Fable created an orbitable city map with landmarks and stronger spatial context. Sol created a polished beacon-based 3D journey with images and controls. Both retained navigation, accuracy, and content problems.

This was the closest round. Pat leaned toward Fable's map while preferring parts of Sol's interaction design. The best product would combine Fable's information architecture and spatial overview with Sol's visual system and local interactions.

The Cost Breakdown Is Directional

Pat used subscription plans, not metered API invoices: a $100 ChatGPT plan and a $200 Claude Max plan. He found conflicting values in built-in usage commands and used additional session-analysis tooling to estimate API-equivalent cost. He explicitly said the numbers were "all over the place" and should be taken with caution.

The official rates are clearer. GPT-5.6 Sol is $5 per million input tokens and $30 per million output tokens. Claude Fable 5 is $10 input and $50 output. Fable's direct token rates are higher, but the total bill still depends on token volume, caching, tool calls, retries, harness overhead, and how long the agent keeps working.

Why Sol Won This Particular Test

• It followed long process instructions. The clone progressed through reconnaissance, specification, architecture, build, QA, and polish.
• It built denser interactions. Sol's viral drop felt like a product experience rather than a concept page.
• It showed stronger visual judgment. Pat preferred Sol's hierarchy, composition, motion, and fidelity in all three first passes.
• It spent more effort when the task justified it. The Shots build was dramatically slower and more expensive, but also dramatically more complete.
• It interpreted ambiguity productively. In the creative brief, Sol turned a loose idea into an unusual, coherent system of interactions.

This direction matches OpenAI's own positioning of GPT-5.6 around stronger design judgment, computer use, tool coordination, and long-running work. It does not independently validate OpenAI's benchmark claims; it provides one real-world example consistent with them.

What Fable Still Did Better

• Speed on the complex clone. Fable produced a usable partial editor in a fraction of Sol's time.
• Content coverage. The first NYC build contained more facts, pages, and a richer knowledge structure.
• Clearer creative premise. The free-shirt concept was less ambitious but easier to understand immediately.
• Response to direct feedback. Its revised NYC map was a large improvement and became Pat's preferred spatial overview.
• Potential manager role. Fable's richer content model could pair well with Sol as the interface and implementation worker.

A Better Model-Evaluation Template

# SAME-BRIEF MODEL EVAL

TASK:
Build one original product from the supplied brief and source packet.

CONTROL:
- Same files and reference screenshots
- Equivalent tool permissions
- Same time and token budget
- Same deployment target
- No hidden follow-up instructions

ACCEPTANCE TESTS:
- Critical user flow completes
- Required features work
- No console or server errors
- Mobile and desktop layouts pass
- Accessibility checks pass
- Data and citations are accurate
- No copied proprietary assets or source code

RUNS:
- Minimum 3 runs per model
- Record total tokens, wall time, tool calls, and failures

SCORE:
- Functional coverage: 30%
- Correctness and reliability: 25%
- Visual and interaction quality: 20%
- Repair and review time: 15%
- Cost per accepted result: 10%

STOP:
End at the shared budget. Do not give one model extra repair prompts.

For a visual product, include reference screenshots and state-by-state checks. For a content product, add source accuracy and coverage. For a production product, add security, observability, rollback, and maintainability. One scorecard cannot fit every workflow.

Practical Verdict

GPT-5.6 Sol was the better model in Pat Simmons' three-build comparison. It built the substantially better mockup editor, the more ambitious viral experience, and the stronger-looking first version of the learning platform. Fable made the NYC result competitive after feedback and remained useful where content depth mattered more than surface polish.

The purchasing decision is not "always use Sol." Use Sol when interface quality, interaction design, fidelity, and end-to-end persistence decide whether the result is useful. Use Fable when the task benefits from deep orchestration or richer synthesis and the higher token price is justified. Use cheaper models for routine implementation, extraction, and repetitive edits.

Sources

• Pat Simmons: I Made GPT 5.6 and Fable 5 Build the Same App - Raw Results
• Pat Simmons on YouTube, X, and PerSimmons Studio
• OpenAI: GPT-5.6
• OpenAI API: GPT-5.6 Sol model page
• Anthropic: Claude Fable 5 and Claude Mythos 5
• Claude Platform pricing
• Shots mockup editor and Terms of Service
• MSCHF project archive
• MediaWiki Action API and Wikimedia Commons API