A renderer, not a world model

Most systems sold as world models try to do two jobs at once: keep track of what exists and what happened, and draw the next frame. EdenLive splits the jobs. The world state lives upstream, in a game engine or an agent that already knows the rules, the layout and the camera path. That program emits a plain reference video — greybox geometry is enough. EdenLive's model then re-renders the stream, taking its look from a target first frame and a text prompt. It is not the game engine, and it is not a world simulator.

That split is why the real-time claim is plausible at all. The model never has to remember that a door was opened three rooms ago, because the engine remembers. It also defines the limits honestly: EdenLive cannot fix a broken simulation, and a reference feed with the wrong camera move produces a beautifully rendered wrong camera move. What it offers instead of a simulated world is a neural finishing layer for worlds that already work — restyling a prototype, giving a coding agent's rough game a finished surface, or turning human footage into robot-view training data, one of the uses VAST lists in the README itself.

Where the 24 fps number comes from

The headline figure survives contact with the documentation, but it shrinks. The project page demonstrates over 24 fps at up to 720p, and the README's measured number is specific: the 5B model, run through the LightX2V acceleration stack — low-bit quantization, fused kernels, torch.compile, CUDA Graphs and a streaming decoder — reaches about 24.7 fps at 1280×704 on a single RTX 5090. That is a real result on a card a person can buy, and it is also the top of the consumer range, a card that costs more than most gaming PCs. The repo offers no measured figure for a 4090, let alone anything mid-range, and the 24.7 fps belongs to the 5B model on this accelerated path; the README reports nothing measured for the 14B model or the other variants.

Then the documentation pulls in two directions at once. The installation table's verified environment is Linux on NVIDIA GPUs with 80 GB of memory — datacentre territory — with a CUDA 13 driver, Python 3.10 and a PyTorch nightly/cu130 stack, and the default 5B bidirectional profile, as documented, wants SM90 hardware, BF16 and a beta flash-attention 4 build. An RTX 5090 has 32 GB of memory. The README, as published, does not reconcile the two claims: it does not establish that the default configuration runs on the 5090, and it does not say the LightX2V benchmark path needs an 80 GB card either. Those are different documented claims on different execution paths, and the gap between them is unresolved. That gap matters more than the card's price, because it is the difference between a setup a reader can reproduce and one they cannot yet plan.

The weights download is about 210 GB, and that figure needs its own scope. It is the combined footprint of everything in the single Hugging Face tree: both DiT sizes, the Wan2.1 and Wan2.2 VAEs, the real-time decoders, the text encoder, the CLIP and vision encoders and the first-frame component. It is not what any one configuration loads, and it is not a runtime VRAM requirement; the README gives no complete per-profile breakdown of what a given setup actually downloads or holds in memory.

The licence is mostly clean, with one labelled exception

For an open release in this field, the licensing is unusually straightforward — and VAST's own table is where the exception is stated plainly. The code is Apache 2.0, and so are the main model weights: both DiT sizes, the VAEs, the text encoder and the real-time decoders. Compare that with the territorial exclusions that came with MiniMax's H3 weights, and EdenLive is the easier release to build on. This summary follows the repository's own licence table; it is not a legal determination for any particular downstream use.

The exception is the showcase. The workbench — the chat that builds a playable game from a prompt and plays it in the browser — renders its first frames with FLUX.2 [klein] 9B, which ships under Black Forest Labs' FLUX Non-Commercial License. VAST states the consequence directly: the documented workbench is for non-commercial use only, and the licence requires content filtering on generated images. Running the model service on games that already exist does not load FLUX, so that path is not the restricted one. But a commercial product built on the documented workbench configuration inherits that component's restriction, and the other components carry separate terms of their own — the vision encoder under Meta's DINOv3 licence, the CLIP component under MIT. Anyone planning to ship should assess each component in the pipeline they actually use, not just the renderer's Apache 2.0 headline.

What to do with it

If you have a 5090 and a greybox game or simulation that looks rough, EdenLive is worth investigating: the two sample projects ship with the repo, and the 5B model on the LightX2V path is the configuration the benchmark documents — with the caveat above that the README does not yet show how its verified 80 GB installation environment and its 5090 benchmark fit together, so expect to resolve that gap yourself before committing to a setup. If you have an 80 GB card, the verified environment is written for you. Budget the setup time honestly — a 210 GB combined download, a pinned nightly-adjacent PyTorch stack, a TURN relay for the streaming service. One operational warning, scoped to where it belongs: the workbench's game-generation bridge runs its coding agent with permission checks skipped (--dangerously-skip-permissions, per the README). That workflow belongs on a machine isolated from sensitive credentials and production environments. Running the rendering service for games that already exist does not invoke that bridge. If your hardware is a generation older, the useful move is to watch the LightX2V numbers rather than the launch claims. Our judgment: real-time generative rendering is arriving from the top of the GPU stack downward, and EdenLive's documented 5090 result is a credible marker of where the line currently sits.

Sources

  1. [1] VAST-AI-Research, EdenLive GitHub repository and README (primary source: overview, open-sourced components, installation table, weights manifest and ~210 GB total, LightX2V RTX 5090 measurement of ~24.7 fps at 1280×704, workbench services and FLUX note, licence table)Read source
  2. [2] VAST-AI, EdenLive project page (24 fps+, minute-scale generation, 480p/720p output claims)Read source
  3. [3] VAST-AI, EdenLive model weights on Hugging Face (the single VAST-AI/EdenLive download tree itemised in the README)Read source
  4. [4] SiliconNoon, "Today in AI — October 19, 2026" (secondary roundup noting the open-source release and the one-consumer-GPU framing)Read source