---
title: "Latent volume: How video models hold time | Runware Docs"
url: https://runware.ai/docs/learn/latent-volume
description: How a video model holds time as another axis of what it denoises, and what that decides about every clip.
relatedDocuments:
  - https://runware.ai/docs/learn/latent-space
  - https://runware.ai/docs/learn/image-to-video
  - https://runware.ai/docs/learn/glossary
---
## Introduction

**A video model does not generate images one after another.** It works on a **latent volume**: frames, height and width held together as a single tensor, denoised all at once. Time is just another axis of the thing being shaped.

That one structural fact explains most of what looks like a list of unrelated rules in video generation.

## One tensor, not a sequence

An image model shapes a [latent](https://runware.ai/docs/learn/glossary#latent) of roughly 128 x 128. A video model shapes something closer to 128 x 128 x the number of frames, and **every [denoising](https://runware.ai/docs/learn/glossary#denoising) step operates on all of it**.

What ties the frames to each other is the **[temporal layer](https://runware.ai/docs/learn/glossary#temporal-layer)**: attention or convolution that runs along the time axis, so each frame is shaped with the others in view. An image architecture has no such layer, and adding one is the main structural difference between the two.

> [!NOTE]
> This is why consistency is free and motion is expensive. A subject stays itself across the clip because every frame is being generated from the same volume, not re-invented. What the model has to work at is making the change between frames plausible.

## Conditioning fixes a slice

**Supplying a first frame is not a separate mode.** The image is encoded with the same [VAE](https://runware.ai/docs/learn/vae) that handles stills, and the result is written into one slice of the volume, which is then held fixed while everything else is denoised around it.

That framing answers several questions at once:

- **Why the subject, framing and light carry forward.** They are not being copied frame to frame. They were never generated, because that slice was fixed from the start.
- **Why the output inherits the frame's shape.** The slice and the volume have to agree, so the supplied image sets the dimensions rather than the request. This is why many models reject `width` and `height` once a frame is present.
- **Why a first and a last frame is the same mechanism.** Two slices are fixed instead of one, and the denoising fills the span between them. Nothing new is switched on.
- **Why a last frame alone is sometimes refused.** It is a valid thing to ask for structurally, and some models accept it, but a model trained only to extend forward has no reason to support it.

## Why clips are short

The volume grows linearly with frame count, and **the attention that ties frames together grows faster than that**. A clip twice as long is more than twice the work, and beyond some length the model was never trained on the shape at all.

So duration limits are not a product decision layered on top. They are the size of tensor the architecture can hold and was trained to denoise.

**Chaining** follows from the same constraint. Taking the final frame of one clip and using it to fix the first slice of the next is how you exceed a limit that exists in the tensor rather than in the API. Each link inherits only what its opening slice carries, which is why a detail that left the frame does not come back.

## Where this stops being true

This is the account of video models built on [diffusion](https://runware.ai/docs/learn/glossary#diffusion), which is most of the ones you will meet. An [autoregressive](https://runware.ai/docs/learn/glossary#autoregressive) video model extends a sequence instead of denoising a volume, and the reasoning above does not describe it.

Video models on the platform are hosted endpoints that do not declare which they are, so treat this as the mechanism behind the behavior you can observe, not as a claim about any particular model's internals.