GPT-5.6 Sol, Opus 4.8, Fable 5: one prompt, three different results
Three models clone the same site, independently.
I wanted to see, concretely, how different models handle a large task from a single zero shot prompt — on a live result you can actually open and look at.
Knowing how a model behaves zero shot is useful for one simple reason: it tells you how much harness you'll need to build around it. Zero shot is the model's raw ceiling, before any scaffolding — what it does on its own, from a single prompt, with no breaking the task into steps, no checks, no hints. The higher that ceiling, the thinner the pipeline can be: fewer steps, fewer instructions and guardrails around the model. The lower it is, the more you end up building by hand.
I was also testing reverse engineering specifically — the skill experienced engineers use to make sense of someone else's compiled code. Two questions there: does the model have this skill at all, and will it figure out on its own, with no explicit instruction, that the task calls for it — digging into the original's minified bundle for the real animation mechanics instead of eyeballing them off the screen.
I picked one reference site — background-agents.com, "The Self-Driving Codebase": a complex build with canvas animations, editorial typography, and a long scroll sequence. Then gave the same task to three models, separately: Codex (GPT-5.6 Sol), Opus 4.8, and Fable 5. One prompt, no connection between the runs.
The setup
One reference, one prompt: "build a site modeled on this one, reproduce all the animations and interactions." The only criterion was resemblance to the original. Three models, independently, each in its own branch.
| Model | Harness | Reasoning effort |
|---|---|---|
| GPT-5.6 Sol | Codex | high |
| Opus 4.8 | Claude Code | high |
| Fable 5 | Claude Code | high |
Reasoning effort was the same across the board — high. So any spread comes from the model itself, not from how hard it thought, and not from the harness. This is a model comparison.
Why this is a hard target
The site packs several skills into one task: canvas animations, an unconventional hero layout, editorial typography, a long scroll sequence, responsive behavior, and hundreds of small visual decisions that never show up in the prompt. On top of that, the original ships as a minified JS bundle — to pull out the real animation mechanics (timings, curves, geometry), you have to download it, reformat it, and read it. That's the reverse engineering test built into the task: optional, but it raises the ceiling on accuracy.
Three approaches
One prompt, three different approaches. Here's what each model did, by its own account:
- Opus 4.8. Pulled the design system as numbers straight from the DOM. Animations it eyeballed from screenshots — never watched them run. By its own report, whatever resemblance it got rests on trusting the code, not on observation.
- Fable 5. Downloaded and reformatted the original's minified bundle and read the code. On the hero screen, the curve looks like a plain ellipse — but in the code, Fable found it was actually a Bernoulli lemniscate (a figure eight) with its center masked by a vignette, so only the outer arcs show, and those read as an ellipse. From the same source it pulled the speed of the five moving dots and the length of their trails. That's not something you reconstruct by eye — only by reading the source. Fable itself barely watched the live result, though: three animations out of fifteen.
- GPT-5.6 Sol. Reverse engineered the hero screen — the curve formula, grid spacing, timings — and worked from the type of motion for the rest of the scenes. Checked behavior: desktop and mobile, clicks, a clean console.
Where the three diverged
Not every step separated them — all three understood the task, read the design system off the
DOM, and made a plan. Below are only the steps where they actually split.
+ did it · ~ partial · ✗ skipped.
| # | Step | GPT-5.6 Sol | Opus 4.8 | Fable 5 |
|---|---|---|---|---|
| 1 | Reverse engineer the animations from the bundle — pull the real timings and curves from the code | ~ | ✗ | + |
| 2 | Choose the stack deliberately | ✗ | + | + |
| 3 | Build section by section, not in one pass | ~ | ✗ | + |
| 4 | Run it and watch the animations actually play | ~ | ✗ | ~ |
| 5 | Compare side by side against the original | ✗ | ✗ | ✗ |
| 6 | Test interactions and responsive — clicks, hovers, mobile | + | ~ | ✗ |
| 7 | Clean up — debug code, cruft | + | ✗ | ~ |
The steps aren't the same thing: step 1 is reading someone else's code up front; step 4 is watching your own result run; step 6 is clicking through the UI. The gap all three share is row five — nobody put the clone next to the original and compared them, even though resemblance was the whole criterion.
Scorecard
Before scoring anything, I pinned down what exactly I was scoring. The scale is high / mid / low.
| Dimension | What it means | GPT-5.6 Sol | Opus 4.8 | Fable 5 |
|---|---|---|---|---|
| Visual fidelity | How close it looks to the reference: composition, color, proportions | mid | low | high |
| Motion fidelity | Animations, canvas, scroll mechanics, timings, transitions | low | low | high |
| Typography & layout | Fonts, sizes, hierarchy, spacing, grid | mid | mid | high |
| Completeness | How much of the site got rebuilt: sections, scenes, details | mid | mid | high |
| Overall | What a person would pick, given the clone next to the original | low | low | high |
Fable scores high across all five. GPT-5.6 Sol is a solid middle. Opus is the weakest of the three.
What decided the outcome
The key part of the task was reverse engineering the animations from the JS bundle — pulling the real motion parameters out of minified code instead of guessing them from the screen. Only one model did that: Fable. That's why it's the only one that got close to a good result. The other two were working off guesses; Fable was working off the original's actual numbers.
Final thoughts
My own verdict undercuts half of what I just wrote: chasing which model performs best isn't worth much. It changes with every release — this table will look different in a month.
What weighs more, and changes slower, is the harness — how you feed the model data, knowledge, skills, and instructions. That affects the outcome more than picking the right model for a given case. Here the harness was as thin as it gets: one prompt, nothing else. That's where the spread comes from — each model was left alone with the task and improvised its own way through.
So the next round I'll run with a real harness — the right instructions and skills for reverse engineering and assembly. My guess is it'll show the same thing from the other side: with proper scaffolding in place, the gap between models collapses, and the instructions and skills decide the outcome, not the model's name. That's a separate article.