Introduction

EdenLive is open. VAST, the team behind Tripo, has published the code and weights for EdenLive, a real-time generative renderer for playable worlds. You feed it a greybox game recording (or a live game stream), a styled first frame and a text prompt, and it repaints every frame into detailed video while keeping the game's layout, camera motion and timing. The GitHub repo is Apache 2.0, the 5B and 14B weights are on Hugging Face, and you can run it today on your own GPU server. As of October 18, the code, both model sizes and a prompt-to-game workbench are all in the public repo.

The idea behind it is a clean split. A normal program (a game engine, or a coding agent writing Three.js) owns the rules and the world state. EdenLive only handles how it looks. That's a different bet from world models that try to learn the physics and the visuals together.

What shipped

  • Name and vendor: EdenLive, from VAST (Tripo / Project Eden)
  • Modality: video-to-video generative rendering. The inputs are a proxy video, a first frame and a text prompt (a static prompt plus optional timestamped prompts). The output is a rendered video stream
  • Open vs API: open. The code is Apache 2.0, and the DiT, VAE, UMT5 text encoder, scheduler and decoder weights are Apache 2.0 too. The DINOv3-based vision encoder uses the DINOv3 License, and the FLUX first-frame worker is non-commercial (see Caveats)
  • Where to run it today: self-hosted. hf download VAST-AI/EdenLive pulls about 210 GB of weights, and the repo has offline inference scripts plus a WebRTC real-time service
  • Models: a 14B model built on Wan2.1-I2V at 480p and a 5B model built on Wan2.2-TI2V at 720p. Each comes in a bidirectional version (all frames denoised together) and a few-step chunk-autoregressive version (4 steps per chunk) for streaming
  • Speed claims: VAST reports over 24 FPS, minute-scale generation and 480p/720p output. The README says the 5B model reaches about 24.7 FPS at 1280×704 on a single RTX 5090 using LightX2V acceleration
  • Extras: a game-prototype-turbo agent skill that turns a text prompt into a rough playable Three.js game, four sample games (including Ember Den, a first-person axe-vs-spiders cave fight), two sample proxy recordings, and a browser workbench that runs the whole prompt-to-game-to-render loop

How it works

  1. Upstream program: an engine or agent-built game runs the mechanics and renders a plain greybox view. The repo's samples are 1280×704 proxy recordings
  2. Control signal: a post-trained DINOv3 vision encoder embeds each proxy frame, and those features condition the diffusion transformer
  3. Look and style: a target first frame plus a text prompt sets the appearance. In the workbench, that first frame comes from FLUX.2 [klein] 9B with a VAST LoRA
  4. Rendering: the few-step model renders chunks one after another and streams them to the browser over WebRTC (built on NVIDIA FlashDreams), with a fast TAEHV decoder for the real-time path

Try it

The offline quick start runs on the samples that ship with the repo:

git clone https://github.com/VAST-AI-Research/EdenLive.git && cd EdenLive
hf download VAST-AI/EdenLive --local-dir ./models/EdenLive

# 5B, 720p, few-step (chunk-autoregressive)
python -m edenlive.scripts.infer \
  --config edenlive/configs/wan22_5b_720p_few_step.yaml

For the live service, set your TURN relay and weight paths in realtime/deploy.conf, then run bash turn_server.sh followed by bash start.sh 5b (or 14b) on the GPU host. The full workbench is served at port 8089.

Prompts to start with

The bundled games show the prompt style EdenLive expects: a literal scene description that pins down camera, props, creature count and what must stay the same. This is the Ember Den prompt from the repo's game registry:

First-person axe combat in a basalt cavern with faceted rock walls, stalactites, glowing teal crystals and amber braziers. Exactly three large brown eight-legged spiders crawl toward the camera. A steel axe on a long wooden handle stays in the lower right foreground without hands or arms. Axe swings leave a pale slash trail, strike sparks and green ichor; spiders rear up before biting; defeated spiders curl up on the ground. Keep the cave layout and spider identities. No extra creatures, text or HUD.

Pro Tip

Write prompts the way the samples do. Give exact counts ("exactly three spiders"), say what stays fixed ("keep the cave layout"), and list what to exclude ("no text or HUD"). The proxy already handles motion, so the prompt's job is to lock down identity and materials. Use the timestamped dynamicPrompts in prompts.json for in-game events instead of packing everything into one long prompt.

Why game teams should care

  • Greybox in, final look out: you can prototype mechanics with placeholder geometry and judge the feel with near-final visuals, without making any art first
  • Logic stays deterministic: game state lives in real code, not in a model's memory, so collisions, scores and win/lose states don't drift the way they can in end-to-end world models
  • Open and inspectable: unlike hosted world-model demos, you get the weights, configs and the streaming stack, with an Apache 2.0 core you can build on

Caveats

  • Big hardware: the verified setup is Linux with NVIDIA GPUs that have 80 GB of VRAM (for example an H100), CUDA 13 and Python 3.10. The default 5B bidirectional profile needs SM90 and FlashAttention 4. The single RTX 5090 path goes through LightX2V. Its deployment guide link in the README returned a 404 when we checked, so expect some setup work
  • Workbench is non-commercial: its first-frame renderer uses FLUX.2 [klein] 9B under the FLUX Non-Commercial License, which also requires content filtering. Playing registered games with start.sh doesn't load FLUX
  • Agent dependency: the workbench's game builder needs the claude CLI on the bridge host and runs with --dangerously-skip-permissions, so keep it in a sandbox
  • Scope: game-prototype-turbo is limited to bounded 3D browser prototypes with clear win and loss states. It isn't meant for 2D-only, audio-led or open-ended games
  • No hosted demo yet: there's no API or one-click Space. The project page is the only place to see results without a GPU

Original Source

https://github.com/VAST-AI-Research/EdenLive

https://huggingface.co/VAST-AI/EdenLive

https://vast-eden.ai/?p=edenlive

Conclusion

EdenLive is the clearest open take yet on "let the engine run the game, let the model paint it." If you have an 80 GB card, or the patience to get the RTX 5090 path working, you can stream your own greybox prototypes into a detailed render today. You'll be wiring it up yourself, but it's all open: weights, streaming service and a prompt-to-game agent skill.

—Titus