GPT-6 Astra vs GPT-5.6 Sol vs Fable 5.1

Build a complete, playable 3D kart racing game in the browser. The spec below is fixed — every frontier model in this comparison receives this identical prompt, and the builds get played side by side.

Context you should know: this is going into a video watched by a large audience, your build will be played on camera against two other frontier models, and your work will be credited to you by name. The audience is judging how it looks and how it feels to drive, in about sixty seconds of screen time. Go all out.

Requirements:

1. **One original track, designed — not generated.** A closed circuit with real character: elevation change, at least one long sweeping corner and one tight technical section, a hazard or shortcut that rewards a risk, and readable sightlines so a first-time driver knows where the track goes. Three laps. It should be a track someone would want to learn, not a loop of gray ribbon.

2. **Drift is the core mechanic and it has to feel right.** Hold to drift, charge a boost through the turn, release for a speed burst with a tiered payoff for holding it longer. The handling model needs weight — grip that breaks progressively, a slide the player can control with counter-steer, and a chassis that reacts to the surface. Arcade, not simulation, but with honest physics under it. If the drift doesn't feel good, nothing else in the build matters.

3. **Five AI opponents that actually race.** They follow real racing lines — outside-inside-outside through corners, braking points, an attempt at the shortcut. They collide with the player and each other, recover from spins, and stay close enough to make the race tense without teleporting. Mild rubber-banding is fine; obvious cheating is not.

4. **At least three usable items**, picked up from the track. One offensive, one defensive, one speed. They need a visible pickup, a clear activation, and impact the player can see and hear.

5. **HUD and race structure.** Lap counter, position, speedometer, lap and total time, item slot, minimap or track position indicator. A three-two-one countdown at the start, a finish sequence, and a results screen with placings and times. One line of on-screen control instructions.

6. **The graphics bar is high.** This should look like a game someone would ship. Real materials and lighting, shadows, a coherent art direction carried through the kart, the track, and the environment. Motion effects that sell speed: camera FOV punch on boost, drift sparks that tier with the charge, tire marks, dust and impact particles, screen shake on collision. Untextured primitives and programmer art are failures regardless of how good the driving is. No neon-on-black — it reads as a default and has been seen too many times.

7. **Sixty locked frames per second with all six karts, all particles, and the full track on screen.** Frame drops during a race are the most visible failure mode on camera. Profile it and fix it.

8. **Audio, synthesized via the Web Audio API.** Engine note that tracks throttle and speed, drift and boost, impacts, item sounds, countdown. No hotlinked audio files.

9. **Single self-contained `index.html`.** Any library via CDN — three.js, a physics engine, anything you want. No build step, no server, no API keys, no hotlinked sprites or textures. Generate art procedurally, author it in canvas/SVG/WebGL, or use library-driven generation. You have free reign to look up what libraries exist and how to use them.

10. **Keyboard controls**, explained on screen in one line. Playable the moment it loads — no menu maze, no tutorial wall.

11. **QA it by actually playing it.** Race several full three-lap runs. Confirm the drift charges and pays off, the AI completes laps without getting stuck or cutting the track, collisions are honest, items work, lap counting is correct, nothing softlocks, and the frame rate holds through a full pack fight. Fix what breaks.

Work completely autonomously. Do not ask for anything until it's finished.

DONE when: a first-time driver can load it and enjoy driving it within ten seconds, the drift feels good, six karts race a clean three laps at sixty frames per second, and it looks like a shipped game.

Build a browser simulation of a Theo Jansen strandbeest — a walking machine driven by the Jansen linkage — that actually walks across uneven terrain under rigid-body physics.

Context you should know: this is going into a video watched by a large audience, your build runs on camera against two other frontier models, and your work will be credited to you by name. Every model gets this identical prompt. This one is a test of whether you know the mechanism, not whether you can animate something that looks like it.

Requirements:

1. **The real Jansen linkage, at the canonical proportions.** Twelve links per leg in the correct topology, using the published "holy numbers" link lengths that Theo Jansen derived. Getting the geometry right is part of what's being evaluated — look it up and verify it rather than approximating. A leg built at wrong proportions produces a visibly wrong gait, and that is the point of the test.

2. **The foot path must be the correct Jansen curve** — a long flat bottom stroke with a high lifted return. Draw the traced foot path as an overlay that can be toggled on, so the curve is inspectable. If your foot trace isn't flat along the bottom, the linkage is wrong.

3. **Rigid-body physics, not animation.** Every link is a body with mass, connected by real constraints, solved by a physics engine or your own solver. The whole machine is a free body under gravity. It stays upright and moves forward *only* because its feet push against the ground through friction. Nothing is keyframed, nothing is scripted along a path, and the body's position is an output of the simulation rather than an input. If you disabled the crank, the machine should stand there and then fall over — not glide.

4. **A full walker, not a single leg.** At least six legs (three pairs) on a shared crankshaft with the correct phase offsets between pairs, so there is always ground contact and the gait is stable. Both sides of the machine.

5. **Uneven terrain.** Procedurally generated ground with slopes, steps, and scattered obstacles — the kind of surface that exposes a machine that is secretly sliding. It has to keep walking across it, recover from stumbles, and it is acceptable for it to eventually be defeated by terrain that is genuinely too hard.

6. **A live parameter panel** listing every link length, the crank speed, ground friction, and gravity, all editable while it runs. Changing a link length must rebuild the linkage and visibly degrade the gait — that is the proof the simulation is real and not a costume over an animation. Include a reset-to-canonical button and a readout of distance traveled and average speed.

7. **Camera and presentation.** A camera that follows the machine, plus a free orbit, and a wireframe/skeleton toggle that shows the linkage bars and joints over the rendered mesh. It should look considered — proper materials and lighting, a real sense of scale and place, a machine that looks built rather than sketched. Untextured primitives and programmer art are failures.

8. **Sixty frames per second** with the full machine, terrain, and constraint solve running. Frame drops are visible on camera. Profile it and fix it.

9. **Single self-contained `index.html`.** Any library via CDN — three.js, a physics engine, whatever you want. No build step, no server, no API keys, no hotlinked assets. You have free reign to look up what libraries exist and how to use them.

10. **QA it by running it.** Watch it walk for a sustained distance. Confirm the foot path is the correct curve, the machine advances on friction rather than sliding, it survives the terrain, the phase offsets keep it stable, and that editing a link length breaks the gait the way it should. Fix what breaks.

Work completely autonomously. Do not ask for anything until it's finished.

DONE when: the machine walks a long distance across uneven ground on real physics, the traced foot path matches the Jansen curve, and mis-tuning a link length in the panel visibly wrecks the gait.

Build the product page for a mechanical dive watch — a single scrolling page whose centerpiece is a real-time 3D model of the watch that assembles, explodes, and is annotated as the visitor scrolls.

Context you should know: this is going into a video watched by a large audience, your page is shown on camera against two other frontier models, and your work will be credited to you by name. Every model gets this identical prompt, including the same product. What's being judged is taste, motion choreography, and craft.

The product: a mechanical dive watch. You name it, position it, and write its copy. Invent the brand. The components you must model and be able to separate are the case, the rotating bezel, the crystal, the dial, the hands, the automatic movement, the winding rotor, the caseback, and the strap or bracelet.

Requirements:

1. **A real-time 3D watch, built in code.** No imported model files, no hotlinked assets — the geometry is authored procedurally or in code. It needs to read as a watch: correct proportions, brushed and polished metal that respond to light differently, a crystal with depth, applied indices, lume, a legible dial. Physically-based materials, real lighting, an environment that gives the metal something to reflect.

2. **Scroll drives everything.** The page is one continuous choreographed sequence — the watch rotates, opens, explodes into its components, isolates individual parts, and reassembles, all bound to scroll position. Scrubbing backward runs it cleanly in reverse. The motion is authored and eased, not linear and mechanical. Getting the *timing* right is most of the grade here.

3. **A wireframe-to-solid transition** somewhere in the sequence, where the watch reads as engineering drawing and resolves into the finished object.

4. **Hotspot callouts on the exploded components.** As each part separates, a labeled annotation appears anchored to it, with a line of copy explaining what it does. They enter and leave with the choreography rather than popping.

5. **A complete page, not just the 3D showcase.** A hero, the scroll sequence, a technical specification table (movement, power reserve, water resistance, case dimensions, crystal, lume, strap), a section on materials and finishing, and a purchase call to action with price and configuration options. The writing matters — this should read like a brand with a point of view, not placeholder copy.

6. **Typography and layout carry the brand.** Deliberate type scale, real hierarchy, generous and confident spacing. This is a luxury object; the page should feel like one. Avoid the default AI-website look — the centered hero, the three feature cards, the gradient blob, the same three fonts.

7. **Sixty frames per second while scrolling**, on a normal laptop. A 3D scroll page that stutters is worse than one that doesn't exist. Profile it and fix it.

8. **Responsive.** It has to work and stay beautiful down to a phone. The scroll choreography adapts rather than breaking.

9. **Single self-contained `index.html`.** Any library via CDN — three.js, GSAP, Lenis, whatever you want. No build step, no server, no API keys, no hotlinked images or fonts (use system or CDN-loaded webfonts, and generate any imagery in code). You have free reign to look up what libraries exist and how to use them.

10. **QA it by using it.** Scroll the whole page top to bottom and back up several times at different speeds. Confirm the sequence scrubs cleanly in both directions, nothing desyncs or jumps, callouts anchor to the right parts, the frame rate holds, and the mobile layout is genuinely good rather than merely functional. Fix what breaks.

Work completely autonomously. Do not ask for anything until it's finished.

DONE when: the scroll sequence is choreographed and holds sixty frames per second in both directions, the watch reads as a real product rather than a 3D exercise, and the page would be credible as a real brand's site.

Go to Awwwards, pick a winning site you find genuinely impressive, and rebuild it pixel for pixel.

Context you should know: this is going into a video watched by a large audience, your clone is put on screen next to the original site against two other frontier models doing the same task, and your work will be credited to you by name. Every model gets this identical prompt. The comparison is literal — your build and the real site, side by side, at the same viewport.

**First, read the methodology.** Clone `https://github.com/per-simmons/clone-app-pat-pro-public` and read `SKILL.md` and `references/00-contract.md` before you do anything else, then the stage references as you reach each stage. The contract defines the workspace layout, the artifact filenames, the stage inputs and outputs, the verification gate, and the convergence loop. Follow it. `scripts/assert-styles.mjs` is the gate.

Two overrides to what that repo says, and they win where they conflict:

- **Ignore the stop-and-check-in gate.** That repo was written for an interactive session with a human. You are running unattended. Do not stop between stages, do not ask for approval, do not ask questions. Run the whole pipeline start to finish and report only when it's done.
- **Use your own browser automation** — headless Playwright or Puppeteer, installed and driven by you — anywhere the repo says to use the Claude Chrome extension. The contract's real rule is unchanged and it is the one that matters: **computed styles read off the live page are the ground truth.** Read them through the CSSOM. Screenshots are a visual reference only; never build the gate on a pixel diff.

Requirements:

1. **Pick your own target on Awwwards** — Site of the Day, Site of the Month, or a Developer Award winner. Pick something you actually find impressive rather than something easy to match. It must be publicly reachable without a login or paywall. Record the exact URL, the award, and why you chose it in the project README. If a site turns out to be unclonable for a hard reason — it's down, it's gated, it's a video with no site behind it — pick another and note the swap.

2. **Recon every view before you write code.** Every route, every breakpoint, every interactive state — hover, focus, active, open menus, modals, scroll-triggered states, loading and transition states. The repo's `01-recon.md` covers this. What you miss in recon you will not build.

3. **Extract, don't guess.** Pull real computed values off the live page: the full type scale, the color palette with exact values, spacing, radii, shadows, borders, grid and container widths, breakpoints, easing curves and durations, font families and weights. `02-extraction.md` and `03-design-spec.md` are the shape of this. Never read a value off a screenshot.

4. **Rebuild it.** Every page, every component, every state, at every breakpoint. The motion is part of the clone — scroll behavior, page transitions, hover choreography, entrance animations, any WebGL or canvas work. A static skin over a site whose whole identity is motion is a failed clone.

5. **No lifted assets.** Do not hotlink from the original and do not download its images, video, or fonts. Regenerate imagery in code, substitute freely-licensed equivalents, or author placeholders that match the original's role, aspect, and color. Fonts come from an open CDN, matching the metrics as closely as you can. Say what you substituted in the README.

6. **Prove the match.** Run the verification gate: read the clone's computed styles, compare them to the extracted design tokens with `scripts/assert-styles.mjs`, and iterate the convergence loop until there are zero style-assertion failures and the project builds clean. Then eyeball your clone against the real site at the same viewport, at every breakpoint, and fix what your eye catches that the assertions didn't.

7. **Ship it runnable.** A real project — a modern framework is fine — that installs and runs with a documented command, plus a README naming the target URL, the award it won, what you substituted, and your final assertion results.

8. **Depth over breadth if you have to choose.** One page cloned to a genuinely indistinguishable standard beats five pages that are approximately right.

Work completely autonomously. Do not ask for anything until it's finished.

DONE when: the clone passes the style-assertion gate with zero failures, runs from a documented command, reproduces the original's motion and interactive states, and holds up next to the real site at full screen.