Grok 4.7 launched today. xAI calls it their most capable model for coding and knowledge work, and priced it at $2 per million input tokens and $6 per million output, against $10 and $50 for both Claude Fable 5.1 and GPT-6 Astra. Their own benchmark table is more modest than the pricing suggests: Grok 4.7 wins two of the seven benchmarks they published and loses five to Fable 5.1, including CursorBench, the one they lead the announcement with. So I gave all three models the same three builds and recorded what each run cost.
What I tested
Three builds, one prompt each, the same text sent to every model with nothing added. Each model ran inside the agent its own lab ships: Grok 4.7 in Grok Build, Fable 5.1 in Claude Code, GPT-6 Astra in Codex. All three were set to high reasoning effort. No subagent steering, no follow-up prompts, and no re-running a build to get a better result. All nine runs happened on September 21, 2026, the day Grok 4.7 launched. Input tokens, output tokens, dollar cost and wall clock time were recorded during each run rather than estimated afterward.
Test 1: Clone an Awwwards winner
A pixel-for-pixel rebuild of an Awwwards winning site that the model picks for itself.
The Awwwards clone prompt
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.
| Grok 4.7 | Fable 5.1 | GPT-6 Astra | |
|---|---|---|---|
| Input tokens | 8.9M | 90.9M | 66.6M |
| Output tokens | 82k | 1.2M | 265k |
| Cost | $7.26 | $123.12 | $97.79 |
| Build time | 23 min | 68 min | 43 min |
Test 2: A scroll-driven 3D product page
A product page for a mechanical keyboard whose 3D centerpiece is built in code and driven by scroll.
The product page prompt
Build the product page for a high-end mechanical keyboard — a single scrolling page whose centerpiece
is a real-time 3D model of the board that assembles, explodes, and is annotated as the visitor scrolls, and
that responds when the visitor types.
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 premium 75% mechanical keyboard. 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 (top and bottom), the weight, the
plate, the PCB, the sound-damping foam, the stabilizers, the switches, and the keycaps.
Requirements:
1. **A real-time 3D keyboard, built in code.** No imported model files, no hotlinked assets — the geometry is
authored procedurally or in code. It needs to read as a real board: correct key spacing and row profiles,
sculpted keycaps with proper top surfaces, legible legends, an anodized or PVD case with believable edge
chamfers, and metal that responds to light differently from the plastic next to it. Physically-based
materials, real lighting, an environment the case has something to reflect.
2. **Scroll drives everything.** The page is one continuous choreographed sequence — the board rotates, the
case opens, the stack separates into its layers, individual components isolate, and everything 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 single switch, isolated and cut away.** Somewhere in the sequence, one switch separates from the board
and opens up — housing, stem, spring, contact leaf — and actuates on a loop so the travel is visible. This
is the detail that separates a real understanding of the product from a pretty render.
4. **It has to respond to typing.** The visitor types on their own physical keyboard and the corresponding 3D
keycaps depress and rebound with real weight and real travel distance. Key-up cannot be the mirror of
key-down — a switch rebounds faster than it depresses. Handle held keys, fast repeats, and multiple keys at
once without the animation desyncing or queueing.
5. **A wireframe-to-solid transition** somewhere in the sequence, where the board reads as engineering drawing
and resolves into the finished object.
6. **Hotspot callouts on the exploded components.** As each layer separates, a labeled annotation appears
anchored to it with a line of copy explaining what it does and why it matters to how the board sounds or
feels. They enter and leave with the choreography rather than popping.
7. **A complete page, not just the 3D showcase.** A hero, the scroll sequence, a technical specification table
(layout, switch type and actuation force, mount style, case material, plate material, keycap profile and
material, connectivity, polling rate), a section on materials and finishing, a section on sound with some
visual treatment of the typing acoustics, 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.
8. **Typography and layout carry the brand.** Deliberate type scale, real hierarchy, generous and confident
spacing. This is an enthusiast object sold on craft; 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. Avoid
the default mechanical-keyboard-site look too: pure black background and RGB underglow is the cliché of
this exact category, and a large audience has seen it hundreds of times.
9. **Sixty frames per second while scrolling**, on a normal laptop, with the full board and all keycaps on
screen. A 3D scroll page that stutters is worse than one that doesn't exist. Profile it and fix it.
10. **Responsive.** It has to work and stay beautiful down to a phone. The scroll choreography adapts rather
than breaking, and the typing interaction degrades gracefully where there's no physical keyboard.
11. **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.
12. **QA it by using it.** Scroll the whole page top to bottom and back up several times at different speeds.
Type on it — single keys, held keys, fast bursts, chords. Confirm the sequence scrubs cleanly in both
directions, nothing desyncs or jumps, callouts anchor to the right parts, the switch cutaway actuates
correctly, the frame rate holds, and the mobile layout is genuinely good rather than merely functional.
Fix what breaks.
| Grok 4.7 | Fable 5.1 | GPT-6 Astra | |
|---|---|---|---|
| Input tokens | 13.9M | 24.7M | 2.2M |
| Output tokens | 218k | 692k | 43k |
| Cost | $5.73 | $58.52 | $5.25 |
| Build time | 57 min | 14 min | 24 min |
Test 3: Clone Mario Kart
A playable browser clone of Rainbow Road using Mario Kart 8's drift and item mechanics.
The Mario Kart prompt
Build a browser clone of Mario Kart — specifically Rainbow Road, with Mario Kart 8's drift and item
mechanics reproduced exactly — that is genuinely playable and genuinely feels like the real thing.
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. Every model
gets this identical prompt. The audience has played this game. They will know immediately if the drift is
wrong, and "close enough" reads as failure. Go all out.
Requirements:
1. **Rainbow Road, reconstructed.** Not "a rainbow-themed track" — the actual thing: a narrow, guard-rail-less
ribbon suspended in open space, banked turns, the signature drop, at least one split path, and the
constant threat of falling off with a Lakitu-style respawn that drops you back on the track with a brief
invulnerability and a speed penalty. Look up the layout and reproduce its character honestly. The track
should be readable at speed — a first-time driver must be able to see where it goes.
2. **Mario Kart 8's drift model, exactly.** Hop-then-hold to initiate. Mini-turbo charges in three visible
tiers while drifting — blue, then orange, then purple — each with its own spark color and its own boost
duration on release. Counter-steer tightens or widens the slide. The kart has weight and the drift is
controllable, not a slide-and-pray. **This is the single most important requirement in this prompt.** If
the drift doesn't feel like Mario Kart, nothing else you build matters.
3. **Coins and speed.** Coins on the track, up to ten, each incrementally raising top speed. Taking a hit
scatters them. This is load-bearing on the real game's feel and it is the detail most clones skip.
4. **The real item set, with the real roulette.** Item boxes that spin a roulette weighted by race position —
the leader gets coins and bananas, the back of the pack gets the good stuff. At minimum: green shell
(travels straight, bounces off walls), red shell (homes on the kart ahead), banana (drops behind, spins
out whoever hits it), mushroom (instant boost), star (brief invulnerability plus speed), and a blue shell
that seeks the leader. Each needs a visible pickup, a clear activation, and audible impact.
5. **Eight racers, three laps, real AI.** Seven AI opponents on genuine racing lines — outside-inside-outside,
real braking points, they take the split path, they use items on each other and on you, they recover from
spins and from falling off. Position-based rubber-banding matching the real game's is expected; obvious
cheating is not.
6. **The full race structure.** Lap counter, position out of eight, coin count, item slot, speedometer, lap
and total splits, and a track-position minimap. A three-two-one-GO countdown with a rocket-start window
that rewards correct timing. A finish sequence and a results screen with placings and times.
7. **It has to look like a shipped game.** Real materials and lighting, shadows, and a coherent art direction
held across the kart, the track and the skybox. Motion that sells speed: FOV punch on boost, drift sparks
that visibly tier with the charge, tire marks, impact particles, screen shake on collision. Untextured
primitives and programmer art are failures regardless of how good the driving is. Original characters and
karts — design your own racers rather than approximating Nintendo's.
8. **Sixty locked frames per second** with all eight karts, full particles and the whole track visible. Frame
drops during a race are the most visible failure mode on camera. Profile it and fix it.
9. **Audio, synthesized via the Web Audio API.** Engine note that tracks throttle and speed, drift-charge
tones that step with the mini-turbo tiers, boost, impacts, item sounds, coin pickup, countdown. No
hotlinked audio and no Nintendo music.
10. **Single self-contained `index.html`.** Any library via CDN — three.js, a physics engine, anything. No
build step, no server, no API keys, no hotlinked sprites or textures. Generate art procedurally or author
it in canvas/SVG/WebGL. You have free reign to look up what libraries exist and how to use them.
11. **Log every asset's license** in BUILD_NOTES.md — anything CC0/CC-BY you pulled in, and confirmation that
nothing came from Nintendo.
12. **QA it by actually playing it.** Race several full three-lap races. Confirm all three mini-turbo tiers
charge and pay off, the AI completes laps without getting stuck or cutting, red and blue shells track
correctly, falling off respawns properly, coins raise speed, lap counting is correct, nothing softlocks,
and the frame rate holds through a pack fight. Fix what breaks.
| Grok 4.7 | Fable 5.1 | GPT-6 Astra | |
|---|---|---|---|
| Input tokens | 47.8M | 38.2M | 6.3M |
| Output tokens | 379k | 601k | 67k |
| Cost | $16.54 | $52.46 | $11.25 |
| Build time | 118 min | 64 min | 38 min |
What it cost
On agentic builds the bill is set by input, not output. A model re-reads the task and all of its own previous work on every turn, so what you pay tracks how many turns a build takes rather than how much code arrives at the end. Fable 5.1 wrote 1.17 million output tokens on the Awwwards clone and read 90.9 million to do it. That ratio, not the size of the finished page, is what the invoice reflects.
| Grok 4.7 | Fable 5.1 | GPT-6 Astra | |
|---|---|---|---|
| Input tokens | 70.6M | 153.8M | 75.0M |
| Output tokens | 678k | 2.5M | 375k |
| Cost | $29.52 | $234.10 | $114.29 |
| Build time | 198 min | 147 min | 106 min |
These are API-equivalent costs: real token counts from each build, priced at each model’s published rates. The builds themselves ran on subscriptions.
The takeaway
My read on Grok 4.7 is not great. I was ready to give it the benefit of the doubt on price alone, and it still did not come anywhere close to Fable 5.1 or GPT-6 Astra on any of these three builds.
Three builds is a limited test, and these were heavy coding tasks. I ran no knowledge work and no automations, which is where xAI's own benchmarks claim it excels, and none of the day to day jobs you would actually reach for it on. These are also one-shot outputs. Every model got a single pass at the prompt, which is not how you would use any of this in practice.
At a fifth of the price you could in theory run Grok four or five times over and still not reach what Fable or Astra cost. The Mario Kart build is the exception, and it is the one worth looking at: Grok spent $16.54 against Astra's $11.25, so it finished more expensive than the model that beat it. More turns were not going to close that gap.
I am hitting usage limits constantly, and I hold two max subscriptions on both ChatGPT and Claude. A real competitor showing up at a fifth of the price is good for all of us. I just wish this one were better.
Put Grok through its paces yourself, and rotate between models rather than defaulting to one. xAI owns its own compute, which is their advantage, and I would bet Grok closes this gap over time. On these tests they still have work to do.