Methodology

What a run records

Inspiration id and the exact snapshot id it was shown; a short id; prompt name, a SHA-256 of the template body and a SHA-256 of the rendered prompt text; the variables filled in and which variable set they came from; which images were attached; model id and parameters; runtime (Cursor SDK local agent, or manual for the original proof-of-concept); repetition number, cohort id and batch id; start/finish time and duration; token usage where available; status; the collected output files; the capture of that output; and the full agent transcript.

Only the deliverable is kept

The agent works in an empty temporary directory. When it finishes, only allowlisted web files (HTML, CSS, JS, images, fonts) are copied into the run. Debug screenshots, scratch scripts and comparison crops the agent made for itself are never filed as output, so they can’t contaminate review.

Repetition is the default

Agentic generation is not deterministic. Every prompt × model combination is run at least three times as one cohort, and results are always reported with the spread across repetitions, not a single lucky run.

Fresh agent, empty folder, no ambient context

Each run is a new agent with no conversation history, started in an empty directory containing only the prompt’s declared inputs. Project rules, user rules, MCP servers and other ambient Cursor settings are disabled for the agent, so nothing leaks in from the operator’s environment.

The prompt is only what a user would type

The agent receives the rendered prompt template and its attachments, plus a short fixed instruction: work only in the given folder, write a complete working index.html early and keep it working, and list its files when done. No hints, no corrections, and no follow-ups beyond the single time warning described below. If a run fails it is filed as failed, not retried with extra guidance.

A fixed time limit, with one warning

Every run gets the same wall-clock limit, currently 30 minutes. Five minutes before the limit (minute 25), the agent is sent one fixed message saying how long remains and asking it to stop exploring and make sure index.html and its files are finished. The same text goes to every run, and the manifest records when it was sent and whether the agent received it. At the limit the agent is stopped and whatever page it has written is collected and captured as usual. The run is filed as cancelled, not retried.

What never passes through

This website and its code; other runs, their outputs or transcripts; other prompts; design notes taken from the inspiration; reviewer scores.

Limits we can’t remove

A model may have seen the inspiration site during training. Runs that include the URL fetch the live public web. Runs that receive only an image are kept offline from the live site by instruction, which is enforced by inspection of the transcript, not by a sandbox.

One approved snapshot per inspiration

A snapshot is a versioned artifact: the full-page capture, viewport tiles, the archived HTML, text and perceptual hashes, and an approval record. A run cannot start unless its inspiration has an approved snapshot, and the run manifest records the snapshot id. Two runs five minutes apart therefore see byte-identical images; a capture glitch cannot split a cohort.

Drift detection

Re-snapshotting compares a hash of the page’s visible text and a perceptual hash of the capture against the approved snapshot. Unchanged sites produce no new snapshot. Changed sites produce a new pending snapshot that a designer must approve before it is used, and any comparison across snapshot ids is flagged because the reference changed.

A person is the quality gate

The pipeline does not judge whether a screenshot is correct. A designer views each pending capture next to the live site and approves or rejects it. Because snapshots are reused, this costs one review per inspiration, not one per run, and a trained eye catches the failures that matter (a missing footer, a stuck animation, a duplicated section) more reliably than heuristics would.

Deterministic browser

Headless Chromium at a fixed 1440×900 viewport and fixed device scale factor, light colour scheme, reduced-motion preference, fixed locale and timezone, a fixed Date so date-based content is stable, seeded Math.random, and a block list for analytics, consent managers, chat widgets and video embeds.

Settle before shooting

Wait for network idle, web fonts, and every image to decode, then poll until the document height and the count of unloaded images have been stable for a full second. Pages that keep growing are not photographed until they stop.

Scroll pass at real viewport size

Lazy loaders and scroll-triggered reveals only fire when their element enters a normal-sized viewport. The page is scrolled top to bottom in half-viewport steps with pauses, then returned to the top, before any screenshot is taken.

Freeze motion generically

All CSS animations and transitions are disabled and background-attachment: fixed is neutralised. Elements still hidden by a reveal library (opacity near zero, visibility hidden, or transformed off their box) that contain text or images are forced visible. This is done by computed style, not by guessing class names, so it works across animation libraries.

One full-page screenshot, never capped

After settling, scrolling and freezing, a single full-page screenshot is taken at the fixed viewport. Earlier tooling silently truncated tall pages at a fixed height; this pipeline does not. content-visibility is forced on before the shot, and each video is replaced with a still of its current frame, because a full-page screenshot otherwise leaves those regions blank. Known limits that remain are accepted and reviewed rather than worked around: fixed headers appear once at the top, and sections sized in viewport units can stretch. A reviewer sees these and decides.

Per-site overrides are explicit and versioned

Some sites need a cookie banner removed or a dialog dismissed. These fixes are declared per inspiration as selectors and stored with the snapshot, never applied ad hoc.

What we deliberately do not automate

We tried automated checks for missing footers, blank bands, duplicated regions and render-to-render disagreement. They caught real problems but also introduced their own (a stitching fallback duplicated a section; clock manipulation stalled a page). With a handful of inspirations snapshotted rarely, a designer approving each capture once is cheaper and more reliable than heuristics, so approval is the only gate. Generated output is captured with the same code and is reviewed alongside its screenshot in any case.

Downscaling destroys the detail we judge on

Vision pipelines cap the long edge of an input image, commonly around 1,500 pixels. A 1440×9000 full-page capture is therefore shrunk to roughly 240 pixels wide before the model reads it. Typography, spacing, card treatments and iconography, the things designers score, are gone before the prompt starts. A tall page also costs a fixed number of tokens regardless of how little survives the resize.

Image packs are a declared variable

Each snapshot produces an image pack: the full page for layout overview, plus viewport-sized tiles (1440×900 with overlap) in reading order so each section is seen at usable resolution. A prompt template declares which pack it attaches: none, full only, tiles only, or full plus tiles. The choice is stored in every run manifest and compared like any other variable rather than left implicit.

Models re-interpret, they don’t copy

A model does not transcribe an image; it describes it internally and regenerates from that description. Colours drift toward common palettes, uncommon typefaces are substituted, dense sections are simplified, and decorative detail is invented or dropped. Runs that receive only an image are judged on design language and taste, and are not expected to be pixel-faithful. Runs that receive the URL can fetch real assets and copy, and are judged on a different scale.

The reference shown to reviewers is the reference shown to the model

Review always displays the exact snapshot the run referenced, not a live view of the site, so reviewers judge fidelity against what the model was given.

Templates with declared inputs

Each template declares its variables (brand, business, content brief, attached image), whether it includes the live URL, which image pack it attaches, and whether it asks for a clone or an original design. Prompts whose only inputs are the URL or image run once per model; prompts with brief variables run once per variable set.

Variable sets are fictional businesses

Each set describes an invented company that would plausibly ship a site like the inspiration (brand, site type, industry, one-line business). Sets are files, reviewed before use, and reusable across inspirations. The run manifest records which set filled the prompt.

Two hashes per run

The run stores a SHA-256 of the unrendered template body and a SHA-256 of the exact text sent with variables filled in. Two runs with the same rendered hash received identical instructions; any difference in outcome is model variance. If a named prompt file is edited after runs used it, the template hash no longer matches and the index flags every affected run as not comparable under that name.

Composer 2.5: speed and cost ($3 / $15, Fast)

Cursor’s everyday model. Prices here and below are per million input / output tokens at Cursor’s list rates. Composer has no effort setting, so Fast is its only mode, and the lineup runs it that way. Standard is $0.50 / $2.50; Fast is $3 / $15. Fast is the default because Composer is inexpensive enough to run that way.

Grok 4.7: cost-effective quality ($2 / $6)

Cursor’s long-task model, at about 2.4× Composer’s standard (non-Fast) output rate. Run at high reasoning effort with the 256k context. Its default 500k context is billed at twice the standard rate, which would put it on the same input price as Opus and blur the cost comparison.

Claude Sonnet 5.5: the mid tier ($2 / $10)

Same input price as Grok, with output pricing closer to a frontier model. Run at high reasoning effort on the 300k context. The listed default is 1M high, and the API rejects that pair. Sonnet has no Fast option.

GPT-5.6 Terra: a second mid-tier vendor ($2 / $12)

OpenAI’s mid-tier model, between Sonnet and Opus on output price. Run at high reasoning with the 272k context, because input beyond 272k is billed at twice the rate.

Claude Opus 5.5: the quality ceiling ($4 / $20)

The model public posts still treat as the daily driver, at 8× Composer’s standard output rate. Run at high effort.

Fast is on for Composer, off for the rest

Composer 2.5 runs Fast. At $3 / $15 that tier is cheap enough to leave on, and Composer has no other quality knob. Fast stays off for the other models: Grok Fast is $4 / $12, which would put Grok on Opus’s input price and erase its slot. A fast run of those models stops being the run its price point describes.

Effort is high for every model

Effort is held at high rather than maximum. An Opus run at max effort costs about 3× the same run at high, which would swamp the comparison between models. Vendors don’t define “high” identically; each run records the vendor’s own setting name and value.

Models deliberately left out

GPT-5.6 Sol is in the same $4 / $20 band as Opus, so it would repeat the quality price instead of filling a gap. Gemini 3.1 Pro ($2 / $12) sits next to Sonnet without being the model people reach for. Claude Haiku 5.5 looks cheapest at $0.10 / $0.50, but bills at 5× once input passes 100k tokens, which an image brief does.

The exact mode is recorded

A model is specified with its mode (for example grok-4.7:high-256k) and resolved against Cursor’s published presets before anything runs. An impossible combination fails at planning time. Each manifest stores the full parameter set the run used, defaults included, plus a short mode label such as “high”. Runs made before modes were recorded used each model’s default preset at the time. Today that is the Fast tier for Grok 4.7 and Composer 2.5, but older manifests don’t record which tier they actually ran.

Blind review

Reviewers do not see the model, prompt, run id or date. Knowing which model produced a page measurably biases taste judgements, so labels are revealed only after a score is submitted.

Pairwise preference over absolute scores

Reviewers are shown two candidates against the same pinned reference and choose the better one. Pairwise choices are far more consistent between people than 1–10 ratings. Choices are aggregated into Bradley–Terry ratings per run, then rolled up to prompt and model.

Rubric tags

A short, versioned rubric (fidelity to the reference’s design language, hierarchy and layout, typography, colour, polish, and originality for non-clone runs) is available as optional tags to explain a choice, not as required numeric scores.

Reviewer identity and agreement

Every judgement records who made it, when, and against which rubric version, so inter-rater agreement can be measured and reviewer drift noticed.

Automated pre-filter only

A model-based judge may be used to flag obviously broken output (blank pages, collapsed layouts, missing sections) before human review. It is calibrated against human scores and never substitutes for them.

Generated index

The site is built from an index of every inspiration, snapshot, prompt and run on disk. Product names, prompts, models and captures are read from manifests. If it is on the page, it is in the data.

Variance and cost, not just winners

Results are reported with spread across repetitions, with the snapshot id they were judged against, and with duration and token cost per run, so improvements in quality can be weighed against what they cost.

Agentic runs are not reproducible

The same prompt and model will produce different pages. We record everything that can be recorded and rely on repetition, not on any single run.

URL-based runs are not fully pinned

When the prompt includes the live URL, the agent fetches the live site, which can change between runs. The snapshot’s text hash at run time is recorded so mid-cohort changes can be detected. Serving the archived copy to the agent instead would pin it fully but changes the prompt, so it is treated as a distinct prompt variant.

Source material

Clone runs reproduce copyrighted sites and may download their assets. These runs exist for internal research into design fidelity and are not published as products.

The proof-of-concept runs

The first twenty runs were prompted by hand in separate chat sessions and filed into the store afterwards. They are marked as manual runtime in their manifests and were not captured with the current pipeline; their inspiration snapshots are marked legacy.