Recipe 009

One Prompt, Four Claude Models: The Spinning-Hexagon Physics Test

We gave the same physics-simulation prompt to Fable 5, Opus 4.8, Sonnet 5, and Haiku 4.5 — one shot each, effort pinned, no retries — then ran all four artifacts in a real browser. Three passed. One lost its balls, literally. Play all four demos yourself.

Benchmark charts are somebody else's kitchen. This week we ran our own taste test: the same prompt, four Claude models, one shot each — no retries, no edits — and then actually ran what they cooked.

The dish: the classic viral LLM stress test. Three balls bouncing inside a spinning hexagon. It looks like a toy, but it's secretly a physics exam. A ball bouncing off a moving wall can't be faked with an if-statement — you have to compute the wall's velocity at the contact point (the rigid-body equation v = ω × r), work in relative velocity, reflect, and hand momentum back. Get any step wrong and reality visibly falls apart. Which, spoiler, it did.

The setup

Methodology, so you can trust (or replicate) it:

  • Identical prompt, character for character — full text at the bottom of this post. Single self-contained HTML file, real equations required, no physics library, plus gravity, ball-to-ball collisions, a trail effect, and two sliders (rotation speed, gravity).
  • Same harness — each model ran as a Claude Code subagent with the same instructions. This is exactly what you get by flipping /model in your own kitchen.
  • Effort pinned to high for Fable 5, Opus 4.8, and Sonnet 5 — the API default, explicitly fixed so it's a controlled variable. Haiku 4.5 doesn't have an effort dial at all, so it ran the only way it can; that asymmetry is part of what "budget tier" means.
  • One take each. No cherry-picking. (Fair warning: models are non-deterministic — your rerun may land differently. That's why the full prompt is below.)
  • Judged in a real browser, including a stress test: both sliders to maximum.

The production stats, straight off the stove:

Model Code Time to cook Harness tokens Physics verdict
Fable 5 320 lines 92s ~30K ✅ correct, survived extremes
Opus 4.8 336 lines 85s ~29K ✅ correct, survived extremes
Sonnet 5 429 lines 191s ~48K ✅ correct, survived extremes
Haiku 4.5 375 lines 63s ~39K ❌ balls fell through the floor

Fable 5 — the physicist

Fable 5's simulation under stress test: three glowing balls with curved motion trails contained inside the fast-spinning hexagon.

Textbook. The code derives the wall's velocity at the contact point from v = ω × r with a comment explaining the equation, reflects the relative velocity, and hands momentum back to the ball. At maximum rotation and 2,500 px/s² gravity the balls carve curved trails as the walls fling them around — and never clip through anything. Also the shortest code of the four, with the fewest tokens. Confidence looks like brevity.

Play Fable 5's version →

Opus 4.8 — the physicist with plating skills

Opus 4.8's simulation under stress test: a yellow ball rides the spinning wall leaving a long trail hugging the hexagon's edge.

Same correct physics (a dedicated wallVelocityAt function, same rigid-body equation), delivered fastest of the three big models, plus small touches nobody asked for but nobody minds: a caption explaining the simulation, tasteful glow. In the stress test the yellow ball rides the spinning wall — you can watch the momentum transfer happen. If Fable is the physicist, Opus is the physicist who also plates the dish.

Play Opus 4.8's version →

Sonnet 5 — the belt-and-suspenders engineer

Sonnet 5's simulation under stress test: balls contained in the spinning hexagon, one launched upward by a wall kick.

Also correct — and the most defensive implementation: Sonnet sub-divides each animation frame into smaller physics steps (sub-stepping), the standard trick to stop fast balls tunneling through walls. The price: the most code (429 lines), double the tokens, and triple the wall-clock of Opus. It even took an extra pass to review its own file. Thorough, slightly anxious, gets there.

Play Sonnet 5's version →

Haiku 4.5 — the beautiful, empty hexagon

Haiku 4.5's simulation: a beautifully rendered spinning hexagon with no balls inside — all three fell through the walls within the first second.

The hexagon spins beautifully. The sliders are laid out neatly. There is just one problem: there are no balls. They fell through the floor within the first second, leaving three faint trails, and never came back. When we inspected the simulation state, the balls' y-coordinates read 69,000 pixels — about eighty-five screens below the visible canvas, still falling.

The autopsy is the best part. Haiku's collision code is structurally ~90% right — it projects the ball onto each wall, computes a normal, reflects relative velocity, even attempts wall-motion transfer. But one line computes the projection parameter without dividing by the wall's length, then clamps it to [0, 1]. Net effect: collisions only register near the hexagon's corners, and the flat walls are intangible. One missing division; the floor stops existing.

That's the shape of model capability cliffs in 2026: the cheap model doesn't produce garbage. It produces something that looks 95% identical — page loads, no console errors, controls work — with one quiet, load-bearing mistake. On a landing page you'd never notice. In anything that has to compute, you will.

Play Haiku 4.5's version → (bring your own balls)

What this taste test actually teaches

  1. The top three tiers all clear real physics now. A year ago this exact test embarrassed flagship models. Today even Sonnet — a third of Opus's price — nails rotating-frame collision math. For most builds, mid-tier is genuinely enough.
  2. "It runs" is not "it's right." All four files ran without errors. Only running the simulation — and stress-testing the sliders — exposed the difference. Taste the dish before you serve it, especially anything numerical: money, dates, units, physics.
  3. Style differences are real: Fable was economical, Opus was fast and polished, Sonnet triple-checked itself, Haiku sprinted. Same family, four temperaments — worth knowing when you pick a model for a task.

Order up

Run the exam on any model you like — here's the exact prompt we used, unabridged:

Create a single self-contained HTML file (inline CSS and JavaScript, no external
libraries, no CDN) that simulates 3 colorful balls bouncing inside a spinning
hexagon.

Requirements:
- The hexagon rotates at a constant speed.
- Gravity pulls the balls down.
- Balls bounce realistically off the hexagon's walls: compute collisions against
  the rotating walls from real equations, including the effect of the walls'
  motion. No physics library.
- Balls collide with each other.
- Include a subtle motion trail effect.
- Add two sliders: rotation speed and gravity strength.
- Everything in one file.

Then do what we did: open the file, drag both sliders to the end, and watch what the walls are made of.

Hungry for more?

New recipes land in your inbox as they leave the kitchen. No spam, unsubscribe anytime.