3D Tetris Doesn't Care About Your LLM Benchmark Score

A one-shot stress test reveals what leaderboards and front-end demos hide: which AI models can hold a complex system together, and which ones lose control while building it.

AI coding demos are easy to fake. A model generates a glowing city, drops a car into it, adds a third-person camera and calls the result a “3D GTA clone.” It looks spectacular in a video. Underneath, there’s a vehicle controller, some primitive buildings and a large amount of visual atmosphere. Nothing else.

A real GTA clone would be vastly harder than Tetris. But the kind of “GTA clone” that gets posted on Twitter is often easier to fake than a small, rule-bound game. The human eye does most of the work. A road, a car, a skyline and a moving camera are enough to suggest an entire world. Minor errors vanish inside the scenery. The car can slide slightly, buildings can have no interiors, and the city can contain almost no real systems. As long as the image feels right, the demo works.

3D Tetris is almost the opposite. It is small, closed and brutally verifiable. Every cube has an exact position. Every move is either legal or illegal. Every rotation must produce another valid arrangement of integer coordinates. A complete layer contains exactly 25 occupied cells. If two layers disappear, every cube above them must fall by exactly two cells. There is nowhere for the program to hide.

We didn’t ask for ordinary Tetris rendered from an attractive camera angle. The assignment required a genuinely volumetric board: five cells wide, five cells deep, twelve visible cells high.

Each falling piece had to consist of four connected cubes. Pieces had to move across both horizontal dimensions and rotate around all three spatial axes. A complete horizontal X–Z layer had to disappear, after which the remaining structure had to collapse correctly.

That alone already combines discrete geometry, collision detection and game-state management. The prompt then added a ghost piece, wall kicks, lock delay, soft and hard drop, a shuffled bag, scoring, levels, previews, pause, restart, game over, camera controls and an animated clearing sequence. The logical board had to remain separate from the Three.js scene. Mesh positions were not allowed to become the collision system. The entire game had to live inside one HTML file and run directly in a browser.

The task works as a test because it is not difficult in the way that a novel algorithm is difficult. It is difficult because a large number of individually manageable systems must all agree with each other. A web design can be 80 percent successful and still look good. A game state cannot be 80 percent correct. The missing 20 percent eventually shows up as an impossible rotation, a disappearing piece, a broken layer collapse or a game that never ends.

What this test actually measures

This is not a universal ranking of coding intelligence.

Each model received one attempt. No model was allowed to run the result, inspect browser errors and repair its own work. The experiment measures a narrower ability: can a model turn a long specification into a closed, immediately usable product in a single generation?

That ability is real and commercially relevant. Many people use AI coding tools in exactly this way. They describe an application, ask for a complete file and expect the first result to work. The test is especially relevant to browser prototypes, interactive explainers, small games, visualizations and self-contained tools. It tests whether a model can keep logic, rendering, interface and input handling synchronized across a long output.

But “coding” is not one ability. Designing an attractive interface is not the same as maintaining a complex state machine. Solving a local algorithm is not the same as integrating an entire product. Editing an existing repository is not the same as creating one large file from nothing. Debugging with a terminal, tests and repeated tool calls is not the same as producing correct code in a single shot. The experiment says nothing about how well the models would perform inside an established codebase, or whether they can read failing tests, inspect logs, search through several files or improve a program over multiple iterations. It also doesn’t isolate visual design ability.

That distinction matters because some of the results look almost backwards compared with the models’ public reputations.

The current WebDev Arena places Kimi K3 first, Claude Fable 5 second, GPT-5.6 Sol third and GLM-5.2 fourth. Grok 4.5 sits near the top, while Gemini 3.1 Pro and DeepSeek V4 Pro are much lower. That leaderboard is based on human preferences across front-end development tasks, not this exact kind of one-shot game-engine challenge.

Kimi K3 and GLM-5.2 are also explicitly marketed by their developers as models for long-horizon coding and agentic engineering. Kimi is promoted for building playable and 3D games, Z.ai describes GLM-5.2 as specialized for sustained coding-agent work. Both failed to produce an executable file.

Gemini 3.1 Pro, by contrast, was one of the least visually exciting entries and sits much lower on the public WebDev ranking. It produced one of the most reliable games in this particular test. Google positions the model for autonomous coding, agentic tasks and “vibe-coding,” but that doesn’t automatically mean it’s expected to beat the current front-end leaders.

This is not proof that the public rankings are wrong. It shows that model ability is uneven. A model may have excellent visual taste but weak long-output integrity. Another may create boring interfaces while maintaining unusually solid internal state. A third may write a sophisticated engine and fail on one DOM identifier. The important unit is not “coding skill.” It is the particular combination of skills that a task demands.

One more caveat. This was a qualitative one-shot stress test, not a statistical benchmark. A second run could produce a different ordering. Several runs per model would be needed to estimate reliability rather than merely inspect one concrete result. But the individual results are real. Users never receive a model’s average benchmark score. They receive one particular output.

The ranking

1. ChatGPT 5.6 Sol

2. Claude Fable

3. Grok 4.5

4. Gemini 3.1 Pro

5. Kimi K3 — manually repaired

6. DeepSeek V4 Pro

7. Kimi K3 — original output

8. GLM 5.2

Kimi appears twice because the repair became a useful secondary experiment. The manually repaired version reveals the quality of the solution beneath the damaged output. It doesn’t receive a high ranking, because 26 touched lines are no longer a trivial typo correction. The repaired version is evidence about what Kimi had almost constructed, not what it actually delivered.

1. ChatGPT 5.6 Sol - the most complete product

ChatGPT produced the strongest overall result.

The logical board is cleanly separated from its visual representation. Pieces, the board, input handling, rendering and the interface have understandable responsibilities. Rotations, collisions, wall kicks, the ghost piece, lock delay, scoring and layer compression work together as one system. The implementation handles the less visible details too: pieces can enter from above the visible board, multiple cleared layers are collapsed correctly, the mesh representation stays synchronized with the logical grid.

The game looks and behaves like a finished browser product rather than a Three.js experiment. Its code is long, but the complexity remains controlled. ChatGPT didn’t win because of one particularly clever algorithm. It won because no critical connection appears to have been forgotten.

That matches the model’s current positioning. OpenAI describes GPT-5.6 Sol as its strongest coding model, emphasizing planning, iteration, tool coordination and the delivery of polished outputs.

Verdict: The strongest combination of architecture, presentation and completeness.

2. Claude Fable - controlled and pragmatic

Claude took a more compact route. Its game has the essential logical systems, including a proper hidden spawn buffer above the twelve visible layers that allows pieces to enter the board naturally and makes the top of the playfield easier to manage.

The code is structured clearly without becoming elaborate. Claude generally attempts fewer visual and architectural tricks than ChatGPT, but nearly everything it attempts works.

One formal deviation: the prompt specifically requested the Three.js OrbitControls module. Claude implemented its own camera orbit system instead. The player can still rotate and zoom the camera, so this is a specification issue rather than a broken feature.

Claude’s success is not especially surprising. Anthropic presents Fable 5 as a model for difficult coding work, complex implementations and game prototyping, and it currently ranks near the top of the WebDev Arena.

Verdict: Slightly less ambitious than ChatGPT, but highly controlled and dependable.

3. Grok 4.5: A Strong Demo With a Hidden Hole

Grok also produced a real and largely playable volumetric Tetris game.

Movement, three-dimensional rotation, the piece bag, ghost projection, layer detection and camera controls are all present. The game is more visually distinctive than Gemini’s and makes a convincing first impression.

Grok 4.5 is explicitly positioned as a frontier model for coding, agentic tasks and end-to-end application building, so the general quality of the result fits its intended role.

The serious problem only appears late in the game.

Pieces spawn several rows above the visible board. The collision system permits this, which is normal. But when the visible board fills up, a piece can become locked while still partly or entirely above it. Cubes outside the twelve stored rows are then simply discarded.

The game therefore fails to recognize the condition under which it should end. Instead of producing game over, overflowing pieces can disappear.

This is more interesting than a syntax error because a brief test may never reveal it. Grok passes the demo test but fails a deeper state-transition test.

It also lacks a real lock delay and deviates from some scoring and resource requirements.

Verdict: Highly convincing at first, but undermined by a major long-term logic flaw.

4. Gemini 3.1 Pro: More Solid Than It Looks — Until Hard Drop Breaks the Board

Gemini was still one of the more surprising results.

Its visual design is basic: dark panels, turquoise borders and a fairly generic developer-demo appearance. Underneath, however, it implements most of the requested systems: three-axis rotation, wall kicks, a shuffled bag, ghost pieces, lock delay, layer clearing, scoring, OrbitControls and a working game-over path.

The code is procedural rather than elegant, but much of the ordinary game loop works correctly.

The major problem is hard drop.

When the player presses Space, Gemini moves the piece downward only inside the logical game state. It does not update the visible cube positions before transferring them into the group of locked blocks. The result is a piece that appears to remain suspended in the air even though the collision grid has already placed it on the floor or on top of another structure.

This is more than a visual glitch. From that moment onward, the player sees blocks in one location while the game calculates collisions in another. The logical and visual boards have separated.

Because hard drop is a central and frequently used control, this is a serious failure rather than a rare edge case. Gemini remains more complete than the non-executable entries, but it can no longer be described as one of the fully successful implementations.

Verdict: surprisingly capable core logic, undermined by a major synchronization bug in one of the game’s primary controls.

5. Kimi K3 — manually repaired

Kimi’s original file did not run.

At first, the damage appeared limited to two malformed Three.js URLs and one missing zero in a boundary check. A closer inspection revealed the same pattern across the entire file. Zeros or tokens were missing from piece definitions, loops, wall-kick values and array accesses. Repairing the output required changes on 26 lines.

The architecture and game design were not rewritten. The repair was deliberately mechanical: reconstruct obviously broken values, correct the CDN versions and leave the intended logic alone.

After those changes, the JavaScript passed syntax checking and the core game logic passed local tests for connected tetracubes, integer rotations, spawning, dropping, locking, layer detection and multi-layer collapse. That makes the repaired version a serious game rather than a speculative reconstruction.

But it doesn’t belong beside the untouched winners. Twenty-six changed lines are too many to describe the failure as one unlucky typo. A human had to restore the output before the browser could evaluate the model’s underlying design.

There are also remaining logical defects. Most notably, the original scoring code awards ten points instead of one thousand for clearing four layers simultaneously.

The repaired result shows that Kimi understood much of the task. It doesn’t erase the fact that Kimi failed to deliver that result itself.

Verdict: A respectable underlying solution recovered through substantial mechanical repair.

6. DeepSeek V4 Pro - almost an engine, not a usable game

DeepSeek is the classic 95-percent failure.

The difficult systems are mostly there. Its design contains real tetracubes, integer rotations, wall kicks, a bag randomizer, a ghost piece and plausible layer logic. Then the output fails at the integration layer. The start, pause and game-over overlays use conflicting identifiers. The JavaScript searches for elements that don’t exist under the expected IDs. The game engine may be largely present, but the interface cannot reliably transition into it.

DeepSeek also rebuilds active Three.js objects more frequently than necessary, and the intended soft-drop scoring is not properly connected to the actual input path.

This is not a case of the model misunderstanding 3D Tetris. It understood many of the individual problems. It failed to verify that the completed document joined them into one accessible product. DeepSeek officially promotes V4 Pro for agentic coding and integration with coding tools, but that broader capability doesn’t rescue this particular one-shot file.

Verdict: Considerable local competence, insufficient end-to-end control.

7. Kimi K3 - original output

The original Kimi file is not executable. Its CDN versions are malformed, and missing zeros damage expressions throughout the code. The browser can’t reach the architecture behind them because JavaScript parsing stops first.

This is the sharpest contrast with public reputation. Kimi K3 currently leads the WebDev Arena and is marketed specifically for long-horizon coding, playable games and complex end-to-end work. That doesn’t make the result impossible or invalidate the leaderboard. It illustrates the variance hidden inside any average score. A highly capable model can still produce a dead-on-arrival output. For the user, the distinction between a brilliant plan and an executable file is not philosophical.

Verdict: A promising design destroyed during delivery.

8. GLM 5.2 - the output itself collapses

GLM’s failure is more extensive than Kimi’s. Missing values appear throughout the CSS and JavaScript. Colors, coordinates, array definitions, dimensions and import versions are damaged. Repairing one syntax error merely exposes another.

The underlying response still shows signs of a sensible plan. It attempts to separate the board, pieces, rendering, input and interface. But the delivered document is too corrupted to function as code.

GLM-5.2 is not broadly regarded as a useless coding model. Z.ai presents it as a flagship for long-horizon coding, and it performs strongly on both official coding benchmarks and the public WebDev Arena. It is also capable of producing highly attractive web designs, sometimes more visually interesting than the safer interfaces generated by GPT. Those facts don’t conflict with the result. Visual taste, front-end composition and long-output syntactic integrity are related but separate abilities. A model can make excellent design decisions and still lose control while emitting a large stateful program.

There is also a remaining uncertainty: the pattern of missing values may have originated in the model output itself, but an export or transmission problem can’t be ruled out from the final file alone. The only thing that can be scored with certainty is what arrived.

Verdict: Potentially sound planning, unusable execution.

What the test actually shows

The simplest takeaway is that ChatGPT won, Claude followed and GLM came last. The more useful takeaway is that the models failed in fundamentally different ways.

Gemini produced an unexciting interface and kept the game logic together. Grok created an impressive, playable demo with a hole hidden near the end of the state machine. DeepSeek solved many technical subproblems but failed to connect the interface to the engine. Kimi designed a plausible system and then damaged its own output. GLM lost the integrity of the long response almost entirely.

ChatGPT and Claude didn’t win because every line of their code was brilliant. They won because the program remained one coherent object from beginning to end.

That’s why true 3D Tetris works as a test. It is large enough to require planning, spatial mathematics, rendering and product judgment. But it is formal enough that a model can’t hide behind visual spectacle. A generated city can suggest that more systems exist than were actually built. A Tetris cube either belongs in the grid or it doesn’t.

---

Appendix: The complete prompt

Every model received exactly this text. Nothing was added, adapted or paraphrased between runs.

Create a fully playable, true 3D Tetris game that runs directly in the browser.

Use:

• HTML

• CSS

• vanilla JavaScript

• Three.js loaded from a CDN

Do not use:

• npm

• Vite

• React

• TypeScript

• build tools

• external models

• external textures

• backend services

Return one complete index.html file containing all HTML, CSS, and JavaScript.

The game must be immediately playable in a browser preview. Do not provide pseudocode, partial snippets, setup instructions, or placeholder functions.

Core concept

This must be real volumetric 3D Tetris, not ordinary 2D Tetris rendered with 3D graphics.

The board is a three-dimensional grid:

• width: 5 cells

• depth: 5 cells

• height: 12 visible cells

• falling direction: downward along the Y-axis

Each falling piece consists of four connected cubes.

Pieces can move in both horizontal dimensions and rotate around all three spatial axes.

A complete horizontal X-Z layer containing 25 occupied cells must disappear.

All cubes above cleared layers must fall downward by the correct number of cells.

Pieces

Use a varied set of tetracube pieces made from four orthogonally connected cubes.

Include both flat and genuinely three-dimensional shapes.

Store every piece as integer local coordinates such as:

[
  { x: 0, y: 0, z: 0 },
  { x: 1, y: 0, z: 0 },
  { x: 0, y: 1, z: 0 },
  { x: 0, y: 0, z: 1 }
]

Use a shuffled bag randomizer so that all piece types appear once before the bag is refilled.

Movement

The active piece must support:

• movement along the X-axis

• movement along the Z-axis

• rotation around the X-axis

• rotation around the Y-axis

• rotation around the Z-axis

• soft drop

• hard drop

All positions must remain aligned to the integer grid.

All rotations must happen in exact 90-degree increments.

Use integer coordinate transformations rather than floating-point mesh rotation for game logic.

Controls

Use these controls:

• Arrow Left / Arrow Right: move along X

• Arrow Up / Arrow Down: move along Z

• W / S: rotate around X

• Q / E: rotate around Y

• A / D: rotate around Z

• Shift: soft drop

• Space: hard drop

• P or Escape: pause

• R: restart

• drag with mouse: orbit the camera

• mouse wheel: zoom

Prevent the arrow keys, space bar, and other game controls from scrolling the browser page.

Display the controls clearly inside the interface.

Collision system

A movement or rotation is valid only when every cube of the active piece:

• remains inside the board width

• remains inside the board depth

• remains above the floor

• does not overlap a locked cube

If a rotation collides, attempt simple wall kicks using nearby offsets:

• one cell left

• one cell right

• one cell forward

• one cell backward

• one cell upward

• diagonal combinations in the X-Z plane

Reject the rotation if no tested offset is valid.

Falling and locking

Pieces fall automatically using elapsed time, independently of frame rate.

When a piece can no longer move downward:

• wait for a short lock delay

• lock it into the board

• detect complete layers

• clear complete layers

• move all higher cubes downward

• spawn the next piece

The game ends when a new piece cannot be placed in the spawn area.

Layer clearing

A layer is complete when every X-Z position at one Y coordinate is occupied.

For a 5 × 5 board, this means exactly 25 occupied cells.

When one or more layers are completed:

1. briefly highlight them

2. animate their disappearance

3. remove them from the logical board

4. move every cube above them downward

5. update the score

6. update the level

Multiple layers completed at the same time must be handled correctly.

Three.js presentation

Create a polished, readable Three.js scene.

Include:

• perspective camera

• WebGL renderer

• orbit camera controls

• dark background

• transparent board boundary

• visible floor grid

• subtle internal grid guides

• ambient or hemisphere light

• directional light

• shadows

• colored cube pieces

• visible cube edges

• active-piece highlight

• translucent ghost piece

• clear visual distinction between locked and active cubes

The board must remain spatially understandable from different camera angles.

The camera should initially look diagonally downward into the board.

Limit camera zoom so the player cannot accidentally lose sight of the game.

Orbiting the camera must not alter the logical control directions. Controls always use the fixed world X and Z axes.

Visual style

Use a clean, modern arcade style.

The game should feel like a finished browser game rather than a technical demo.

Use:

• dark neutral background

• bright but tasteful piece colors

• subtle transparency

• small gaps or beveled appearance between cubes

• soft shadows

• restrained animations

• readable typography

• responsive layout

Do not use external images, fonts, models, or textures.

Interface

Display:

• score

• level

• cleared layers

• next three pieces

• pause state

• game-over state

• restart button

• control guide

The canvas should use most of the available browser window.

The interface must remain usable on smaller desktop windows.

Add a clear start overlay with a “Start Game” button.

Scoring

Use:

• one cleared layer: 100 × level

• two cleared layers: 300 × level

• three cleared layers: 600 × level

• four cleared layers: 1000 × level

• each additional simultaneous layer: add 500 × level

Soft drop awards 1 point per manually dropped cell.

Hard drop awards 2 points per dropped cell.

Increase the level after every five cleared layers.

Increase falling speed with each level, but keep a reasonable minimum interval.

Architecture

Keep the code organized inside the single HTML file using clear classes or modules such as:

• Game

• Board

• Piece

• Renderer

• InputManager

• HUD

The board state must be logical data, not derived from Three.js meshes.

Three.js objects should only visualize the game state.

Do not use mesh positions as the authoritative collision system.

Use integer grid coordinates for:

• collision detection

• rotations

• layer detection

• hard drop distance

• ghost-piece position

• locking pieces

Performance

Reuse cube geometry and materials where practical.

Do not recreate geometry every animation frame.

Remove obsolete Three.js objects cleanly.

Use requestAnimationFrame for rendering.

Use elapsed-time accumulation for automatic falling.

The game must remain smooth with many locked cubes.

Required result

Return only one complete HTML document.

It must contain:

• all HTML

• all CSS

• all JavaScript

• the Three.js CDN import

• the OrbitControls CDN import

The result must be playable immediately in the browser preview without installing anything.

Before finishing, verify that:

• pieces spawn

• pieces fall automatically

• X and Z movement works

• rotation around X, Y, and Z works

• wall and cube collision works

• hard drop works

• the ghost piece works

• layers are detected and cleared

• cubes above cleared layers move downward correctly

• scoring works

• levels increase

• pause works

• restart works

• game over works

• camera orbit and zoom work

• no placeholder code remains

Do not explain how to build the game. Build the complete playable game.