Change the Prompt Mid-Shot With Evoke, and Watch the One Number That Says When It Stopped Remembering

A three-step open world model repaints the sky halfway through a take without cutting. The reason it can, and the log column that tells you when it has given up without saying so, are the same piece of engineering.

Halfway through a shot of a frozen tundra under flat polar daylight, an aurora ignites across the entire sky. There is no cut. The ground does not move, the horizon does not jump, the light on the snow changes because the sky changed. Four of these ship as bundled demos in Alaya Lab's Evoke: tundra to aurora, a still mountain lake to a meteor shower, a valley of crystal spires to an electrical storm arcing between them, a dormant ring megastructure to a gateway igniting.

Every video model can generate a tundra. Very few can be told, at second four of an eight-second take, to change the weather over the tundra it already made and have it still be the same tundra. The reason Evoke can is that the tundra is not stored in the model.

That architectural choice is what makes the trick work. It is also, and almost nobody writes this part down, what creates the specific way this model fails. The good news is that the repository prints a number every 1.5 seconds that tells you exactly when the failure is happening, in a log most people will never open.

What is actually running

Evoke is a three-step, guidance-free world model producing 384 by 640 at 24 fps. One chunk is 36 pixel frames, so 1.5 seconds, and the repository quotes 1.5 seconds of video generated every 2.11 seconds on a single H200. Set NUM_CHUNKS=20 and you get a thirty-second clip. The weights are Apache-2.0, GitHub star count sits at 466, and a controllability-tuned variant called Evoke-Turbo landed September 11 at 13:32 UTC: 14.3 billion parameters stored in FP32, about 57 GB of safetensors.

Three steps and no classifier-free guidance are not settings. They are properties of the distilled weights, and the launcher will warn you if you try to raise NUM_INFERENCE_STEPS, because raising it does nothing.

Turbo's benchmark story is worth reading carefully, and I will give the lab credit for making that possible. It reports a WBench average of 82.0003 against base Evoke's 80.8210, gained by winning Navigation, Consistency and Physical while losing Video Quality (81.8914 against 82.7900) and Setting (82.0518 against 83.7600). Then the model card adds the sentence that most labs would leave out: Turbo's row uses "seed-44 results selected from six prompt variants," while the Evoke row uses published reference scores measured with different prompts and poses. The two rows were not produced the same way. That caveat is on the Hugging Face card and not in the GitHub README, which still leads with "state of the art on WBench."

So: Turbo follows direction better and looks slightly worse doing it, and the size of the gain is softer than the number implies. Take it anyway if steering is what you came for.

The mechanism: the scene lives outside the denoiser

Normal video models hold recent history in the denoiser's context window. Push the clip long enough and you are trading session length against memory, and the model forgets where it was.

Evoke puts the geometry somewhere else. Each chunk it emits gets run through a monocular depth model under its known camera poses, and the result is unprojected into a persistent point cloud. That cloud is the world state bank, and it has three operations. Write adds each new chunk's depth. Read takes the current camera pose, ranks sources by co-visibility, fuses up to eight of them, and does a batched z-buffered scatter that returns a warped image plus a per-pixel visibility mask. Evict is an optional retention window that only long runs turn on.

That warped image gets laid into the chunk's attention layout as its own tier. The full arrangement, from the repository, is prefix | long(16) | mid(2) | warp(W) | prev_short(1) | noise(W), with prefix as the frame-zero anchor, long and mid as coarsely patched parametric memory, and prev_short as the last latent of the previous chunk. Every tier sits at the same latent resolution; the compression comes from the patchify kernel, not from storing anything smaller.

The payoff is that the denoiser's context stays bounded no matter how long you run, because it only ever sees what the current view needs. And the payoff for a director is the thing in the demos: because the place is held outside the model, changing the prompt does not change the place. Per-chunk conditioning swaps the description, the world state bank supplies the same geometry, and the model repaints rather than reinvents.

The failure this creates, and the column that catches it

Every architecture buys a capability with a failure mode. Evoke's is that if the camera moves somewhere the bank has no points for, the warp comes back mostly holes, and the model fills those holes from the prompt. The scene it hands you at that moment is not the scene you established. It is a new one that happens to start where the old one stopped.

The repository prints this. A single-GPU run streams a line per chunk:

  chunk   3/20   warp   1.17s (pool=  72 cov=0.877)  |  diffusion   2.05s (3 steps)  |  decode+dump   5.78s  |  total   9.01s

cov is warp coverage and pool is the number of source frames fused. The inference docs give the threshold outright: below roughly 0.35, "the model is filling holes from the prompt." Two numbers worth watching over a long rollout, and coverage is the one that decides whether your shot is continuous.

Then comes the part that made me stop and reread it. The docs also say that optical flow will not catch this, "because a mid-clip reset leaves the tail/body flow ratio near 1.0." The tool a video person would reach for to detect a discontinuity reports normal, because the reinvented scene moves at a perfectly plausible rate. It just is not the same place.

There is a second, sharper version of the same trap in the image-to-video path. Two calibration knobs control how far the camera is allowed to travel: GEO_CHUNK0_TARGET_DISP_PX, defaulting to 135 pixels, and VIGEO_DEPTH_MEDIAN_TARGET, defaulting to 5. That second default used to be 1.0, the bare unit definition. At 1.0, the docs report, a specific five-second sekai track commands about 1.8 scene-depths of motion per chunk, so the camera walks out of the geometry, the warp collapses, and the model rebuilds the scene from the prompt. What you see, in the maintainers' own words, "reads as a sudden acceleration even though the commanded motion is flat or falling."

Sit with that. The artifact you perceive is a speed change. The thing that happened is a memory failure. If you were tuning by eye you would reach for the camera path, slow it down, and make the problem worse by chasing a symptom that is not the cause. The only honest signal is the coverage number.

Both defaults are now calibrated, so image-to-video needs no flags. The choice between 5 and 10 for world scale is described as a look call: 10 is what video-to-video measures for the same quantity (about 9.9) and is safer on worst-case coverage, while 5 keeps twice the parallax.

Put this into practice

Run the prompt switch first. From a cloned repository with weights and the depth backend in place:

MODE=segment NUM_CHUNKS=6 MAX_CASES=0 bash scripts/inference/infer_post_distill.sh

Six chunks gives 213 frames, roughly 8.9 seconds, with the prompt switching at chunk 3. Four bundled cases run with no external data. The result lands at <OUT_ROOT>/<case>/geo_pred.mp4, per-chunk pieces at segments/segment_NNN_pred.mp4, and the settings that produced it at run_info.json.

Then open the log and read the coverage column. It is at <OUT_ROOT>/_logs/<case>.log. Scan the cov= values across chunks. If any of them dip toward 0.35, the shot broke there, and the fix is a shorter camera move or a different world scale, not a different prompt. Resolved calibration values also print as chunk0_target_disparity_px and chunk0 disparity rescale: k=, so you can see what the model decided before you argue with it.

Use NUM_CHUNKS, never NUM_FRAMES. This one will bite you. NUM_FRAMES is the older knob and it is not an output length. It picks a chunk count with ceil(NUM_FRAMES / 33) and nothing trims the result back, so NUM_FRAMES=721 yields 22 chunks, 789 frames, 32.9 seconds. You asked for thirty. NUM_CHUNKS sets the frame count exactly.

If you want a UI instead of shell scripts, there is one. The Director UI shipped August 30 and runs with python ui/app.py on port 7860. It gives you 1 to 40 chunks, a required prompt per chunk emitted as Evoke's native schedule, two game-style camera pads (movement handles forward, back and strafe; look handles yaw and pitch independently), per-chunk MP4 previews as each segment is written, and non-destructive branching where you pick a completed chunk and regenerate it plus everything after, keeping the chunks before it. Revisions stack as r0001, r0002 and never overwrite a parent. The first start preloads the pipeline and the depth weights before it says READY, which the docs warn can take several minutes, and it deliberately does that so your first chunk is not paying for a 4.8 GB lazy load. The movement pad is described honestly as "a top-down director-friendly abstraction rather than a SLAM solver."

Bring your own footage by copying examples/. Each mode has one working case. Poses are vipe .npz files carrying cam_c2w [T,4,4] and intrinsics, and you declare pose_fps and pose_source_resolution per row when they differ from the image-to-video defaults of 24 fps and 480 by 832. Get that wrong and you will not be told: a 30 fps track declared as 24 "renders 25 % long and 25 % slow, and nothing detects it."

For video-to-video, REF_VIDEO_SEC defaults to five seconds and generation continues after that window, so the default run conditions on the first five seconds and invents from there. START_SECONDS shifts where the window is taken from, and it also shifts the pose track, which is why it applies to image-to-video too.

Where this breaks

The hardware bar is high and the environment is fussy. You need Python 3.10, CUDA 12.4, torch 2.4, deepspeed 0.14.5 and flash-attn, and the repository says those pins are "load-bearing, not aspirational." Two things pip will not do for you: diffusers is pinned to a development fork that is not on PyPI, so nothing imports until you install it by hand, and the visualization step needs the ffmpeg binary on PATH. Turbo alone is about 57 GB before you add base components and depth weights.

The license does not survive the quickstart. Evoke's weights are Apache-2.0, and every shipped recipe requires pkqbajng/ViGeo as the depth backend, which is CC-BY-NC-4.0. The optional Depth-Anything-3 alternative is the same. The repository says so plainly and tells you to check before commercial use. The practical reading: the documented pipeline is not commercially licensed, and swapping depth backends is described as a recipe change rather than a speed knob, since training and inference have to agree on it.

The distilled models are running outside their training distribution on two of three modes. Both were trained on video-to-video conditioning only, so MODE=i2v and MODE=t2v are zero-shot on them. The launchers announce this at startup. Only stage1_camera_control, the undistilled 50-step model, has all three modes in distribution.

There is no working hosted demo. The community Space at hugging-apps/evoke is asleep and points at a different repository id than the release. If you cannot run this locally, you cannot try it.

Long runs need an explicit opt-in and a real decision. Without streaming, the pipeline accumulates the whole clip as one fp32 GPU tensor at about 2.95 MB per frame, so the driver refuses more than 7,200 frames. STREAM_LONG=1 decodes per chunk and produces identical pixels with different side outputs. GEO_HIST_MAX_FRAMES slides the point cloud to keep only the last N frames and is required beyond about ten minutes, and the docs flag that it "changes what the warp sees, i.e. it is a recipe change and not just a memory knob." You are altering what the model can remember, not how much RAM it uses.

One smaller trap worth knowing: text-to-video drops frame 0 from the final video, because with no prior frame to warm the causal VAE cache, that first pixel carries a colour cast the rest of the clip does not. The frame still exists in segments/segment_000_pred.mp4, so stitching the segments yourself is not the same as the final render.

What to take from this

The capability here is a genuinely new shape for a shot. Weather, light and events changing inside one continuous take, without a cut, is a thing a director had to buy with a second setup or a compositing pass. Evoke does it because it holds the place outside the model, and that is the interesting engineering.

But the part I would actually carry into other tools is the coverage number. A generative video system that reports, per chunk, how much of the current frame it is reconstructing from memory versus imagining fresh, is telling you something no output metric can. FID will not know. Optical flow, in this specific failure, actively lies. The model itself knows, and Evoke prints it.

Almost no video model exposes anything like that. When you evaluate the next one, ask what it reports about its own uncertainty, and treat a project that tells you where it is guessing as more trustworthy than one that only shows you a benchmark average.

If you have the card for it, the sixty seconds worth running first is the segment demo, then the log. Watch the aurora ignite over ground that stays where you left it. Then find the chunk where coverage dropped, and go look at what the model did with the hole.

---

Medium metadata

• Title: Change the Prompt Mid-Shot With Evoke, and Watch the One Number That Says When It Stopped Remembering
• Subtitle: A three-step open world model repaints the sky halfway through a take without cutting. The reason it can, and the log column that tells you when it has given up without saying so, are the same piece of engineering.
• Tags: AI Video, Generative AI, Open Source, Filmmaking, Machine Learning
• Suggested reading time: 10 minutes
• Canonical subject: Alaya-EVOKE and Evoke-Turbo (arXiv:2608.13546), Apache-2.0 weights, September 2026