MIRA Mini: we reproduced a multiplayer world model in a week

It works#

The small wonder of the original holds up at a fifth of the size: there is no game engine underneath, and the model still keeps score, tracks your boost gauge, respawns cars after demolitions, and shows four views of one match that agree with each other about where the ball is.

The four-view consistency is the part that still feels illegal. Each player sees their own first-person view; the model predicts all four jointly as one tiled frame, so when the ball flies past you on your screen, it arrives on your teammate's screen from the right direction at the right time. At 1B parameters and a fifth of the paper's training budget the views bind later in training and less perfectly than the 5B demo, but they bind.

You can steer it (we measured exactly how much)#

Here is the honest part. When our multiplayer model first became playable, at around 30-40k training steps, it looked great and felt dead. The cars drove themselves competently; your inputs seemed to vanish. We spent two days convinced we had a bug: we bisected the browser key capture, the WebSocket relay, the seat routing, the action encoding. Every layer was correct. The model was simply young.

The tool that settled it is one we now recommend to anyone training world models: roll the model twice from the same context with the same random seed, holding opposite steering keys, and measure how fast the two futures diverge. No probe network to train, no human in the loop, and it cannot be fooled by the model looking good. We call it the divergence ladder, and it turned "steering feels dead" into a curve:

Two findings from that curve. First, controllability arrives late and from the far end: the model obeys you at a four-second horizon long before it obeys you in the first second, which is exactly the window your hands can feel. Second, multiplayer training pays for its four-view consistency with roughly a 2x step-count delay in per-player control compared to the single-player model, which we attribute to the recipe's per-player action dropout: the same mechanism that makes autopilot possible dilutes the action signal while it trains.¹

Then we found a lever. Because the model is trained with action dropout, it knows two futures for every state: one conditioned on your inputs and one where it ignores you. At inference you can extrapolate between them, the same classifier-free-guidance trick image models use for prompts, applied to controller inputs. No retraining. On the 50k checkpoint it took guidance weight 4 for our playtests to cross from "am I doing anything?" to "I'm driving this car"; on the frozen 63k model the same crossing happens at weight 2, the setting with no visible image cost. The measured early-window authority moved with the playtests both times. To our knowledge nobody had applied action guidance to rescue controllability in an undertrained multiplayer world model before; it costs a second forward pass per step, and it ships as a toggle in our demo.

Boost and jump are further behind. The paper's Figure 13 says why: rare actions are recovered last, and the binary keys are rare in bot play. At the freeze they show their first clear response (the mid-horizon boost signal more than doubled between 50k and 63k, exactly where our pre-registered prediction put it) but they do not yet feel reliable. We publish the per-checkpoint curves rather than pretend otherwise.

Autopilot#

Same as the original: hide a player's actions during training and the model learns to predict what that player would have done. Since the data is bot self-play, an empty seat plays like the bot. Four autopilot seats make a watchable match with kickoffs, saves, and the occasional own goal.

Why reproduce it?#

The original team built MIRA as a stepping stone to physical AI. We reproduced it for a more basic reason: "open" and "reproducible" are different claims, and the gap between them is where most of the cost lives. Five days after the release the repository had hundreds of stars and no public reproduction.

What we can now report from the other side: the recipe is real. It works as written, at a scale a small team can afford, on the released data alone. The cost is not in the GPUs; it is in the operational machinery the paper does not cover (and has no obligation to): keeping a four-node spot-instance fleet training through preemptions without losing a step, evaluation discipline so you know a checkpoint is better rather than merely newer, and a serving stack that turns a checkpoint into something four people can actually join.²

Data#

We trained on the released dataset exactly as published: about 15,800 bot-vs-bot matches, roughly 2,000 match-hours, with four synchronized views and per-player action streams. The paper's flagship models train on the full ~10,000-hour corpus, about five times more than the release. That gap sets a ceiling we can measure: the paper's own data-scaling ablation shows image quality saturates early but action-following keeps improving with unique data, so our controllability ceiling is lower than theirs before we train a single step. Reproducers should budget expectations accordingly.

What we ran#

The published recipe, at the paper's ablation scale, with every deviation documented in the report. The short version:

One deviation is worth calling out because we got to test the paper's advice against our own instinct. The paper's budget-split ablation says a modest single-player share is best before switching to multiplayer. We warm-started later than their demo did (52k vs 30k), reasoning from their own sweep. The controllability lag we measured afterwards is consistent with either choice; the honest answer is the ablation that separates them costs about $3k and we list it as future work.

Making it fast#

The paper's demo runs at 20 fps on one B200 because of two things it mentions almost in passing: few-step distillation and custom decode kernels. Our reproduction started at 9 fps, and closing that gap became its own project:

• A CUDA-graph serving port (on NVIDIA's FlashDreams) took the single-player

model from 9.3 to 25.7 fps, bit-exact. The same port on the four-view model yields 10.8 fps: at four views the codec decoder becomes the bottleneck.³

• So we profiled the decoder, and the profile was the surprise: of its 89 ms,

only 6.5 ms was real matrix math. The rest was a materialized attention mask forcing a slow kernel, and thousands of tiny elementwise launches. Dropping the mask for a causal flag, compiling the elementwise storm away, and writing one custom Triton kernel for the short-sequence temporal attention took decode from 89 to 15.7 ms (5.7x) at 57 dB parity --- and the four-view model from 11 to 18 fps, on the full-quality decoder. The paper mentions custom decode kernels in one sentence; that sentence is doing a lot of work.

• The paper distills its pretrained model for few-step sampling but leaves the

warm-start construction unspecified. We contribute one: inject the step-size conditioning with a zero-initialized projection (so step 0 is bit-identical to the base model), then distill. Two sampling steps now match our eight-step quality; the launch demo serves on $2/hr GPUs at ~19 fps measured.

• A retrained small decoder (8x fewer decode FLOPs, same latent space) and a

364M student distilled from the 1B close the loop: the student plays the full game on a 2021 MacBook at ~8 fps, no cloud, through an MLX port of the transformer and a Core ML decoder.

Evaluation#

We used the paper's metrics where we could run them (gFID against held-out data: 28.7 for the multiplayer model at the freeze, versus 29.0 at 50k --- improving, against the paper's 9.4-9.9 at five times our budget) and built one of our own where we could not afford theirs. The paper measures controllability by training an inverse-dynamics probe; our divergence ladder gets the same qualitative curve for the cost of two rollouts per checkpoint, and it reproduced our blinded human playtest reports checkpoint for checkpoint. The report publishes both the instrument and its calibration against the single-player model.

Limitations#

Everything the paper lists, plus the ones specific to reproducing at a fifth of the scale on a fifth of the data:

• Early-window steering is the weakest axis, quantified above; guidance narrows

it at 2x inference cost. Boost and jump lag steering.

• Replays after goals are hallucinated. The model has a ~4-second memory, so

the replay shows a plausible goal, not your goal. (The paper reports the same.)

• Out-of-distribution play (parking all four cars in a corner, refusing to

chase the ball) degrades the image, and our model recovers the same way the paper describes: it snaps back to something sensible rather than staying broken.

Open source#

• Weights: the 1B single-player model, the few-step distilled variant, the

364M laptop student, and the four-player model, each as a pull-and-play bundle (CC BY-NC-SA, inherited from the dataset).

• Player: pip install alakazam-mira; mira play starts the model, the room

relay, and the web UI on your machine.

• Technical report: every number in this post, with the training logs,

evaluation protocol, the divergence-ladder instrument, and the failure archive.

Credits#

MIRA is General Intuition and Kyutai's work, with Epic Games, released openly enough that a small team could rebuild it in a week. That is the point of open releases, and it worked. Errors and shortcuts in the reproduction are ours alone. The dataset is bot-collected; no human gameplay was used, by us or by them.

Alakazam, July 2026.