Skywork AI has open-sourced Matrix-Game 4.0, an interactive world model that treats a video generator as a renderer rather than a game designer. The official repository dates the release to October 15, 2026, and the paper reached Hugging Face daily papers on October 21. The headline numbers: 480p gameplay at 60 FPS on one RTX 5090, with 112 ms from key press to pixels, under an Apache-2.0 license.
The idea matters more than the frame rate. Earlier playable world models, such as the ones we covered from Odyssey and Runway, ask a video network to remember the world, obey physics and render everything at once. Matrix-Game 4.0 splits those jobs apart.
TL;DR: Matrix-Game 4.0 at a glance
| Question | Answer |
|---|---|
| Who made it? | Skywork AI (paper authors include Jihai Zhang, Runjia Qian and Yahui Zhou) |
| When was it released? | October 15, 2026; technical report and RTX 5080 / 5070 Ti optimizations followed October 16 |
| What does it do? | Runs a playable game where an engine holds the rules and a video model draws the frames |
| Speed? | 480p at 60 FPS on one RTX 5090, 112 ms key-press-to-display latency (paper) |
| Smaller GPUs? | About 67 FPS on RTX 5080 and 58 FPS on RTX 5070 Ti, fixed prompts, one step (repo) |
| License? | Apache-2.0, third-party assets keep their own licenses |
| Can I try it? | Yes: code on GitHub, weights on Hugging Face, plus a browser demo described in the README |
| Scenes shipped? | Medieval Castle, Ancient Egypt, City Racing |
What is Matrix-Game 4.0, in plain terms?
A normal video game has two halves: logic (where things are, what collides, what a button does) and rendering (what it looks like). Matrix-Game 4.0 keeps the logic in a small, conventional game engine and hands the rendering to a neural network.
The engine produces cheap, low-poly frames. The neural renderer takes those frames and, in the repository's words, "transforms low-poly RGB frames into detailed visuals through streaming neural rendering." The player sees a rich, stylized scene, while the engine still decides what is solid, where the player stands and what a click does.
That is the opposite of the "whole game inside the network" approach. It trades some generality for something builders care about: rules that stay consistent because code, not a probabilistic model, enforces them.
How the system is built
The paper lays out three pieces working together.
- A lightweight game engine maintains persistent world state and enforces rules, separate from visual generation.
- A multimodal coding agent turns a player's idea into game code and dynamic scene captions.
- An autoregressive video renderer converts the engine's proxy frames into detailed visuals, guided by those captions and memory references.
Matrix-Game 4.0 architecture: game engine, coding agent and video renderer for a playable world model
Image: Skywork AI
The renderer is trained on aligned pairs of low-poly and high-fidelity video, so it learns to "dress" simple geometry. It is then distilled into a causal generator that produces four-frame chunks in one or two denoising steps. Distillation is what makes real time possible: standard diffusion video models need many denoising steps per frame, which is far too slow for a game.
Because generation is causal, each chunk only looks backward at what already happened, plus memory references. That is the same property that lets a world model stream frames to a player instead of rendering a clip offline.
The numbers: from 4.5 FPS to 83 FPS
GPU memory stack showing the peak memory budget a real-time Matrix-Game 4.0 renderer needs on consumer cards
The paper's optimization story is the most useful part for anyone planning to run this locally.
| Metric | Reported value | Source |
|---|---|---|
| Gameplay on one RTX 5090 | 480p, 60 FPS | Paper abstract |
| Key-press-to-display latency | 112 ms | Paper abstract |
| One-step steady-state throughput, RTX 5090 | About 83 FPS, 18.2 GiB peak memory | Paper |
| Two-step throughput, RTX 5090 | About 57 FPS, same memory | Paper |
| RTX 5080, one step, fixed prompts | About 67 FPS, 12.8 GiB | Paper and repo |
| RTX 5070 Ti, one step, fixed prompts | About 58 FPS, 10.9 GiB | Paper and repo |
| Optimization gain (Table 2) | 4.5 to 83.4 FPS (19x); latency 1110 ms to 112 ms (9.9x) | Paper |
Two caveats are worth stating plainly. First, the repository says its FPS figures exclude video I/O and use fixed prompts with SageAttention, so they are steady-state throughput, not necessarily what you see in a full interactive session. Second, the headline 60 FPS gameplay figure and the 83 FPS throughput figure are different measurements: the first is end-to-end play, the second is renderer throughput at one denoising step.
The paper also compares against other systems in its Table 3 and says Matrix-Game 4.0 has the lowest end-to-end latency among them, about a fifth of the next one, and is the only one that runs on a single consumer GPU. That is the authors' comparison, on their chosen systems and settings, and we have not reproduced it.
A look at the output
Skywork's project page includes an Ancient Egypt clip from the third-person shooter scene.
Video: Skywork AI
Resolution is 864 x 480 in the repository, so this is not a visual leap over a modern engine. The pitch is that the look comes from a model conditioned on text captions, not from hand-authored art assets.
How it compares with other world models
Wireframe cube over a grid floor, illustrating an engine-backed playable world model versus pure video generation
The field is splitting into two camps. One treats the world model as the whole game. The other, where Matrix-Game 4.0 sits, treats it as a rendering layer on top of explicit state.
| Approach | Example on explainx.ai | Where the rules live |
|---|---|---|
| Pure learned world, many players | Odyssey Agora-2 | Inside the model, with explicit shared state |
| Foundation world model for general simulation | Odyssey-3 | Inside the model |
| Video-generation giant entering the space | ByteDance Seedance as a Genie rival | Inside the model |
| World model for robots | Dream Labs Dream-1 | Inside the model, action-conditioned |
| Engine plus neural renderer | Matrix-Game 4.0 | In executable game code |
The practical difference: if you want a game where a door stays locked until the player has a key, an explicit engine can guarantee it. A pure video model can only make it likely.
Why this matters for builders
Three things stand out.
- Consumer-GPU real time. A card many hobbyists could own, rather than a datacenter rack, is the target. If you are weighing local AI hardware, the RTX 5090 supply rumor is relevant context.
- Code as the control surface. A coding agent writes game code and scene captions. That points toward a workflow where you describe a game and iterate on text and code, instead of retraining a model.
- Open weights and assets. Apache-2.0 plus released low-poly game assets means you can reproduce the demos and swap in your own scenes.
World models also matter beyond games. Engines that stay consistent under a learned renderer are a plausible way to generate training environments for agents and robots, a theme running through our coverage of GreenWAM.
How to try Matrix-Game 4.0
The README directs you to the v4 folder for installation, resource downloads, offline rendering and the online browser demo. In outline:
- Clone github.com/SkyworkAI/Matrix-Game and open the v4 README.
- Download checkpoints and assets from Hugging Face under
Skywork/Matrix-Game-4.0. The listed scene folders arefps-castle,fps-egyptanddriving_game. - Pick a GPU path. The repo documents single-GPU inference for A100, RTX 5090, RTX 5080 and RTX 5070 Ti.
- Start with the one-step setting if memory is tight; the paper's figures put one-step peak memory at about 18.2 GiB on the 5090 and about 10.9 GiB on the 5070 Ti.
We have not run the model ourselves for this post, so treat the figures above as the authors' reports. The paper describes the renderer as a 5B-parameter diffusion transformer initialized from Wan2.2 5B and distilled into a causal generator, which helps explain the memory figures above.
What is not yet established
- Independent reproduction. All speed and latency numbers come from Skywork. No third-party benchmark was available when we wrote this.
- Generalization beyond the demos. Three shipped scenes show the pipeline works; they do not show that any prompt becomes a good game. The coding-agent step is described in the paper, but the quality of games it produces from arbitrary ideas is not measured in the material we read.
- Visual quality at 480p. The renderer output is 864 x 480, and the repository does not report a perceptual quality benchmark.
- Long-horizon consistency. Earlier versions focused on memory over long play. Matrix-Game 3.0, released March 27, 2026, was billed as streaming interaction with long-horizon memory; how 4.0 compares on very long sessions is not reported in the repository summary.
The series so far
Matrix-Game has moved quickly. According to the repository: version 1.0 arrived May 12, 2025, 2.0 (real-time interactive long video generation) on August 12, 2025, 3.0 (streaming interaction with long-horizon memory) on March 27, 2026, and 4.0 on October 15, 2026. The through-line is a move from "generate a controllable video" to "run a game," and version 4 is the first to bring an executable engine into the loop.
Bottom line
Matrix-Game 4.0 is a credible open example of the hybrid design many researchers expect to win in practice: deterministic logic where you need guarantees, neural rendering where you want richness. The 60 FPS on one RTX 5090 and 112 ms latency claims are strong, openly released and checkable. The open questions are quality, generality and independent numbers.
Follow @explainx_ai for updates as people start running the weights.
Related reading
-
Another open world model: Tencent Hy-Nomas, steered by text and camera
-
Official: Matrix-Game repository, project page, paper on Hugging Face
Details are accurate as of October 21, 2026; check the repository for later changes.
