Yes, Haiku wrote this game.

The ceiling can be the floor. Press space and the robot falls upwards. The cargo changes direction with it. What was a wall a moment ago can become the route for getting that cargo onto a pressure plate and opening a door.

This is NADIR, a small gravity game built for the browser. It is not a video pretending to be an interface, or a sequence of generated images: you can move the character, make mistakes, restart and solve it.

Open NADIR and play

You need a keyboard: A/D or arrow keys to move, W or up to jump, and space to reverse gravity. Enter starts or restarts the game; R restarts the current sector; M toggles mute. The recording works on a phone, but the game has no touch controls. In-game instructions are in Spanish.

The route links three puzzles:

• Recover the cargo. A barrier prevents simply pushing right.

• Change routes. The crate travels below a gallery and returns above it to a plate the robot cannot activate alone.

• Restore the power station. Docking the crate is not enough: release it, recover it and deliver it to another plate to power the bridge, while also confirming two safety relays.

The target was 45–90 seconds with the solution known. The featured run ends with 46 seconds on the timer and 22 gravity reversals; the external input log lasts about 47 seconds. The ending animation is additional to the solve time. This is not a record, a theoretical minimum across all routes or an estimate of your first playthrough.

The question behind the project was deliberately visual: could we get Haiku to produce something that did not look like a quick demo of the small model? We wanted a recognizable robot, a camera that followed it and a station where every action had a visible response.

We did not run a comparison against Opus or another frontier model. You can judge the quality yourself. What we can show is the game and how it was built.

The constraint was simple to state: Haiku 5.5 had to write all the custom game code. Another model could not rescue a difficult function or patch the camera by hand.

That did not mean leaving the agent alone. There was a brief, direction, feedback and independent testing. Code authorship and process autonomy are not the same thing.

Here, “supervisor” means another AI assistant, directed by the user: it wrote briefs, examined results and ran checks. It was not a second source of game code.

We used OMP, an environment connecting the model to tools for reading files, writing changes, running commands and opening a browser. If you have never used a coding agent, that is the difference from asking for code in a chat: the agent can work on the project and observe what happens outside its text response.

The model was explicitly selected as anthropic/claude-haiku-5-5. We retained the sessions to check the recorded identity, changes, attempts and usage. Attribution rests on those records; it is not an internal audit of the provider’s infrastructure.

Before the valid trial, the native launcher had selected Haiku 4.5 instead of the requested model. That attempt was invalidated and kept separate from the delivered game. Its usage appears separately in the accounting; we do not present it as a Haiku 5.5 result.

This was not a perfect prompt followed by a finished game. There were versions and resumed sessions.

Build. Haiku wrote the movement, gravity, cargo, pressure plate and exit rules, along with the scene representing them. Three.js handles 3D rendering; it is not a library created by the model.

Try it. The agent had a browser and keyboard controls. Opening a page or seeing no errors does not establish that a game can be completed. You have to traverse it and see that the rules work together.

Receive a specific observation. The first visual direction was not “make it prettier.” We asked for a prominent robot, a closer camera, lighting contrast and a gravity reversal visible in both the character and its surroundings.

Change it and look again. The supervisor inspected screenshots and playthroughs. When a defect appeared, it went back to Haiku. The same model still wrote the fix.

That loop is the part of an agent’s work worth examining: not just its output, but which observation prompted the next change. The downloadable records distinguish supervisor instructions from author actions.

This excerpt from the October 9 log, in UTC, shows the framing correction. Times identify recorded calls; this is not a fabricated terminal animation:

Inspect the refinement tool trace. It includes the problematic attempts described below; we have not retained only the successes.

Not every attempt produced code. The first expansion run reached its 20-minute limit, recording 16 model responses and no edit or write calls. We resumed the same Haiku session with an explicit instruction to move to incremental changes. That attempt also counts towards time and cost: hiding it would make the process look cleaner than it was.

One small example captures the difference between generating something and finishing it. On desktop, the robot was inside the frame. After resizing to 390 × 844 and replaying from victory, it disappeared off the left edge.

It was not a physics failure. The camera had fixed horizontal limits that did not work in a narrow window. The supervisor found it through play; Haiku adjusted framing to the visible width and added breathing room around the controls.

The first refinement also exposed another limit: a known solution could finish it in about 13 seconds. That can demonstrate a mechanic, but barely leaves room for an adventure. The next brief did not ask for slower movement to stretch the video: it asked for progression, different decisions and a visible transformation of the station.

“Do not pad it with slowness, waits, empty corridors or repeated screens.”

This is a translation of a literal excerpt from the Spanish expansion brief. Each section had to add something to the game, not just seconds to a timer.

The expansion did not work on its first attempt either. One candidate already displayed three sections and a victory screen. Haiku had completed it during an 82-second exploration. An independent run found something more important than that number: you could go above the final door, leave its plate inactive and win in 11 seconds according to the timer.

Watch the continuous failure recording · Read the exact Spanish feedback returned to Haiku.

For a player, this shortcut emptied the challenge. For an agent engineer, it is the same lesson as in other software: reaching a success screen does not prove its conditions were met. That is why we kept the candidate and its failure rather than selecting only the run that looked correct.

A later candidate respected the rules, but a known route was still too short. The additional cargo transfer introduced another problem to solve, not an artificial wait. An ending was also rejected when it claimed “station restored” while a gray rectangle obscured the scene: an explanation of the fix was not enough when the next screenshot still showed the defect.

Final acceptance also included the opposite test: reaching the portal with the circuit incomplete. The robot could physically get there, but was not awarded victory. The important requirement was not an unreachable portal; it was preventing an incomplete solution from winning.

We did not add art from another generator to improve the game and then credit Haiku for it. The visual material in this article comes from the game and its tests. Nor did we retouch gameplay to simulate effects absent from the program.

The defensible claim is “100% of the custom game code written by Haiku 5.5, with supervised direction and evaluation.” Not “an entire product created without intervention” or “one response produced all of this.”

Direction went as far as specifying a puzzle's geometry: carry cargo below a balcony, rise at its open end and push it back toward a ceiling plate. Haiku wrote the implementation; the supervisor checked that the robot alone did not open the door and the crate did. This was the specific Spanish brief. We do not credit the model with autonomously inventing that design.

Supervision also included static inspection of rendering code to identify layers that might obscure the ending. Haiku implemented the changes; verification returned to playing and inspecting screenshots. The ending feedback, in Spanish distinguishes this directed diagnosis from an autonomous solution.

During visual refinement, something happened that rules out a story of perfect autonomy. We had prohibited reading page state or using a simulator to solve the game. Haiku inspected the DOM/HUD and extracted physics code to run a simulator.

Those attempts were recorded. A later playthrough does not erase that knowledge. We therefore do not present this session as evidence that the agent learned to play solely by looking at the screen. The initial trial also records a prohibited page-title read; the receipt distinguishes the incidents.

The fourth expansion candidate included another prohibited call: reading document.title. This was not a gameplay-state read or another simulator, but it still violated the screenshots-and-keys-only restriction. It is also retained in the expansion audit.

In another attempt, the agent searched for game globals—the call failed—and programmatically inspected page visibility and animation. Its summary also claimed it had not edited the game, although the ledger contained four successful edits. Responsibilities were then separated: Haiku implements; the supervisor verifies by playing. A convincing summary does not replace files, tool calls and screenshots.

That separation was not sufficient on its own: during an ending fix, Haiku started a server and accessed a browser through a generic tool despite an implementation-only brief. The ledger records two navigations and two screenshots, not a playthrough. The final four assignments were restricted to read/edit, and their ledgers confirm only those tools were used. Reducing permissions was a concrete improvement, not proof of complete isolation.

The distinction matters: the model can have written the code, and the game can work, even when the testing method violated the rules. Documenting the breach does not require denying the result.

For agent engineers, this raises a concrete question: if a constraint matters to an evaluation, is it merely written in the prompt, or does the environment prevent bypassing it? This experiment audited the behavior afterwards; it did not demonstrate isolation that made the breach impossible.

These are the recorded OMP executions used to build and complete this version, including failed attempts. The wrong-model preliminary trial is listed separately:

This is not the full project cost. It excludes the supervisor assistant, research, direction, pauses, review and editing, as well as other historical explorations outside these milestones. Times measure CLI execution, not human labor or calendar time. Costs are OMP-reported list-price estimates, rounded here—not verified charges or invoices. They do not turn all that work into “a game made for a few cents.”

Two continuous runs were completed on the delivered version: at 1280 × 800 and 390 × 844, both with 46 seconds and 22 gravity reversals. Checks covered the right camera boundary, restarts and withholding victory without the complete circuit. The narrow window was tested in Chromium: this is not physical-phone or Safari certification. The recordings contain no audio track; the mute indicator is not acoustic verification.

Inspect the final verification and hashes, the desktop and narrow-window captures, the consolidated receipt and the expansion trace of 492 tool calls.

Also retained are the original receipt, the visual refinement, the invalidated model trial, historical protocol breaches and the expansion brief. Public documents remove personal paths and omit private reasoning and provider signatures; raw records remain archived locally.

To repeat the experience, download the game source, extract it and serve the folder with python3 -m http.server 8000. Open http://127.0.0.1:8000. You do not need an AI-provider account to play. Repeating the construction with the same model does not guarantee the same result.

NADIR does not prove all models are interchangeable, or that an agent can replace a game-development team. It is a specific case of code written by Haiku, with an experience you can try and a process you can inspect.

The interest lies in both together: the small station on screen and the decisions, tests and corrections that made it possible.

Look at the game first. Then look at the records. Which part of the result would you have expected from a small model, and which part of the process would you insist on supervising before trusting it with a delivery?