internal draft — not published — numbers final as of the 63k freeze

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

by Alakazam · July 2026

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.

seat view, ball kicked, boost gauge draining

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.

grid clip of one aerial play seen from all four seats

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:

early-window action authority vs training step, SP vs MP
early-window action authority vs training step, SP vs MP
the same context and seed rolled at 10k, 30k, 50k, and the 63k freeze

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.1

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.

side-by-side, same inputs, guidance off vs w=4

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.

four-seat autopilot match, 30s

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.2

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:

PieceOursPaper (demo)
CodecRAEv2, 125k steps, PSNR 28.6same recipe, PSNR 29.7
Single-player1B, 52k steps, gFID 12.85B-class references at 10.7
Multiplayerwarm-start at 52k, 63k steps30k warm-start, 100k steps
Hardware4 nodes × 8 H100, preemptibleundisclosed fleet
Cost≈$10k end to endn/a

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:

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.3

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.

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.

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.

the 1B single-player model (the tier you drive) on the same arena
364M student running live on the M1 MacBook

Evaluation#

We used the paper's metrics where we could run them (gFID against held-out data; {{GFID}} for the multiplayer model at the freeze) 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:

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

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

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.

OOD corner-parking degradation and recovery

Open source#

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

relay, and the web UI on your machine.

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.

1. The paper trains with per-player action dropout so any seat can run on autopilot (their §6.8). The cost side of that trade—diluted action signal, slower per-player controllability—is visible at 1B scale and mid-training budgets; at the paper's scale it presumably washes out.

2. The report's operations section is the part we most wish had existed a week ago: fleet-consistent resume on spot instances, NCCL topology luck worth 25-40% of throughput, and why you should never trust a checkpoint that merely exists.

3. We also built and measured the "obvious" fix, overlapping decode with the next denoise on a separate CUDA stream: bit-exact, and zero throughput gain on the B200. The paper's answer is making the decode itself cheaper, and they are right --- see the next bullet.