muse spark open beats 3 open-weight models at a pixel game for $0.59

meta's new muse spark open built the most playable game of four open-weight models for $0.59. we gave muse, hy4 preview, step 5 preview and inkling one brief: a vampire survivors-style pixel game in plain canvas 2d, built in four steps.

the setup

every model got the same brief in four stages: gameplay, sprites, world and effects, then polish. after each stage we ran the game in headless chrome and sent any console errors back to the same model.

• models: meta muse spark open, tencent hy4 preview, stepfun step 5 preview, thinking machines inkling
• all four through openrouter, one call per stage
• one self-contained html file, plain javascript and canvas 2d, no libraries, no images
• an autopilot plays the game, so every run can be recorded the same way
• test date: oct 15, 2026

the code, the art and the balance are each model's own work.

the numbers

time is pure generation time on the provider, cost is what openrouter billed. tokens include reasoning.

the spread on cost is only 8 cents. the gap is in time: inkling was 5x faster than hy4.

what each model built

the screenshots below are each model's own final file, 28 seconds into an autopilot run.

• muse spark open – the most game-like: hordes, damage numbers, level-ups and no crash at any stage
• hy4 preview – the slowest by far, but its code ran clean at every stage
• step 5 preview – crashed mid-build and needed one extra fix turn
• inkling – the fastest and the prettiest graveyard, but its weapons deal zero damage

muse was the only model that looked like a finished game at the 30-second mark.

the brief

the same text went to all four models, one stage at a time:

You are building a complete, polished browser game step by step: a top-down PIXEL-ART survival game in the style of Vampire Survivors. You will receive the work in 4 stages. In every stage you get your current code and the next part of the brief, and you reply with the COMPLETE updated HTML file (never a diff, never "the rest stays the same").

THE GAME
- The hero walks around an endless field; the camera follows the hero smoothly.
- Endless waves of enemies come from all sides; over time they get tougher, faster and more numerous, with new enemy types joining every 30–45 seconds and an occasional bigger elite / mini-boss.
- Weapons fire automatically; the player only moves (WASD / arrow keys).
- Weapon pickups (chests or glowing icons) appear around the map: walking over one adds a new weapon. At least 4 weapon types with distinct look and behaviour, e.g. a whip slash to the facing side, orbiting holy books / blades, homing magic bolts, a garlic-style damage aura, a thrown axe / boomerang.
- Defeated enemies drop XP gems (several sizes/colours by value) that fly to the hero when close. On level-up one weapon is upgraded automatically (more damage, more projectiles, faster fire, bigger area) — show the upgrade with a flashy "LEVEL UP" moment and the weapon's new level.
- HP, small regeneration, invulnerability frames after a hit, knockback.
- When HP reaches 0: short game-over screen with time survived and kills, then automatic restart.

AUTOPILOT (required)
If the player has not pressed a key for 2 seconds, the hero plays by itself: steer away from the densest nearby enemies (sum of repulsion vectors), toward gems and pickups when safe, never stand still, avoid getting cornered. The game must look exciting with nobody touching it — it will be recorded for a video.

TECHNICAL RULES (all stages)
- ONE self-contained HTML file; plain JavaScript + Canvas 2D only; no libraries, no external files, images or fonts.
- Render the world to a low-resolution offscreen canvas (about 320–400 px wide; height from the window aspect) and scale it up with imageSmoothingEnabled = false so pixels stay crisp. The game must FILL the whole window with no black bars — if the integer scale does not fit exactly, render a slightly larger buffer and crop, or choose the buffer size from the window. It may be shown as small as 930x380 and as large as 1920x1080; handle resize.
- Starts immediately, no menu. body margin 0, no scrollbars.
- Smooth 60 fps with 300+ enemies: object pools, simple spatial grid for collisions, no per-frame allocations in hot loops.
- requestAnimationFrame loop with delta time clamped (max 50 ms).
- Zero runtime errors: declare every variable you use, guard against empty arrays / undefined, double-check every function and variable name you reference.

Reply with the complete HTML file only — no explanations, no markdown fences.

STAGE 1 of 4 — ENGINE AND GAMEPLAY
Build the full game loop and all mechanics from the overview: movement, camera, enemy waves and types, all 4+ weapons, XP gems, level-ups with weapon upgrades, pickups, HP / i-frames / knockback, game-over and restart, and the autopilot.
Graphics in this stage can be simple placeholder pixel shapes, but already use the low-res buffer + crisp scaling that fills the window. Focus on gameplay being complete, fun and bug-free.

STAGE 2 of 4 — PIXEL-ART SPRITES AND ANIMATION
Replace every placeholder with hand-crafted pixel art defined in code (strings or arrays of palette indices, e.g. "..1122..", rendered once to small offscreen canvases and cached):
- Hero: about 16x24 px, a readable character (hooded hunter, knight or mage), 1-px dark outline, 3–4 shades per colour, highlights; 4-frame walk cycle, idle bob, flips to face movement direction, white flash on hit.
- At least 5 enemy types with clearly different silhouettes and colours: e.g. bat (2-frame flap), skeleton (walk cycle), ghost (floating, semi-transparent), slime (squash & stretch), zombie or mummy; one big elite / mini-boss 32x32. Each with outline, shading and 2–4 frame animation, facing direction, white hit flash.
- Weapons and projectiles drawn as pixel sprites (whip arc, spinning blade/book, glowing bolt, axe), XP gems (3 sizes/colours, twinkling), chests / pickup icons.
- Soft elliptical drop shadows under every character.
- A deliberate limited palette (e.g. 24–32 colours): darker, muted world; bright, saturated characters and effects so they pop.
Keep all stage-1 gameplay working.

STAGE 3 of 4 — WORLD, EFFECTS AND HUD
- World: an atmospheric endless ground made of several 16x16 tile variants (dark grass, dirt, flowers, moss, small stones) chosen by a deterministic hash of the tile position so it never looks like a checkerboard; plus scattered decorations drawn as sprites: tombstones, dead trees, rocks, bushes, bones, candles/torches with flickering warm light (radial glow), maybe a ruined wall or fence. A subtle dark vignette around the screen edges.
- Effects: whip slashes with a bright arc that fades, projectile trails, expanding shockwave rings, sparks and death puffs (small pixel particle bursts in the enemy's colour), XP gems that sparkle and fly to the hero, floating damage numbers in a pixel font (white, yellow for crits), short screen shake on big hits and on level-up, a flash + particle ring on level-up.
- HUD in pixel style (draw your own 3x5 or 5x7 pixel font from bitmaps — no system fonts): framed XP bar across the top with the level number, survival timer centred under it, kill counter with a skull icon, HP bar above the hero's head, and a row of weapon slots with pixel icons and level pips. A small "AUTOPILOT" tag when the autopilot is driving.
Keep all gameplay working.

STAGE 4 of 4 — POLISH, BALANCE AND BUG HUNT
- Review the whole file line by line as a strict code reviewer: find and fix every bug, undefined variable, typo in a name, unreachable code, and anything that could throw at runtime. Make sure the game runs for 10+ minutes without errors or slowdowns.
- Balance for an exciting 2–3 minute recording on autopilot: enemies arrive within the first 2 seconds, the screen fills up over time, the hero levels up roughly every 10–20 seconds early on, gets a new weapon by ~20 s and several upgrades by 60 s, and survives at least 90 s on autopilot before things get dangerous.
- Visual polish: consistent pixel scale everywhere (no blurry or mixed-resolution elements), nothing drawn at sub-pixel positions, readable at 930x380 and at 1920x1080, no black bars.
- Make it look as close as you can to a commercial pixel-art game of this genre.
Reply with the final complete HTML file.

no model saw another model's code, and no stage was rerun to pick a better take.

our take

meta calls muse spark open the most capable us open-weight model to date. on this job it shipped the only complete game of the four, in 20 minutes, for 59 cents. speed alone did not decide it: inkling finished in half the time with a game that does not fight back.

sources

• introducing muse spark open, meta ai research – oct 15, 2026
• muse spark open on openrouter
• hy4 preview on openrouter
• step 5 preview on openrouter
• inkling on openrouter
• briefs, builds, timings and bills: our test, oct 15, 2026