Dreamverse gives FastH3 a four-GPU chain. It does not give it a live-capacity result.

The documented chain

Project says: the opt-in fast-h3 profile loads MiniMax H3 plus FastVideo’s VSA data-free FastH3 Preview v1 adapter. Each request makes a 124-frame 768×1344 audio-video segment using five sigma-grid points. At 24 fps, that is about 5.2 seconds of media.

Project says: Dreamverse feeds a segment’s last frame into the following segment as first-frame conditioning. That is a real continuity mechanism to inspect. It is not proof that a character, camera, audio, or story survives the handoff cleanly.

The first wait comes before the first clip

The README says default torch.compile warm-up builds two segment paths before the backend is ready. On a cold cache, it can take tens of minutes; the stated readiness endpoint stays unavailable until that work finishes.

That creates a simple but easily hidden boundary: a running process is not a ready generator. Record boot-to-ready separately from a warm segment time. Do not price, schedule, or market an interactive loop from a health check.

What this does not settle

• It does not publish generated-segment time, ready-buffer margin, prompt-to-visible-change time, cost, retries, delivery behavior, or uptime.
• It does not prove that first-frame conditioning produces a viewer-safe transition.
• It uses FastH3 Preview v1, not FastH3 8-Step V2. The separate V2 first/last-frame conflict is still open.

The next honest record

Before treating this as a continuous-video route, capture the four GPUs, source revision, model and adapter, cold and warm readiness, accepted direction, segment-ready time, playable-media time, first visible frame, last-frame handoff, buffer, and visible fallback after one miss. A carried frame is useful evidence. It is not the result the viewer experiences.