How we test

The short version

• Every model gets the identical prompt, word for word. It is printed on every build page.
• One attempt each. No follow-up messages, no "try again", no picking the best of several runs.
• Each run starts in a fresh, empty folder with a clean environment and every user customisation switched off.
• Nothing the model delivers is edited. Broken builds are published broken, with their errors.
• A script records every build with the same scrolls, clicks and keystrokes. You can also open every build live.
• We never turn any of this into a score.

The briefs

Round 01 has four briefs chosen to cover the work developers most often hand to a model: a marketing website, a product interface, a physics simulation and a 3D game. Each brief fixes the content (product name, copy facts, prices, the dataset, the controls) so the differences you see come from how well each model executes, not from what it decided to make.

Builds must be a single index.html with no build step, so anyone can open them years from now. Network access at runtime is limited to Google Fonts for the two interface briefs, and to nothing at all for the simulation and the game. The game brief ships three.js r186 as a local file so every model has the same engine.

How each model is run

Each model runs inside its vendor's own coding agent, the way developers actually use it, with the reasoning effort shown below. The agent may run its own commands while it works (for example to open its page in a browser and check it); every agent has the same freedom.

The exact commands, with the prompt passed as the argument:

# Claude Opus 5.5 (and every Claude model)
claude -p "<prompt>" --safe-mode --model claude-opus-5-5 --effort max \
  --dangerously-skip-permissions --no-session-persistence \
  --output-format stream-json --verbose

# GPT-6 Astra (and every GPT model)
codex exec --ignore-user-config --skip-git-repo-check --ephemeral \
  --dangerously-bypass-approvals-and-sandbox \
  -m gpt-6-astra -c model_reasoning_effort="xhigh" --json "<prompt>"

--safe-mode and --ignore-user-config switch off personal instruction files, plugins, MCP servers and hooks, so each agent starts with only its built-in tools. Every attempt has the same wall-clock limit of 150 minutes of running time; a model still working at that point is stopped, and whatever it has on disk is published and flagged on the build. Runs happen in neutral folders outside any project, so no repository instructions can leak in. The only retry we allow is for an infrastructure failure (a rate limit or an outage) that stopped a run before the model finished. When that happens, the interrupted attempt is listed on the build with its reason, and whatever it left on disk is kept as evidence but never published.

How the videos are recorded

Simulation and game. These are rendered frame by frame on a virtual clock: the recorder controls requestAnimationFrame, performance.now(), Date.now() and timers, and captures each frame at 60 fps. A slow recording machine can never make one model look choppier than another. Randomness is seeded identically for every build. In the game, the same 40-second input script (move, strafe, turn, fire, reload) is played into every build after pressing Play; if a build reaches its game-over screen, the recorder presses Restart.

Website and dashboard. These are captured in real time from Chrome at 1440×900 and on a 390×844 phone viewport, while a script scrolls at a fixed speed and uses the controls the brief asked for: the Yearly toggle, an FAQ question, chart hover, table sorting, filters, pagination, search and dark mode. A small circle shows where the script is pointing. If a control the brief required can't be found, that is noted on the build rather than worked around.

A video can't carry sound, game feel or how an interface responds to your own hands. That's why every build has an Open live button.

How builds are published

The files each model delivered are published byte for byte. They run from a separate origin inside a sandboxed frame, so model-written code never runs with this site's privileges. Agent transcripts are kept as evidence. Errors the browser reported during recording are listed under each build.

Limits we know about

• One sample. Models are not deterministic; a second run could come out better or worse. We show the first attempt because that is what you get when you ask.
• The harness matters. You are seeing each model through its own agent. That is the comparison most developers face, but it is a model-plus-agent comparison, not a raw model one.
• Time and tokens are context, not merit. Build time depends on server load. Token counts come from each CLI and use different tokenizers.
• English prompts, browser builds. Results may differ for other languages and other platforms.

Run it yourself

Every prompt is on its build page with a copy button, and the commands are above. If your results look very different from ours, we'd genuinely like to hear about it: get in touch.