On October 15, 2026, SkyworkAI, a unit under Kunlun Wanwei, pushed Matrix-Game 4.0 to GitHub. The series repository dates back to 2025-05-06, and this release sits inside the subdirectory Matrix-Game-4/. The homepage is matrix-game-v4-0.github.io, and the weights and assets are hosted on Hugging Face as Skywork/Matrix-Game-4.0, covering three scenes: Medieval Castle, Ancient Egypt, and City Racing.
The project lives at SkyworkAI/Matrix-Game, repository address: github.com/SkyworkAI/Matrix-Game. As of a GitHub API snapshot on 2026-10-16, the series repository holds 2,488 stars and 272 forks. One caveat: that is the aggregate for the whole series, folding in versions 1.0 through 3.0, not just 4.0.
The README positions it as "Streaming neural rendering for executable low-poly games." In plain terms, the engine still owns gameplay, physics, and input, but renders only a rough low-poly "proxy" frame first; a causal video model then renders that crude frame, in a stream, into the final image. This is a single-project teardown, not a comparison or install guide. This site's September 14, 2026 comparison already runs the four accounts of license, hardware, data, and openness, and a companion SOP article covers installing and running; this piece includes no commands.
Engine Draws the Skeleton, the Model Paints the Surface
In a normal game, the engine handles both state and rendering: it positions objects each frame, then applies materials and lighting. Matrix-Game 4.0 takes another route. The engine's first frame is still a low-poly image, with simple geometry, flat colors, and almost no shading; the polished image that reaches your eyes is filled in by the video model.
That is the biggest difference from ordinary video generation. Text-to-video gives you a clip from nothing, with no link to a player's actions; here the low-poly frame already carries the engine's physics and input, so the model renders a skeleton whose physics and camera motion are already fixed, rather than imagining from zero.
The README settles the division of labor: "The game engine owns gameplay, physics and input. A causal video model renders the clean low-poly RGB stream; HUD and sound remain frame-aligned presentation layers outside the model." Note the last clause: the HUD, crosshair, health bar, and sound are not generated by the model but stacked as separate, frame-aligned layers outside it. That keeps the must-be-pixel-exact elements out of the generative model entirely.
Three Layers: State, Rendering, and Instruction
The README and homepage split the system into three layers, read from the bottom up.
The first layer is the game engine: it holds game state, runs physics, takes input, and outputs the low-poly proxy frames. Determinism is the point here, since collisions, hits, AI behavior, and racing lines come from conventional code, not model randomness, so gameplay stays reproducible and tunable.
The second layer is the coding agent: a user gives instructions in natural language, and the agent turns them into new rules that rewrite the engine's behavior, while retrieving engine state to produce a "dynamic prompt" for the video model. So editing terrain, NPC behavior, or rules lands through two paths, code and conditional text, with no retraining.
The third layer is the causal DiT video model. It performs streaming neural rendering: the model is distilled to one or two denoising steps, and each generated latent equals four output frames, rolling forward to form a "stream." "Causal" is the key: the model looks only backward, never forward, which lets it generate while you play rather than waiting for a whole clip to finish.
Version Line: From 1.0 to 4.0
The README's News section dates four generations: 1.0 (2025-05-12), 2.0 (2025-08-12), 3.0 (2026-03-27, a turn to real-time streaming interaction with long-term memory, so the image remembers earlier events), and 4.0 (2026-10-15). The gap from 3.0 is the longest, about seven and a half months, and 4.0 adds a fuller toolchain (offline rendering, a browser demo, a playable game) plus the first preset for a single RTX 5090.
The License Chain: Read One Account as Three
One license name does not tell the story here; you have to read it directory by directory, with the LICENSE originals as the authority.
The first layer is the root repository's LICENSE, which is MIT, reading "Copyright 2025 SkyworkAI and contributors." It is the older license used since 1.0 and mainly covers the early code.
The second layer is the v4 directory's Matrix-Game-4/LICENSE, which is Apache-2.0, the full 11,357-character text and the primary license for the new 4.0 code.
The third layer is the bundled licenses/ directory inside v4, where components keep their own originals. MG4CF's file is the Apache-2.0 text; TAEHV's is MIT, carrying "Copyright (c) 2025 Ollin Boer Bohan." Components keep their original licenses; being placed in this repository does not relicense them.
The README states it directly: "Project code is Apache-2.0; vendored components retain their original licenses. Model and asset distributions carry their own accompanying license statements." So code is one layer, components another, weights and assets a third.
For the weights and assets, this article will not guess. The license field on the Hugging Face model card for Skywork/Matrix-Game-4.0 could not be retrieved for this piece, so the only honest wording is the README's own: weights and assets carry separate statements, with that model card as the final authority. Naming a specific license for them would be speculation, and is not done here. The takeaway: if you build only on the 4.0 code, the v4 directory's Apache-2.0 applies; for the weights or assets, read that statement on the model card first.
Performance: Three Numbers, Three Accounts
Three sets of performance numbers circulate for the same project, with different sources and definitions; they must be read together, not cherry-picked.
Account one, the official launch figures: a single RTX 5090, 480p at 60 FPS, end-to-end latency under 150 milliseconds, a steady-state 83 FPS for one-step denoising, and 18.5 GiB peak VRAM. These are official figures and were not independently reproduced, so read them as vendor claims rather than third-party measurements.
Account two, the homepage panel is still a placeholder. As of this site's visit on 2026-10-16, it showed 0 FPS, 0 ms, 0p, and 0 GPU, with a footer reading "project page preview, content will be updated at release." The official numbers above have not yet been populated on the project's own site. At this stage, the README is the more reliable place to check official performance.
Account three, the README's own measurements, the hardest of the three. It reports a single NVIDIA A100-SXM4-80GB at 864 x 480, using one denoising step plus TAEHV encoding and decoding, SDPA, ring and fused DiT, and CUDA graphs, excluding startup and warmup:
| Scene | Prompt mode | Measured FPS | What is measured |
|---|---|---|---|
| Castle / Ancient Egypt | Fixed | about 38-39 | Model processing within an online session |
| Racing | Fixed | about 38.5 | Server-side online pipeline throughput |
| Racing | Dynamic | about 28.9 | Server-side online pipeline throughput |
The README states the reading boundaries, and they must travel with the table. First, --fps 40 is a target capture cadence, not a throughput or latency guarantee. Second, those numbers are neither browser presentation FPS nor action-to-photon latency. Third, the two Racing rows come from an earlier checkpoint with the same architecture and inference configuration, so they serve only as a reference.
The core is to separate the three senses of "real-time": model processing throughput, which the A100 numbers of about 38-39 FPS describe; server-side pipeline throughput, which includes waiting for game frames; and the presentation frame rate a player actually perceives. Which layer the official 480p 60 FPS belongs to has to be checked against the launch wording, and the README's 38-39 FPS is model-side throughput, not a claim that your screen runs at 38 frames.
The RTX 5090 Preset
A highlight released alongside 4.0 on 2026-10-15 is optimization for consumer flagship cards: two presets, --preset rtx5090 (PyTorch SDPA) and --preset rtx5090-sage (SageAttention), so a single RTX 5090 can run the pipeline.
The README points to two sources of saving. First, the DiT block linear weights are converted to FP8 at load time and their activations are quantized during inference, while embeddings and the output head stay in BF16; that compresses the most compute-hungry matrix multiplies to 8 bits while keeping the precision-sensitive ends higher. Second, fused kernels work with CUDA graphs to cut operator launch and scheduling overhead. The presets share the same scene checkpoints and resources, so no separate quantized weight file is needed. A version for the RTX 5080 and 5070 is slated for next week and is not out yet.
Ecosystem and Boundaries: A Single-User Demo, Not Cloud Gaming
On the ecosystem side, 4.0 is fairly complete. The browser demo runs single-user WebRTC (MediaMTX plus serve.sh, listening on 127.0.0.1:8025 by default). The local play and recording build targets macOS and Linux and needs CMake, C++20, SDL2, and FFmpeg.
The boundaries are equally plain. Windows is only a "retained entry," not validated for feature parity. A single server process supports only one active session and one scene model, so multi-user or multi-scene concurrency is not provided. And networking binds to loopback by default: the security statement reads "This is a trusted single-user demo, not an authenticated public cloud-gaming service," with HTTP, RTSP, and WebRTC on loopback, and the project explicitly asks that they not be exposed directly to the internet. It is a single-person research tool, not a cloud-gaming backend ready for production.
Related reading
- Open Source Is Not a License to Sell: World Models Audited
- Ant Robbyant's LingBot-World 2.0: two hard barriers
- Open Video Model LTX-2.5: Diffusion Decoder, 12GB VRAM Entry
FAQ
Q1: What exactly is Matrix-Game 4.0?
A1: A system open-sourced by SkyworkAI, under Kunlun Wanwei, on 2026-10-15. The game engine first renders a low-poly "proxy" frame, then a causal DiT video model performs streaming neural rendering to produce the final image. Gameplay, physics, and input stay with the engine, while the HUD and sound are frame-aligned layers outside the model. It ships with three scenes, Medieval Castle, Ancient Egypt, and City Racing, plus offline rendering, a browser demo, and a playable game.
Q2: What are the licenses for the code and the weights, and can they be used commercially?
A2: Read it in three layers, with the LICENSE originals as the authority. The root repository's LICENSE is MIT; the v4 directory's Matrix-Game-4/LICENSE is Apache-2.0; inside v4's bundled component directory, MG4CF keeps Apache-2.0 and TAEHV keeps MIT. Both allow commercial use, modification, and redistribution. The weights and assets, however, carry separate statements, and since the Hugging Face model card's license field could not be retrieved for this piece, this article names no license for them and defers to that card.
Q3: The official line says 480p 60 FPS, so why does the README say 38-39 FPS?
A3: Because the definitions differ and the numbers are not directly comparable. The official figures (a single RTX 5090, 480p, 60 FPS, latency under 150 ms, a steady-state 83 FPS, 18.5 GiB peak VRAM) are launch figures and were not independently reproduced. The README's roughly 38-39 FPS is model processing throughput on a single A100-SXM4-80GB at 864 x 480, and the README itself says this is neither browser presentation FPS nor end-to-end latency, while the Racing numbers come from an earlier checkpoint.
Q4: Can a consumer card run it, and what hardware is needed?
A4: Version 4.0 ships a dedicated RTX 5090 preset (--preset rtx5090, and --preset rtx5090-sage using SageAttention) that squeezes the pipeline onto a single consumer card with FP8 load-time weight quantization, fused kernels, and CUDA graphs. A version for the RTX 5080 and 5070 is slated for next week and is not out yet. The README's hardest reference numbers come from the A100-SXM4-80GB, so whether it runs on your card and at what frame rate needs your own testing.
Q5: How does this relate to the site's existing open-source comparison?
A5: This site published an open-source comparison on 2026-09-14 running the four accounts of license, hardware, data, and openness. This piece does not redo that account; it is a single-project teardown covering what the project is, why its architecture matters, the license, and how to read its performance figures. A companion SOP article covers install and run, so the two do not overlap.
Closing Thoughts
Handing the engine's low-poly skeleton to a video model to render matters not because "AI can draw," but because it drops a generative model into a deterministic, controllable loop: gameplay is guaranteed by conventional code, and the image is filled in by neural rendering. Three things stand out. First, the closed loop where a coding agent rewrites the engine and produces dynamic prompts. Second, the README's honesty in separating model throughput, pipeline throughput, and presentation frame rate as three senses of "real-time." Third, the license chain, read as four accounts: the root MIT, the v4 directory's Apache-2.0, the component licenses, and the Hugging Face weight statement. As for how real that official 480p 60 FPS is, the homepage panel still reads 0, and the surest way to find out is to run it yourself.