DreamForge-World 0.1 Preview

DreamForge is the two of us: 19-year-old students from Kazakhstan. We have been building DreamForge-World in our free time for about a year now, and the compute budget, roughly $2,000 so far, is covered mostly by a Minecraft performance mod one of us wrote years earlier. We never trained a foundation model, and we couldn't have. The question we set out to answer was narrower: how far can you get by taking open video research apart and putting it back together into something you can actually play? This page is the answer so far. What we reused, what we changed, and where the whole thing falls apart.

What 0.1 actually is

DF-World 0.1 is an action-conditioned visual predictor running in a closed autoregressive loop. The model sees its own generated history, takes your input, predicts the next state of the world, decodes it into frames, and feeds those frames back in as context for the next step. You can change direction at any moment, and the model has to keep up. Nothing in the scene is a mesh, a sprite, or a level. The world is the model's output.

From a prompt, an image, a video — or a mix of them — it gives you:

• Real-time keyboard-and-mouse control, first- or third-person view
• Mid-stream reprompting. Our favorite demo: a calm coastal rollout, one new sentence, and the model summons a tsunami
• Minute-scale continuous rollouts. The first minute is the best it ever looks, more on that below
• 14–15 FPS end-to-end at 480×832 on a single RTX 4090, fp8, in about 4 GB of VRAM

It is also not an engine. There is no physics system, no object list, no reliable 3D state inside. The model predicts the picture of a world, not the world itself. If there was a tree behind you ten seconds ago, there is no guarantee it is still there when you turn around. That is the central limitation of 0.1, and most of the "where it breaks" section follows from it.

Why you can't just loop a video generator

The obvious idea is to generate a few seconds of video, feed the last frame back in, and repeat. Everyone starts there, and the loop falls apart fast.

In ordinary video generation the model gets a clean context to work from. In an autoregressive loop it conditions on its own mistakes during inference: a small defect in one clip becomes part of the context for the next one. Errors compound. Textures smooth out, colors oversaturate, objects change shape, geometry quietly rearranges itself, and one fast camera swing can damage the entire rollout that follows. This is autoregressive drift, and dealing with it is most of what separates a world model from a video model.

There is also a second problem. A text-to-video model has no reason to know that pressing W means move forward. Connecting keystrokes and mouse movement to camera motion needs a dedicated action pathway, and training data where the video is synchronized with real input. That is not a fine-tune. It is a second system.

What we built on, and why the pieces fit

By the time we started, the field had already produced most of the parts:

• GameNGen and OASIS proved that a diffusion model could impersonate a running game, one specific game each.
• Genie 3 defines the frontier on quality and spatial consistency. It is closed, and out of our budget class by several orders of magnitude.
• Matrix-Game 2.0 was open, small, and had exactly the thing we were missing: a frame-level keyboard and mouse action module. But it dropped the text branch completely, so it is image-to-world only, no prompts.
• LongLive was the mirror opposite: a strong causal streaming video stack with KV-cache rollout and live reprompting, and no game control at all.

The key observation behind 0.1: LongLive and Matrix-Game 2.0 are built on the same base model, Wan2.1-T2V-1.3B. That shared base made the composition approach possible. We took LongLive as the video backbone and transplanted the Matrix-Game action module on top of it. The transplant didn't work out of the box: it took a repair fine-tune, two view-specific LoRAs, and several rounds of tuning in between to get stable. But it meant our budget went into adaptation, not into re-teaching a model what worlds look like. DF-World 0.1 is not a foundation model we trained; it's a composition, tuned into place.

How the runtime fits together

Everything above assembles into a runtime with three connected streams: world state, control, and generation.

Text promptswitchable mid-stream

a quiet winter cabin in the woods at night, falling snow

Send →

Image / video seedencoded by Wan VAE

Send →

Keyboard + mouseaction module · FPV / TPV checkpoint

W

A S D

move · click · press

live input — this is what drives the model

↓ text conditioning + visual prefix merge into the history

Latent history + KV cache text conditioning + visual prefix land here

↓ visual context · steering enters the DiT directly

LongLive / Wan 2.1 DiT causal autoregressive rollout · short-window attention · frame sink · KV recache

↓

New latent frames

VAE decoderWan 2.1 / LightTAEW

Interactive frames

streamed output — generated frame by frame

↓ generated frames become the new history — the loop that drifts

A schematic of the 0.1 runtime, and it is live: send the prompt and the seed and watch the signal travel. Text conditioning and the visual prefix merge into the latent history. The action module steers the DiT directly and never touches the history. And whatever the model generates becomes the context for its next step, which is exactly where the interesting failures below come from.

The build, in three stages

Stage 1 — bend the video prior toward games

Out of the box, LongLive is heavily biased toward cinematic stock footage. So before any control work we trained a rank-64 LoRA on the backbone. LoRA — low-rank adaptation — adjusts the model's behavior by training a tiny fraction of its total parameters instead of fine-tuning all of them, and here it served one purpose: to move the model toward interactive scenes, first- and third-person gameplay, open locations, camera movement, game-style characters. The training mix came from the NitroGen and GameGen-X datasets plus a smaller set we collected and filtered by hand; the camera regime was selected by prompt tokens. This stage teaches nothing about control. It exists so that the next stage doesn't have to learn game visuals and input response at the same time.

Stage 2 — transplant the action module, then split the views

Next we transplanted Matrix-Game 2.0's action-conditioning weights onto the LongLive DiT. This only works because both models share the Wan 2.1 base. A short fine-tune afterwards repaired the weight mismatches and brought the control path back to a stable state. On top of the transplanted module we trained two high-rank LoRAs, one per camera regime, with an MSE objective plus trajectory and pose losses (Depth Anything 3 generated the pose supervision for our data). The LoRAs were fused into two separate checkpoints, and the runtime swaps them in before generation starts. The paper names the failure this avoids: perspective drift between the two regimes.

The split is the one decision here worth stealing. In first person, pressing W moves the camera. In third person, the same key has to move a character, play the right animation, shift the parallax, and sometimes re-frame an external camera. A small controller trained on both mappings learns neither properly. Two controllers, one job each, were cheaper and more stable.

The control data we collected ourselves: five-second clips at 24 FPS with continuous mouse motion and labeled keys. Movement, jump, sprint, crouch, interact, plus two spare action channels. We recorded it by hand because public datasets have very little synchronized control video, and almost nothing in third person.

Stage 3 — let images and video in

LongLive is a text-to-video system, so it had no interface for starting from your own image or clip. Instead of bolting on a separate image-to-video model, we used the runtime's own history. An image or a video segment is encoded through the Wan VAE and inserted into the KV cache as if the model had generated that history itself, and the rollout continues from there under your control. One runtime, four ways in: text, image, video, or a mix. Reprompting mid-stream came for free from LongLive.

Making it real-time: where the FPS actually goes

A fast transformer by itself is not an interactive system. The DiT is one link in a chain that also has action conditioning, KV-cache management, VAE decoding, frame streaming, input handling and display sync. If you generate latents quickly and then stall on a heavy decoder, the user still ends up with a slow world. That is why we measure the whole path rather than the transformer in isolation, and why our numbers are lower than the headline numbers other projects report.

On the runtime side we added asynchronous streaming of generation and decoding, KV-cache quantization, fp8 execution, Deep Forcing-style training-free cache management against long-session drift, and an optional lightweight decoder, LightTAEW 2.1, which trades some decode quality for latency and memory.

End-to-end preview throughput at 480×832: diffusion transformer execution, action conditioning, VAE decoding, and streaming overhead — the frame rate observed through the runtime, not isolated transformer-only throughput. The quantized build also runs on RTX 2060-class laptop GPUs.

To be honest about what this means: 14–15 FPS is enough to control the world, and not enough to be comfortable. There is visible latency between a keypress and the world's reaction, worst on sharp turns. Rollouts do run past a minute, but the first minute is when the model looks its best. After that, drift takes its toll.

Where it breaks

We think the most useful part of this page is the section you are reading now. These are the ways 0.1 breaks, ordered by how much each one limits the system.

1. No persistent memory — the structural limit

The model keeps local visual context and nothing that resembles a map. Look at a place, walk away, come back, and you will often find a new, plausible version of it waiting, not the one you left.

A longer attention window probably doesn't fix this. It needs a real memory mechanism: retrieval, external state, or training that specifically rewards remembering. This is the main architectural goal for 0.5.

2. Autoregressive drift

Every frame is conditioned on imperfect earlier frames. Over a few minutes the fine texture washes out, colors oversaturate, objects slowly change shape, and character identity degrades. Training the model to resist drift helps somewhat: color balance sometimes comes back. Lost detail never does.

3. Fast camera motion

Smooth movement works well, fast rotation doesn't. A quick camera swing forces the model to update the camera direction, invent the area that was never on screen, keep the existing geometry in place, and stay consistent with its history, all at once, with no persistent state to settle the conflicts. The scene destabilizes.

4. Third person is harder than first

In first person, most of the motion is the camera. Third person adds a whole character body: pose, animation, occlusion, parallax, and a background that has to stay coherent around both of them. Our third-person checkpoint works, but it is visibly more fragile than the first-person one.

5. It isn't a simulator

Your actions influence the world but don't command it. There is no exact physics, no deterministic interaction, no sound, and no persistent objects you could build with. 0.1 is a visual world predictor, and with the weights staying closed, this page and the technical report are the only sources of truth on what it can and can't do.

Why $2,000 was enough

Here is where the $2,000 actually went. It didn't buy a world model. It paid for an adaptation trajectory built on top of free, open infrastructure:

• We didn't retrain visual world knowledge. Wan already knew what scenes look like and how they move.
• We didn't build a streaming video stack. LongLive had already solved causal long-form rollout and reprompting.
• We didn't train control from scratch. Matrix-Game's action module transferred because the base models matched, and a short repair fine-tune made it hold.
• We used LoRAs everywhere a full fine-tune would have been overkill.
• We split FPV and TPV instead of forcing one controller to be mediocre at both.
• We optimized the whole runtime, not just the DiT.
• We accepted the preview's limits instead of burning the budget fighting them.

Most frontier world models report tens of thousands of hours of training video. The full adaptation set for 0.1 was 64 hours of curated video. Matrix-Game 2.0 reports roughly 1,200 hours. Genie reported 30,000.

Reported training-video scale for systems with public hour-level training reports. Bars show raw hours and scale relative to DF-World's 64-hour curated adaptation set. The visual scale is softly compressed above 1,000 hours while preserving ordering and separation. Matrix-Game 2.0 reports about 1,200 hours of interaction-annotated data; Genie reports a 30,000-hour filtered platformer training set.

The chart is not there to show how clever 64 hours is. It shows the real shape of this project. 0.1 does not compete with frontier systems on their axis; it shows that the axis exists, and that broad interactive capability on one consumer GPU now has a low entry price. To be just as clear about what $2,000 does not buy: persistent memory, exact physics, or Genie-3-class fidelity. Those aren't features we postponed. They are a different weight class.

Where 0.1 sits

Functional coverage compared to publicly discussed interactive world models. A checkmark means the feature is reported as supported and says nothing about quality, scale, or benchmark protocol. This is not a leaderboard, and on visual quality and memory, 0.1 sits behind the systems in this table. What it does have is an unusually wide feature set for its class (text, image and video entry, reprompting, dual view, real-time on one consumer GPU) at a fraction of the adaptation cost.

DF-World 0.1 column highlights DreamForge-World 0.1 Preview against publicly discussed interactive world model projects. Checkmarks reflect reported support from public system descriptions and do not imply equal quality, scale, or benchmark protocol.

One contrast is worth keeping. "AI game builder" products assemble playable things from pre-made assets. DF-World generates the world itself. It is a different category, and an earlier point on the maturity curve, but the generative direction is the one we think wins long term.

What a year of this taught us

The most important result of 0.1 is not the FPS number. It is that the real-time loop is no longer the hard part. Once interaction works, the frontier moves to state: where objects are, what the user has already seen, what has to survive a camera turn, how to return to a place without rewriting it. Persistent state is what separates today's interactive video generators from real neural world engines, and it is where 0.5 is going.

What's next: 0.5

In progress: a larger base video model, audiovisual generation, 720p, more stable dual-view control, and the main event, persistent spatial memory. On memory we are currently exploring latent memory retrieval, camera-aware memory, loop-closure training, and hybrid external scene state.

On release: 0.1 will not be released, the preview checkpoint stays closed. The GitHub repo documents the architecture and the reproduction recipe. For 0.5 we plan to open the weights and code once licensing, safety, and engineering constraints allow. That is the honest current state of the plan.

@article{ayupov2026dreamforgeworld01,
  title={DreamForge-World 0.1 Preview: A Low-Compute Real-Time Controllable World Model},
  author={Ayupov, Daniyel and Markov-Tsoy, Artur},
  journal={arXiv preprint arXiv:2606.30292},
  year={2026}
}