Sudoku — Three Models, One Game

An experiment comparing three Claude models building the same prompt: a fancy, web-responsive Sudoku game — pure HTML / CSS / JavaScript, no frameworks, no build step.

Each model worked independently in its own folder, with no shared code or hints between runs. The result is three distinct takes on the same brief.

Live demos: https://dynaum.github.io/sudoku/

Folder	Model	Demo
sonnet/	Claude Sonnet 4.6	Play
haiku/	Claude Haiku 4.5	Play
opus/	Claude Opus 4.7	Play

---

The numbers

Timings are wall-clock from first user prompt to the last assistant message. Token counts are summed across every turn in the run (cache reads billed at the discounted rate).

Model	Wall time	Output tokens	Input tokens	Cache-read tokens	Cache-create tokens	Turns	Tool calls
Sonnet 4.6	~31 min	94,105	97	2,291,348	272,560	55	Skill, ToolSearch, Bash, TaskCreate×9, TaskUpdate×12, Write×3, Agent
Haiku 4.5	~2 min 47 s	26,817	218	871,477	62,211	25	Skill, Bash×4, Read×2, Write×3
Opus 4.7	~5 min 27 s	55,595	43	1,122,095	105,800	28	Bash×5, Write×3, Edit×3

Sonnet's run also delegated a small slice to Haiku (4 extra turns, ~1k output tokens) for a sub-task — included above as the Agent tool call, excluded from its token totals.

Output size on disk

Model	HTML	CSS	JS	Total
Sonnet	4.5 KB	16.0 KB	21.1 KB	41.6 KB
Haiku	3.7 KB	10.3 KB	10.8 KB	24.8 KB
Opus	5.4 KB	12.3 KB	21.8 KB	39.5 KB

---

How each model worked

All three received essentially the same prompt ("create a fancy web-responsive Sudoku game"), but their process to get there was strikingly different.

Sonnet 4.6 — the planner

• Invoked the brainstorming skill first, then wrote a plan, then executed against it.
• Broke work into 9 explicit tasks and tracked progress via TaskCreate / TaskUpdate — 12 status updates across the run.
• Spawned a sub-agent (Haiku) to parallelize one piece of the work.
• Longest run by a wide margin (~31 min) — almost all of that was deliberation, review, and skill orchestration rather than code output.
• Highest total output and the largest cache footprint, consistent with a run that re-reads its plan across many turns.

Haiku 4.5 — the sprinter

• No brainstorming, no plan document, no task tracking — invoked the brainstorming skill once, was told "just create it, no validation," and went straight to code.
• 3 Write calls (HTML, CSS, JS) and a handful of Bash / Read checks. That's the whole run.
• Finished in under 3 minutes — the fastest by ~2× over Opus and ~11× over Sonnet.
• Smallest artifact on disk but still a complete playable game.

Opus 4.7 — the craftsman

• Skipped the planning skills entirely and implemented directly.
• Wrote the three files, then did 3 targeted Edit passes to polish behavior — no rewrites.
• ~5.5 min total; tokenwise sits between Haiku and Sonnet.
• Produced the largest HTML (richer markup — theme toggle, SVG icons, etc.) with the tightest edit-to-output ratio.

---

What the numbers tell you

• Speed is not just about model weight. Haiku was fastest because it did less process, not just because it's a smaller model. When Sonnet ran the same brief with the full superpowers workflow (brainstorm → plan → task tracking → sub-agent), it took ~11× longer.
• Process scales tokens more than code does. All three outputs are in the 25–42 KB range. Sonnet emitted ~3.5× Haiku's output tokens, most of it spent on planning/review, not on the artifact.
• Cache reads dominate. Across all three runs, cache-read tokens are 10–25× the fresh input tokens — the skill system and conversation context get re-read each turn. This is the bill item to watch when choosing a workflow.

The brief, per run

Model	Exact prompt
Sonnet	"we have a folder called sudoku, please create a web responsive sudoku game there."
Haiku	"inside of the folder sudoku/haiku please create a fancy sudolu web responsive game. no need for any visual validation."
Opus	"create a fancy web responsive sudoku game"

Repo layout

.
├── index.html        # landing page linking to all three builds
├── sonnet/           # Sonnet 4.6's build
├── haiku/            # Haiku 4.5's build
├── opus/             # Opus 4.7's build
└── README.md

Running locally

No build step. Open any of sonnet/index.html, haiku/index.html, or opus/index.html directly in a browser, or serve the repo root with any static server:

python3 -m http.server 8000
# then visit http://localhost:8000